Field service and workforce
Field-Service Dispatch & First-Time Fix
Predicts what each job needs from the work order and the asset's history, then assigns and sequences technicians within your service rules, so the van leaves stocked. Measured in first-time fix, repeat visits, and jobs per technician.
The problem
A technician arrives without the part or the skill the job needed, and the job becomes a second visit. Dispatch works from a short description and a calendar, so job durations are guesses, routes cross each other, and some visits were never needed because the fix could have been done remotely.
Who owns it
The head of service operations. Dispatchers run the board, technicians close out jobs, and parts planning stocks the vans.
What it learns from
- Work orders, including their free text
- Asset and service history
- Parts used on past jobs
- Technician skills, certifications, and territories
- Job durations and drive times
How it works
Predict, decide, act, measure
The same four steps in every solution, in this order, each one visible to the team that owns it.
- 01
Predicts duration, the likely fault, and the parts and skill needed
Models read the work-order text alongside the asset's history to predict how long the job will take, what is most likely wrong, and which parts and skills it will need. Some jobs are flagged as ones a remote session is likely to resolve.
- 02
Decides assignment and sequence through a policy
An optimizer assigns and sequences jobs within service-level commitments, skill and certification rules, drive-time limits, and working hours. Parts are reserved for the van before it leaves, and jobs likely to resolve remotely are offered a remote session first.
- 03
Acts in the field-service system
Assignments, sequences, predicted durations, and parts lists land on the dispatch board and the technician's mobile app in the field-service system your team already uses. Dispatchers can override any assignment, and every override is logged.
- 04
Measures against a holdout of territories or weeks
Territories or weeks that keep the current dispatch process form the holdout. First-time-fix rate, repeat visits, jobs per technician, and drive time are compared between the two.
What it moves
The business levers
First-time fix
More jobs closed on the first visit, with the part already on the van.
Technician capacity
More completed jobs per technician per day, from better sequencing and accurate durations.
Drive time
Less time on the road between jobs.
Remote resolution
Visits avoided where a remote session fixes the problem.
Proof
How the return is proven
The return is the change in repeat visits, jobs per technician, and drive time in the dispatched territories over the holdout, stated against the return model agreed up front. Service-level adherence and customer satisfaction are reported beside it.
What you see: the ROI readout
Every solution produces the same readout, assembled from the system's own records rather than built by hand.
Correctness
The checks the pipeline passed on your own data: leakage, point-in-time, and entity resolution.
Incrementality
The incremental effect against the holdout or equivalent design, with its confidence interval.
Return
The measured return against the investment, set beside the return model agreed before work started.
Guardrails
Complaints, cost, margin, fairness, and contact limits, each shown against its bounds.
Audit extract
Every score, action, and outcome, with the model and policy versions behind it.
Governance
What is governed
Access, approvals, and the audit trail are part of the solution, not a review step added at the end.
Identity-scoped access
Boards, schedules, and customer sites are visible by role and territory through your single sign-on.
Approval gates
Changes to service-level rules, skill requirements, and the optimizer's limits need the service operations head's approval.
Audit trail
Every assignment, override, and job outcome is logged with the model and policy versions behind it.
Working-time rules
Hours, breaks, and certification requirements are hard constraints in the policy, never traded off by the optimizer.
Why it holds up
Trained on your data, framed by the outcome
This solution trains models on your own data, checks every stage from data to decision, and is measured against the outcome it was built for. Because its predictive power is measured, it also shows the drivers behind the metric, so your team can fix causes as well as act on scores.
Why solutions hold upStart with one decision
Bring the problem and the systems your team works in. We scope the first solution with you, agree how its return will be measured, and run it in production with your people.