Driver Decision Authority in Last Mile: Why Dispatch Autonomy Has Two Dials, Not One

Driver decision authority is the set of choices a delivery driver is permitted to make without asking, covering safe drops, reattempt timing, local resequencing, refusing an unsafe delivery and accepting a substitution at the door. Every dispatch deployment sets this level, but most set it by accident, as a byproduct of which actions the driver app happens to expose. This piece argues it should be designed deliberately, on a ladder, alongside the system autonomy levels operators already configure. There are two dials, and most operations only know about one of them.

Why Driver Authority Is a Design Decision

Two things are happening at once in last mile operations. Machine autonomy is rising, with Gartner predicting that by 2031, 60% of supply chain disruptions will be resolved without human intervention. At the same time, buyers are cautious about how they get there, and Gartner expects 40% of agentic AI projects or more to be canceled by the end of 2027 on cost, unclear value or inadequate risk controls. The usual response is to design system autonomy in levels and treat the driver as an execution endpoint. That leaves half the design unexamined.

Aviation has already run this experiment, and the findings transfer. NASA research on automation-induced complacency documents how operators shifted into a monitoring role become less effective at detecting the failures they are monitoring for. NASA’s Flightdeck Automation Problems model separately identifies erosion of manual flight skills arising from continuous operation of autoflight systems and lack of practice. The two findings compound: the operator is both less alert and less capable at the moment the automation reaches its limits.

The last mile analogy is not exact and the difference favors caution. A pilot encounters unmodeled situations rarely. A delivery driver encounters them constantly, because a doorstep is an unstructured environment. A blocked loading bay, a dog in the yard, a customer who is not the person named on the order, a corridor that will not take the pallet. No routing model holds those, and the driver is the only sensor present. Designing that person into a purely executional role removes the judgment the operation depends on precisely where the model is weakest.

Regulation is now pushing in the same direction. Directive (EU) 2024/2831 on platform work, which must be in national law by 2 December 2026, requires that automated decisions substantially affecting working conditions be overseen by humans holding the requisite knowledge, skills and authority. Authority is the operative word. A system in which nobody near the work can change an outcome does not satisfy it, and driver-side discretion is one of the few places that authority genuinely sits.

Also Read: Agentic Driver Management for Last-Mile Delivery 2026

How to Design a Driver Discretion Ladder

1. Name the levels, the way you already name system autonomy

Most operators running agentic dispatch configure autonomy from L1, where the system recommends and a human approves, through L3, where the system acts within policy bounds. The driver side deserves the same treatment.

The value of naming levels is that it forces the question to be answered per decision class rather than once for the whole app. An operation can legitimately run D0 on pharmaceutical consignments and D3 on ambient residential drops in the same city on the same day. The common failure is not choosing the wrong level, it is choosing one level for everything, which happens by default whenever nobody writes the ladder down.

2. Apply the reversibility test

The primary question is whether a wrong decision can be undone. Reversible decisions are candidates for delegation, because the cost of a driver error is bounded and recoverable. Irreversible decisions are not, regardless of how experienced the driver is.

Shares are illustrative rather than benchmarked and should be replaced with your own exception mix. On this distribution, 78% of decision volume is clearly reversible, which is the delegable share.

The fourth column matters as much as the third. Reversibility says whether delegation is safe, and the information advantage says whether it is useful. A decision that is reversible but where the driver knows nothing the system does not is better left with the system, since delegating it adds variance without adding information. The delegable set is the intersection of the two, not the union.

3. Do the escalation arithmetic before deciding

Withholding authority has a measurable cost, and it lands on the dispatch desk. At 2,000 stops a day with 8% needing a decision, that is 160 decisions daily. At three minutes of dispatcher time each, escalating all of them consumes eight dispatcher-hours a day.

Delegating the 78% reversible share takes dispatcher decision time from eight hours a day to roughly 1.8. That is not primarily a cost saving. It is dispatcher attention released for the decisions that genuinely need a second party. Run this calculation with your own exception rate and handling time before setting policy, because the number is highly sensitive to both and a three-minute assumption is optimistic for anything requiring a customer call.

4. Understand what happens to this at peak

The escalation load does not scale linearly with volume, because exception rates rise during a surge as well. Access problems, missed windows and customer-unavailable events all become more common when the plan is under strain.

A 3x volume day produces roughly 4.8 times the decision load. That arrives precisely when dispatcher capacity is already the binding constraint, which means an operation running D0 or D1 across the board has built a system that fails hardest on its busiest day. Delegation is a peak-resilience decision, not only an efficiency one. It is also the cheapest peak intervention available, because unlike adding dispatchers or vehicles it requires no incremental capacity, only a decision about who is allowed to decide.

5. Guard against skill erosion deliberately

This is the aviation finding applied. A driver who has never made a doorstep judgment call will not suddenly make a good one during the incident where it matters. If the operation intends drivers to exercise judgment on the hard 22%, they need practice on some of the easy 78%, which is an argument against delegating by seniority alone. Rotating authority rather than reserving it for veterans keeps the capability distributed. It also protects against a specific fragility, which is an operation whose doorstep judgment lives entirely in a handful of long-tenured drivers in a labor market where those are the hardest people to replace.

6. Instrument the decisions drivers make

