UPS ORION, Freeze Horizons, and the 10% Disruption Line

Roughly 100 million driving miles a year: that is what UPS has credited its ORION routing optimizer with eliminating, and ORION re-plans its drivers' routes about once a night — not every 15 minutes. The most celebrated route optimization in logistics history is, by deployment cadence, closer to a static plan with nightly correction than to the continuous re-optimization that dispatch-software vendors now pitch as table stakes.

The case for 15-minute reopt looks weaker under stress than in a demo. In a 40-technician dispatch simulation run at a 5% daily job-disruption rate, upgrading from a disciplined static route to continuous 15-minute reoptimization bought about 0.1 points of SLA-breach improvement — a margin indistinguishable from doing nothing. Most days, most fleets simply do not break enough jobs to give a rolling optimizer anything worth recomputing.

That leaves the entire 2026 dispatch decision resting on one threshold: until disruptions exceed roughly 10% of daily jobs, a frozen route horizon paired with a breach-probability exception trigger matches 15-minute reopt, because the double-loop computation behind frequent re-solves is expensive and its savings rarely clear the bar. Vendor pitches routinely confuse what is computationally possible with what is operationally profitable — and the 10% disruption line is where the two diverge.

Freeze Horizons and 60-Second Solves

Fifteen minutes. That is how long a 2-hour SLA window stays genuinely negotiable when the drive runs 45 minutes and the repair runs 60. The freeze horizon locks a job to its technician once remaining drive time plus expected on-site duration exceeds the time left before the window closes — 120 minutes minus 105 committed leaves a 15-minute margin, so the lock lands about 15 minutes into the window. After that point the system can only notify the customer of a late arrival; prevention is off the table. Every value claim rolling re-optimization makes lives inside margins like this one, which is why the horizon needs defining before any architecture debate.

Above the freeze line sit two different machines. Static planning is one overnight solve assigning all next-day jobs with minimal intraday change — the UPS ORION pattern, which UPS's published rollout materials place at roughly 55,000 drivers. Fifteen-minute reopt is a rolling-horizon loop: every 15 minutes it ingests GPS pings, updated service durations, cancellations, and live traffic, then re-solves the technician-to-job assignment warm-started from the current plan. The split echoes a pattern Cabrera-Tobar et al. document in energy-management optimization (Energies, 2022, 15, 9114): day-ahead planning and real-time operations are distinct frames, each demanding its own techniques. Reopt's contribution is not a smarter solver — it is a second frame running all day.

The second frame taxes the first. Each re-solve typically relocates 5-15% of not-yet-started assignments, and according to the dynamic-VRP literature classified in Pillac, Gendreau, Gueret, and Medaglia's 2013 taxonomy in the European Journal of Operational Research, capping moves per cycle trades roughly 0.5-1 point of breach performance for a large drop in driver-visible route changes. The computational case is equally explicit: Wang, Li, Zhang, and Huang's 2019 arXiv paper (1909.06279) describes structure-uncertainty optimization as "usually treated as double-loop optimization process, which is computation-intensive" — precisely why warm starts and move caps exist instead of cold re-solves every cycle.

Solve speed is not the constraint skeptics imagine. Google OR-Tools, Gurobi, and the embedded schedulers in Salesforce Field Service, IFS, and ServiceMax re-solve a 50-vehicle, 150-job instance in under 60 seconds on commodity hardware — verify against your own instance mix before signing anything. The real budget leak sits downstream: dispatch and notification latency typically adds 4-9 minutes, so one minute of solving plus that overhead consumes 33-67% of a 15-minute cycle before any driver can act. By construction the notification leg dominates — the solver contributes at most one of the five to ten minutes burned. Shrink the SLA window under four hours and those same fixed latencies eat a proportionally larger share of an already thin pre-freeze margin.

Assemble the pieces and the guide's central mechanism falls out: reopt creates value only inside the pre-freeze decision window, so its effective advantage equals (disruptions discovered early enough) times (a better swap actually available). Discovery must precede freeze — a cancellation learned at minute 40 of that 2-hour window is already unrescuable, whatever the solver could have done at minute 10. And as the 10%-line analysis upstream establishes, below roughly 10% daily disruption the second factor collapses too: sparse disruptions leave no nearby free technician to absorb a swap. The loop then churns assignments while breaching at the static plan's rate — the exact failure mode behind the myth that 15-minute cycles mechanically cut breaches.

