A facilities management company handling service calls across fifteen commercial properties was using a dispatcher as a human routing table: receive the request, look up the right vendor for that property and trade, dispatch by phone, follow up when nothing closed. The system worked until request volume outpaced the dispatcher's capacity to track open jobs.
The problem
The company managed service calls across fifteen commercial properties: office buildings, a light industrial park, and a retail strip. Maintenance requests came from tenants and property managers by email, by text to the dispatcher's phone, and by direct call.
The dispatcher's job was to receive the request, identify the trade (HVAC, plumbing, electrical, janitorial, general maintenance), look up the right vendor for that property, dispatch by email or phone, and follow up if nothing closed. Vendor coverage lived in a shared folder of PDF contracts. The dispatcher had memorized the relevant details. Nobody else could work through the folder quickly enough to act on a request.
When volume spiked, whether from summer HVAC calls, a building systems failure, or the dispatcher being out for a week, the queue backed up in their inbox. Response windows slipped without automatic tracking. Property owners called the operations office asking for status on jobs they assumed were in progress.
What we built
A work order intake and routing tool that accepts requests from three channels: a shared email address, a web intake form linked from the tenant portal, and an SMS line that converts inbound texts to structured records.
Each request is automatically classified by trade and matched against the property's vendor roster, a table the operations manager maintains: which contractors cover which properties, for which trades, under which contract, and what the SLA is for urgent versus standard jobs. The vendor roster replaced the shared PDF folder.
The right vendor is dispatched automatically: an email with the job details, property access instructions, and the SLA deadline. The tool tracks each job through acknowledged, dispatched, on-site, and complete. If a vendor does not acknowledge within the contracted window, an escalation routes to the dispatcher as a flagged exception instead of getting buried in a shared inbox.
At month-end, the tool compiles a property report: requests received, closed within SLA, escalations, and open items. Property owners receive the report without the dispatcher assembling it manually.
What the dispatcher sees
An exception queue, not a full inbox. Requests that route cleanly and close within SLA do not require dispatcher attention. They log and close. What appears in the queue is specific: a vendor that did not acknowledge within the window, a job that went on-site but did not close, a request the classification flagged as ambiguous because the tenant's description could be read as plumbing or general maintenance.
Each exception shows the property, the vendor, the elapsed time against SLA, and a re-dispatch or override action. The dispatcher handles real problems instead of acting as a routing table for every clean request.
What changed
Response time on standard requests dropped because dispatch is now immediate instead of waiting on the dispatcher to be available when the request arrived. Escalation tracking became systematic: no more jobs aging silently because no one was watching them.
Property owners started receiving consistent monthly reports for the first time, which reduced inbound calls to the operations team asking for job status.
The dispatcher's role changed from fielding and routing every request to managing exceptions and keeping the vendor roster current. The knowledge that had lived in one person's head is now in an editable table the whole operations team can read.