Route Optimization Software: What It Does, What It Costs

Route optimization software decides which vehicle serves which stops and in what order, under constraints such as vehicle capacity, customer time windows and legal driver hours. It is the layer between a list of orders and a plan a dispatcher can actually send out. Underneath the product name sits a well-studied piece of operations research, and the quality of anything in this category comes down to how honestly it models your constraints and how good its numbers are before the search even starts.

Search the term and you get vendor homepages and roundups written by vendors. Very few say what the engine is, what the category costs at list price, what the free options really do, or which questions expose a demo tuned on a generous time budget. Idealogic builds logistics platforms, so what follows is the framing we would want in hand before signing anything: what the software does, the capabilities that separate a solver from a spreadsheet, the engine underneath, where AI route optimization genuinely helps, published prices, the open-source path, build versus buy, and how any of it survives contact with a TMS. It sits under our broader piece on AI in supply chain.

The short version

• The category solves the vehicle routing problem. Which vehicle serves which stops, in what order, under capacity, time windows, driver rules and a dozen other constraints.
• The problem is NP-hard, so no product gives you a provably optimal plan at real scale. You get a good one with an unknown gap, and the only comparison that matters is against the plan you run today.
• The search is almost never machine learning. Google OR-Tools, LKH-3 and hybrid genetic search are metaheuristics, and the Routing Arena benchmark still puts classical operations research solvers ahead of neural routing models.
• Machine learning earns its place on the inputs: travel time by hour and direction, service time at each stop, where a van can park, and which routes drivers will actually follow.
• Pricing splits four ways and the model matters more than the headline: per driver, per order, per task, or per API call.
• Free engines are real. OR-Tools, VROOM and Timefold are open source. What they lack is everything around the solver.
• Integration decides whether any of it survives operations. Four data contracts, and the one nobody builds is the return path carrying actuals back.

What route optimization software actually does

Route optimization software takes a set of orders and a set of vehicles and returns an assignment and a sequence: which van serves which stops, in which order, arriving when. Everything else in the category is a variation on how the constraints are modeled, how the search is run, and how much workflow is wrapped around the answer.

Separate it from navigation, because buyers conflate the two constantly. Navigation solves a shortest path between two points, which Dijkstra handled in 1956 and every phone now does in milliseconds. Route optimization solves assignment and sequencing across many stops and many vehicles at once. The hard part is not finding the road. It is deciding that stop 47 belongs on van 3 rather than van 8, and that van 3 should reach it at 11:20 rather than 14:40.

Most products in the category bundle three layers and sell them as one: the combinatorial optimizer that decides the routes, the predictive models feeding it, and the workflow around it that dispatches, tracks and handles exceptions. Only the middle layer is reliably machine learning, and it is the layer that most determines whether the plan survives the morning. It is a large category and getting larger: Mordor Intelligence sizes route optimization software at 7.92 billion dollars in 2025, reaching 8.98 billion in 2026 and a projected 16.78 billion by 2031, a 13.32% compound annual rate.

Route optimization software versus route planning and navigation

Route planning produces a workable set of routes. Route optimization searches for a better one. The distinction sounds pedantic until you look at what most tools sold as planners actually do, which is draw the routes a human already decided on.

Consumer mapping makes the gap concrete. Google Maps caps a route at nine stops including the final destination, and it will not reorder them for you; you drag stops into sequence by hand. That is a drawing tool. Real route optimization software takes hundreds of stops and dozens of vehicles and searches the assignment space, which is the thing a person cannot do.

The useful comparison is between three operating models most fleets pass through in order, each fixing a different bottleneck than the last.

The step from column one to column two is usually the largest, and it has nothing to do with AI: it is the step from a human who cannot evaluate a million alternatives to an algorithm that can. The step from two to three is smaller in distance and larger in reliability, because that is where the plan stops disagreeing with the road.

Capabilities that matter: constraints, windows, and driver rules

The feature grids in this category are nearly identical, which is why they are useless. What actually separates products is constraint coverage: which real-world rules the model can express, and what happens when they conflict.

Time windows and driver rules deserve particular attention, because they are where most first builds fail. A time window modeled as a hard constraint can render an entire day infeasible, and an infeasible answer is useless to a dispatcher who still has to send vans out. Production systems use soft windows with a lateness penalty instead, so the solver degrades gracefully and reports which promises it broke.