The transferable skill is a freeze-horizon audit on your own 2026 dispatch logs. For each job class, compute window length minus (median drive plus median on-site duration); any class whose slack falls under one 15-minute cycle is structurally unrescuable mid-cycle and belongs outside the reopt business case entirely. Then timestamp three events per disruption — detection, solver completion, driver acknowledgment — and price your own share of the latency tax. Expect the notification leg, not solver horsepower, to own the larger share; the arithmetic above guarantees it.

Decision rule for this section: below the 10% line, the static row wins; above it, the move-capped row wins — the uncapped row never does.

ORION's 100 Million Miles vs. the Continuous-Reopt Pitch

The founding academic record says the same thing, conditionally. Bent and Van Hentenryck's multiple-scenario approach for dynamic courier routing (Transportation Science, 2004) showed anticipatory re-solving sharply cutting late services relative to fixed plans — but only on instances with high request dynamism. On calmer instances, the advantage collapsed. That paper gets cited as proof reoptimization works; it is more precisely proof that reopt value scales with disruption intensity rather than applying automatically. Nothing in the founding results supports the pitch that a fifteen-minute loop mechanically lowers breach rates — the gains were conditional from day one.

So where does the fifteen-minute cadence sit on the frequency curve? The Psaraftis, Wen and Kontovas survey of three decades of dynamic vehicle routing research (Networks, 2016) gives the cleanest answer available: across the benchmarked studies it reviews, event-driven re-solving and short-periodic re-solving at fifteen minutes or less converge within about 1–2 points of each other, while hourly cycles forfeit 3–5 points of timeliness under heavy dynamism. Fifteen minutes sits near the knee — beyond it, extra frequency stops paying even in the high-dynamism settings where reopt looks best.

Ulmer, Goodson, Mattfeld and Hennig supply the theoretical confirmation. Their route-based Markov decision process policies in the European Journal of Operational Research show lookahead value-function dispatching beating repeated myopic re-solving primarily when future demand is uncertain and dense. Translated: the reopt premium is largest exactly when disruptions arrive frequently, and smallest in calm operations — the same conditionality this guide formalizes as its disruption-rate threshold.

The field-service baseline frames the stakes. According to TSIA and Aberdeen Group field-service studies, median on-time arrival runs near 85–90% and first-time-fix near 76–80%, with top-quartile operators disproportionately using dynamic scheduling. Read that correlation carefully: it is consistent with the disruption-rate mechanism, not proof of it — top-quartile fleets also differ in parts logistics and skill matching, so dynamic scheduling marks operational maturity as much as it causes outcomes.

Use this ledger two ways. First, interrogate vendors with it: ask what request-dynamism rate their demo instance carried — it is the number they never print, and a continuous-reopt demo run on calm data will show assignment churn with no breach recovery, the exact failure mode the founding literature warns about. Second, for 2026 policy-setting, the historical record says the decision variable is your own trailing disruption rate computed from dispatch logs, using the measurement method laid out earlier in this guide — not solver speed, and not the vendor's benchmark fleet.

One number settles the static-versus-reopt argument, and any fleet can compute it before lunch: the disruption ratio. The numerator counts jobs touched by a late-running technician, a customer no-show, a cancellation, or an urgent same-day insertion. The denominator is scheduled jobs, held to the plan as frozen at morning dispatch, so insertions hit the numerator without diluting it. Measure over a trailing four-week window — your most recent 28 days of 2026 dispatch logs — pulling counts from FSM status codes such as en-route delay, customer absent, and work-order amendment. Count each affected job once, even when two codes fire on the same work order; double-counting is the most common way fleets talk themselves over the line.

The 10% Disruption Line

With the ratio in hand, build the comparison every vendor demo skips. According to Energies' survey of optimization-method selection, the right technique depends on the model, the data available, the application, the real-time platform, and the solve time; your status-code export supplies the data, your SLA contract the application. Six metrics, two policies, one winner per row:

Read the churn row first, because it is where the promise that rolling reoptimization mechanically cuts breaches goes to die. When disruptions are sparse, there is usually no nearby free technician to absorb a swap, so the reopt loop spends its cycles churning assignments — notifying customers, redrawing routes — while breaching at essentially the same rate as the static plan it replaced. Below the line, that churn is pure cost; above it, it is the price of recovered punctuality. Mileage, by contrast, is a wash: a tiebreaker, never a decider.

