Dispatch Software: Why the 9:40am Reassignment Matters More Than the Morning Plan

Dispatch software assigns jobs to drivers, sequences their stops, and then manages the shift as it changes: tracking vehicles live, updating ETAs, capturing proof of delivery, notifying customers and handling failed attempts. This guide covers delivery, fleet and field-service dispatch, not freight load boards or emergency services dispatch.

That distinction matters, because three different products share the name. Freight and load dispatch serves trucking and brokerage. Computer-aided dispatch (CAD) serves police, ambulance and taxi fleets. Delivery, fleet and field-service dispatch serves everyone who moves goods or technicians to customer addresses. This guide is about the third one.

And here is the thing almost every explainer on this topic skips. Building the morning plan is the easy part. Every vendor can sequence stops on a map. The real test arrives at 9:40am, when the plan stops being true.

9:40am, 40 stops left, one van down: the moment dispatch software is actually tested

It's a Tuesday. Your 7am plan was clean: five vans, tight clusters, sensible windows.

Then a van goes off the road with a coolant warning. It has 40 unserved stops on board. Three of them sit inside a two-hour window. One is refrigerated and cannot wait for tomorrow.

What happens next is the only fair test of a dispatch system.

Can the dispatcher see, in one view, which of the other four vans has capacity, which is physically closest, and which one already has a chilled compartment running? Can they move those 40 stops without rebuilding four routes from scratch?

Does the driver app on the receiving van update instantly, or does someone have to ring the driver and read out addresses?

Do the affected customers get a revised ETA automatically, or do they find out when the van doesn't arrive and they call you?

Most software fails somewhere in that chain. Usually at step three or four, where the plan is technically recoverable but the customer communication is still manual.

This is why we push buyers to evaluate dispatch platforms on recovery, not on planning. Planning is commodity. Recovery is where operating cost and customer trust actually live.

The financial weight behind that argument is not marketing spin. McKinsey's analysis of parcel delivery economics puts last-mile at roughly half of total parcel delivery cost, which means a decision made at 9:40am about who takes 40 stops carries more cost impact than most decisions made in the warehouse that morning.

What is dispatch software? (And the three different products that share the name)

Dispatch software is the system that turns a list of jobs into assigned, sequenced, tracked work, then manages that work as conditions change during the shift.

It sits between your order source (a webstore, an ERP, a booking system, a spreadsheet import) and your drivers or technicians in the field.

Now the disambiguation, properly.

Freight and load dispatch is built for trucking operators and brokers. It centres on load boards, carrier rating, IFTA fuel tax reporting and line-haul documentation. If you are matching a full trailer to a lane, that is the category you want.

Computer-aided dispatch (CAD) serves emergency services, taxi and rideshare operations. It optimises for incident priority and response time, not for delivery windows or proof of delivery.

Delivery, fleet and field-service dispatch handles multi-stop days: couriers, e-commerce fulfilment, meal kits, pharmacy delivery, wholesale replenishment, maintenance rounds. Dozens to hundreds of stops per vehicle, with time windows, capacity limits and a customer waiting at each address.

Those three products look similar in a feature list and behave nothing alike in production. Buying the wrong one is a common and expensive mistake, usually discovered three weeks into implementation when nobody can work out where the proof-of-delivery photos go.

Before the wheels turn: job intake, assignment, scheduling and route optimisation

This half of the platform is table stakes. Every credible vendor does it. Judge it quickly and move on.

Job intake. Orders arrive from your webstore, ERP, WMS, a CSV, or a public API. The question worth asking is what happens to a malformed address, not what happens to a clean one.

Geocoding quality is the quiet differentiator here. Rural properties, industrial estates, apartment complexes and new subdivisions break weak geocoders, and a stop dropped 400 metres from the actual gate ruins a route silently.

Driver and vehicle constraints. Shift start and finish times, break rules, vehicle capacity by weight and volume, refrigeration, tail lift, licence class, skill or certification for service jobs.

A planner that ignores constraints produces routes that look brilliant on screen and collapse by 10am.

Route optimisation. The engine sequences stops against distance, drive time, traffic patterns, service duration at each stop and hard time windows.

Ask how it handles a day where the constraints cannot all be met. Good engines tell you which stops are at risk and why. Weak ones quietly drop the window and let the driver find out.

The dispatch console. One screen showing the map, the job list, the driver roster and the timeline, with drag-and-drop reassignment between routes.

If a dispatcher needs three tabs to move one stop, the interface will fail at exactly the moment described earlier.

After the wheels turn: live tracking, predictive ETAs, proof of delivery, notifications and exception handling