Driver hours are stricter, because they are law. In the US, FMCSA hours-of-service rules for property-carrying drivers set an 11-hour driving limit after 10 consecutive hours off duty, inside a 14-hour on-duty window, with a 30-minute break required after 8 cumulative hours of driving and weekly caps of 60 hours in 7 days or 70 in 8. In Europe, Regulation (EC) No 561/2006 limits daily driving to 9 hours, extendable to 10 twice a week, with 56 hours a week and an uninterrupted 45-minute break after four and a half hours of driving.

Here is the part vendors skip. Break scheduling has to sit inside route construction, not after it. Inserting a mandatory 45-minute break shifts every downstream arrival by 45 minutes, which can break a customer window six stops later that was comfortably feasible before. Software that plans first and validates hours afterward hands the dispatcher a plan that fails legal review and has to be repaired by hand, which is the work it was bought to eliminate. The duty clock also has to arrive live from the ELD, because a driver who ran late yesterday starts today with less. We covered that compliance layer in our piece on fleet management software.

What route optimization software does when the plan is infeasible

Every production routing system meets days it cannot solve, and how it behaves on those days separates mature products from demos. The wrong behaviour is a silent drop: a dispatcher who sees 12 stops missing with no explanation stops using the system that week.

The right behaviour is a relaxation hierarchy declared in advance, naming which constraints may bend, in what order, and at what penalty. Windows soften before capacity does, capacity before legal driver limits, and legal limits never. With it comes a diagnostic naming the binding constraint, so the answer is that stop 118 needs a tail lift and no vehicle has one, rather than a shorter list with no reason attached.

Inside the engine: the vehicle routing problem

The vehicle routing problem, or VRP, is the formal version of what this software does: given a set of stops, one or more depots, and a fleet with limited capacity, find the set of routes that minimizes total cost while satisfying every constraint. It generalizes the travelling salesman problem, which handles one vehicle and no constraints, into something resembling a real delivery operation.

The variants have names, and knowing which one you have is the single most useful thing you can bring to a vendor conversation. CVRP once capacity binds. VRPTW once customers have appointment windows. Pickup-and-delivery once loads must be collected before they are dropped. Multi-depot once vehicles start from more than one site. Skills or compatibility variants once a stop needs a specific vehicle or a certified driver. Split delivery once one order can be served by two vehicles. Open VRP once drivers do not return to the depot. Periodic VRP once stops recur on a weekly pattern. And min-max or fairness objectives once the goal is balanced days rather than the shortest total. Products in this category quietly assume one or two of these and model the rest badly, which is why a demo can look perfect and a pilot can fall apart.

It is NP-hard, which means no known algorithm finds and proves the best answer in time that grows polynomially with the number of stops. You cannot enumerate your way out. One vehicle with 20 stops has more than 60 quadrillion distinct sequences; add a second vehicle and an assignment decision and the space stops being describable. Specialised solvers have proved optimal tours for pure travelling salesman instances with tens of thousands of cities, and the Waterloo TSP project documents those record attempts in detail. Add capacity, time windows and driver breaks, though, and exact methods top out in the low hundreds of stops. A depot dispatching 40 vans against 3,000 parcels sits far outside that range every single day.

Three consequences follow, and they should shape how you read any product claim. First, you never get the optimal route. A vendor using the word optimal is either solving a toy instance or using it loosely; what you get is a good feasible solution with an unknown gap, under a time budget somebody chose. Second, the gap that matters is against your current plan, not against theory. A solver landing within 1% of the theoretical best is commercially irrelevant if your dispatcher was already within 4%. Third, compute time is a dial, because every metaheuristic improves with more seconds. A demo on a 60-second budget and a production run capped at 5 seconds are different products, and you should find out which one you are being shown.

Then there is the objective, which is rarely distance. A working cost function blends driving time, distance, vehicle fixed cost, overtime, lateness penalties, and usually a fairness term so one driver does not finish at eight while another finishes at two. Setting those weights is a negotiation with operations, not a technical decision, and it is the most common reason a technically correct router produces plans nobody wants to run.

The solver under most route optimization software

Under nearly every product in this category is a metaheuristic. It builds a feasible solution quickly with a construction heuristic, then improves it through local search moves under a strategy that escapes local minima. This machinery predates the current AI cycle by decades.

