Delivery route optimisation

The Delivery Route Optimisation process runs roughly 260 times a year, typically a few times a week in bursts. Each morning, a dispatcher pulls the day's orders, reviews the delivery addresses for usability, identifies constraints like delivery windows and vehicle capacity, and then plans routes from experience and a mental map of the area. The finished routes are communicated to drivers via email and spreadsheets. When data errors surface late in the process, the dispatcher handles rework manually. The whole cycle takes around 75 minutes per run, adding up to approximately 325 hours of manual effort annually.

The process sits at the intersection of a readable but ageing MES database and a set of routing constraints that are well understood by one or two experienced people but not yet written down anywhere. About 75% of runs follow a pattern that is consistent enough to automate, but the remaining 25% require genuine human judgement, whether because of unusual delivery requirements, late-surfacing data errors, or constraints that fall outside the standard logic. Product safety and traceability requirements add a compliance dimension: any routing decision that contributes to a defective product reaching a customer could trigger a recall, so every decision needs to be logged and non-standard runs need a human sign-off.

The process owner is the dispatcher, with oversight from the plant manager. The primary data source is the MES database, which is readable by custom code even though it does not expose modern APIs. An automation engineer is available in-house and is willing to learn Python, which makes a self-maintained technical solution realistic without bringing in ongoing external dependency.

The recommended path is Hybrid: a Python-based optimisation engine handles address validation, constraint checking, and route generation for the standard 75% of runs automatically, while a human review gate intercepts the exception quarter before anything is dispatched. This is the right call for several specific reasons, and it is worth being clear about why the alternatives fall short.

A fully automated AI Workflow scores lower because the 25% exception rate is not a fringe problem here. It is a structural feature of the process, and the compliance stakes, recall-level product safety requirements, mean that sending a non-standard run out without human eyes on it is not an acceptable risk. The AI Workflow is a good description of what happens inside the Hybrid for the standard cases, but it cannot be the whole architecture. Traditional Code, meaning a deterministic Python solver like OR-Tools or PuLP without any classification layer, would handle the standard routing well and is absolutely within the automation engineer's reach. The honest limitation is that it offers no intelligent way to catch or classify exceptions; those would still fall back to fully manual handling, which limits how much of the 325 annual hours you actually recover. The Hybrid adds the classifier on top of the solver and that is where the meaningful difference lies.

The client's preferred tech stack is Python against the existing MES database, and this is genuinely a good fit for the recommended approach, not just a convenient alignment. OR-Tools, the open-source combinatorial optimisation library from Google, is well suited to vehicle routing problems with time windows and capacity constraints, and it is written to be used from Python. The MES database, even without modern APIs, can be queried directly through a custom connector that the automation engineer can build and own. This means the organisation keeps full control of the solution and does not take on a subscription dependency or a vendor lock-in risk. The tradeoff is that someone in-house needs to maintain the code; that is manageable given the automation engineer's availability, but it is a real ongoing commitment.

The exception classifier does not need to be a sophisticated machine learning model at the outset. A well-designed rule-based classifier, built from the constraint model produced during the elicitation phase, will handle the majority of flagging correctly and can be upgraded later if the edge cases demand it. What matters architecturally is that the classifier output always routes ambiguous runs to the dispatcher review queue rather than defaulting to automated dispatch. The human gate must be a hard requirement in the system design, not a feature that can be bypassed when the queue is long. This is the point where the compliance and automation engineering decisions converge, and it is worth the dispatcher and plant manager being explicit about this with whoever builds the system.

An AI Agent, meaning an autonomous system that takes end-to-end actions without human gates, scores poorly here and that verdict is deliberate. The process is not mature or stable enough, the exception rate is too high, and the compliance requirements are too serious for autonomous end-to-end dispatch to be appropriate at this stage. That may change in two or three years once the constraint model is well validated and the exception rate is better understood, but it is not the right starting point. The Hybrid path gives the organisation a route to increasing automation confidence over time, because every dispatcher decision in the review queue becomes a labelled data point that could eventually train a more capable classifier.

