Project Overview and Business Context
The client was a regional last-mile logistics operator handling B2B deliveries for food service and catering suppliers across a major UK city. They managed a fleet of 12 vehicles with daily route planning done by a dispatcher using a combination of experience, a whiteboard, and Google Maps. The process took 2-3 hours each morning and produced routes that drivers regularly improvised on, creating a gap between planned and actual routes that made performance tracking and customer ETAs unreliable. The brief was to build a tool that the dispatcher could use to import the day's delivery list, generate optimised routes for each vehicle, assign drivers, and produce both a driver-facing turn-by-turn route and a customer notification with an estimated delivery window. The routing challenge has several specific constraints: vehicle load capacity, driver time windows (each driver has contracted hours), delivery time windows specified by customers, priority deliveries (refrigerated goods that must be delivered within a shorter time window), and the fixed depot start and end location. These constraints make the routing problem a Vehicle Routing Problem with Time Windows (VRPTW), one of the classic combinatorial optimisation problems in operations research. The solution combines a VRP solver for the mathematical optimisation layer with Google Maps API for real-time traffic and GPT-4o for the dispatch narrative layer.
Technical Architecture and Stack Decisions
The backend is a Python FastAPI service deployed on AWS EC2 with PostgreSQL for delivery data, route records, and historical performance storage. The routing pipeline runs in three stages. Stage one: data preparation. The dispatcher uploads the day's delivery manifest (from their customer order management system, as a CSV), which is validated, geocoded via the Google Maps Geocoding API, and loaded into PostgreSQL with all delivery constraints (time windows, load weight, priority flags). Stage two: optimisation. The VRPTW solver runs on the delivery set, using the Google OR-Tools library (Google's open-source operations research toolkit) which implements a metaheuristic search algorithm for the Vehicle Routing Problem. OR-Tools is given the distance matrix (computed from Google Maps Distance Matrix API with traffic conditions at expected delivery time), vehicle capacities, driver time windows, and delivery time window constraints, and produces an optimised assignment of deliveries to vehicles and a sequence for each vehicle. Stage three: enrichment. Each computed route is enriched with Google Maps directions API calls for turn-by-turn navigation links, estimated arrival times per stop, and total route metrics. GPT-4o receives the route summary for each driver and generates a plain-English dispatch briefing: the driver's name, total stops, first stop, any priority deliveries flagged, estimated finish time, and any constraints to be aware of. The driver-facing interface is a mobile-optimised Next.js page accessed via a link in the driver's briefing, showing their route list with one-tap navigation to each stop.
Key AI and ML Components
The OR-Tools VRPTW solver is the core optimisation engine. It is not an LLM or a neural network: it is a metaheuristic combinatorial optimisation algorithm that provably improves route quality over manual planning at scale. For the client's typical daily delivery volume of 80-140 stops across 12 vehicles, OR-Tools produces a solution within 30-60 seconds that is typically within 5-8% of the mathematical optimal, which is computationally sufficient for practical routing. Google Maps Distance Matrix API provides real-time distance and duration estimates between all stop pairs, accounting for current traffic conditions. This data is the primary input to the OR-Tools solver and determines the quality of the resulting routes. GPT-4o contributes the communication layer: generating driver dispatch briefings and customer ETA notifications in natural language. The customer notification is personalised per delivery: it includes the customer's name, the estimated delivery window (30-minute slot), the driver's name, and a contact number if there is a query. GPT-4o generates these notifications from the structured route data, formatted for SMS or email delivery. For the dispatcher, GPT-4o generates a daily operations summary: total planned delivery distance, estimated fuel cost saving versus previous manual routing (computed from baseline data), and any flagged constraints that may require manual intervention (a delivery window that the algorithm could not satisfy, a vehicle at capacity).
Challenges Solved and How
Real-world routing constraints are always messier than clean textbook VRTWPs. The build handled several recurring edge cases. Driver familiarity with specific areas was represented as a soft constraint: drivers can be assigned preference zones, and the solver weights assignments within preference zones more favourably, reflecting the reality that an experienced driver on their familiar patch is faster than a driver following GPS into an unfamiliar area. Delivery failures (customer not present, access issues) needed to be fed back into the routing system for re-routing during the day. A FastAPI endpoint accepts driver-reported failures from the mobile interface, triggers a partial re-solve for remaining stops on that vehicle's route, and updates the estimated arrival times for all subsequent stops. Customer ETA notifications are automatically updated via SMS when re-routing occurs. Traffic events that significantly change route optimality mid-day (major accident, road closure) are detected via a Google Maps real-time traffic monitoring call that runs every 30 minutes. If a route segment's estimated duration has increased by more than 20%, the route is flagged for re-optimisation and the dispatcher is alerted.
Outcome and Measurable Results
The client ran the optimised routing system for a 10-week pilot period alongside their manual process. Total planned route distance fell by 18% compared to the manual routing baseline, computed from the GPS tracking data collected from vehicles. Average driver finish time moved 22 minutes earlier per shift, contributing to reduced overtime costs. Customer ETA accuracy improved: 89% of deliveries arrived within the estimated 30-minute window, compared to 67% with manual routing. Dispatcher morning planning time fell from 2.5 hours to 35 minutes. The client reported that the driver briefing feature was particularly valued by newer drivers who lacked the area knowledge of senior drivers, allowing the business to onboard new drivers more quickly.
Lessons for Similar Projects
Use the right optimisation tool. Route optimisation is a well-studied combinatorial problem with mature solver libraries. OR-Tools, VRP Solver, and similar libraries produce better results than LLM-based routing at a fraction of the cost and latency. LLMs belong in the communication layer, not the solver layer. Invest in the constraint modelling. The quality of a VRP solution depends entirely on how accurately the constraints are modelled. Time windows, vehicle capacities, driver preferences, and priority deliveries all need to be represented accurately. Incomplete constraint modelling produces routes that drivers cannot actually follow. Build re-routing capability from day one. Real delivery operations encounter failures, delays, and unexpected changes every day. A routing system that cannot adapt to real-world events loses driver trust quickly. Traffic data quality matters as much as algorithm quality. A great solver with poor distance matrix data produces worse routes than a simpler solver with accurate real-time traffic data. Invest in the Google Maps API integration and budget for API costs at scale.