Last-mile job assignment software decides which driver receives which job, and in what order those offers are made. It is a matching problem with competing constraints — proximity, vehicle type, capacity, service window, driver availability and cost all pull in different directions — and the quality of your operation depends far more on how those constraints are weighted than on whether you have automated the decision at all. Most operators running delivery management software configure one variable, distance, and then wonder why allocation quality plateaus.
This article covers what the assignment engine is actually deciding, why “nearest available driver” is a poor default, the eight constraints that belong in the rule set, and one legal constraint that most operators overlook entirely.
Job assignment and route optimisation are not the same problem
These two get conflated constantly, and the confusion produces bad software decisions. Job assignment answers which driver should do a job. Route optimisation answers in what order a driver should complete the jobs they already have. They run on different time horizons and different data.
Assignment is the harder problem for on-demand and same-day work, because it happens under uncertainty: at the moment you allocate, you do not yet know what the driver’s next two hours look like. Route optimisation software then sequences whatever assignment has handed it. Optimise a badly assigned round and you get an efficient route through the wrong drops. The sequencing cannot recover a poor allocation decision, which is why automated job assignment software deserves more configuration attention than it usually gets.
Why “nearest available driver” is the wrong default
Proximity is the rule almost every operator starts with, because it is intuitive and easy to configure. It is also the rule that produces the most avoidable failures, for four reasons.
- Proximity is not availability. A driver 1.2 miles away with forty minutes left on a delivery window is further away, operationally, than one three miles out who has just closed their last job. Straight-line distance says otherwise.
- It ignores direction of travel. Allocating a collection to the closest driver frequently means sending them back across a route they have just completed. The next-nearest driver already heading that way costs less in both time and fuel.
- It ignores what happens next. Assigning the nearest driver to a low-value job can strand your only large-van driver in the wrong part of the city twenty minutes before a booking that needs a large van. Assignment decisions have downstream cost that proximity cannot see.
- It distributes work unevenly. Drivers who habitually work central zones receive disproportionately more offers. Over a few weeks that produces earnings disparity, and in a subcontractor pool it produces churn — expensive at a time when the Department for Transport reports that 23% of businesses with driver vacancies missed a delivery in the previous week because drivers were not available.
None of this means proximity is useless. It means proximity is a tie-breaker, not a decision rule.
The eight constraints a real assignment engine weighs
The useful distinction is between hard constraints, which must be satisfied or the allocation is invalid, and soft preferences, which improve quality but can be traded off. Configuring everything as a hard constraint produces an engine that cannot find a match; configuring everything as soft produces one that makes illegal or impossible allocations.
| Constraint | Type | What goes wrong when it is ignored |
|---|---|---|
| Vehicle type and capacity | Hard | Driver arrives at collection unable to load. Job fails, re-allocation costs an hour, customer sees a missed slot. |
| Service window and SLA | Hard | Job is allocated to a driver who cannot physically arrive in time. The failure is baked in at allocation. |
| Licences, training and clearances | Hard | Hazardous goods, pharmacy runs and high-value work carry qualification requirements. Non-compliance is a regulatory issue, not an efficiency one. |
| Driver hours and working time | Hard | Allocating into a driver’s remaining hours without checking creates compliance exposure and mid-round abandonment. |
| Current workload and committed route | Soft | Overloaded rounds become rushed drops — the behaviour behind a large share of doorstep complaints. |
| Direction of travel | Soft | Backtracking mileage accumulates invisibly across a day and shows up in the fuel line, not the dispatch report. |
| Cost to serve | Soft | Employed, subcontracted and exchange-sourced capacity carry different costs. Ignoring this optimises time at the expense of margin. |
| Fair distribution across the pool | Soft | Uneven allocation drives earnings disparity and driver attrition in self-employed pools. |
A practical rule hierarchy runs in that order: filter the eligible pool by the hard constraints first, score the remainder against the soft preferences, then use proximity or first-response to break ties. Operators who invert this — scoring everything at once with weighted points — tend to produce allocations that are defensible on paper and wrong in the yard.
The weighting also differs sharply by operation type, and copying a rule set across the two is a common mistake. Scheduled multidrop work is allocated in advance against known volumes, so capacity and geographic clustering dominate and there is time to optimise. On-demand same-day work is allocated in seconds against an unknown next hour, so availability and direction of travel matter far more than theoretical efficiency, and a fast adequate allocation beats a slow optimal one. Operators running both should expect to maintain two distinct rule sets rather than one compromise that serves neither well.
The constraint most operators miss: how assignment affects employment status
This is the section that rarely appears in vendor material, and it matters more than most configuration questions. If your drivers are engaged as self-employed subcontractors — the standard model across UK same-day and on-demand courier work — then the mechanics of how jobs are assigned form part of the evidence a tribunal will weigh in determining employment status.
In Stuart Delivery Ltd v Augustine, the Court of Appeal considered a courier who could release a booked time slot back to a pool of other couriers through the company’s app. Because he faced penalties if nobody else picked it up, the court held this was not a genuine right of substitution, and upheld the tribunal’s finding that he was a worker rather than self-employed — with the entitlements that follow, including minimum wage, holiday pay and working time protections.
The operational read-across for anyone configuring delivery driver allocation software is direct:
- Forced auto-assignment with penalties for refusal looks a great deal like control. If a driver cannot decline an offer without consequence, the arrangement drifts towards worker status.
- Offer-and-accept models — where jobs are broadcast to eligible drivers who choose to take them — sit more comfortably with genuine self-employment, at the cost of slower allocation and occasional unclaimed jobs.
- A meaningful right of substitution means a driver can send a qualified alternative of their choosing, not merely return the job to a pool and hope.
- Acceptance-rate scoring that affects future work allocation is functionally a penalty, even where no financial deduction applies.
This is not an argument against automation. It is an argument for choosing the assignment model deliberately, in consultation with an employment lawyer, rather than inheriting whatever default a platform ships with. Operators running mixed fleets often configure auto-assignment for employed drivers and self-selection for subcontractors — a pattern supported in same-day courier dispatch software that allows allocation rules to differ by driver engagement type. Note that this is a summary of a general position, not legal advice for your circumstances.
Reassignment: the part that usually breaks
Most systems handle the initial allocation competently. Far fewer handle what happens twenty minutes later, when a collection is not ready, a vehicle fails its check, a customer moves a slot, or a premium job arrives that should displace something already allocated.
Two design questions decide whether reassignment helps or hurts. The first is whether the engine reallocates continuously or only on exception. Continuous reallocation produces better theoretical efficiency and worse driver experience — a round that reshuffles every few minutes destroys a driver’s ability to plan their own day, and drivers respond by ignoring the app. The second is whether reassignment is automatic or proposed to a controller. In practice, most operators land on automatic reallocation within tightly defined triggers, with anything outside those triggers surfaced to a human.
Whichever model you choose, log every reassignment with a reason code. Reassignment volume is the single most diagnostic number in the whole system: a lane with a high reassignment rate almost always has a data problem upstream — wrong vehicle requirements on the booking form, optimistic service windows, or collection addresses that are not where the goods actually are.
What to measure
Assignment quality is measurable, and most operations do not measure it. Five numbers give an honest picture:
- Time to allocate. From job creation to driver acceptance. This is the metric automation is usually bought to fix, and the easiest to demonstrate improvement on.
- Offer rejection rate, by driver and by job type. A job type with a high rejection rate is priced wrong, described wrong, or genuinely unattractive — all fixable, none visible without the data.
- Reassignment rate, with reason codes. Your upstream data quality indicator, as above.
- Allocation fairness. Distribution of jobs and earnings across the active driver pool. Track the spread, not the average; the average always looks fine.
- Failed-first-time rate attributable to allocation — jobs that failed because the wrong driver, wrong vehicle or an unachievable window was assigned, separated from failures caused by the customer being out.
That last one connects directly to service quality. Citizens Advice found that among the record 15 million people who had a problem with their most recent parcel delivery, 29% reported the driver left before they had time to get to the door. That is rarely a driver attitude problem. It is usually a round that had more drops on it than the day could hold — which is an assignment decision, made hours earlier, by software or by a controller under pressure.
One further measure is worth adding if you subcontract or use a load exchange: the proportion of jobs allocated to your own drivers versus bought-in capacity, tracked by lane and by day of week. Assignment engines optimising purely for speed will reach for external capacity readily, and the cost shows up in the margin rather than in any dispatch report. Against a cost base where Logistics UK puts driver employment costs up almost 8% and typical operating margins at two to three per cent, a few percentage points of unnecessary subcontracting is the difference between a profitable lane and a busy one.
Where to start
Start by writing down your current allocation rules as they actually operate, not as the policy document describes them. Most operators discover at this point that allocation is really being done by two experienced controllers using judgement they have never articulated, and that the software is rubber-stamping their decisions. That tacit knowledge is what you are trying to encode — and capturing it is a week of conversations, not a configuration exercise.
Then implement hard constraints first and leave the soft scoring alone for a month. Getting vehicle type, capacity, licences and hours right eliminates the failures that cost you customers. Optimising direction of travel and cost to serve can wait until the engine is reliably producing valid allocations.
InstaDispatch supports configurable allocation covering nearest-driver rules, radius from collection, vehicle type matching and driver self-selection, with route planning, live tracking, ePOD and invoicing running from the same courier management software. If you would like to work through how your existing allocation rules would translate, book a demo and bring a live day’s job list.
