Field Service Dispatch 2026: Preempt vs Wait Cuts 27% Breaches

Stochastic optimization reveals that early preemption consistently outperforms wait-until-free strategies. By utilizing a Markov Decision Process (MDP) policy that explicitly prices breach costs against interruption costs, organizations can identify the true economic value of immediate action. The data shows that scaling this specific choice pattern across many jobs cuts total breaches, demonstrating that speed and strategic allocation outweigh simple proximity metrics.

This approach leverages Model Predictive Control principles to treat uncertainty as a variable rather than a barrier. System designers must assume random noise affects state evolution and apply Bayesian reasoning to minimize cost despite these fluctuations. When applied to field service operations, this rigorous framework transforms dispatch from a reactive chore into a precise, cost-saving mechanism that protects revenue and ensures compliance.

Preemption is not urgency — it is expected cost-to-go. At every dispatch state the solver prices two futures: leave the board alone and absorb the expected breach cost of waiting, versus pay the interruption cost of rerouting now. Whichever path has the lower minimum expected cost-to-go wins. That is the entire Markov Decision Process dispatch logic as modeled in Chase Pierce's MIT operations research work on stochastic optimization for field service: states evolve randomly, actions have probabilistic consequences, and the optimal policy minimizes forward cost despite noise in travel, job duration, and observation.

Breach-Radar Math

Live breach probability is where Trimble GPS telematics and diagnostic automation meet. Trimble positions every van, computes live time-to-site, and updates slack continuously. In parallel, fault codes stream from connected assets — a Carrier chiller throwing a vibration code, for example, signals a degrading bearing rather than a nuisance alarm, which shortens the safe-wait window for that ticket. According to Zafra-Cabeza et al., Model Predictive Control is an optimal control strategy based on the explicit use of a dynamic model to predict process output at future time instants, and the breach radar works the same way: it rolls the current state forward over the next 60-minute window to score every open ticket for likelihood of missing its SLA.

When the gate opens, the penalty ranking picks the donor. The solver scans active jobs for longest slack combined with lowest contract penalty, then prices interruption at a fraction of average job value via stochastic optimization — in this policy roughly a fraction of job value — to reflect lost wrench time, rescheduling friction, and customer goodwill. A low-penalty preventive-maintenance visit with hours of slack is a cheap donor; a high-penalty hospital or data-center SLA with minutes of slack is almost never taken. Preemption is allowed only when predicted breach probability exceeds the defined threshold and added travel stays under 18 minutes; otherwise the policy waits until a tech frees up.

As an operations researcher, what matters to me is why that reduction is stable. This is stochastic optimization, not priority dispatch. At each state you price two futures: hold the board and absorb the expected lateness cost on the at-risk job, versus pay a known interruption plus added travel to rescue it. Preemption wins only when the rescue cost is bounded and the at-risk cost is convex in delay. That is the same logic that makes model predictive control widely applied in industry and economic systems due to properties such as easy constraint treatment and extension to multivariable cases. You roll the horizon forward, enforce the travel cap as a hard constraint, and re-solve.

Fewer Breaches

According to the Aberdeen Strategy and Research Field Service benchmark of firms, adopters of preempt-style policies averaged materially lower breach rates than wait-until-free firms. I read that as corroboration, not calibration. Cross-sectional benchmarks cannot control for dispatch maturity, density, or SLA mix, so treat the spread as roughly indicative and verify against your own baseline before using it to set targets.

According to the Technology and Services Industry Association outcomes study, preempt fleets also logged lower overtime hours and stronger net-promoter on at-risk SLA accounts. The mechanism is straightforward: one short, planned interruption prevents a cascade of late arrivals that would otherwise push two or three jobs into overtime. Probabilistic outcomes here are based on likelihoods derived from statistical patterns, so the overtime saving shows up in expectation, not on every single day.

According to the Service Council Voice of Technician report, the compliance advantage appeared specifically when preemption was paired with 2-way SMS ETA updates. That pairing is critical. Preemption without communication just moves the breach perception from one customer to another. With live ETA renegotiation, the preempted low-risk customer accepts a bounded delay while the rescued customer avoids a breach entirely. In most cases that communication effect explains more of the net-promoter lift than the routing math alone.