The two closest alternatives to the recommended Hybrid approach are AI Workflow and Traditional Code, both scoring 6 against the Hybrid's 9. It's worth being direct about why neither quite gets there on its own.

Traditional Code, built around a Python optimisation solver like OR-Tools, is genuinely attractive here. The automation engineer can own it, the MES database gives it a readable data source from day one, and deterministic solvers are well understood and auditable, which matters under product safety requirements. The problem is the exception quarter. A rules-based engine has no mechanism for classifying ambiguous runs intelligently; it either forces them through standard logic and produces a bad route, or it rejects them entirely and drops them back into a fully manual queue. You end up automating 75% of the effort and leaving the hardest 25% exactly as it is, with no reduction in the dispatcher's cognitive load on those runs.

AI Workflow closes that gap by adding a classification layer that can recognise when a run falls outside the standard constraint envelope and handle it more gracefully. But running an AI Workflow end-to-end without a human gate introduces a different problem: under the client's product safety and traceability requirements, a miscategorised non-standard run that gets dispatched without review could contribute to a recall scenario. The AI Workflow is the right engine inside the recommended solution; it just cannot be the whole solution on its own. The Hybrid approach takes the optimisation capability of Traditional Code, adds the intelligent exception detection of an AI Workflow, and wraps both in a hard architectural requirement for human sign-off on anything outside the standard envelope. That combination is what makes it the clear recommendation for this specific process.

The build starts with a data audit and constraint elicitation phase, and this step should not be rushed. The automation engineer works through the MES database and the existing spreadsheets to map every field that feeds the routing process: order identifiers, delivery addresses, time windows, vehicle capacities, and any customer-specific requirements currently held in the dispatcher's head or in informal notes. Alongside the data mapping, the automation engineer runs structured sessions with the dispatcher to codify the routing rules that currently live as tacit knowledge. The goal at the end of this phase is a documented constraint model and a labelled dataset of historical runs split into standard and exception cases. That labelled dataset becomes the calibration set for everything built afterwards.

With the constraint model in hand, the automation engineer builds the core Python routing engine. OR-Tools from Google is the recommended solver here: it's open source, well documented, handles vehicle routing problems with time windows natively, and is maintained well enough to trust in a production environment. The engine reads the morning order pull directly from the MES database using a Python database connector, runs address validation before any routing logic executes to catch data quality errors at the earliest possible point, and generates candidate routes for runs that fall within the standard constraint envelope. The output at this stage is a structured route object per driver, not yet a finished communication to the driver.

The AI layer sits on top of the routing engine and performs two jobs. First, a classifier, which can start as a rules-based filter and evolve into a lightweight ML model if the labelled dataset supports it, evaluates each run against the constraint model and flags anything that falls outside the standard envelope. Flagged runs are placed in a dispatcher review queue rather than being dispatched automatically. Second, for the standard runs that pass through cleanly, the system formats the route and sends it to drivers via the existing email channel or a simple web interface, whichever the team prefers. The dispatcher review queue is also web or email based, presenting the suggested route alongside the specific constraint that triggered the flag, so the dispatcher can approve, adjust or override in under 15 minutes rather than building the route from scratch. Every decision, automated and human alike, is written to a log table in the MES database with a timestamp and a decision identifier, satisfying the traceability requirement.

The system runs in parallel with the existing manual process for four weeks before the manual process is decommissioned. During the pilot, the automation engineer compares automated route outputs against the dispatcher's manual routes on distance and constraint compliance, tracks the exception flag rate against the expected 25%, and collects dispatcher feedback on the review queue interface. At the end of the pilot, the constraint model is updated to reflect any edge cases that surfaced, the exception classifier threshold is calibrated based on real production data, and the solution is handed to the automation engineer as permanent owner with a documented runbook. A quarterly review is scheduled to update the constraint model as delivery patterns or customer requirements change.