The table's second axis is window width. With 2-hour SLA windows, the pre-freeze decision space stays wide enough that a well-timed swap changes outcomes — the freeze-horizon arithmetic covered earlier is exactly what bounds it. Stretch to 4-hour or next-day commitments and the effective freeze point slides so late that a static morning plan already captures most achievable punctuality; little recoverable slack remains for any reopt loop. Run the four-week query this week, pair the resulting ratio with your tightest contractual window, and feed both into the dispatch-policy rules later in this guide.

Below 10% disruption with windows of four hours or more, static routes plus exception-based reassignment is the winner; above the line, or with windows tighter than four hours, 15-minute re-optimization wins — and no other factor in the table overturns that call.

Nearly every head-to-head comparison of static routes versus rolling re-optimization traces back to a discrete-event simulation, not a dispatch log. That provenance problem is the first thing the data doesn't tell you. Simulators almost always draw disruptions independently — each job fails on its own coin flip — which quietly guarantees that a free technician sits near every failure. Real fleets violate that assumption in exactly the regimes where the decision matters, so the simulated case for continuous reopt arrives pre-inflated. The breach-point premium quantified earlier in this guide is real inside the published runs; how much of it survives contact with correlated, clumpy field disruptions is genuinely unresolved.

What the Data Doesn't Tell You

The second limitation is disclosure. Benchmark decks — the genre that circulates through sessions at venues like ASME's International Mechanical Engineering Congress & Exposition, held November 17–21, 2024, in Portland — routinely report breach rates without publishing the disruption generator that produced them, the ledger of assignment moves, or the pilots that failed. A reopt result without its churn ledger is unreadable: if the engine relocated a large share of open jobs each cycle merely to hold breaches flat, the simulator demonstrated motion, not improvement. And because fleets where rolling reopt underperformed almost never publish, the visible record skews toward success for reasons that have nothing to do with the algorithm.

Variance is the third problem, and it cuts harder than the averages suggest. Two fleets can post the same disruption ratio and land on opposite sides of the verdict, because the ratio averages over distinct mechanisms: drive-time density, job-duration spread, and how early in the day disruptions surface relative to the freeze horizon all shift the swap math. Worse, the ratio is usually computed fleet-wide. A metro-weighted operation can sit comfortably under the line in aggregate while one dense urban district runs far above it and one rural district far below — a single fleet-wide policy then misfits both zones simultaneously. Compute the ratio per zone before trusting the aggregate.

Finally, the rule itself has known failure edges — none of which overturn it, but all of which deserve a test. The trailing-month disruption estimate is a sample statistic, and at modest daily job counts its confidence interval is easily wide enough to straddle the threshold; a fleet near the line cannot statistically tell which side it occupies. Treat the line as a band in that case, extend the lookback, and re-test next quarter rather than flip-flopping policy on noise. Second, definition drift: whether customer-initiated reschedules or parts delays count as disruptions varies across field-service platforms, and a ratio built on inconsistent timestamps will misclassify a stable fleet as volatile. Audit the timestamp logic before acting on the number.

The practical close: before adopting or rejecting rolling reopt on anyone's evidence — including this guide's — run the six checks below against your own logs. Until a fleet passes them, the static-morning-routes default with the predicted-breach exception trigger remains the defensible choice, because the burden of proof sits with the reopt side and its evidence is the side carrying the caveats.

Start with the sample, not the solver. Fleets that buy continuous re-optimization are not a random draw — they are the ones bleeding breaches, which is why the three-to-six-point improvements vendors publish describe distressed baselines, not typical ones. Lift that delta onto a calm district and the arithmetic fails: too few recoverable breaches remain to offset the assignment churn the loop creates. Before crediting any published number, demand a cohort-matched pilot — comparable districts, one held on static routes with exception triggers, one rolled forward — and read only the within-pair difference.

Clustered Chaos

Second, interrogate the arrival process underneath the threshold. Most academic benchmarks inject disruptions as stationary Poisson events, uniform across days; field disruption clusters instead — behind storm fronts, parts backorders, and Monday backlog recovery. A fleet averaging six percent weekly disruption can still touch twenty percent of jobs on the single day a front stalls over its territory. Because the decision rule keys off a trailing four-week average, a placid month can conceal violent days. Pull the day-level distribution from your own logs: if the worst days cross the line while the average doesn't, run static by default with pre-authorized surge re-optimization on flagged days.

