Automate job intake first: turn each order into a complete, checked dispatch record with an address, time window, load and contact method. Next, let software suggest a driver and draft ETA updates, while a dispatcher approves exceptions. Starting with automatic routes before the underlying jobs are clean merely moves mistakes faster.
The first useful pilot can be modest. It may read a structured form and a shared inbox, flag missing fields, and place approved jobs in a dispatch queue. The dispatcher still owns the promised service window, vehicle suitability and customer communication. This creates evidence for deciding whether automated assignment is safe.
Map the handoffs that slow a delivery desk
Follow one job from first request to proof of delivery. Note every place a person retypes information: an email into a spreadsheet, a spreadsheet into a routing tool, a route into a driver message, and a driver note into a customer reply. Count how often the dispatcher has to call back because a field is missing. These observations tell you where automation should begin without assuming that route optimisation is the largest problem.
A small delivery firm may receive web orders, standing customer spreadsheets and phone requests. A web form might already provide all required fields, while a phone note says “three boxes tomorrow morning” without a collection address. Treat these as different intake channels that must produce the same final job record. Keep the raw request alongside the interpreted record so a dispatcher can check doubtful extraction.
Define one job as one service obligation, with its own identifier and status. Minimum fields are pickup and delivery addresses, contact details, item count, size or weight when relevant, collection and delivery windows, service level, handling instructions and the source of the request. Add capacity fields your vehicles truly need, such as refrigeration or a lifting limit, rather than collecting everything a software demo can display.
Use the wider guide to AI jobs in a delivery service for ideas beyond the dispatch desk. Here the aim is narrower: make each incoming job assignable, changeable and traceable. If the business cannot say which request created a job or who changed its window, an assignment model will be hard to trust.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowTurn free-text requests into a queue with visible gaps
AI can extract likely fields from an email, but it must not treat guesses as confirmed facts. A simple form can sometimes do this job more reliably. Use AI for the unstructured part: emails, attachments and driver notes. Put extracted values into a draft state. Required blanks and contradictory values must go back to a person for clarification before the job becomes available for dispatch.
Illustrative before and after: an email says, “Can you take the usual four cartons to the workshop on Thursday? Back entrance this time. Call before arriving.” The draft record can capture four cartons and “call before arriving”. It must mark the exact address, contact number and Thursday time window as unknown unless they are present in an approved standing instruction. “Usual” is not an address. An owner who sees a completed-looking job card may otherwise miss that the model silently selected the last address it saw.
Illustrative extraction instruction:
Read the customer's message and return only these fields:
pickup, delivery, date, collection window, delivery window,
item count, weight, handling, contact method, special access.
Use UNKNOWN where the message does not say. Quote the exact
source phrase beside each extracted value. Do not infer an
address from previous orders. Flag contradictions separately.
The corresponding illustrative output might be: item count “four cartons” from “usual four cartons”; special access “back entrance” from the same sentence; delivery address UNKNOWN. The dispatcher can send a short clarification: “Please confirm the delivery address and a two-hour delivery window for Thursday. We have noted four cartons and back-entrance access.” A polished AI reply that invents a window is worse than a brief, accurate question.
Keep a required-field gate. For example, a job cannot enter the assignment queue until both addresses, date, service window and load class are confirmed. A contact phone can be optional for a business delivery with a documented reception point, but mandatory where a driver needs an access call. These are your operating rules, not universal software defaults. Write them down and test each against a genuine awkward job.
Let assignments be suggestions until the constraints are proven
Assignment combines capacity, working hours, location, service window, equipment and driver knowledge. Onfleet's API documentation, for example, describes assigning existing tasks in bulk to available drivers in either a distance or a load mode, with an optional cap on how many tasks each driver may hold. That shows such a function exists; it does not prove it suits every service promise. Review the tool's current options and your own driver data before enabling automatic acceptance.
Start with a rule sheet. Vehicle V1 can carry up to a defined volume and is available until a set time. Driver D2 is authorised for a particular handling requirement. A new task needs a forty-minute service allowance at the destination. The assignment engine may suggest a combination, but the dispatcher checks whether these constraints are current. A driver who is nominally on shift may be delayed at a collection point.
| Condition | Queue action | Reason for human review |
|---|---|---|
| All fields complete; capacity and window fit | Suggest driver and route position | Dispatcher approves during pilot |
| Load near vehicle limit | Hold assignment | Confirm actual dimensions and other loads |
| Customer changes address after dispatch | Pause old ETA | Reprice and check route impact |
| Access or handling note unclear | Request clarification | A route engine cannot resolve the service promise |
The main illustrative worked example is a firm with three drivers and 36 daily stops. It reviews a week of requests and finds eight jobs with missing fields, five late address changes and four driver assignment changes after dispatch. An intake check that prevents six of the eight incomplete jobs would save follow-up work, but the firm should measure the actual minutes rather than claim a fixed saving. Suppose each prevented follow-up previously took four minutes: six times four is 24 minutes on that observed day. The arithmetic is illustrative.
The same firm tests automatic suggestions for 30 complete jobs. Twenty-four suggestions match the dispatcher's eventual choice; six do not. Two mismatches are due to a vehicle already full, two to a customer's narrow access window and two to driver availability that was never updated. A simple “80% agreement” headline would hide the operational problem. The firm first fixes the capacity and shift fields, then reruns the test. It does not release full automatic assignment because a bad assignment can create a failed delivery and a customer complaint.
For a different illustration, a furniture delivery with one heavy wardrobe is not equivalent to one small parcel stop. The job record needs dimensions, crew requirement and access notes. An AI system that counts both as one stop may put the wardrobe into a vehicle with no space or assign one driver where two are needed. The remedy is a load class and a rule that unusual dimensions demand dispatcher approval.
Draft ETA messages from events you can trust
An estimated time of arrival should have a source and a timestamp. A scheduled slot, a route calculation and a driver status update are different kinds of evidence. Tell customers which one they are receiving. “Your delivery is booked for 10:00–12:00” is a service window; “Driver is approximately 25 minutes away” is a live estimate. Do not relabel the former as a live ETA.
Prepare a small set of approved templates: booking confirmed, driver en route, revised arrival window, failed attempt and delivery complete. Let AI fill only named variables from the job record, such as order reference and approved time window. Keep free-form composition for a person when an unusual incident needs explanation. Check consent and the firm's communication policy for the chosen channel.
Illustrative message: “Hello [first name], your delivery reference 481 is scheduled for 14:00–16:00. We will send another update when the driver starts the final leg.” If the driver is delayed, a corrected message might say: “The current estimate is 16:20–16:50. Please reply if access will be unavailable.” The firm should confirm that the customer can actually reply and that someone monitors the response. Do not promise an exact minute the system cannot support.
Consider a third case: the route engine says 15:10 after a driver marks the previous stop complete, but the driver has not loaded a replacement parcel. Triggering “arriving in 20 minutes” would be false. Require a load-complete or departure event before the en-route message. Late and missed-drop message templates can help with the cases that need careful wording.
One useful override is “freeze customer ETA”. The dispatcher activates it when an address changes, a vehicle breaks down or a driver reports an access problem. The system may keep updating the internal plan, but it cannot send fresh customer promises until a human confirms the new basis. Record who applied and removed the freeze. This is especially useful when two systems, such as a route planner and a messaging service, are linked.
Test the exception path before a busy day
Choose a set of past jobs that includes awkward requests, not just routine ones. Test a missing address, a last-minute cancellation, a driver who becomes unavailable, a job beyond vehicle capacity, a customer who changes the destination, and an unreadable proof-of-delivery note. For each, write the expected system action and who can approve the next step. A pilot passes only if it handles the exceptions visibly.
A cancellation illustrates why state matters. If job 612 is cancelled after assignment, the route should remove the stop, the driver should see the cancellation and the customer should receive the approved acknowledgement. The old ETA must be invalidated. If only the spreadsheet row disappears, a driver might still travel to the address from a cached route. Test the full chain with a fake job before depending on it for live service.
Another example is a driver note: “Gate locked, left with neighbour.” That is not automatically a completed delivery under every service agreement. The system should flag the note for review, retain the photo or signature if captured, and avoid an unqualified “delivered” message until a person confirms the allowed outcome. Proof-of-delivery evidence deserves its own control because customer disputes may turn on exact wording and timestamps.
For the first two weeks of a pilot, run suggestions alongside the established dispatch method. Log the AI suggestion, dispatcher decision, reason for any override, delivery outcome and customer contact. This creates a comparison set without giving the system unchecked authority. Review the logs daily while the sample is small enough to inspect. If overrides cluster around one service type, narrow the automation to the routine jobs that meet your rules.
Know whether the first automation earns its place
Measure four things before and after the pilot: time from request to complete job record, proportion of jobs needing clarification, assignment overrides and late or incorrect customer messages. Also note failed attempts and cost per completed drop, because a superficially faster desk can create expensive rework. Do not compare a quiet week with the busiest week without accounting for job mix.
For example, suppose the firm handles 180 jobs in a week. Before the pilot, 30 require clarification; after a new intake gate, 18 do. That is a reduction of 12 jobs, but ask whether customers supplied better information or staff simply stopped recording missing fields. Audit a sample of accepted jobs against the raw requests. If five of those 18 still contain guessed access details, the apparent improvement is overstated.
Calculate the economics with your own costs. If a dispatcher spends 45 minutes a day less on retyping but 30 minutes more correcting AI suggestions, the net time released is 15 minutes, before software cost and setup. That may still be worthwhile if the job record is clearer, but it does not justify a large subscription on time savings alone. If error rates rise, pause the assignment feature while keeping the useful intake checks.
A firm with mostly recurring routes may find fixed rules sufficient. Another with many same-day requests may benefit from route suggestions. A route-planner comparison can guide the later software choice; a daily exceptions report helps keep the resulting operation visible. The first dispatch automation has succeeded when every new job is trustworthy, exceptions are surfaced early and the dispatcher can explain and reverse each automated step.
Write the desk rules before connecting the systems
Automation is easier to control when the dispatch desk has a one-page operating rule set. Define who creates a job, who can change a promised window, which fields are required, when a driver may decline a task and who can send a revised ETA. Include the point at which a customer request becomes an accepted booking. A forwarded email is not necessarily a confirmed service commitment.
Use a simple change log with job ID, old value, new value, source, time and approver. If a customer phones to move a collection from 09:00 to 11:00, the dispatcher enters the change and records that it was confirmed by phone. A model should not infer the change from a casual “later is fine” reply in an email thread. If the source is ambiguous, the draft remains pending. This gives the team a way to trace the cause of a missed window without hunting through several inboxes.
Define a fallback for system downtime too. Drivers need an agreed way to see the latest authorised stops and report completion if the routing application is unavailable. The dispatcher should know whether the backup is a printed manifest, an exported list or a telephone call. Test one simulated outage before turning off the old process. Otherwise a technically small failure can leave the team unsure which copy of the route is current.
Use a small approval ladder for routine and risky jobs
Not every job needs the owner's attention. Categorise work by what can go wrong. A routine repeat customer with a confirmed address, standard parcel and broad window can receive a suggested assignment for dispatcher approval. A new address with a special access note needs direct review. A high-value, fragile or time-critical item may require a second check on handling and communication. These categories are based on your service contract and experience, not on a generic AI risk score.
For an illustrative example, a car-parts courier receives a request for a small boxed component at 13:00. All fields are present and a nearby driver has capacity; the dispatcher accepts the suggestion in one click. Ten minutes later, another email requests collection of an oversized panel but omits its dimensions. The intake system can flag “large item, dimensions unknown”, but it should not assign a vehicle. A phone call resolves the dimensions, after which the desk checks capacity and issues a new promise. The useful automation is the stop sign, not a clever guess.
When approving a suggested driver, show the reason alongside the name: current route, spare capacity, window fit and required equipment. If the interface presents only “Driver 2 selected”, staff cannot learn from or challenge the decision. Keep a short override reason menu such as unavailable, vehicle full, access issue, customer preference and dispatcher judgement. Allow a free-text note for unusual cases. Review these reasons weekly; a repeated override may reveal bad data, an unrecorded rule or a tool that does not fit the work.
Keep the customer promise separate from the internal plan
Dispatchers often need to rearrange work without changing what the customer was promised. Store the accepted customer window separately from the latest internal target arrival. If a driver is moved from 14:10 to 14:35 inside a promised 14:00–16:00 window, the customer may not need a revised message. If the new plan is 16:25, the desk must decide whether and how to warn them. Merging these two times into one field leads to either needless notifications or late surprises.
For a concrete check, sample ten jobs and reconstruct each timeline: request received, booking accepted, driver assigned, driver departed, ETA sent and proof recorded. Compare the customer-facing wording with the event that triggered it. If an “out for delivery” message was sent before the parcel was loaded, change the trigger. If a late update was sent after the original window ended, change the escalation rule. This audit uses ordinary operational records and gives a more reliable picture than asking the tool for a satisfaction score.
Dispatch automation questions from small operators
Should a small delivery firm automate route planning first?
Usually start with consistent job intake and exception flags. A route optimiser cannot correct a missing address, an impossible access window or an unavailable vehicle. Once the intake fields are reliable, compare assignment and route suggestions against dispatcher decisions on real jobs.
Can customer ETA messages be sent automatically?
They can, if the ETA comes from a reliable live status, the customer has agreed to the channel and someone can stop or correct a message. Begin with approved templates and a human review for unusual delays, failed attempts and sensitive deliveries.
How much history is needed before trying AI dispatch?
A small firm can pilot rule-based intake and assignment with current jobs and a short set of past examples. More history helps test recurring patterns, but accurate addresses, capacity, shift status and service windows matter more than a large pile of unclean records.
Further reads
- Cost per Drop: Work Out Delivery Cost From Route and Fuel Data — Track the economics of each completed delivery.
- Taxi Business Automation: AI Booking Confirmations and Receipts — Send taxi booking confirmations, driver job cards and receipts automatically, with AI reading messy requests and your records doing the sums.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Onfleet API reference, Automatically assign list of tasks (docs.onfleet.com/reference/automatically-assign-list-of-tasks).