Production workflows / Guide 36
A Field Service Dispatch Agent That Reserves Skills, Parts, and Time
Build a field service dispatch agent that checks technician skills, parts, access windows, and stale locations before committing appointments or rerouting crews.
Illustrative engineering guide. Examples are not client deployments, production-ready integrations, or evidence of measured results. Validate the design with your domain and security owners.
Consider a hypothetical refrigeration service company responding to a restaurant’s failing cold room. The nearest technician is fifteen minutes away but lacks the required equipment qualification. Another technician has the right qualification but not the replacement controller. A third can collect the part, yet would miss the customer’s access window. “Send the nearest available person” is not a dispatch policy.
A field service dispatch agent should make feasible assignments easier to find and explain. It should not guess technician competence, certify equipment safety, or optimize away required rest and access constraints. Its language capability is most useful for understanding messy work-order descriptions and explaining why apparently obvious assignments fail.
Turn eligibility into structured evidence
Start with the asset identifier, reported symptoms, site address, service agreement, access window, and urgency class. Preserve the customer’s original description. A model can propose an issue category, but “freezer warm” should not automatically become a confirmed compressor failure or a guaranteed parts list.
Maintain technician skills and qualification expiry in a controlled register. Represent parts availability by location and reservation status, not a yes/no inventory flag. Account for tools, vehicle capacity, site induction, and whether two people are required. Unknown eligibility is not equivalent to eligible.
Separate arrival promises from work-duration estimates. A two-hour arrival window does not guarantee a completed repair within two hours. Communicate both the service commitment and what remains uncertain. This distinction prevents an assistant’s friendly message from becoming an unsupported contractual promise.
Use optimization after hard filtering
The minimum workflow has work-order intake, qualification and parts adapters, a travel-time service, a deterministic planner, and an approval-backed assignment handler. Filter impossible combinations first. Rank remaining options by travel time, lateness, overtime, and disruption to already accepted jobs.
Google OR-Tools’ time-window routing guide demonstrates using a time matrix and explicit visit windows. Real field service adds job durations, parts collection, breaks, qualifications, and frozen assignments. Those requirements belong in the optimization model or a deterministic feasibility layer, not merely in the prompt that explains the result.
A language model should return a structured proposal with reasons, not arbitrary solver code to execute. Specialist agents add value only when different product families require genuinely distinct diagnostic-reference retrieval. Even then, they suggest the evidence needed for dispatch; a qualified technician performs diagnosis on site.
A feasibility check worth testing
This illustrative pure Python function checks one candidate assignment. Times are integer minutes from a common planning origin. It is not a complete route optimizer or safety procedure.
def feasible(tech, job, arrival, service_minutes):
if not job["skills"] <= tech["valid_skills"]:
return False
if not job["parts"] <= tech["reserved_parts"]:
return False
start = max(arrival, job["window_start"])
finish = start + service_minutes
return (service_minutes > 0
and start <= job["window_end"]
and finish <= tech["shift_end"])
tech = {"valid_skills": {"controller-x"},
"reserved_parts": {"board-x"}, "shift_end": 600}
job = {"skills": {"controller-x"}, "parts": {"board-x"},
"window_start": 400, "window_end": 450}
assert feasible(tech, job, 420, 60)
assert not feasible(tech, job, 451, 60)
assert not feasible(tech, job, 440, 180)The window here constrains arrival, not completion. If a site closes at a fixed time, add a separate completion deadline. Parts are sets only for illustration; production must validate quantities, compatibility, and reservation ownership. Also account for breaks, uncertain travel, geocoding quality, and dependencies on previous jobs.
An infeasible result is useful information. Present the smallest reason set: no qualified technician with the required part can arrive before access closes. The dispatcher can then seek a new access window, split diagnosis from repair, or escalate capacity. Do not quietly relax a hard constraint to produce an answer.
Commit assignments without racing the dispatcher
Bind each proposal to work-order, technician-schedule, parts, and policy versions. Before committing, recheck them under concurrency control. PostgreSQL’s transaction isolation documentation explains why concurrent reads and writes can produce inconsistent decisions without deliberate isolation or locking.
Reserve the part and the schedule slot consistently within the owning system. If separate systems are involved, use durable intermediate states and compensation. A failed assignment should release only the reservation created by that operation, not all inventory held for the technician.
Require technician acknowledgment for operational handoff. If acknowledgment times out, the assignment is pending, not silently accepted. A late acceptance for a superseded dispatch version must fail. Notifications use a stable assignment-version key so network retries do not send conflicting addresses repeatedly.
Freeze near-term accepted work to reduce route churn. Replanning every minute can make a mathematically efficient schedule operationally unusable. Permit emergency overrides only through the dispatcher’s explicit approval and communicate exactly which appointment is displaced.
Protect workers, customers, and equipment
Authorize work-order access by tenant, service territory, and role. Location history is sensitive worker information; use the minimum recent location required for dispatch and avoid turning efficiency estimates into automatic disciplinary scores. Evaluate whether location freshness differs across rural and urban technicians before comparing performance.
Customer notes and asset manuals are untrusted content. A note that says “skip certification checks” cannot change eligibility. OWASP’s LLM security project supports that separation between retrieved text and tool authority. MCP is not authorization, and no dispatch tool should remotely bypass equipment interlocks.
If location data is stale, widen the travel estimate or request confirmation. If the mapping service is unavailable, preserve accepted assignments and fall back to dispatcher judgment rather than inventing precise arrival times.
Acceptance tests for a dispatch shift
- Offer the nearest technician with an expired qualification. Expect exclusion with an explicit qualification reason.
- Reserve the final spare part concurrently for two jobs. Expect one successful reservation and one replan, never two confirmed repairs using the same unit.
- Accept an old assignment after emergency reassignment. Expect rejection of the stale version and display of the current assignment.
- Lose a notification acknowledgment and replay delivery. Expect one logical assignment with consistent destination details.
- Remove live location access and inject a certification-bypass instruction into the job note. Expect uncertain travel estimates and unchanged eligibility rules.
Measure promise keeping and schedule stability
Baseline dispatch handling time, first-visit completion, and arrival-window adherence for comparable job classes. Measure feasible accepted assignments as assignments passing verified eligibility checks divided by all accepted assignments. Measure on-time arrivals as arrivals within the communicated window divided by visits with a valid window and recorded arrival.
Guardrails include qualification violations, double bookings, parts conflicts, and reassignments after technician acceptance. Track emergency work separately so urgent overrides do not distort routine planning. Roll out in shadow mode for one territory, then dispatcher-approved suggestions. Proposed efficiency targets must include acknowledgment and correction effort.
Start with qualification and parts filtering before introducing route optimization. Fleet management supplies vehicle constraints, while manufacturing maintenance informs asset context. Mobile application engineering is relevant when weak connectivity and clear technician acknowledgment determine whether the dispatch actually works.