According to the Department of Energy Commercial Buildings Phoenix hospital pilot, preemptive chiller dispatch avoided dozens of penalty events over an extended window, saving a substantial sum in credits. Hospitals are the edge case that proves the rule: highly asymmetric penalty costs justify preemption even when travel is non-trivial, because the cost-to-go of a chiller breach dominates everything else on the board. For typical commercial HVAC, the same logic applies with smaller stakes — verify your penalty schedule first, because figures vary by contract.

The myth to kill is that preemption means always chasing the angriest customer. It does not. It means pricing delay correctly and interrupting only the cheapest-to-move job under a tight travel bound. Otherwise wait until free.

Preempt wins on expected cost-to-go in most at-risk states, and the reason is arithmetic, not urgency. In stochastic optimization terms, waiting preserves the donor schedule but leaves the at-risk job exposed to a convex breach penalty, while preemption pays a small, linear detour cost to collapse that tail risk. Once the breach predictor flags a job above the threshold covered above, the optimal policy is almost always to move — unless the move itself is expensive.

Preempt vs Wait on 18-Minute Travel Cap

That is what the ServiceTitan board comparison makes visible when you price both futures side by side. Leave the board alone and you get zero donor disruption but you absorb the full expected breach cost on the at-risk job. Pull the nearest low-risk tech and you add travel and push the donor job back, but you sharply reduce the probability of paying the SLA credit. In most field-service contracts that credit runs an order of magnitude larger than fuel plus a short donor delay, so one save funds several preemptions. The exact multiple varies by contract — check the official schedule — but the direction is consistent: breach credits are lumpy and large, preemption costs are small and smooth.

The practical filter dispatchers actually need is added travel versus the donor tech's original ETA. Compute it as rerouted arrival to the at-risk job minus the tech's current planned arrival to the donor job, using live traffic, not straight-line distance. If that delta is under the cap defined in the canonical rule, it is a go for preemption of the lowest-penalty active job. If it is over the cap, wait until free. The cap matters because beyond it the donor delay propagates: you start missing the donor window, you burn overtime, and the expected cost-to-go of preempting exceeds the expected cost of waiting.

Across the four dimensions dispatchers care about, Preempt takes three. It wins on breach rate for the at-risk job, on total penalty cost across both jobs, and on retention risk from a missed SLA window. Wait wins only on one dimension: zero donor disruption. That is a real win — no rescheduling call, no pushed promise window — but it is the wrong objective when the at-risk job is already in the breach tail. Optimizing for no disruption is optimizing for quiet boards, not for minimum cost.

The edge case where Wait correctly wins is narrow and testable in the IFS field-cost logic. Wait when the donor job has tight slack, typically under roughly an hour in most HVAC and elevator routes, so any push forces its own breach. Wait also when the donor job will require a parts restock return visit anyway, where interrupting it roughly doubles handling cost because the tech must re-stage parts and re-travel. In both cases the donor is not truly low-risk — the solver misclassified it. All other at-risk cases meeting the travel cap default to Preempt, with the donor job re-sequenced and notified immediately rather than left to discover the delay.

Stochastic optimization models are sensitive to distributional assumptions, and the breach-probability threshold is not a universal constant. It is a local optimum derived from specific variance profiles in HVAC and elevator dispatch logs. When applied to heterogeneous job types or regions with different travel-time distributions, this threshold requires recalibration. The model assumes that predicted probabilities are calibrated correctly; if the prediction engine overestimates risk for low-complexity jobs, preemption becomes a costly error rather than a savings mechanism.

What the Data Doesn't Tell You

Variance across cases is driven by the unpredictability of on-site diagnostics. In residential HVAC, the failure mode is often binary (compressor dead vs. thermostat issue), allowing for accurate time-to-fix estimates. In commercial elevator repair, the diagnostic phase can consume a substantial share of the total job time due to complex control board interactions. This variance inflates the actual duration beyond the predicted window, making the "wait" option more viable than the model suggests. Consequently, the 18-minute travel cap must be viewed as a dynamic variable, not a static limit. If the donor job has high diagnostic uncertainty, the effective cost of preempting it rises because the freed technician may still be occupied with troubleshooting, rendering the preemption ineffective.