The names worth knowing are few. Google's OR-Tools routing library pairs constraint programming with local search and metaheuristics including guided local search, simulated annealing and tabu search, and its routing documentation is the clearest free account of how these systems fit together. LKH-3 extends the Lin-Kernighan-Helsgaun travelling salesman solver to constrained routing and is what most teams benchmark against. Hybrid genetic search sits alongside it as the current leader on standard capacitated instances.

None of that is machine learning. It is operations research, refined over thirty years, and the benchmark literature says learned models have not caught up on the search itself. The attention-based reinforcement learning models that opened this line of work, starting with Kool and colleagues in 2019, land close to but behind the best classical heuristics on standard capacitated instances. The Routing Arena benchmark suite, which evaluates machine learning and operations research solvers under matched protocols and time budgets, reaches the same conclusion: recent operations research solvers still set the state of the art on quality and runtime alike.

So when a product is sold as AI route optimization, the useful follow-up is which part is learned. If the answer is the optimizer, ask for numbers against LKH-3 or hybrid genetic search. If the answer is the inputs, you are talking to someone who understands the problem.

How to tell whether a routing solver is any good

Solver quality has an established vocabulary, and vendors who know the field will recognise it. Public benchmark libraries exist for exactly this: CVRPLIB for capacitated instances, the Solomon and Gehring-Homberger sets for time windows, the Li and Lim sets for pickup and delivery. Each carries best-known solutions, so quality is expressible as a gap to best known at a fixed time budget.

Those two words, fixed budget, carry the weight. Hexaly's published comparison on Solomon and Gehring-Homberger instances gives one minute to three solvers and reports gap to best known as instance size grows. Its own Hexaly 15.0 moves from 0.2% at 100 customers to 4.7% at 1,000. OR-Tools 9.14 moves from 1.5% to 14.4% across the same range. Gurobi 11.0, a general mixed integer solver rather than a routing specialist, degrades from 5.5% to 186.6%. Read it as a vendor benchmark, because it is one, but the shape is the lesson: quality falls off as instances grow, and a number quoted without an instance size and a time budget attached means nothing.

Those numbers do not transfer to your operation, but they tell you whether the engine is credible. The number that decides a purchase is different: the plan the solver would have produced on 30 of your historical days, against what actually happened. The vendors who decline to run it are telling you something.

Where AI route optimization genuinely helps

Machine learning earns its place in this software on the inputs, not the search. The solver is only as good as the numbers handed to it, and those numbers are predictions.

Travel time prediction is the largest lever. Routing engines consume a matrix of times between every relevant pair of points, and that matrix is a forecast that varies by hour, day of week, direction and season. Graph neural networks are the current best answer: DeepMind reported that deploying graph neural networks for traffic prediction in Google Maps cut ETA errors by up to 50% in cities including Berlin, Jakarta, São Paulo, Sydney and Tokyo, with the production architecture published in full. A solver fed a bad matrix optimizes confidently toward a plan that cannot happen.

Service time prediction is the underrated one. How long a stop takes depends on whether it is a loading dock or a fourth-floor walk-up, the parcel count, whether a signature is needed, and the time of day. In dense urban delivery, time at stops routinely exceeds time driving between them, so a five-minute error per stop across 120 stops dwarfs anything sequencing can recover. The model trains on your own telematics and proof-of-delivery timestamps, and almost nobody markets it as AI.

Access point learning is the quiet one. An address geocode is usually a rooftop centroid, while the driver needs the loading bay or the one legal parking spot around the corner. Learned access points from historical GPS traces beat any address database, and they shift travel time and service time together.

Failure prediction closes the loop. A first-time miss costs an entire second visit, so predicting which customers will be out is often worth more than a shorter route.

What the Amazon Last Mile Routing Challenge proved

The cleanest public evidence for where learning helps came from a competition Amazon ran in 2021 with the MIT Center for Transportation and Logistics. Rather than asking teams to minimize distance, it asked them to propose stop sequences experienced drivers would rate as high quality, because Amazon's planned routes and its drivers' executed routes did not match for reasons invisible to the optimizer: road blockages, parking, building access, and knowledge accumulated over months on a territory. The dataset released with the challenge covered 9,184 real routes driven across five US metropolitan areas in 2018, and the MIT challenge awarded 175,000 dollars in prizes across 45 submissions.

