Maintenance Request Triage & Dispatch Agent

Facilities dispatchers spend most of a shift reading tickets that all look urgent until someone opens them. A resident reports “no heat.” A retailer logs a leaking roof. A night porter forwards a photo of a jammed dock door. The work is not writing the work order. The work is deciding how fast it must move, which trade owns it, and who is actually available to take it.

This page is for the dispatcher who already lives in a CMMS or facilities platform (Facilio, MagicDoor, and similar) and needs a model that reads inbound request text, classifies urgency and trade, and proposes a vendor or in-house crew. The dispatcher still assigns. The model does not close the loop on its own.

Related reading: Building Defect Detection via Computer Vision, Contractor Invoice Validation, Energy Optimization Agent.

The agent sits on inbound work orders: portal forms, email-to-ticket, tenant apps, and front-desk notes. For each request it should return a structured triage packet: urgency band, trade, a short rationale tied to the ticket text, a suggested assignee (named in-house tech, preferred vendor, or a short ranked list), and a draft status message the tenant or requester can receive once a human has assigned the job.

Speed is the outcome. Classification that takes a dispatcher ninety seconds of reading and tribal knowledge should take a few seconds of model output plus a glance. That only helps if the glance is cheap. If the packet is wrong more often than a junior dispatcher, people stop opening it.

Do not treat this as auto-dispatch. Emergency trades (gas smell, active water into occupied space, elevator entrapment, life-safety alarms, after-hours lockouts that strand people) get a suggested crew and a loud flag. Staff still confirm before anyone is paged or a purchase order is cut. Routine jobs (slow drain, cosmetic paint, non-critical lighting) can move faster because the suggestion is usually enough for a one-click assign.

Urgency is not the same as the requester’s tone. “URGENT” in the subject line is a signal, not a decision. The model should score against building-risk rules you already use: safety and legal exposure first, asset damage that will worsen in hours second, occupancy disruption third, comfort and appearance last. A polite note that the boiler is down in February outranks an all-caps complaint about a scuffed lobby wall.

Trade classification should map to the codes your CMMS already uses: HVAC, plumbing, electrical, carpentry, fire/life safety, elevators, landscaping, janitorial, and a catch-all only when the text truly does not fit. Multi-trade tickets are common (“AC leaking onto electrical panel”). Return a primary trade and a secondary flag rather than inventing a fake combined vendor.

Ground every label in quoted spans from the request. If the model cannot point to words or a photo caption that support “flooding” versus “damp stain,” it should drop urgency, not invent a story. Photo-only tickets with no caption are not automatically high severity. They are incomplete unless vision is in the same pipeline and the image is actually inspected.

Keep a short, versioned rubric next to the prompt: what counts as P1 versus P2 in this portfolio, after-hours rules, and which asset types (roofs, chillers, fire pumps) escalate even when the wording is mild. Dispatchers will correct the model. Those corrections belong in the rubric, not in a private Slack thread.

Assignment is a human action in the CMMS. The model proposes. It should rank candidates using fields you already trust: trade match, site or campus coverage, contract status, current open-job load if that feed is reliable, and preferred-vendor lists per property. It should not invent a contractor because the name sounds right.

In-house versus vendor is a policy choice, not a language trick. Union rules, warranty holds, and owner-directed vendors override a “faster” suggestion. Surface those constraints in the packet (“warranty vendor required on this RTU”) so the dispatcher is not fighting the model.

When two vendors are both eligible, show why the top name won: closer, already on site today, lower open-ticket count, or contract SLA. Opacity makes people ignore the ranking. Transparency makes a one-click assign feel like confirmation, not a leap.

Never auto-dispatch emergency trades. A gas odor classified as plumbing with a suggested after-hours plumber is still a confirm-first event. Page the on-call supervisor or the life-safety vendor only after a human hits assign, even if the model is confident. Confidence is not authorization.

For non-emergency work, keep the same gate: suggested assignee is a recommendation field. The dispatcher (or a defined backup during lunch coverage) remains the person who creates the assignment, sets the appointment window, and owns the audit trail.

Tenants and store managers chase tickets because silence feels like neglect. Once a human has assigned the job, a drafted update is useful: received, trade, expected next step, and whether access is needed. Send that draft through the same channel the CMMS already uses. Do not let the model send mail from a shadow inbox.

Drafts should stay boring and specific. “A plumber has been assigned; they will call to arrange access” is better than “We’re on it!” Do not promise arrival times the schedule does not contain. If the assignment is still pending, the only honest automated line is that the request is in triage, not that a tech is en route.

Updates after assignment (en route, parts on order, complete) should follow work-order status changes, not model guesses. The agent can template the language. The CMMS remains the source of truth for whether the status actually changed.

Empty output is a feature. If the request is too thin (“fix it,” a single emoji, a ticket with no location, no asset, and no symptom), do not guess urgency or trade. Return a structured empty or needs_intake result and a short list of missing fields: unit or floor, symptom, since when, access instructions, and whether the issue is spreading.

Thin text plus a blurry photo is still thin. Do not fill gaps with typical-building folklore (“probably the same leak as last winter”). The dispatcher would ask a clarifying question. The agent should queue that question, not invent a dispatch.

Conflicting tickets also warrant silence or a hold: two work orders for the same unit in ten minutes, one saying heat works and one saying it does not. Flag the collision. Do not pick a winner.

If required systems are down (vendor list stale, property unmatched, after-hours calendar missing), fail closed. A wrong vendor at 2 a.m. is worse than a ticket sitting in the human queue for five more minutes.

The dispatcher still assigns every job, confirms emergencies, and decides when a ticket is a duplicate or a capital issue pretending to be maintenance. They still handle access, keys, and escort rules the model cannot see. They still take the call when the suggested vendor is at capacity and the second choice has a worse SLA.

Review the first weeks of packets the way you review a new coordinator: sample P1s, after-hours, and “fix it” tickets every day. Log disagreements as rubric changes. If emergency suggestions are routinely wrong, tighten the confirm-first list; do not loosen auto-send.

The agent is doing its job when the board is sorted before the second coffee, vendors are the ones you would have picked, requesters get a status only after someone has actually assigned the work, and garbage tickets come back empty instead of as fake P1s.