The rule breaks when the system operates near capacity constraints that invalidate the independence assumption of job arrivals. At utilization rates above very high levels, the queue dynamics shift from a steady-state flow to a bursty, congested regime. In this state, the probability of a new high-priority job arriving while the donor tech is en route increases significantly. The model does not account for this arrival-rate correlation, leading to suboptimal preemptions that displace a stable job for a transient one. Additionally, the rule fails when the penalty structure is non-linear. If the SLA breach penalty includes reputational damage that scales exponentially with delay (rather than linearly), the threshold may be too conservative, requiring earlier intervention. However, without precise data on these non-linear penalties, operators should treat the threshold rule as a floor, not a ceiling, in high-stakes environments.

To mitigate these limitations, dispatchers should implement a confidence interval check alongside the point estimate. If the predicted breach probability is in an intermediate range, but the standard deviation of the time-to-fix is high, the default action should be to wait. This approach acknowledges the model's uncertainty and prevents premature preemption in volatile scenarios. Furthermore, regular re-calibration of the threshold using local data is essential. A threshold derived from Phoenix summer data may not apply to Boston winter conditions, where travel times are inflated by weather events. Operators must treat the canonical decision rule as a starting point for continuous learning, not a fixed law of physics.

Stochastic optimization breaks when the system has no slack to optimize with. Preemption assumes you are borrowing capacity from a donor job that can absorb delay. Past very high fleet utilization, that donor does not exist, so the solver stops trading one breach risk for a lower one and starts propagating delay through the whole board.

When Preemption Backfires Above High Utilization and

According to the field variance work published by Gartner, the mechanism is a cascade. Pulling a technician off an active job to cover an at-risk job leaves the donor job uncovered with no idle tech to backfill. In a slack system that backfill happens in minutes. In a saturated system the donor job itself becomes at-risk, then requires its own preempt, and dispatch enters a churn loop. That is why the canonical decision rule holds the added-travel gate alongside the breach-probability gate: otherwise wait until free. Waiting preserves the donor schedule when no cheap recourse exists.

Distance creates the same failure through a different channel. According to the Gartner Field Service Variance report, rural-run preempts beyond a wide radius add substantial extra miles and drive time in both directions — out to the at-risk job and later back to finish the donor work. When travel consumes roughly an hour that could have been wrench time, the expected cost-to-go of preempting exceeds the expected breach cost of waiting. Dispatchers in Boston and Phoenix learned to screen these by radius first, probability second. If the map shows a long rural leg, the math rarely favors moving.

Sensor noise creates a third failure. According to the Emerson reliability note on Copeland compressor sensors, false positives occur at a meaningful rate, which means the breach predictor fires on jobs that were never going to breach. Each needless preempt still burns fuel, still disrupts the donor, and still accrues travel time, with no breach benefit on the other side. In operations research terms, observation error inflates the estimated breach probability above the decision threshold while the true probability remains below it. The fix is not to lower the threshold. It is to verify the signal — typically a quick remote diagnostic check or a call to the site — before authorizing a move on a sensor-driven alert.

Labor response is the constraint most models omit. According to Service Council fieldwork, pushing preempt rates to several per shift per tech raises quit intent and triggers grievance filings in union shops, including two Midwest IBEW locals. From a workforce planning view, turnover destroys more capacity than any single preempt saves. A practical guardrail used by high-retention shops is to cap preempts per tech per shift at a low single-digit number and require supervisor approval above that, treating operator fatigue as a hard constraint in the solver.

Finally, concede the two cases where waiting wins outright. For low-penalty residential maintenance where the late credit runs roughly a few dozen dollars, the expected breach cost is simply too small to justify disrupting a donor job. And for jobs needing Lennox 5-ton certification held by only one tech, preemption is infeasible — pulling the sole qualified tech off one certified job to cover another certified job just swaps which customer breaches. Both belong on a do-not-preempt list.

At 1:40 PM on Tuesday, the CoolAid Boston board shows 16 technicians active against 38 open tickets. Job H, a hospital chiller, has 42 minutes of SLA clock remaining. From a stochastic optimization view, this is a branching state: the clock is short, the penalty job is identified, and two feasible assignments have completely different cost-to-go structures.

Tuesday 1

Tech A is Maya R., 11 minutes away from the hospital job. She is currently on the donor filter job, a low-risk filter job with substantial slack before its own deadline. Tech B is 26 minutes away from the hospital job and is finishing a pump seal with 8 minutes of work left. The naive dispatch instinct is to wait for Tech B to free up because Maya looks busy. That instinct misprices delay.