The winners were William Cook, Stephan Held and Keld Helsgaun, which is a detail worth pausing on, because those three are the people behind the Concorde TSP solver and the LKH solver family. Their method was a penalty-based local search extending the LKH machinery, with driver preferences extracted from historical data and encoded as constraints for a classical solver to optimize against. A competition framed around machine learning was won by the authors of the classical solvers, with the learning applied to the objective rather than the search. That is the pattern that generalizes.

Dynamic route optimization software and live re-routing

Live re-routing is the dynamic vehicle routing problem: some information only arrives after the plan is already in motion. A new order comes in, a delivery fails, a road closes, a van breaks down, or a stop estimated at eight minutes takes thirty-five. The academic taxonomy separates static from dynamic problems and deterministic from stochastic inputs, and Pillac and colleagues' review is still the standard map of that territory.

The engineering, though, is less about a smarter algorithm than about restraint. Four mechanisms do most of the work.

A commit horizon. The next few stops on each route are frozen and cannot be reassigned. Without this, a router re-solving every minute keeps moving work between vans and drivers stop trusting the plan inside two days. Commit depth is a policy dial: two stops for dense urban parcel, a whole leg for long-haul.

Event triggers rather than a clock. Re-planning on a timer wastes compute and creates churn. Working systems re-plan on meaningful events: a stop finishing past a lateness threshold, a new order in a served zone, a closure on a committed leg, a vehicle going offline.

Stability in the objective. An explicit penalty for deviating from the published plan means the solver only moves a stop when the improvement exceeds the disruption, so noise in the traffic feed does not reshuffle the afternoon.

Warm starts. Seed the solver with the current plan rather than restarting cold. On a three-second budget mid-shift, a warm start yields an improvement while a cold start yields something arbitrary.

There is also a modeling choice most teams make by accident. Plan against mean travel times and roughly half your legs run late by construction, with the lateness compounding down the route. Planning against a higher percentile, or sampling scenarios and optimizing expected cost, buys reliability at the price of slack. Which percentile is a business decision about what a missed window costs you, and it belongs in a config file rather than in whatever the matrix API returned.

Worth saying plainly: most systems marketed as real-time AI routing run a periodic re-solve against a fresh traffic feed. That works, and it is a reasonable design. It is just not a different algorithm.

What route optimization software costs

Route optimization software is priced four different ways, and the model matters more than the headline number, because each one bills something different about your operation and only one of them tracks the value you get.

The enterprise end of the category mostly declines to publish at all, which is itself information: the price is being set by what your operation is worth rather than by what the software costs to run. Budget for a procurement cycle to match, and ask early where their smallest customer sits, because a product priced for national carriers rarely fits a regional one.

The fourth row is the one worth doing arithmetic on, because it is the cost of assembling the software yourself and it is where teams get surprised. Solver calls are the small number: a depot planning 500 stops a day across 22 working days is 11,000 shipments a month, roughly 330 dollars at the entry Fleet Routing rate. The travel time matrix is the large number, because it is quadratic in stops. A 500-stop instance needs a 500 by 500 matrix, which is 250,000 elements, and Google's Compute Route Matrix Essentials SKU bills 5 dollars per 1,000 elements at its entry tier with 10,000 free billable events a month. That is 1,250 dollars for a single matrix build before you have solved anything. Volume tiers take the marginal rate down substantially, but the shape does not change, and it is the single reason serious teams self-host a routing engine such as OSRM, Valhalla or GraphHopper on their own map extract. That decision is architectural and hard to reverse, so make it before the first invoice rather than after.

Free and open-source route optimization software

Free route optimization software exists, and it is not a stripped-down tier of something better. It is the same class of engine that sits inside the paid products. Three are worth knowing.

OR-Tools is the default first stop: Google's optimization suite under the Apache License 2.0, with a routing library covering vehicle routing and travelling salesman problems alongside constraint programming and mixed integer solvers. It is also the best documented, which matters more than it sounds when you are debugging why a constraint did not bind.

VROOM is narrower and faster to stand up. A C++20 engine under a BSD-2-Clause licence, it handles TSP, capacitated routing, time windows, multi-depot heterogeneous fleets and pickup-and-delivery with time windows, and it plugs straight into OSRM, Openrouteservice or Valhalla for the matrix. Or it takes a cost matrix from anywhere you like.

Timefold Solver is the one to reach for when routing is tangled up with rostering. Forked from OptaPlanner on 20 April 2023, Community Edition under Apache-2.0, it solves vehicle routing with time windows in the same model as employee scheduling and maintenance planning. If your real problem is which technician goes where, that matters.