This is the half that decides whether you keep the platform in year two.

Live tracking and predictive ETAs. A dot on a map is not visibility. Visibility is an ETA that recalculates when the driver is 20 minutes behind and pushes the revision out before the customer notices.

Shipment visibility is not a nice-to-have on a feature grid either. The World Bank's Logistics Performance Index scores 139 economies across six dimensions, and tracking and tracing is one of them, which tells you the industry treats it as a core capability rather than an upgrade.

The driver app. Job list, turn-by-turn navigation, barcode scanning, status changes, notes and photo capture, ideally working offline in a basement car park or a rural blackspot.

Drivers are the least forgiving user group in the business. If the app takes six taps to complete a stop, they will stop using it properly by week three and your data quality dies with it.

Proof of delivery. Signature, photo, timestamp, geostamp, and a note field for the exception the driver just encountered.

Good proof-of-delivery capture is not about the driver. It's about the person in your office who has to answer a chargeback claim four weeks later with something better than "the driver says he left it".

Customer notifications. Booking confirmation, day-before reminder, on-the-way alert with a live tracking link, delivered confirmation with the POD attached.

Every one of those messages is a phone call your dispatch team doesn't take. Capgemini's research into the last-mile challenge ties delivery experience directly to repeat purchase behaviour, so the notification layer is doing commercial work as well as operational work.

Exception handling. The part buyers check last and regret most.

• Failed attempt with a reason code, photo evidence and an automatic reschedule path
• Partial delivery and short-pick handling on wholesale drops
• Return-to-depot workflow that doesn't require re-keying the order
• Live reassignment of a whole route, or a subset of stops, from one driver to another
• An alert when a stop is at risk of breaching its window, before it breaches

That last one is the difference between a dispatch system and a rear-view mirror. Plenty of platforms will tell you at 5pm that 11 stops were late. Very few will tell you at 11am that they are going to be.

The four numbers that expose weak dispatch software: first-attempt success rate, on-time delivery %, stops per route, cost per stop

There's a simple filter for vendor calls. Ask which of these four the platform reports natively, without a data export and a spreadsheet.

First-attempt success rate. The percentage of stops completed on the first visit. It is the single most cost-sensitive number in delivery, because every failure buys you a second journey you already paid for once.

If a platform cannot separate "failed, nobody home" from "failed, wrong address" from "failed, refused", it cannot help you fix anything.

On-time delivery percentage. Measured against the promised window, not against the driver's own arrival estimate. Some tools grade their own homework here. Check the definition in writing.

Stops per route. Your productivity baseline. Track it against a fixed period, because seasonal mix and stop density move it around and a headline average hides the story.

Cost per stop. Fuel, wages, vehicle cost and failed-attempt rework divided by completed stops. This is the number your finance team will ask for and the one most dispatch platforms cannot produce.

A tool that reports the first three and not the fourth is still worth having. A tool that reports none of them is a route planner wearing a dispatch badge.

Dispatch software vs route planners vs TMS vs telematics: where the categories actually overlap

Four categories get sold into the same budget line, and they answer different questions.

Route planning answers "what order". Dispatch answers "who, and what now". A TMS answers "which carrier and what does it cost". Telematics answers "what is the vehicle doing".

Plenty of operations run two or three of these together. The mistake is buying one expecting it to behave like another.

Category	The question it answers	Operating window	Platforms in this space
Dispatch software	Who takes this job, in what order, and what happens when that changes	Day of, minute by minute	Locate2u, Onfleet, DispatchTrack
Route planning	What is the most efficient stop sequence for this set of addresses	Before the shift	Standalone optimisers, plus the planning module inside dispatch platforms
TMS	Which carrier, what rate, what documentation for this freight	Days to weeks ahead, line-haul level	McLeod, AscendTMS, Bringg (orchestration layer)
Telematics	Where is the vehicle, how is it being driven, when is it due for service	Continuous, asset level	Samsara, Motive, Verizon Connect, Teletrac Navman, EROAD

That table is a map, not a ranking. Each of those platforms is competent inside its own column, and several of them integrate with each other in production fleets.

If you want the head-to-head view of the delivery dispatch column specifically, our comparison of dispatch management platforms covers pricing models and feature depth side by side.

Four operations, four dispatch profiles: cold chain, prescription delivery, heavy goods site delivery, scheduled maintenance

The same category behaves differently depending on what is in the vehicle.

Cold chain and refrigerated food. Time in transit is a product-quality constraint, not just a service constraint, so a rerouted stop late in the day can be a write-off rather than a delay. Premium seafood delivery, the operating context described on the Madam Seafood case study, is a clean example: tight windows, temperature-sensitive freight, no tolerance for a second attempt tomorrow.

