# Field Service Routing: 14% Cost-to-Serve vs Union Seniority/Hours-of-Service Split

Chase Pierce · October 22, 2026

> Union seniority and hours-of-service constraints can raise AI dispatch cost-to-serve in field service routing; compare complete options before committing.

This guide shows how union seniority and hours-of-service constraints alter AI dispatch cost-to-serve in field service routing.

It gives a verify-before-you-commit method for comparing live, complete options on like-for-like totals and terms.

![Wide aerial view dawn service depot with rows](https://static.mm-ais.com/article-images-ai/field-service-routing-14-cost-to-serve-v-ai-922ea909.jpg)
Wide aerial view dawn service depot with rows

## How It Works

AI dispatch cost-to-serve is the full cost of completing a field job under the rules that actually govern who can take it and how long they can work. The mechanism is constraint-first optimization: the router first removes infeasible technician-job pairings, then prices the remaining options. Union seniority can reserve certain customers, territories, equipment, or shift types for more senior technicians; hours-of-service rules cap driving, on-duty, or weekly hours. When those constraints bind, the cheapest-looking assignment may disappear, and the next feasible option can carry more travel, waiting, overtime, or callback risk.

| Term | Meaning in dispatch |
| --- | --- |
| Feasible assignment | A technician-job pairing that satisfies seniority, skill, location, and hours-of-service limits. |
| Binding constraint | A rule that changes the selected assignment or total cost if it is removed. |
| Deadhead | Nonproductive travel between jobs or back to base. |
| Reset | The required off-duty period before capped hours become available again. |
| Shadow cost | The extra cost created by a binding constraint. |
| Callback risk | The chance that incomplete or rushed work creates a return visit. |

A binding constraint is one that changes the answer: if removing it would lower cost, it is binding. Seniority is binding when a job must wait for an eligible technician even though a closer technician is available. Hours-of-service is binding when a technician has too little remaining drive or on-duty time to finish the job and return, or to start the next one without a reset. The optimizer then reallocates work, and the cost difference between the unconstrained plan and the feasible plan is the constraint cost.

Cost-to-serve should be compared on a like-for-like basis: same job scope, service window, parts, and customer commitment. Direct labor is only one component. Travel time, deadhead miles, idle time between jobs, overtime premium, and the risk of a repeat visit can all move with routing. A lower hourly rate is not cheaper if it requires a longer route or a second trip.

Verify the live, complete option before committing: confirm remaining hours, eligibility, route feasibility, and the full cost stack, not just the quoted labor rate. The mechanism is not that constraints merely add a fee; they shrink the feasible set, change which technician can legally and contractually take the work, and can move cost into travel, waiting, overtime, or callback risk.

![Field service vans parked beside concrete union hall](https://static.mm-ais.com/article-images-ai/field-service-routing-14-cost-to-serve-v-ai-1449869f.jpg)
Field service vans parked beside concrete union hall

## Key Factors to Consider

Start with three checks, in this order: eligibility, remaining hours, and all-in cost per feasible assignment. Eligibility asks how many technicians can legally and contractually take the job after seniority, union, certification, territory, and shift rules; if that count is one, the job is a constraint, not a market. Remaining hours asks how many compliant minutes each eligible technician still has after travel, breaks, and prior work; a technician with zero remaining minutes is not capacity. All-in cost asks what the completed job costs under those constraints, including overtime, penalties, reassignment, and platform overhead, not the average labor rate.

For a SaaS dispatch platform, one published cost anchor matters: maintenance is commonly 15–20% of build cost per year, plus hosting, third-party services, and LLM tokens (yarify.tech). Ask each vendor for the build price and the annual maintenance figure on the same scope and term length before committing; a lower build quote with higher maintenance or token exposure can be the higher lifetime cost.

Benchmarks need the same caution. One source puts median senior in-home care at approximately $35 per hour, with rates varying by state because they are based on caregiver wages (seniorliving.org); treat this as a wage-proxy sanity check only, not as a field-service rate. A published formula, cost_avoided = (senior_hours × 100) − agent_cost, shows how to test whether automation pays, but only if both inputs are measured from your own dispatch data (ai-manual.ru).

Verify the live, complete option: same job mix, same constraint set, same time horizon, and same included services. If one quote excludes maintenance, tokens, or overtime, add them before comparing. If a vendor publishes almost nothing about price, treat the quote as incomplete until scope, term, and overage rules are written down (ryzlabs.com).

| Decision criterion | What to verify | Number to compare |
| --- | --- | --- |
| Eligible technician pool | Who can take the job under seniority and hours rules | Eligible techs per job window |
| Remaining compliant hours | Minutes left after travel, breaks, and prior work | Available minutes per technician |
| All-in cost per job | Labor, overtime, penalties, platform overhead | Cost per completed feasible assignment |

![Key Factors to Consider — Field Service Routing](https://static.mm-ais.com/article-images-pixabay/field-service-routing-14-cost-to-serve-v-3346ef8a.jpg)

## Common Mistakes

The first common mistake is treating a lower quoted labor rate as the cheaper assignment. A dispatcher may see a senior union technician with a lower base rate and assign a long route, but seniority rules can trigger an overtime premium and hours-of-service limits can make the job impossible to finish in the remaining duty window. The result is not savings; it is a reassignment, idle time, and a second trip. Verify the live, complete option by checking current duty status, union tier, travel time, and service time before committing.

The second common mistake is comparing AI dispatch platforms on subscription price alone. A lower license can look attractive until stale seniority tables or hours-of-service logs cause infeasible plans and manual overrides. The savings disappear in dispatcher time and rework. Compare like-for-like totals that include data maintenance, integration effort, and override labor, not just the license line.

A concrete example of the first pitfall: a route plan assigns a senior technician to a distant job because the base rate looks low. The technician has already used most of the allowed duty time, and the union agreement adds a premium once the job crosses into overtime. The optimizer's "best" assignment fails in the field, and the job moves to a junior technician with more remaining hours. The cheaper plan was never feasible.

A concrete example of the second pitfall: two vendors quote different license prices, but one requires manual updates to seniority and hours-of-service data while the other automates feeds. The manual option creates stale constraints, infeasible assignments, and daily overrides. The automated option costs more on paper but fewer exceptions in practice. The right comparison is total cost-to-serve, not license price.

Before committing, run one final check: confirm the assignment is feasible under current rules, confirm the vendor quote includes the same data and support scope, and confirm the total includes exceptions. If any element is missing, treat the option as unverified.

![Common Mistakes — Field Service Routing](https://static.mm-ais.com/article-images-pixabay/field-service-routing-14-cost-to-serve-v-b1460721.jpg)

## Insider Tactics

Insider tactic: treat the first feasible assignment as a candidate, not a decision. Run a second pass that re-checks seniority, remaining hours, certification, territory, and shift fit immediately before commit, because the live roster and hours-of-service state can change between quote and dispatch. Commit only when both passes agree.

Non-obvious strategy: compare like-for-like totals on the complete option, not on the labor line alone. Include overtime exposure, travel time, callback risk, and any union or seniority-driven premium that appears only after the full assignment is assembled. A lower quoted rate can lose once the complete option is priced.

Timing tip: verify the live, complete option at the moment of commitment, not when the job is first quoted. Eligibility and remaining hours are moving constraints; a check that is even slightly stale can turn a feasible assignment into an infeasible one after commit.

Practical check: keep a short pre-commit checklist that mirrors the decision criteria—eligibility, remaining hours, all-in cost per feasible assignment—and require a fresh roster version or timestamp before release. If any item cannot be verified live, hold the assignment and escalate rather than commit on partial information.

Another timing tip: align verification with roster and schedule updates rather than with job intake. If seniority lists or hours-of-service balances refresh on a known cadence, run the final check after that refresh and before the next dispatch wave, so the committed assignment reflects the current state rather than a snapshot from intake.

When two assignments look close, prefer the one whose constraints are easiest to verify completely and whose total is most stable under a small change in hours or seniority. That reduces rework if the roster shifts after dispatch.

![Insider Tactics — Field Service Routing](https://static.mm-ais.com/article-images-pixabay/field-service-routing-14-cost-to-serve-v-f68a6d7f.jpg)

## Comparison

Compare only assignments that remain feasible under the same seniority and hours-of-service screen; the winner is the option with the lowest verified all-in cost-to-serve for that job, not the lowest visible rate.

| Option | Cost basis | Hidden exposure | When it wins |
| --- | --- | --- | --- |
| Hours-aware AI dispatch | Platform maintenance at 15–20% of build cost (Yarify) | Agent and integration cost not in the labor quote | Avoided senior hours exceed platform and agent cost |
| Lowest-quoted-rate dispatch | Quoted labor rate only | True-up after overtime, travel, or callback work | Narrow cases with no overtime or callback exposure |

The comparison is job-specific, not a permanent ranking: seniority-first can be the lower all-in choice when the feasible set has one technician, while hours-aware assignment wins when more than one feasible technician creates a real tradeoff.

Use the grounded maintenance range as a fixed-cost check: on a $40,000–$150,000 build, 15–20% maintenance is $6,000–$30,000 per year. Against that, the avoided-cost formula is (senior hours × $100) − agent cost (AiManual); 100 avoided senior hours are worth $10,000 before agent cost. The AI option wins when that avoided value exceeds maintenance plus agent cost and the feasible set is large enough to create choices.

Seniority-first wins when rules or a thin feasible set leave no real choice; the lowest-quoted-rate option wins only in narrow cases with no overtime or callback exposure. Before committing, recompute the live, complete option on a like-for-like basis, including maintenance, overtime, travel, callback, and agent cost, and verify that the selected assignment is still feasible at commit time.

## Frequently Asked Questions

**What does the verify-before-you-commit method compare?**

It compares live, complete options on like-for-like totals and terms.

**What is AI dispatch cost-to-serve?**

AI dispatch cost-to-serve is the full cost of completing a field job under the rules that actually govern who can take it and how long they can work.

**How does constraint-first optimization work?**

The router first removes infeasible technician-job pairings, then prices the remaining options.

**What can union seniority reserve?**

Union seniority can reserve certain customers, territories, equipment, or shift types for more senior technicians.

**What happens when constraints bind?**

When those constraints bind, the cheapest-looking assignment may disappear, and the next feasible option can carry more travel, waiting, overtime, or callback risk.

**What is a binding constraint?**

A binding constraint is a rule that changes the selected assignment or total cost if it is removed.

## Quick answers

| What is AI dispatch cost-to-serve? | It is the full cost of completing a field job under the rules that actually govern who can take it and how long they can work. |
| --- | --- |
| What does constraint-first optimization do? | The router first removes infeasible technician-job pairings, then prices the remaining options. |
| What can union seniority reserve? | It can reserve certain customers, territories, equipment, or shift types for more senior technicians. |
| What is a binding constraint? | It is a rule that changes the selected assignment or total cost if it is removed. |
| What is deadhead? | It is nonproductive travel between jobs or back to base. |

Also worth reading: **Work order closeout with voice: 18 to 3-4.2 minutes, dispatch or skip**: [Work order closeout with voice:](https://technician.dev/blog/work-order-closeout-with-voice-18-to-3-42-minutes-dispatch-or-skip.php) · **The AI dispatch metrics that actually move the needle**: [AI dispatch metrics that actually](https://technician.dev/blog/the_ai_dispatch_metrics_that_actually_move_the_needle.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)

### Related reading

- [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)
- [Field Service Dispatcher Overrides: 15-Minute Gate vs Full Automation](https://technician.dev/blog/field-service-dispatcher-overrides-15-minute-gate-vs-full-automation.php)
- [From Moving Averages to Stochastic Demand Forecasting in Field Service](https://technician.dev/blog/from-moving-averages-to-stochastic-demand-forecasting-in-field-service.php)
- [How AI is Optimizing Shift Scheduling for Field Service Teams](https://technician.dev/blog/how_ai_is_optimizing_shift_scheduling_for_field_service_teams.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)
- [Fleet Routing Results: 15% Pickup, Google’s >10%—No Final Verdict](https://technician.dev/blog/fleet-routing-results-15-pickup-googles-10no-final-verdict.php)

### Latest

- [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)
- [Field service parts inventory staleness: AI dispatch first-time fix vs idle...](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)

Canonical: https://technician.dev/blog/field-service-routing-14-cost-to-serve-vs-union-seniorityhours-of-service-split.php
Markdown: https://technician.dev/blog/field-service-routing-14-cost-to-serve-vs-union-seniorityhours-of-service-split.php/index.md