Dispatch management software handles the daily allocation of work to vehicles and drivers: what has to move, what is available to move it, the constraints on both, the assignment, the despatch itself with documents issued, and the continuous re-planning that happens as the day proceeds. With Pentoggle, an operator can describe how dispatch actually works and generate the starting application around it.
Dispatch is among the most real-time functions in a transport business and among the least well supported. It is usually one or two people, a phone, a whiteboard and a great deal of retained knowledge, working against a plan that stops being accurate before ten in the morning.
Many operators already run Tally for accounting and a GPS provider for vehicle data. Those stay where they are. What is often still managed outside them is the allocation itself: which vehicle is going where today, who decided that, and what it replaced.
Key takeaways
- Dispatch is not planning. It is re-planning, continuously, against a plan that changes hourly, and software that assumes a stable plan will not be used.
- The dispatcher is working against a constraint set rather than a preference list, and the constraints are the part the software has to hold.
- Dispatch knowledge frequently lives in one person's head, which makes the function a single point of failure that goes unnoticed until that person is unavailable.
- The record of what changed and why is worth more than the plan itself, because it is what shows whether the problem is planning, availability or commercial commitments.
- A useful number is dispatch lead time, meaning hours from load confirmed to vehicle despatched.
The spreadsheet is often not the problem
A whiteboard and a phone is a genuinely effective dispatch system at small scale, and it has properties software struggles to match: instant to update, visible to everyone in the room, and requiring no login.
The trouble starts at identifiable points.
When the whiteboard is not where the decision is made
The dispatcher is on the phone in the yard, the whiteboard is in the office, and the two agree only when somebody walks between them.
When one person holds the constraints
Which driver is not available Thursday, which vehicle is due a service, which customer will not accept a particular truck. It works until that person is on leave, at which point the operation slows visibly.
When the day's changes are never recorded
The morning plan is erased and rewritten. By evening nobody can say what the plan was, what changed, or why, so the same disruption recurs weekly without ever being addressed.
When despatch and documentation are separate steps
A vehicle leaves and the LR is prepared later, or the e-way bill is arranged after departure. Both create exposure and both come from dispatch not being connected to documents.
What dispatch management software holds
Loads to be moved
Confirmed loads with origin, destination, commitment, weight and any special requirement.
Vehicle availability
Which vehicles are free, when, where they currently are, and what they are committed to next.
Driver availability
Who is available, who is on rest, who is on a multi-day trip, and licence validity.
Constraints
Vehicle type required, customer restrictions, product compatibility, document validity, route permissions.
Allocation
Load to vehicle to driver, with who made the assignment and when.
Despatch confirmation
Loading complete, documents issued, vehicle departed, with time recorded.
Change log
Reassignments during the day with the reason each occurred.
Position at a glance
What is despatched, what is pending, what has no vehicle, and what is at risk.
Dispatch is re-planning, not planning
Software designed for dispatch frequently assumes a planning problem: given loads and vehicles, produce an optimal allocation. That is a real problem and it is not the one a dispatcher has.
The dispatcher's actual problem is that a plan exists, it was reasonable when made, and it is now wrong. A vehicle did not return overnight. A driver did not report. A customer moved a pickup. A load was cancelled. Another load appeared and must move today. The morning plan frequently stops being accurate within the first few hours.
This has direct design consequences.
Reassignment must be as easy as assignment. If changing an allocation takes more effort than making one, dispatchers will keep the real plan on paper and update the system at day end, which produces a system that is always describing the past.
The system must show what is unassigned and what is at risk, continuously. That list is the dispatcher's actual working view, far more than a complete schedule is.
Partial information has to be acceptable. A load with no vehicle yet, a vehicle whose return time is uncertain, a driver who may or may not report. A system that demands complete data before accepting an entry will be bypassed.
And speed of entry matters more than completeness. The dispatcher is on the phone. An entry that takes seconds will get made; one that takes minutes will not.
The constraint set is the product
What makes dispatch hard is not choosing between options. It is that most apparent options are not actually available, and the reasons are scattered.
The constraints in a typical Indian transport operation include vehicle type and capacity for the load, product compatibility for specialised vehicles, customer restrictions such as vehicle age or particular drivers, document validity because an expired permit or fitness certificate stops the vehicle, driver licence class and availability, driver rest after a long trip, route permissions and any restrictions on the corridor, maintenance due, and the vehicle's next committed load.
An experienced dispatcher holds all of this and applies it instantly. That is genuine expertise and it is frequently undocumented, which makes the function fragile. When that person is unavailable, the replacement makes assignments that are technically reasonable and practically wrong, and the errors surface hours later as a vehicle turned away at a gate.
Encoding the constraints does not replace the dispatcher's judgement, and it should not try to. What it does is prevent the specific class of error that comes from not knowing a fact that was written down somewhere. A vehicle whose fitness expires tomorrow should not be assignable to a three-day trip, and that check requires no judgement at all.
The secondary benefit is that constraints become visible and therefore challengeable. A customer restriction that made sense four years ago and now costs deployment flexibility is worth reviewing, and it cannot be reviewed while it exists only as something the dispatcher knows.
The change log is the diagnostic
Many operations do not record what changed during the day, which means they cannot answer whether their dispatch problem is a dispatch problem at all.
A reassignment log with a reason on each entry answers it within a few weeks. The reasons sort into categories with different owners.
Vehicle not available, because of breakdown, delay in returning, or a document issue, is a fleet and maintenance question.
Driver not available is a resourcing question.
Customer changed the requirement is commercial, and if concentrated on particular customers it is a conversation with them.
Load cancelled or added late is commercial, and it is often a larger category than operators expect.
Planning error is the dispatcher's, and it is frequently a smaller category than assumed, which matters because it is the one most often blamed.
An operation that discovers much of its disruption comes from late load confirmations has learned that its dispatch problem is really a sales process problem, which dispatch software alone will not solve. That finding is worth more than any allocation feature.
Where dispatch looks different by business type
- Transport Contractor and Fleet Owner Software, where dispatch includes deciding own vehicle against hired.
- Container Transporter and CFS Software, where trailer allocation runs against gate timings and free-time expiry.
- City Distribution Software, where dispatch is loading fixed routes rather than allocating individual loads.
- Bulk and Tanker Transport Software, where product compatibility eliminates most vehicles before economics is considered.
- Courier and Parcel Business Software, where the equivalent is assigning shipments to delivery runs.
- Packers and Movers Software, where crews are dispatched alongside vehicles.
Why operators choose Pentoggle for dispatch
Built for changing plans
Reassignment as fast as assignment, because the plan will change before noon.
Constraints held, not remembered
Vehicle type, documents, driver availability and customer restrictions checked automatically, so the dispatcher's judgement is spent on judgement.
The unassigned list is the main view
What has no vehicle and what is at risk, continuously, because that is what the dispatcher is actually working on.
Every change carries a reason
A log that shows whether the disruption is operational, commercial or planning.
Sits around your accounting
Tally and comparable systems continue handling accounting, invoicing and GST. Pentoggle adds the operational layer around allocation, availability and despatch.
A useful number for dispatch
Dispatch lead time, meaning hours from load confirmed to vehicle despatched.
It measures the responsiveness of the whole chain from commercial commitment to wheels moving, and it is the figure customers actually experience when they ask how quickly you can move something.
Read the distribution rather than the average, because the average is dominated by routine loads planned a day ahead. The long tail is where the problems are, and the loads sitting longest usually share a characteristic: a particular vehicle type, a particular origin, or a customer who confirms late.
Pair it with the change log. A short lead time achieved by constant reassignment is not efficiency, it is churn, and it costs in ways that show up as driver frustration and missed commitments elsewhere.
Ready to build dispatch management software?
Your dispatcher can tell you where every vehicle is going today.
It is harder to say what the plan was at eight this morning, or why it is no longer the plan.
Describe how you allocate loads and what constrains you to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.