Questions people actually ask

That was the design constraint, not an afterthought. Your operator does the same five steps every morning and is comfortable inside a week. Drivers get a phone app with today's stops in order, one tap to navigate and one tap to confirm, in English, Hindi or Telugu — there is nothing to learn and no new hardware to buy. The parts people get wrong all have a visible undo, so a mistake costs a click, not a phone call to us.

No. RouteSync sits after your order system, not in front of it. You keep taking orders exactly as you do now and export the day's file as usual; we read that file as-is. Nothing writes back into your ERP, and it stays the source of truth for anything commercial.

The honest answer is that it depends on how much slack is in your current plan, which is exactly what nobody can see today. The two levers are vehicle fill and trips per day — if your vans routinely go out well under capacity, that is where the money is. We would rather run one of your real days through the planner and show you the difference on your own numbers than quote you a percentage.

It depends on the number of distributors and whether you host it or we do. Ask on WhatsApp or on the walkthrough call — we would rather quote against your actual shape than publish a number that fits nobody.

Four steps: create the distributor with its warehouse coordinates, add the operator, add the vehicles with their rated weights, add the drivers. Then import the retailer master and the first order file. A distributor with clean master data can plan its first day the same afternoon. Where it takes longer, it is almost always because retailer GPS pins are missing — and that is worth fixing regardless of whether you use us.

A daily sales order export as CSV — order number, order date, customer code, SKU code and name, quantities, unit of measure and value. That is it. We map to your export rather than asking you to change it, and we do not integrate directly with the ERP. Nothing writes back; your ERP stays the source of commercial truth.

No. New product codes, pack configurations and per-case weights are learned from every order import. There is a screen showing which entries are still missing a weight, and you can download just those, fill them in Excel and upload them back. Any correction you make by hand is preserved — later imports never overwrite it.

They are excluded from auto-routing and listed with the reason, so nothing disappears silently — you can still plan them manually. Drivers and field salesmen can capture a correct pin from the shop itself, with a photo and an accuracy reading, and an operator approves it into the master with one click.

No. The auto-route plan is a proposal — you see it on a map, move retailers between trips, reorder stops, drop something entirely, and only then save it. The manual beat-wise builder is still there in full if you prefer to plan by hand on a given day.

Not at all. Beats survive as a tag on the retailer, and they still appear throughout your reports. What changes is that they stop being the planning constraint. Same-beat retailers get a cohesion nudge so they tend to travel together, but the planner will not send a van across town purely to honour a beat.

It sums the base-unit quantity from the sales file for every line measured in kilograms. Nobody types a weight anywhere. That total is frozen onto the order and is exactly what the planner uses. The one thing worth checking is whether your liquid items are exported in litres rather than kilograms — if so they weigh nothing as far as the planner is concerned, and we would flag that before you go live.

Not by the planner. Trips are capped at a fill target you set — typically well under the vehicle's rated weight — as a deliberate margin against last-minute additions and weighbridge surprises. The cap is not overridable from the planning screen.

Auto-route plans one trip per vehicle per day. A second run after lunch is created as a separate plan against whatever is still in the ready pool. Multi-trip rotation inside a single plan is on the roadmap, not in the current version.

No. The driver app is a web app that installs to the home screen with its own icon. There is nothing to publish, nothing to update, and nothing for a driver to reinstall after a phone reset. It works on ordinary Android phones.

English, Hindi or Telugu, chosen by the driver. Everything stored in the database stays in English, so reports and audits read identically no matter what language was on the screen. Adding another language is a translation file, not a code change.

No — and that is deliberate. Location is captured at meaningful moments: trip start, stop arrival, and delivery confirmation. We did not build driver-monitoring dashboards. The design goal was accurate delivery records, not surveillance.

The driver closes the stop with a reason from a fixed list — shop closed, lunch, refused, address mismatch, stock issue, other. It is captured with GPS and a timestamp, appears immediately in the operator's exception feed, and aggregates into the failure-reason report. The order goes back into the ready pool for the operator to decide on; nothing is auto-rescheduled.

There is a fallback code per distributor that the driver can use, so a dead phone never blocks a delivery. You can also switch OTP off entirely for a distributor and use one-tap confirmation instead.

PHP and MySQL on a single ordinary server. No container orchestration, no message broker, no per-seat cloud dependency. That is a deliberate choice — it keeps the running cost low and predictable whether you have three distributors or fifty.

Barely. Road distances between fixed shops are cached permanently and reused, because shops do not move. The cache is invalidated only when a pin or a warehouse location is edited. After the first few weeks of operation almost every leg a planner needs is already known.

No. Every record is scoped to its distributor and enforced at the controller layer before any read or write, with file storage segmented the same way. A brand-side super-admin can look across distributors, but always with an explicit "acting as" banner and a full audit entry for every action.

Yes. It is a self-contained PHP application with a MySQL database, so it deploys to your infrastructure as readily as to ours. Talk to us about what your IT team needs.

Nothing changes technically. The system is multi-distributor from day one, so adding the second or the fiftieth is an onboarding step rather than a new version. Every distributor runs the identical software, which is also what makes their numbers comparable.

It does not touch payments, invoicing, GST or financial reconciliation — your ERP owns all of that. It does not model shop opening hours as a hard constraint. It does not plan across multiple days. It does not do driver surveillance. And it does not silently change your data: stale trips and stuck orders are surfaced as a button for a person to press, never fixed in the background.

The shell loads offline, but delivery confirmation requires a connection — the record has to be written with its GPS and timestamp before the stop closes. In practice drivers retry a moment later when signal returns. Full offline queueing is a roadmap item, not a current feature.

It was built for FMCG wholesale distribution and every design decision reflects that — daily order files, fixed retail outlets, weight-bound vans, a handful of drivers. Operations shaped like that fit well whatever the product category. Operations with time-window commitments, cold chain requirements or long-haul routing would need work we have not done.