# Reassign or hold: computing a per-dispatch technician break-even

Chase Pierce · October 31, 2026

> Reassign a technician only when per-dispatch break-even costs fall at or below the marginal value of a held job's SLA buffer, not just the 15-minute drive rule.

| Takeaway | Detail |
| --- | --- |
| Reassign only when the break-even total is at or below the marginal value of the held job's SLA buffer. | Break-even = (new tech's extra drive minutes × fully loaded cost per tech-minute) + customer-wait penalty of the held job; compute it per dispatch because no vendor publishes a threshold. |
| Use the 15-minute drive-time comparison as the headline reassignment threshold. | The headline frames the decision as 15-minute drive time versus holding the job. |
| Dispatch demand is visible in 89,885 Scheduling Technician and 29,096 Technician Scheduling job listings. | Indeed counts 89,885 Scheduling Technician jobs and 29,096 Technician Scheduling jobs. |
| Timefold identifies nine essential capabilities for technician scheduling software in 2027. | The 2027 capability list includes skill matching and SLA priorities among nine essentials. |

This guide gives a per-dispatch break-even method for deciding whether to reassign a technician or hold the job.

It pairs the 15-minute drive-time comparison with SLA buffer value, cost per tech-minute, and customer-wait penalty.

![Reassign or hold](https://static.mm-ais.com/article-images-ai/reassign-or-hold-computing-a-per-dispatc-ai-6456404b.jpg)

## How the Reassign-vs-Hold Decision Works

At its core, the reassign-vs-hold call is driven by a two-sided cost structure: drive-time cost vs. SLA-hold cost. This trade is the mechanism for every reassignment call. Reassigning pulls an incoming technician off the path to their already committed job, so the action does not just add drive minutes, it puts that committed job at risk of a later arrival. Holding, on the other hand, keeps that incoming technician closer to their original commitment, but it burns the waiting customer's SLA clock and can force the nearest available technician into a longer detour later. Both sides create cost, and neither side is free.

Before making the move, check both directions at the same time. For the reassignment side, ask what extra drive minutes the incoming technician must take to cover the waiting job, and whether that extra travel would meaningfully threaten the arrival for the job they were already en route to. For the hold side, ask how much of the waiting job's SLA buffer remains, and whether leaving the nearest technician in place will make a later detour larger than it is at this moment. The question is not which option looks easier, but which cost is growing faster under delay.

Modern field service scheduling platforms can help with that comparison. According to ServiceTrade, map-based schedulers expose real-time drive-time and skill-match data. According to Timefold, optimization engines can work with those same constraints. However, neither of those sources publish a default "reassign above X minutes" rule. With no vendor preset to rely on, the comparison must be built from your own dispatch conditions, not a blanket cutoff.

As a per-dispatch check, treat the decision as a direct comparison between the projected cost of pulling the incoming technician away, and the projected cost of consuming the waiting job's SLA buffer. If the cost of reassignment is projected to be greater than the cost of holding at this moment, the hold side must be justified. If holding would consume the buffer faster than reassignment would consume the incoming technician's capacity, reassignment can be the justified move. The balance shifts with remaining buffer, skill-match, and location each time, so the check must be repeated for each dispatch where reassignment is even being considered.

![How the Reassign-vs-Hold Decision Works — Reassign or hold](https://static.mm-ais.com/article-images-ai/reassign-or-hold-computing-a-per-dispatc-ai-687a03bd.jpg)

## The Evidence: What Sources Actually Show

The public record shows that scheduling vendors treat drive time and SLA-aware assignment as product capabilities, but it does not publish the measured savings or cost constants that would let a dispatcher copy a reassignment threshold from a brochure. Use these sources to identify what is documented, then verify every number against your own dispatch data.

ServiceTrade documents a map-based scheduler whose stated purpose is to create routes that reduce drive time, which is evidence that commercial dispatch treats drive time as a first-class cost. The same public page does not state how many minutes are saved per route, per technician, or per day, and it does not describe the benchmark method behind any implied savings. Before trusting a vendor's claimed reduction, request the benchmark methodology, sample size, baseline route definition, and whether the reported result is an average or a best case.

Timefold's 2026-2027 technician scheduling capability list names skill matching, SLA priorities, and real-time replanning among essential capabilities. That confirms reassignment-relevant features are marketed as standard, but the list is a capability statement rather than a performance study: it does not quantify drive-time reduction, SLA breach reduction, or the cost of switching a technician mid-route. Treat it as a feature checklist to verify in a pilot, not as evidence of savings.

A February 19, 2026 comparison from worldmetrics.org frames technician scheduling software by operational workflow—turning incoming work into scheduled assignments, tracking job status, and keeping customer updates tied to each work order. That is useful for evaluating whether a tool supports dispatch control, but it is not a source of verified savings figures or break-even constants.

| Source | Publicly documents | Not published |
| --- | --- | --- |
| ServiceTrade | Map-based scheduling to create routes that reduce drive time | Minutes saved, benchmark method, baseline route definition |
| Timefold | Skill matching, SLA priorities, real-time replanning among essential capabilities | Quantified drive-time or SLA impact, switching cost |
| worldmetrics.org (Feb. 19, 2026) | Workflow comparison for scheduling software | Verified savings figures or break-even constants |

What is missing from public grounding is any vendor-published minutes-saved figure or break-even constant. The defensible rule is to treat every published capability claim as a hypothesis to test against your own dispatch data: measure baseline drive minutes, reassignment frequency, and held-job wait time before and after a change, then compute your own threshold rather than importing a vendor's.

## Reassign Now vs. Hold: Options Compared

Dispatchers often frame the choice as reassign or hold, but a third path exists: a split-solution in which the nearest technician performs a partial fix or diagnostic while the originally assigned technician completes the job. Most dispatchers forget that third option, and that omission can turn a manageable wait into an unnecessary drive.

| Option | Wins when | Tradeoff to check |
| --- | --- | --- |
| Reassign to nearest tech | Incoming extra drive is short and the held job's SLA is at risk | Protects the SLA but spends drive minutes and may disrupt the incoming tech's committed route |
| Hold for original tech | Original tech is already close to the committed job | Avoids extra drive and reassignment churn, but the waiting job keeps consuming SLA buffer |
| Split-solution | Waiting job is diagnostic-heavy and nearest tech can start diagnostics or a partial fix | Reduces customer wait without a full reassignment, but requires clear handoff and scope control |

Reassign is the right winner only when both of its conditions are true: the incoming technician's extra drive is short and the held job's SLA is at risk. If the extra drive is not short, or the SLA is not at risk, reassign loses even if it feels faster.

Hold wins when the original technician is already close to the committed job. In that case, the avoided drive and avoided disruption usually outweigh the benefit of pulling another technician across town, provided the waiting job's SLA buffer is still being watched.

Split wins when the waiting job is diagnostic-heavy and the nearest technician can start useful work. Treat it as a distinct service path, not a compromise: it protects the customer experience while preserving the original technician's completion responsibility.

Before acting, state the winner condition in one sentence and compare it with the break-even already computed for that dispatch. If the sentence and the break-even do not point the same way, default to hold, recheck the extra drive and SLA risk, and only then reassign or split.

## Costs and Numbers That Matter

The four inputs that make a reassignment break-even computable are cost per tech-minute, SLA penalty, customer-wait penalty, and reassignment churn cost. Measure each from your own payroll, contract, and work-order records; no grounding source publishes a benchmark figure for any of them, so treat any external number as unverified. The check is simple: if a figure cannot be traced to your own records or contract, leave it out of the calculation.

Cost per tech-minute is fully loaded wages, vehicle cost, and overhead divided by productive minutes. Use actual productive minutes from your own time records rather than scheduled hours, and keep the denominator consistent: include only minutes a technician can complete work, or the rate will understate true cost. Recompute it when pay, fuel, or vehicle costs change. A useful check is to compare the rate calculated from last quarter's payroll with the rate from the most recent pay period; a large swing usually means the denominator changed, not the cost.

SLA penalty is the contractual late fee or credit per breach plus the measured repeat-call rate after late visits. Pull the fee from contract terms and the repeat-call rate from the last 90 days of work-order data. If repeat calls are not tracked by visit timeliness, start tracking before using the rate in a break-even; otherwise the penalty is understated. A practical check is to separate credits issued from repeat work created, because a small credit can hide a larger service cost.

Customer-wait penalty applies to non-contract jobs and should be estimated as the expected cost of the delay, not as a flat guess. Derive it from your own history by comparing margin, callback rate, or lost follow-on work for jobs that waited beyond your target against jobs that did not. Use the same job types and service areas so the comparison is not distorted by mix. A check is to exclude one-off discounts or goodwill credits that were not caused by the wait, so the penalty reflects delay rather than unrelated concessions.

Reassignment churn cost is the disruption cost of pulling a technician off an already committed route: extra miles, idle time, rescheduling labor, and any overtime for both technicians. Measure it from route logs and payroll, and include both the incoming and held-job technicians. If part of it cannot be measured yet, record the visible extra drive minutes first and expand the measure as data improves. A check is to compare churn on reassigned jobs with churn on jobs that were held; if reassigned jobs show lower total churn, the reassignment may be cheaper than it first appears.

## What the Evidence Does Not Establish

No source in the 2026 grounding publishes a validated universal reassignment cutoff, so any vendor figure quoted as "reassign above N drive minutes" should be treated as marketing until the vendor shows the underlying cost model. That absence is the reason this section maps boundaries rather than quoting a cutoff. The break-even rule is therefore a per-dispatch calculation, not a threshold copied from a brochure.

The rule breaks when job constraints make drive time secondary. In a skill-critical job, a nearby technician who cannot do the work has zero value regardless of drive time, so the comparison is not between two drive times but between possible and impossible service. In a multi-technician job, reassigning one person may not release the held job's value because the work depends on a crew and its SLA buffer may be consumed by coordination. When the customer is physically present and waiting, wait cost dominates and can override the drive-time side of the calculation.

| Scenario | Break-even rule | Why |
| --- | --- | --- |
| Skill-critical job | Breaks | A nearby technician who cannot do the work has zero value regardless of drive time. |
| Multi-technician job | Breaks or needs adjustment | The held job's value is not tied to one technician's drive time. |
| Customer physically present and waiting | Breaks | Wait cost dominates the comparison. |
| Single-technician, skill-matched job with no on-site wait | Still wins | Extra drive minutes can be compared directly with the held job's SLA buffer. |

The rule still wins only in the narrower case: one technician, matching skills, no customer physically waiting, and a held job whose SLA buffer is the binding constraint. There, extra drive minutes and the buffer are commensurable, so the break-even calculation remains meaningful.

Use the table as a gate before computing. If a dispatch falls in a break case, treat the break-even number as invalid for that call and hold or escalate. If it falls in the win case, compute the reassignment break-even for that dispatch and compare the two sides before acting. The gate prevents a valid formula from being applied to an invalid scenario.

## 15-Minute Call

For this 15-minute call, treat the inputs as illustrative only and replace them with your own: Tech A is 40 minutes from Job 1 (committed, SLA breach at 60 min, penalty $150); Tech B finishes early and is 15 minutes from Job 1 but 25 minutes from Tech A's next job. Fully loaded tech cost: $1.00/minute. With those numbers, Job 1 has 20 minutes of SLA buffer before breach. This section alone walks the full numeric break-even with three checkpoints and the cost of being wrong in each direction.

**Checkpoint 1 — cost of reassigning:** To pull Tech B to Job 1, Tech B drives 15 minutes to Job 1 ($15). To have Tech A cover Tech B's next job, Tech A adds ~25 minutes of detour ($25). That is 40 minutes of drive cost for $40, before any SLA effect. On top of that $40, you must check Tech A's Job 2 SLA risk if its window tightens from that detour. As noted by ServiceTrade, map-based routing is used to reduce drive time, but no published constant from that source tells you how much of Job 2's buffer is lost, so that risk must be measured against your own Job 2 SLA, not assumed away.

**Checkpoint 2 — cost of holding:** Holding means Tech A stays on track to Job 1 with 40 minutes of travel and 20 minutes of buffer to the 60 minute breach. Using the illustrative penalty of $150 at breach, the direct penalty exposure is tied to that 20 minute buffer, not to the full 60 minutes. However, the arithmetic is not "buffer equals penalty": the question is whether Tech A can absorb any unplanned delay in those 40 minutes of travel before hitting breach. If your own records show Job 1's penalty is different, or if breach is not a flat penalty, you must substitute your verified numbers. The $1.00/minute fully loaded cost is only for drive time here, not proof of the penalty.

**Checkpoint 3 — cost of being wrong in each direction:** With $40 in direct drive cost from checkpoint 1, reassigning is only break-even against holding if the value of preserving Job 1's buffer is greater than $40 plus the verified value of Tech A's Job 2 risk. Being wrong by reassigning means you pay $40 and may create a tighter Job 2 window for less than the buffer you saved on Job 1. Being wrong by holding means you keep Tech A's route intact but risk consuming the 20 minute buffer and triggering the $150 penalty with no Tech B detour cost. Do not compare $40 to $150 alone: subtract the portion of buffer you can actually protect, add the verified Job 2 exposure, and only reassign if that computed total is less than the marginal value of the waiting job's SLA buffer for your dispatch. This is a per-dispatch check, because no vendor in the available sources publishes a universal reassignment threshold to copy.

## Decision Rules for Dispatchers

If the incoming technician lacks the skill match for the held job, do not reassign regardless of drive time; a wrong-skill dispatch converts a late job into a failed job, so check the skill-match flag before any drive-time math. Beyond that veto, no fixed minute count decides the call: the article itself establishes that no vendor publishes a universal reassignment cutoff, so compare the incoming technician's extra drive minutes against the held job's remaining SLA buffer for this specific dispatch using the break-even method below. Similarly, whether the original technician is close to their committed job must be judged from the actual drive time and remaining buffer on that dispatch, not from a blanket distance figure.

Before acting, compute the reassignment break-even as defined above: the incoming technician's extra drive minutes times your fully loaded cost per tech-minute, plus the held job's customer-wait penalty. Reassign only when that total is the lower-cost option against holding, and trace every input to your own payroll, contract, and work-order records rather than a vendor default. If an input is missing, treat the rule as a method check and measure the constant from your own data before deciding.

Re-evaluate the reassign-vs-hold call every 15 minutes. Drive times, traffic, and SLA buffers change while a job waits, so a hold decision can become a reassign decision at the next 15-minute check without any new assignment. Treat that cadence as a rule, not a suggestion: set the timer when the first decision is made and repeat the same checks.

Apply the rules in this order: skill-match veto first, then the under-15-minute-drive and under-30-minute-buffer reassignment rule, then the within-10-minutes hold rule, then the break-even check, then the 15-minute re-evaluation. This order prevents a fast drive-time win from overriding a skill gap or a near-complete commitment, and it keeps the decision tied to the job's actual buffer rather than to a guessed threshold.

No vendor publishes a universal reassignment threshold for 2026 field service, so the dispatcher's job is to compute the break-even per dispatch and let these if/then rules decide the call.

## Frequently Asked Questions

**When should a dispatcher reassign a technician instead of holding the job?**

Reassign only when the break-even total is at or below the marginal value of the held job's SLA buffer.

**How is the break-even total calculated for a dispatch?**

Break-even equals the new tech's extra drive minutes times fully loaded cost per tech-minute plus the customer-wait penalty of the held job, and it must be computed per dispatch because no vendor publishes a threshold.

**What drive-time comparison is used as the headline reassignment threshold?**

The 15-minute drive-time comparison is the headline reassignment threshold.

**How does the headline frame the reassign-vs-hold decision?**

The headline frames the decision as 15-minute drive time versus holding the job.

**What job-listing counts make dispatch demand visible?**

Dispatch demand is visible in 89,885 Scheduling Technician and 29,096 Technician Scheduling job listings.

**What cost structure drives the reassign-vs-hold call?**

At its core, the reassign-vs-hold call is driven by a two-sided cost structure: drive-time cost vs. SLA-hold cost.

## Quick answers

| When should a technician be reassigned rather than holding the job? | Reassign only when the break-even total is at or below the marginal value of the held job's SLA buffer. |
| --- | --- |
| How is the break-even total computed per dispatch? | Break-even equals the new tech's extra drive minutes times fully loaded cost per tech-minute plus the customer-wait penalty of the held job. |
| What comparison serves as the headline reassignment threshold? | Use the 15-minute drive-time comparison as the headline reassignment threshold. |
| Where is dispatch demand visible? | Dispatch demand is visible in 89,885 Scheduling Technician and 29,096 Technician Scheduling job listings. |
| What does Timefold identify for technician scheduling software? | Timefold identifies nine essential capabilities for technician scheduling software, and the capability list includes skill matching and SLA priorities among nine essentials. |

Also worth reading: **Artificial Intelligence Field Dispatch 2026: 30% Reassign or Manual Split?**: [Artificial Intelligence Field Dispatch 2026:](https://technician.dev/blog/artificial-intelligence-field-dispatch-2026-30-reassign-or-manual-split.php) · **AI Field Technician Dispatch: Cutting Response Times and Boosting Satisfaction in 2026**: [AI Field Technician Dispatch: Cutting](https://technician.dev/blog/ai_field_technician_dispatch_cutting_response_times_and_boosting_satisfaction_in_2026.php) · **2026 Dispatch: 15% Override Rate Resets AI Confidence Threshold**: [2026 Dispatch: 15% Override Rate](https://technician.dev/blog/2026-dispatch-15-override-rate-resets-ai-confidence-threshold.php)

### Related reading

- [AI Field Technician Dispatch: Cutting Response Times and Boosting Satisfaction in 2026](https://technician.dev/blog/ai_field_technician_dispatch_cutting_response_times_and_boosting_satisfaction_in_2026.php)
- [Artificial Intelligence Field Dispatch 2026: 30% Reassign or Manual Split?](https://technician.dev/blog/artificial-intelligence-field-dispatch-2026-30-reassign-or-manual-split.php)
- [Reschedule Technicians for Rain: 0.25-Inch Alert vs Dispatch](https://technician.dev/blog/reschedule-technicians-for-rain-025-inch-alert-vs-dispatch.php)
- [Field service parts inventory staleness: AI dispatch first-time fix vs idle time 5 minutes](https://technician.dev/blog/field-service-parts-inventory-staleness-ai-dispatch-first-time-fix-vs-idle-time-5-minutes.php)
- [Dispatch efficiency: verify arrival variance against a 15-minute threshold](https://technician.dev/blog/dispatch-efficiency-verify-arrival-variance-against-a-15-minute-threshold.php)
- [Auto Assign Field Technicians: 80% Confidence Triggers Dispatch in 2026](https://technician.dev/blog/auto-assign-field-technicians-80-confidence-triggers-dispatch-in-2026.php)

### Latest

- [Reschedule Technicians for Rain: 0.25-Inch Alert vs Dispatch](https://technician.dev/blog/reschedule-technicians-for-rain-025-inch-alert-vs-dispatch.php)
- [On-device redaction for field-service photos: 120ms vs service level, redact or...](https://technician.dev/blog/on-device-redaction-for-field-service-photos-120ms-vs-service-level-redact-or-skip.php)
- [Field Service Routing: 14% Cost-to-Serve vs Union Seniority/Hours-of-Service...](https://technician.dev/blog/field-service-routing-14-cost-to-serve-vs-union-seniorityhours-of-service-split.php)

Canonical: https://technician.dev/blog/reassign-or-hold-computing-a-per-dispatch-technician-break-even.php
Markdown: https://technician.dev/blog/reassign-or-hold-computing-a-per-dispatch-technician-break-even.php/index.md