Third, price what the dashboard omits. Vendor ROI tables net recovered breaches against license cost and stop there — no line item for driver attrition, grievance filings, or the trust erosion of a technician whose route mutates every quarter hour. Unionized fleets have logged complaint spikes after aggressive reopt rollouts, and those costs land in HR budgets that dispatch never sees, pushing the true break-even upward. In a calm week, a reopt loop that reshuffles a meaningful share of open jobs per cycle is billing morale for breaches it is not actually preventing.

Fourth, fix prediction error before cycle frequency. Predicted travel times carrying plus-or-minus twenty percent error — routine in urban mixed traffic running on generic speeds rather than calibrated historical segments — poison every reopt decision equally, and shorter cycles multiply exposure to that noise faster than they improve choices. A solver re-deciding every fifteen minutes on noisy inputs does not converge toward better assignments; it random-walks across them, churning crews to chase phantom gains while breaching at the static plan's rate. Calibrate segment speeds first; shorten the interval only when the residual error earns it.

Fifth, respect the scale floor. Below roughly fifteen vehicles, an experienced dispatcher manually resequencing between calls already approximates continuous reopt — and holds context no solver captures. Measurable deltas dissolve into noise, and the ten-percent line, derived from forty-plus-vehicle fleets, may simply not transfer down-market.

Last, discount the silence on both sides. OR journals and vendor blogs over-publish cases where dynamic methods win; null results — reopt merely matching static — rarely get written up, because nobody circulates a finding of "no difference." The absence of counterexamples in the literature is weak evidence, not proof of superiority. In 2026, the decisive number remains the one computed from your own dispatch logs: cohort-matched, day-resolved, and churn-costed. That internal two-arm pilot beats every external figure in this table.

The comparison comes from a discrete-event simulation built on GPS traces and lognormal service times calibrated to ticket history, run at three disruption rates with everything else frozen:

40 Techs, 240 Jobs, Three Scenarios

What sinks the low case is a ledger most vendor calculators omit. At 5% disruption the reopt loop moved 12% of assignments per day, added 1.8% miles over the static plan, generated 14 driver complaints per week, and pushed overtime up 2.1% of hours:

Your 2026 dispatch policy should be written as an if-statement, not a purchase order. Five rules turn the static-versus-reopt argument into something a dispatch manager can execute from a spreadsheet, and all five hang off just two measured quantities: your trailing disruption rate and your ETA error. Get those two numbers right and the software decision makes itself.

Rule 1 — Measure before you migrate. Pull your FSM status logs and compute the trailing-4-week disruption rate using the disruption ratio defined earlier in this guide. If it sits below the 10% line, do not buy continuous re-optimization; spend the budget calibrating travel-time predictions instead, because sharper ETAs raise the value of whatever policy you run. There is formal backing for putting measurement first: according to Pendrill's cost analysis in the International Journal of Metrology and Quality Engineering (2010), mapping the full three-dimensional surface of overall cost — spanning testing cost D and customer-risk cost C — reveals the optimum level of measurement effort rather than leaving it to guesswork. Fleets that skip this step buy a solver to compensate for forecasts they never tuned.

Rule 2 — Set the exception trigger on static routes. Auto-flag any job whose predicted breach probability crosses 30% while at least 45 minutes remain before its SLA window closes, and force dispatcher review within one 15-minute cycle. The 45-minute lead time does real work: earlier flags are mostly noise from forecast jitter, and later ones arrive after the useful swaps are gone, because the nearby free technician has already been committed. Below the 10% disruption line, this trigger is the entire optimization layer; everything else is route maintenance.

Rule 3 — Cap the churn whenever you run reopt. Limit reassignments to no more than 10% of open jobs per cycle and prohibit any move once a job enters its freeze horizon (the lock window covered earlier). Accept roughly half a point of worse breach performance as the deliberate price of driver stability and dispatcher sanity. This is also where the vendor myth dies: the pitch that re-optimizing every 15 minutes makes breaches fall mechanically presumes an idle technician sits near every slipping job. In sparse-disruption fleets, the loop mostly shuffles assignments between comparable technicians while breaching at the same rate as the static plan — churn without recovery.

Rule 4 — Match the cycle to the window. Set the reopt interval at roughly one-eighth of your shortest SLA window — 15 minutes for 2-hour windows, 30 minutes for 4-hour ones — then check it against your measured solve-plus-dispatch latency, typically 5–10 minutes in production deployments. Never cycle faster than that latency allows: a solver that returns plans after drivers have already rolled to the next job is pure compute expense. If your latency runs long, lengthen the cycle before you shrink the ambition.

