SLA risk triage
Which open tickets are going to miss their deadline?
For assigned tickets, it projects when the technician will actually finish, from where they are, what else is on their list and current traffic. Schedule pressure and a calibrated breach probability are reported separately. Unassigned tickets are listed apart, by deadline, since nobody is on the way.
- Where it appears
- Console · Dispatch → Risk triage
- Guardrail
- Without a calibrated model it answers "unknown risk", with no probability.
Dispatch recommendations
Who should go, given everyone else's deadlines?
Ranks technicians by contract urgency, travel time, skills, shift and rest limits, and the effect on every other ticket. It returns the recommended plan, every rejected candidate with the reason, and the traffic data it used.
- Where it appears
- Console · beside each ticket's candidates
- Guardrail
- A plan that raises any other ticket's breach probability by more than 5% is refused, not just penalized.
Parts sourcing after arrival
The part isn't in the van. Now what?
When the technician scans the unit and finds the real fault, the engine weighs sourcing options in order: van stock, a peer delivering or meeting halfway, a courier from the warehouse, the client's own stock, a verified workaround, or escalating procurement to the client and releasing the technician.
- Where it appears
- Console and field app · on the ticket
- Guardrail
- A peer handoff is proposed only when both technicians' routes still meet their deadlines.
Route optimization
What's the best set of routes for the fleet today?
Inserts a new ticket into existing routes with the least disruption, or re-plans a set of stops as a routing problem with time windows, pricing lateness at the contract's penalty rate. With fleet fuel figures configured, it reports fuel and CO₂ against a baseline.
- Where it appears
- Console · Dispatch → Routes and fleet
- Guardrail
- A route that can't be driven within shifts and deadlines comes back as the stops nobody can reach, not as a plan.
Adaptive dispatch weights
Are our dispatch weights the right ones?
Every assignment is logged with its full candidate set. Proposed weights are evaluated against real outcomes (first-time fix, SLA met, offer accepted, overrides) using the decisions already made, before anyone switches them on.
- Where it appears
- Console · Configuration → Model registry
- Guardrail
- New weights go live only when a person promotes them, after five promotion gates pass.
Hotspots
Where do faults concentrate?
Maps incident rate, SLA breaches and resolution time on a hexagon grid, per hour of equipment in service, and flags chronic hotspots that stay high week after week. Each cell is named by the sites inside it.
- Where it appears
- Console · Planning → Hotspots
- Guardrail
- Cells with fewer than five incidents aren't reported as hotspots.
Demand forecast
Where will work come from in the next hours and days?
Forecasts incidents per area from history and the equipment expected to be in service, with prediction intervals, and suggests where technicians should start their shift to be within reach of the forecast demand.
- Where it appears
- Console · Planning → Demand forecast
- Guardrail
- Intervals are labelled uncalibrated until enough evidence has accumulated.
Contract health
Which contracts are at financial risk?
Weighs each client's open obligations against the capacity actually behind them: the remaining shift hours of the technicians who cover each territory, with travel between territories costed. Where penalties are written as rules, it computes financial exposure and proposes moving capacity.
- Where it appears
- Executive dashboard · health score per client
- Guardrail
- Where a contract's penalties can't be computed, exposure is reported as unknown.
Workforce intelligence
Is the team overloaded, and where?
Rest and overtime against contractual limits, workload balance across the team, and pace estimates compared only within comparable groups: a slow pace downtown is quick on a rural round.
- Where it appears
- Console · Workforce
- Guardrail
- No individual attrition score is ever produced; small groups are suppressed.
Arrival reconciliation
When did the technician really arrive and leave?
Reconciles every observation at the site (geofence crossings with their accuracy, the technician's taps and status changes from the audit log) into the best estimate of arrival, departure and time on site, keeping every raw time beside the accepted one.
- Where it appears
- Ticket · Telemetry
- Guardrail
- Mocked or low-confidence readings never become an arrival.
Field assistant
How do I fix this?
A chat on the ticket that diagnoses with tools, suggests solutions from similar resolved tickets across the fleet and the knowledge base, reads a photo of the fault, turns a coordinator's WhatsApp message into a ticket draft and rewrites the report in the house or client voice. Guides are searched on the phone, offline.
- Where it appears
- Field app · Assistant and ticket screens
- Guardrail
- It reads with the technician's own permissions and can change nothing. Provider keys stay in the phone's keystore and AI traffic goes straight to your provider.
Knowledge loop
How does the next technician learn from this one?
After a fix no guide covered, the technician proposes it from the ticket with the steps and photos. A reviewer edits and publishes it, and it reaches every eligible phone on the next sync, searchable offline.
- Where it appears
- Field app · Console → Knowledge
- Guardrail
- A reviewer can't publish their own proposal, and a guide never crosses to another client's sites.
Console assistant
What's happening, and what needs me first?
In the console, the assistant triages incoming work, summarizes a ticket's history and answers questions about the operation. It runs on your own AI provider keys or on platform-metered keys.
- Where it appears
- Console · Assistant
- Guardrail
- It works within the signed-in person's permissions, and changes still go through the normal workflow.