Delegation without measurement is abdication. Record what the driver decided, what the alternative was, and what happened next. That record is what lets you move a decision class up or down the ladder on evidence, and it is also what answers a dispute later, whether from a customer or from a driver contesting how their performance was assessed. Most operations already capture the exception code and discard the reasoning, which is the half that would have told them whether the delegation was working.

Also Read: Logistics AI Governance EU 2026: Six Architectural Mechanisms

The Two Dials Compared

The rows to read together are the information advantage and the failure modes. The two dials are not substitutes, because they draw on different information. A system that models 250 constraints still cannot see the dog. A driver who can see the dog cannot see the other 200 stops. Setting one dial high to compensate for the other being low produces a predictable failure in the domain the chosen party cannot observe.

Also Read: Driver Tracking vs Performance Management in Last-Mile

Five Rules for Calibrating Discretion

1. Calibrate by reversibility, not by seniority. Seniority is a proxy for judgment and a poor one for consequence. A reversible decision is safe to delegate to a new driver, and an irreversible one is not safe to delegate to anyone.

2. Set the level per decision class, never per driver app. A single global setting forces the same answer for a leave-safe judgment and a controlled-substance handover, which guarantees one of them is wrong.

3. Make the boundaries visible in the moment. A driver needs to know which decisions are theirs before they are standing at the door. Ambiguity produces both unauthorized deviations and unnecessary escalations, and the second is more common. The practical form this takes is a short, explicit list surfaced against the stop itself rather than a policy document a driver read during onboarding and has not seen since.

4. Test the peak case explicitly. Model your escalation load at three times volume with a raised exception rate. If the dispatch desk cannot absorb it, delegation is not optional.

5. Review the ladder on outcome data quarterly. Decision classes should move between levels based on what actually happened, not on a policy set once at go-live. The instrumentation from step six is what makes that review possible.

Also Read: Failed Deliveries Don’t Have to Mean Lost Customers

What This Looks Like in Practice

Execution rate at scale. A Fortune 50 operation running more than 4,500 drivers moved execution rate from 75% to 92% and surfaced more than $14M in annualized operational opportunity. At that fleet size, a seventeen-point improvement in what actually gets executed depends on decisions being made close to the work, because no central desk resolves that volume of doorstep variation in a day.

Consolidation and the exception path. A retail enterprise consolidated six legacy systems into a single execution layer, cut manual dispatch effort by more than 80% and held 99%+ on-time delivery. Cutting manual dispatch effort by 80% is only sustainable if the exceptions that used to consume it are being resolved somewhere else, which is either automation or delegation and in practice is both.

Planning cycle time and the decision window. Locus customers connecting warehouse readiness signals to automated dispatch have reduced planning cycle time by 66%. A shorter planning cycle changes the discretion calculation, because a driver who can get a fast answer from the system needs less standing authority than one who would wait twenty minutes for a callback.

Four Mistakes in Setting Driver Authority

Letting the app define the ladder. Authority ends up equal to whichever buttons the driver app exposes, which is a product decision standing in for an operating policy.

Delegating by tenure alone. It concentrates judgment in the drivers most likely to leave, and it denies newer drivers the practice that builds the capability the aviation research says decays without use.

Treating escalation volume as a driver quality signal. High escalation usually means the boundaries are unclear or set too low, not that drivers lack confidence. Check the boundary definition before running a coaching program, since the coaching will not hold if the rules stay ambiguous.

Setting the level once at go-live. Exception mixes shift with season, geography and product line. A ladder that never moves is calibrated for an operation that no longer exists, and peak is precisely when the stale calibration is load-bearing.

Also Read: Driver Retention: Why Operational Layer Beats Bonuses

How Locus Supports Decisions at the Edge

Locus, the world’s first Decision-Intelligent, Agentic TMS, is built around configurable autonomy rather than a single automation setting, and that discipline is what this argument extends to the driver side. Autonomy levels run from L1 recommendation through L3 autonomous execution and are set per decision class rather than globally, so an operation can already vary how much the platform decides according to the risk tier of the decision. The proposal here is to make the driver-side equivalent equally explicit.

On the ground, the Driver Companion App captures exceptions at the point they occur, with condition and damage reporting, proof of delivery, and safe-drop and alternate-location handling offered at the point of exception rather than after a failed attempt. Those are the mechanics a D2 level needs. What turns mechanics into a designed ladder is deciding, per decision class, which of them a driver may use without asking, and recording the outcome when they do.

Six governance mechanisms covering explainability, traceability, evaluation, autonomy levels, execution sandbox and human-in-the-loop mean decisions are traceable to the state and logic that produced them. Traceability is what makes a discretion ladder reviewable, because moving a decision class from D1 to D2 is only defensible on evidence about how those decisions turned out. It is also what supports the contestation and explanation rights the Platform Work Directive introduces, since a driver disputing an assessment is disputing a recorded decision with a stated basis.

Locus runs at 1.5B+ deliveries across 360+ enterprise customers in 30+ countries at 99.99% uptime, modeling 250+ real-world constraints simultaneously including rider skills and shift limits. Locus has been recognized by Gartner for seven consecutive years across multiple research categories, appears in the 2026 Gartner Hype Cycle for AI-powered logistics, features ShipFlex as a Representative Vendor in the 2026 Gartner MCPMS Market Guide, holds Leader designation in the QKS SPARK Matrix for Transportation Management Systems, and ranks #1 on G2 for Route Planning software.

In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

To map your own exception mix against a discretion ladder, schedule a demo.