So what does free actually cost you? Everything around the solver. No dispatcher interface, no driver app, no order ingestion, no proof of delivery capture, no exception workflow, no support contract, and nobody to call when a plan comes back infeasible on a Monday morning. You are getting the component that was never the hard part, which is precisely why nobody charges for it. Open source is the right call when you have engineers and a constraint set the packaged products model badly. It is the wrong call when what you needed was a dispatcher screen.

Build versus buy route optimization software

Buy when your problem is standard. Capacitated vehicles, customer time windows, a single depot, one country's driver rules and a fleet under a few hundred vehicles describes a problem packaged software solves well, encoding years of constraint modeling you will not reproduce on a first build. If you are replacing manual planning, the step change comes from the category itself rather than from bespoke code, and paying a licence to skip two years of learning is straightforwardly good value.

Build when the constraint set is genuinely yours and the packaged data model fights it. That is what happens in auto transport, where freight is priced per vehicle and routed on carrier lanes rather than counted in pallets, and in any operation whose real constraint is not weight or volume. It is also the right call when routing has to sit inside a product you already own, because a routing engine bolted onto a platform through a nightly file exchange gives up most of what makes it useful.

The scoping mistake to avoid: teams budget a build as though the solver is the work. It is not. The solver is a free library. The work is the four data contracts below, the return path that feeds the predictors, and the operational judgement encoded in the cost function. We wrote separately about making that call in build versus buy for software, and about the platform underneath it in transportation management systems.

How route optimization software integrates with a TMS or fleet platform

A routing engine is useless until it is wired into the systems holding the orders, the fleet and the drivers, which usually means a transportation management system on one side and a fleet or telematics platform on the other. Integration is where these projects succeed or fail, and it comes down to four data contracts.

The matrix contract sets your cost and latency ceiling, as the pricing arithmetic above showed. Commercial APIs also cap request size: Google's Routes API limits a route matrix to 625 elements, dropping to 100 in the traffic-aware optimal mode, so at real scale teams either batch aggressively with caching or self-host.

The return path is the contract most projects never build. Pushing plans out is easy and everyone does it. Getting actual arrival times, departure times, proof-of-delivery timestamps and GPS breadcrumbs back into the same data layer is what makes the learned models possible at all. Without it you own a routing engine that plans no better in year three than on day one. On the carrier side, load tenders and status messages still move over EDI, with the X12 204 and 214 transaction sets doing most of the work alongside telematics and ELD APIs; we covered that surface in our guide to logistics management software.

This is where we spend most of our own engineering time in logistics and supply chain. When we rebuilt the auto transport management platform for Conveya, the real work was a shipment record that quoting, dispatch, tracking and the customer app all read from, so the dispatcher's plan and the customer's status cannot drift apart. In HaulBreeze, the supply chain platform we run as our own product, the same principle appears as one data layer under inventory and orders. Route optimization only works on top of a record like that. Without one, the solver plans against a version of reality that three other systems quietly disagree with.

Route optimization software for delivery, fleet, and field service

The constraint families change by operation; the underlying problem does not. Which variant you are buying decides which capabilities you should be testing.

Delivery and courier work is a different problem from linehaul, not a smaller one. The Capgemini Research Institute has put last-mile delivery at 41% of total supply chain costs, which is why it attracts most of the optimization spend, but its economics surprise teams arriving from freight. Density inverts the cost structure: with 150 stops inside a few square kilometres, consecutive stops sit two or three minutes apart and the day goes on parking and getting into buildings rather than on driving. Shaving 40 seconds off the average stop beats any reordering the solver could find, which is why service time prediction matters more here than sequencing. Our piece on last-mile delivery software covers the surrounding platform.

Fleet and long-haul routing inverts that again. Legs are long, stops are few, and the binding constraints are the duty clock, vehicle compatibility and depot hours rather than parking. Compliance modeling is the thing to test hardest, and the ELD integration is not optional.

Field service routes around appointment windows and technician skills rather than capacity, so the skills-matching model and the ability to hold a promised slot matter more than distance. Waste collection routes around weekly patterns and vehicle fill, grocery around temperature and promised slots, and vehicle logistics around carrier lanes rather than pallets.

