Field-service AI has a special failure mode: the power user — the senior technician, the 10-year dispatcher — is the one who burns out on it first. They know the fastest workflow, and any AI turn that adds a re-ask or a fabricated part number costs them time they didn't want to give up. We work with field-service platforms whose AI copilot tested well in demo and now needs to survive the hands of the people most likely to reject it.
Customer address, service history, open tickets, installed equipment — all in the system of record. An AI copilot that interviews the technician about any of these is slower than the existing workflow. Prefill eliminates the friction.
If a technician's natural language says "I need the 30-amp breaker" and the model emits a part number it made up, the order is wrong. Part numbers must come from the parts catalogue tool output, never from the model's own text. UI contract pattern.
Service visits have well-known branches — warranty claim, paid service, callback. Encoding the branching logic in the prompt ("if X, then ask about Y") is fragile and expensive. A server-side state machine runs the branching; the LLM handles only the conversational ambiguity inside each branch.
Appointment confirmations, quote summaries, and status updates in free text look acceptable in a demo and fall apart in production (wrong time zones, wrong units, inconsistent phrasing). Typed UI contracts let the model emit intent; the product renders the correct form.
Workflow audit that separates steps that genuinely benefit from LLM from steps better served by a few lines of typed code
Typed UI contracts for every customer-facing output — appointment confirmations, quotes, status updates
Server-side state machine for branching workflows (warranty, paid, callback, escalation)
Prefill layer sourced from the ERP / CRM / service-history APIs — the copilot stops re-asking
Eval harness targeting technician-speed-up, not just model-response-quality