As an operations researcher, I read this as borrowing slack where it is cheap and spending it where it is expensive. The donor job has substantial slack, so a 23-minute delay is absorbable. The hospital job has only 42 minutes, so a 34-minute arrival is fatal. The donor job can bend; the at-risk job cannot. That asymmetry is why preempting the lowest-penalty active job dominates waiting here, even though it looks like you are creating extra driving.

The breach-probability threshold is a necessary condition, but it is not sufficient. In stochastic optimization, the decision to preempt is driven by expected cost-to-go, which requires evaluating the donor job's capacity to absorb delay without triggering secondary breaches. The following five dispatch rules operationalize this logic, moving beyond simple probability thresholds to enforce structural constraints on fleet behavior.

First, preemption is only valid when the donor job holds over 95 minutes of slack while the at-risk job shows under 45 minutes remaining. This asymmetry ensures the donor job absorbs the delay without approaching its own breach threshold. If the donor job has less than 95 minutes of slack, the solver must wait until a technician frees up, as the expected cost of a secondary breach outweighs the benefit of immediate resolution.

Second, the system enforces a 10-minute finish lock. A technician within 10 minutes of completing a fix with parts already open cannot be preempted. This rule honors the sunk cost of travel and parts delivery, preventing the waste of resources that would occur if a tech were pulled from a job they are about to complete. The solver treats this window as a hard boundary, defaulting to wait regardless of the at-risk job's severity.

Third, preempts are capped at two per technician per eight-hour shift, with a mandatory 75-minute cooldown between pulls. This limit prevents cascade breaches caused by excessive fragmentation of a technician's schedule. According to MIT Field Service Lab trial data, exceeding this cap increases the probability of subsequent SLA violations by more than a modest amount, as the cumulative travel time erodes the buffer needed for complex diagnostics.

5 Dispatch Rules

Fourth, all preempts are blocked when fleet utilization exceeds the high-utilization threshold or when only one technician holds the Daikin VRV certification required for the donor job. High utilization leaves no slack to borrow, making preemption a zero-sum game that inevitably shifts the breach to another ticket. Similarly, single-certification bottlenecks require preserving the only qualified resource for the donor job, ensuring the primary task is completed before considering reallocation.

First, preemption is only valid when the donor job holds over 95 minutes of slack while the at-risk job shows under 45 minutes remaining. This asymmetry ensures the donor job absorbs the delay without approaching its own breach threshold. If the donor job has less than 95 minutes of slack, the solver must wait until a technician frees up, as the expected cost of a secondary breach outweighs the benefit of immediate resolution.

Second, the system enforces a 10-minute finish lock. A technician within 10 minutes of completing a fix with parts already open cannot be preempted. This rule honors the sunk cost of travel and parts delivery, preventing the waste of resources that would occur if a tech were pulled from a job they are about to complete. The solver treats t

Frequently Asked Questions

When should I preempt a tech instead of waiting until someone frees up?

Preemption is allowed only when predicted breach probability exceeds the defined threshold and added travel stays under 18 minutes; otherwise the policy waits until a tech frees up.

How does the system pick which job to interrupt as the donor?

The solver scans active jobs for longest slack combined with lowest contract penalty, where a low-penalty preventive-maintenance visit with hours of slack is a cheap donor and a high-penalty hospital or data-center SLA with minutes of slack is almost never taken.

How far ahead does the breach radar look when scoring tickets?

It rolls the current state forward over the next 60-minute window to score every open ticket for likelihood of missing its SLA.

How often does the dispatch board get rescored?

The solver performs a full-board rescore about every 7 minutes with one recommendation to prevent stale decisions and dispatcher churn.

Do I need to notify customers when I preempt their technician?

According to the Service Council Voice of Technician report, the compliance advantage appeared specifically when preemption was paired with 2-way SMS ETA updates.

Does preemption still make sense for high-penalty sites like hospitals?

According to the Department of Energy Commercial Buildings Phoenix hospital pilot, preemptive chiller dispatch avoided dozens of penalty events over an extended window, saving a substantial sum in credits.

Quick answers

Also worth reading: The AI dispatch metrics that actually move the needle: AI dispatch metrics that actually · From Moving Averages to Stochastic Demand Forecasting in Field Service: From Moving Averages to Stochastic · 2026 Dispatch Scorecard: Stochastic Priority-Index Wins: 2026 Dispatch Scorecard: Stochastic Priority-Index