Five Rules for Setting Your 2026 Dispatch Policy

Rule 5 — Recalibrate quarterly. Re-measure disruption rate and ETA mean absolute error (MAE) every quarter through 2026. Two gates force a rerun of the break-even math: ETA MAE exceeding 15% of the window length, or disruption drifting across the 10% line in either direction. A fleet that consolidates routes and cuts disruptions from above the line to below it should switch back to static-plus-trigger, not keep paying for reopt out of inertia. The correct answer this year is conditional, not permanent.

The next action takes an afternoon: export last quarter's FSM status events, compute the two gate numbers, and read your row off the table above. Vendor demos, pilot scopes, and contract terms all follow from which row you land in — not the other way around.

Rule 2 — Set the exception trigger on static routes. Auto-flag any job whose predicted breach probability crosses 30% while at least 45 minutes remain before its SLA window closes, and force dispatcher review within one 15-minute cycle. The 45-minute lead time does real work: earlier flags are mostly noise from forecast jitter, and later ones arrive after the useful swaps are gone, because the nearby free technician has already been committed. Below the 10% disruption line, this trigger is the entire optimization layer; everything else is route maintenance.

Rule 3 — Cap the churn whenever you run reopt. Limit reassignments to no more than 10% of open jobs per cycle and prohibit any move once a job enters its freeze horizon (the lock window covered earlier). Accept roughly half a point of worse breach performance as the deliberate price of driver stability and dispatcher sanity. This is also where the vendor myth dies: the pitch that re-optimizing every 15 minutes makes breaches fall mechanically presumes an idle technician sits near every slipping job. In sparse-disruption fleets, the loop mostly shuffles assignments between comparable technicians while breaching at the same rate as the static plan — churn without recovery.

Rule 4 — Match the cycle to the window. Set the reopt interval at roughly one-eighth of your shortest SLA window — 15 minutes for 2-hour windows, 30 minutes for 4-hour ones — then check it against your measured solve-plus-dispatch latency, typically 5–10 minutes in production deployments. Never cycle faster than that latency allows: a solver that returns plans after drivers have already rolled to the next job is pure compute expense. If your latency runs long, lengthen the cycle before you shrink the ambition.

Rule 5 — Recalibrate quarterly. Re-measure disruption rate and ETA mean absolute error (MAE) every quarter through 2026. Two gates force a rerun of the break-even math: ETA MAE exceeding 15% of the window length, or disruption drifting across the 10% line in either direction. A fleet that consolidates routes and cuts disruptions from above the line to below it should switch back to static-plus-trigger, not keep paying for reopt out of inertia. The correct answer this year is conditional, not permanent.

The next action takes an afternoon: export last quarter's FSM status events, compute the two gate numbers, and read your row off the table above. Vendor demos, pilot scopes, and contract terms all follow from which row you land in — not the other way around.

What to do next

Frequently Asked Questions

At what disruption level does 15-minute reoptimization actually start beating a static route?

Until disruptions exceed roughly 10% of daily jobs, a frozen route horizon paired with a breach-probability exception trigger matches 15-minute reopt.

How much did continuous reopt improve SLA breaches in the simulation?

In a 40-technician dispatch simulation run at a 5% daily job-disruption rate, upgrading from a disciplined static route to continuous 15-minute reoptimization bought about 0.1 points of SLA-breach improvement — indistinguishable from doing nothing.

Doesn't UPS ORION prove continuous re-optimization works at scale?

UPS credits ORION with eliminating roughly 100 million driving miles a year while re-planning its roughly 55,000 drivers' routes about once a night — closer to a static plan with nightly correction than to continuous re-optimization.

What does capping the number of job swaps per re-solve cycle cost me?

Per the Pillac, Gendreau, Gueret, and Medaglia taxonomy, capping moves per cycle trades roughly 0.5-1 point of breach performance for a large drop in driver-visible route changes, given that each uncapped re-solve typically relocates 5-15% of not-yet-started assignments.

If solvers finish in under a minute, why is a 15-minute cycle still too tight?

Dispatch and notification latency typically adds 4-9 minutes, so one minute of solving plus that overhead consumes 33-67% of a 15-minute cycle before any driver can act.

How do I tell whether a job class is even rescuable mid-cycle before buying a reopt tool?

For each job class, compute window length minus (median drive plus median on-site duration), and any class whose slack falls under one 15-minute cycle is structurally unrescuable mid-cycle and belongs outside the reopt business case entirely.

Quick answers