One structural point applies across all of them: territory design usually beats sequencing. Which stops belong together and which van owns which zone sets most of the achievable efficiency before the sequencer runs, and a badly designed territory cannot be rescued by any sequence. Driver familiarity compounds that, which argues against re-optimizing territories daily. A driver who knows a zone is measurably faster on it, so reshuffling every morning to chase a 2% distance gain can cost more in slowdown than it returns. That is the tension the Amazon challenge exposed, and why stability penalties belong in the objective.

How to evaluate route optimization software vendors

Feature grids will not separate these products, because every vendor ticks every box. Questions will. These six are the ones that produce different answers from different vendors, which is what makes them useful.

• Which solver is underneath, and can it run on 30 of our historical days?
• Where do travel times come from, and are they time-dependent and direction-dependent?
• Is the driver duty clock an input to planning or a check applied afterward?
• What is the re-optimization policy, and what is the commit horizon?
• Which execution actuals do you ingest, and do the models measurably improve from them?
• What does the system return when an instance is infeasible?

The last one is more revealing than it sounds. A product that returns nothing when the constraints cannot all be satisfied has never been used on a bad day.

Four more things belong in a serious evaluation, and none of them appear on a feature grid.

Ask what time budget the demo ran on, because a plan produced in 60 seconds and one produced in the 5 seconds your dispatch window allows are different products wearing the same interface. Ask for the hard limits in writing: maximum stops per route, maximum stops per optimization run, maximum vehicles. Packaged products carry caps that never appear in marketing copy and that you will hit on your worst day, not your average one. Ask what implementation actually involves, because the gap between same-week onboarding and a consulting engagement measured in quarters is the largest single cost difference in the category and it is almost never priced on the page. And ask for the pricing model against your real volume profile, peak included, rather than your average month, because the per-order and per-task models above look cheap in an average week and expensive in November.

What route optimization actually returns

Report results against your own baseline, measured the same way, across enough days to survive weather and seasonality. Anything else is a demo.

The best-documented deployment in the field is still UPS. According to INFORMS, which gave the project its 2016 Franz Edelman Award, the ORION on-road routing system saves roughly 100 million miles and 10 million gallons of fuel a year at full deployment, against a build cost near 250 million dollars and reported annual savings in the 300 to 400 million dollar range. Before extrapolating: UPS runs tens of thousands of drivers, and ORION took the better part of a decade with a large in-house operations research team. It is evidence the category works at scale, not a benchmark for a 40-van operation.

What to measure on your own fleet, in rough order of usefulness:

• Distance and time per stop, never totals, because totals move with volume.
• Stops per route at constant service quality, which is where fleet size reductions show up.
• Planned versus actual arrival error, which measures your travel and service time models rather than your solver, and tells you where to invest next.
• On-time window compliance and failed delivery rate, both customer-visible and both responding to different levers than distance.
• Route adherence, the share of stops served in the sequence given. Low adherence means the plan disagrees with reality, and no distance saving survives it.
• Planner hours per plan, frequently the largest and least discussed win.
• Overtime hours and routes exceeding duty limits, the compliance face of the same plan.

Two disciplines make those numbers mean something. Run the comparison as a proper split, by depot or by alternating days, rather than this month against last month. And attribute honestly: if you also redrew territories, deployed a driver app and cleaned your geocodes in the same quarter, the software did not do all of it. In our experience the geocode cleanup alone often accounts for more of the gain than the optimizer.

Choosing route optimization software without buying the pitch

Route optimization software is real, well understood, and mostly not new. The optimization core is mature operations research that works and is available free under an Apache licence, so nobody's advantage lives there. The genuinely learned parts sit around it: predicting how long a leg takes at 4pm on a Friday, how long a stop takes in a building with no loading bay, where a van can park, and which plans drivers will follow rather than quietly rewrite.

That changes what you are actually shopping for. You are buying constraint coverage, a dispatcher workflow that survives a bad morning, an integration surface that reaches your orders and your duty clocks, and a feedback loop that carries execution back into the models. That loop is a data engineering job before it is a modeling one, which is how our AI software development team scopes it. Software that never learns from its own actuals is an expensive calculator; software that does gets better every week without anyone touching the algorithm.

So take two questions into every demo. Ask which part of the AI is learned, then ask what the plan does when a driver runs 40 minutes late at stop 12. The answers tell you whether the system was built by people who have watched a dispatch board on a bad morning.