Route planning and optimization software takes a set of stops and turns them into workable routes: sequenced against capacity, delivery windows and access constraints, assigned to vehicles and drivers, delivered to the person driving in a form they can use, and compared afterwards against what actually happened. With Pentoggle, an operator can describe the constraints its routes actually run against and generate the starting application around it.
This is the horizontal workflow, applicable to any multi-stop operation. If your question is specifically about running a distribution operation to retail outlets, with crates, returns and depot reconciliation, start with City Distribution Software.
Many operators already run Tally for accounting and a GPS or telematics provider for vehicle data. Those stay where they are. What is often still managed outside them is the plan itself, and almost always the comparison between the plan and what happened.
Key takeaways
- A theoretically shortest route is not necessarily a workable one. Delivery windows, access restrictions, customer availability and vehicle suitability constrain the answer before distance does.
- Driver knowledge of a route is real and frequently better than a map, so a plan that contradicts it without explanation is likely to be ignored.
- The plan has to reach the driver in a usable form. A sequence in the office that arrives as a verbal instruction is not a plan.
- Comparing plan against actual is what makes the next plan better, and it is the part most commonly skipped.
- A useful number is actual against planned for the route, in time taken and stops completed.
The current process is often not the problem
An experienced driver who has run the same area for four years, sequencing his own stops, is a good routing system. He knows which gate to use, which shop opens late, and which turn is impossible with a loaded vehicle at four in the afternoon.
The trouble starts at identifiable points.
When the route changes and the knowledge does not
Outlets are added as they are acquired and rarely removed when they close. The route drifts, and because it drifts slowly nobody redraws it.
When the knowledge sits with one person
The regular driver is on leave. The replacement is given a list and takes most of the day to do what the regular driver does by lunchtime.
When constraints are not written anywhere
The customer who will not accept deliveries between certain hours, the site with a height restriction, the area with timing rules. All known, none recorded, so every new person rediscovers them the hard way.
When nobody compares plan to actual
The route was expected to take seven hours and took nine. Whether that is normal for this route, or something changed, cannot be answered because the planned figure was never recorded.
What route planning software holds
Stops
Locations with addresses, contacts, and the consignments or tasks at each.
Location constraints
Delivery windows, access restrictions, vehicle size or height limits, appointment requirements, and anything else that narrows when and how a stop can be served.
Vehicle and capacity
Which vehicles are available, their capacity by weight and volume, and any restrictions on where they can go.
Sequence
The planned order of stops with expected arrival times and expected duration at each.
The driver's plan
The sequence delivered to a phone, with addresses, contacts and anything the driver needs to know before arriving.
Execution
Actual arrival and departure at each stop, stops completed, and stops not completed with reasons.
Deviation
Where the actual route departed from the plan, and where possible why.
Plan against actual
Time and stops planned against time and stops achieved, per route, over time.
Optimisation is constrained before it is optimised
Routing software is often sold on distance and it is rarely distance that determines whether a route works.
The constraints that bind first are usually these. Delivery windows agreed with customers. Site access hours and appointment requirements. Vehicle suitability, since some locations cannot take a larger vehicle at all. Load capacity by weight and by volume, which are different limits and either can bind. Driver hours and rest. And local rules on where and when commercial vehicles may move, which vary by location and by area within a location, and should be built into the route rules for the areas you serve rather than assumed.
Handling capacity as a single figure is a common source of infeasible plans. A vehicle that is full by volume with weight to spare, or at weight limit with space remaining, is full either way, and a plan built on one dimension will assign a load the vehicle cannot take.
Once constraints are held, the sequencing problem is smaller and more tractable than it looks, because most stops have only a few feasible positions. That is also why optimisation gains in practice tend to come from getting the constraints right rather than from a more sophisticated algorithm.
There is an honest limit worth stating. A plan is a forecast, and travel times in Indian cities vary in ways a plan cannot fully anticipate. The purpose is not a schedule the day will match exactly. It is a workable starting sequence, a realistic view of how many stops fit, and a basis for knowing when the day has gone wrong early enough to tell someone.
The driver's knowledge is data you already have
Any routing system that treats the driver as an instruction-follower will lose to one that treats him as a source.
Drivers know things the plan does not: which entrance actually works, which stop takes twenty minutes rather than five, which customer is reliably unavailable at a particular time, which stretch is impassable at certain hours. This knowledge is accurate, it is specific, and in most operations it exists nowhere except in the head of whoever runs that route.
Two failure modes follow from ignoring it.
The first is that a plan contradicting driver knowledge tends to get quietly ignored. The driver runs his own sequence, the system records the planned one, and every downstream number is wrong.
The second is that the knowledge leaves when the driver does, and the operation rediscovers it over several weeks with a new person.
The practical response is to make the plan correctable and to capture the correction. A driver who resequences should be able to record that he did, ideally with a reason from a short list. Over a few weeks the recorded corrections become the constraint data the plan was missing, and the plan starts agreeing with the driver rather than fighting him.
The same applies to stop duration. Planning systems commonly assume a uniform time per stop. Actual durations vary considerably by location and are learnable from a few weeks of arrival and departure records, which is a better basis than an assumption and requires nothing beyond capturing two timestamps.
Plan against actual is the part that compounds
Most routing effort goes into producing the plan. The comparison afterwards is what makes the next one better, and it is usually skipped.
The comparison is not complicated. Planned sequence against actual sequence. Planned arrival times against actual. Planned stops against stops completed, with reasons for those not completed. Planned duration against actual duration for the route as a whole.
What it produces is worth more than the individual data points.
Stop durations that reflect reality, replacing a uniform assumption with what each location actually takes.
Travel times for your lanes at your times of day, which is more useful than a generic estimate because it reflects the roads and hours you actually run.
Routes that consistently overrun, which usually means too many stops rather than a bad sequence, and which is a route redesign question rather than a driver question.
Stops that are consistently missed, which are frequently the last few on a route and therefore the same customers every time. This is a relationship problem hiding inside an operational one, and it is invisible without the comparison.
Where drivers consistently deviate, which is the constraint data described above arriving through a different door.
The reason this compounds is that route data decays. Customers move, open new locations, change their receiving hours. Roads change. A route planned well two years ago is planned against a world that no longer exists, and only the plan-against-actual comparison surfaces the drift while it is still small.
Where route planning looks different by business type
- City Distribution Software, where routes repeat daily to a fixed set of outlets and returns flow back.
- Courier and Parcel Business Software, where the run is built fresh each day from that day's shipments.
- Packers and Movers Software, where a route is a small number of long jobs rather than many short stops.
- Bulk and Tanker Transport Software, where routes are point to point and the constraint is product and vehicle rather than sequence.
- Container Transporter and CFS Software, where the sequence is dictated by gate timings and document readiness.
- Transport Contractor and Fleet Owner Software, where multi-point deliveries on a long-haul trip are the routing question.
Why operators choose Pentoggle for route planning
Your constraints, held explicitly
Delivery windows, access restrictions, vehicle limits and local area rules recorded rather than remembered.
Capacity by weight and volume
Both limits, because either can bind and a plan built on one produces loads the vehicle cannot take.
A plan the driver can actually use
Sequence, addresses, contacts and site notes on a phone, with the ability to record a correction and why.
Plan against actual, retained
Arrival times, stop durations and completion recorded, so the next plan is built on what happened rather than on an assumption.
Sits around your accounting
Tally and comparable systems continue handling accounting, invoicing and GST. Pentoggle adds the operational layer around routes, constraints and execution.
A useful number for route planning
Actual against planned for the route, in time taken and stops completed.
Two figures rather than one, because they fail differently. A route that completed every stop and took two hours longer than planned has a duration problem. A route that finished on time with four stops undone has a workload problem. Either alone is misleading.
Read it per route over weeks rather than per day. A single day is weather, traffic and one difficult customer. A route that consistently runs over has something structural in it, usually too many stops or a sequence that no longer suits the outlets on it.
Record reasons for stops not completed, from a defined list, since the reasons sort into owners in the same way delivery failures do. Ran out of time is a planning problem. Customer closed or unavailable is a windows problem and possibly a commercial one. Access problem is a constraint that was not recorded and now can be.
Where you also track drops per vehicle per day, as a distribution operation would, treat that as the productivity view and this as the planning-accuracy view. They answer different questions and both are worth having.
Ready to build route planning software?
Your drivers know their routes better than any map does.
None of that knowledge is written down, and none of it survives the week they are on leave.
Describe your stops, your constraints and how routes actually run to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.