Prescription and pharmacy delivery. Identity checks, age or signature requirements and record-keeping obligations sit on top of ordinary routing. The SuperPharmacy operation runs prescription home delivery, where the proof captured at the door is part of the compliance record rather than a convenience feature.

Heavy goods and building sites. Access constraints dominate. Vehicle class, crane or tail-lift requirements, site induction, and a delivery point that moved 200 metres since last week. Franz Building Supplies works in exactly that environment, delivering materials to active sites and trade customers.

Scheduled maintenance and field service. Here the job has a duration, a skill requirement and often a parts dependency, so "stops" are not interchangeable. PTSQ runs B2B service operations built around scheduled maintenance rounds, which is a different scheduling problem from parcel drops.

How to evaluate dispatch software: the eight questions most vendors don't expect

Take these into the demo. Ask for the system to do it live rather than describing it.

1. Move 40 stops from one driver to another, mid-shift, in front of me. Time it. Count the clicks. Watch whether time windows survive the move.
2. Show me a failed delivery and what happens next. Reason code, photo, reschedule, customer message. If the reschedule is manual re-keying, that is your Monday morning forever.
3. Which of the four metrics do you report natively? First-attempt success, on-time percentage, stops per route, cost per stop.
4. How does the ETA recalculate, and what triggers a customer notification? A fixed morning ETA sent at 6am is a promise you cannot keep.
5. What does the driver app do with no signal? Offline job list, offline POD capture, sync on reconnect.
6. How do orders get in? Native integrations with your webstore or ERP, an open API, or a CSV you will be uploading by hand at 6:45am.
7. What is the pricing at my peak-week driver count? Not the average. And confirm whether SMS notifications are billed separately.
8. Who owns the data and how do I get it out? Export format, retention period, API access to historical stop records.

Question one is the whole article in a single request. Vendors who have built a genuine dispatch system enjoy answering it. Vendors who have built a planner start talking about the roadmap.

Where Locate2u fits

Locate2u is a delivery management platform built around a single dispatch console: live fleet map, job list, driver roster and schedule timeline in one view, with drag-and-drop reassignment that pushes straight to the driver app.

Route optimisation, real-time tracking with predictive ETAs, proof of delivery and automated customer notifications run in the same product, so a mid-shift change updates the driver and the customer without a separate tool.

It runs for three-van operations and for enterprise fleets, across Australia, New Zealand, the UK, the US and Canada. Full detail sits on the dispatch and planning product page, and the operating contexts behind it are on our customer stories.

Dispatch software FAQs

What is dispatch software?

Dispatch software assigns jobs to drivers or field technicians, sequences their stops into an efficient route, and manages the shift in real time: live vehicle tracking, updated ETAs, proof of delivery capture, automated customer notifications, and workflows for failed or rescheduled jobs.

What is the difference between dispatch software and route planning software?

Route planning software builds the plan by sequencing stops into an optimised route. Dispatch software runs the day: it assigns the work, pushes it to the driver app, tracks progress, updates ETAs, handles reassignments when a vehicle or job changes, and records proof of delivery.

Is dispatch software the same as a TMS?

No. A transport management system manages freight procurement, carrier selection, rating and shipment documentation, typically at line-haul level. Dispatch software operates at the day-of level: which driver takes which job, in what order, and what happens when that plan changes mid-shift.

Do small fleets need dispatch software?

Manual dispatch usually breaks somewhere between three and five drivers, or once stop counts pass roughly 30 to 40 per driver per day. The trigger is not fleet size but exception volume. If dispatchers spend more time on phone calls than on planning, the spreadsheet has already failed.

What features should dispatch software include?

Five pillars: job assignment and scheduling, route optimisation, real-time GPS tracking with predictive ETAs, customer communication through tracking links and SMS or email updates, and proof of delivery with an audit trail. Exception handling is the feature most buyers check last and regret most.

How much does dispatch software cost?

Most delivery dispatch platforms price per user or per driver per month, with tiers driven by stop volume, driver numbers, integration requirements and whether customer notifications are included. Price against your peak-week driver count rather than your average, and confirm what SMS notifications cost separately.

The practical takeaway is narrow enough to act on this week. Grade every platform on the 9:40am scenario rather than the 7am one, and make the vendor demonstrate a live reassignment, a failed-attempt workflow and a customer notification in the same session.

If you want to see how that recovery sequence looks end to end, start with the Locate2u dispatch and planning console and put your own worst Tuesday through it.