How facilities teams track open work orders across properties (and where jobs go quiet)

A facilities team covering multiple commercial properties has no single inbound channel. Maintenance requests come by email: property managers forwarding tenant complaints, vendors reporting damage they noticed on-site. Some come by text, from a property manager who has the dispatcher's cell number and uses it. Others come by direct call, which produces a verbal job description that someone has to write down before it evaporates.

Fragmented intake stays manageable when volume is low. The dispatcher can keep track of the sources they check and the requests they have already seen. Spikes break it. An HVAC season or a building systems event raises the number of requests, and it also raises the number of sources you have to watch at the same time while managing jobs already in flight.

The request usually survives. The context around it does not. A texted description of a leak reaches the dispatcher. What does not ride along with that text: which tenant, which floor, whether this is the same issue reported two weeks ago, and whether the HVAC vendor for that property is on standard contract terms or emergency call-out terms that cost three times as much.

Every commercial property carries a set of vendors: one or two HVAC contractors, a plumber, an electrician, a janitorial crew, and a general maintenance person who handles everything below the trade line. Which vendor covers a given property for a given trade is rarely a mystery. It is rarely in a format anyone can look up in thirty seconds either.

The knowledge sits in the original contract PDFs. It sits in a shared drive folder that was well-organized at three properties and stopped being organized somewhere around eight. The rest lives in the dispatcher's memory and in a spreadsheet that may or may not reflect recent vendor changes. A property manager swapped their HVAC vendor six months ago. That update might be in an email thread. It is probably not in the spreadsheet.

The dispatcher handles the lookup by memory for properties they know and by document search for the rest. In a normal week that runs a few minutes per job. In a spike week, summer HVAC calls or a post-storm repair queue, the lookup becomes the bottleneck. Anyone covering for the dispatcher has to rebuild the routing knowledge from scratch, because it was never written down in one reliable place.

Dispatch is not finished when the vendor receives the email. It is finished when the job closes. Between those two events sits a gap, and most facilities operations manage it through informal follow-up: a call or email a few days in if nothing has shown up in the inbox.

That gap is where work orders go quiet. The vendor acknowledged the job but never confirmed a site visit date. Or they confirmed a visit, then hit a part on order. The job reads as in-progress, and it would read that way if anyone asked, but nothing has closed and nobody is watching the clock on it.

In a portfolio of fifteen properties running eight to twelve vendors each, the open queue is large enough that quiet jobs blend in. Operations that handle this well lean on a dispatcher who keeps a personal log and checks it obsessively. Lose that dispatcher and a pattern shows up: property owners calling in for job status, vendors invoicing for jobs that were never confirmed complete, and a quarterly cleanup where the operations team works out which open tickets are still real.

Most facilities operations run an implied SLA. Standard maintenance gets addressed in a few days. Urgent issues such as no heat, a leak hitting multiple tenants, or a security system failure get addressed faster. The specific timeline is understood, not written down.

Moving to explicit SLA tracking takes two things most operations skip. First, the trade categories have to be specific enough to map to real response times. 'Mechanical' tells you nothing for SLA purposes. HVAC, plumbing, electrical, fire/life safety, janitorial, and general maintenance do. A six-trade taxonomy usually covers the common request types and routes each one to its own response clock.

Second, the clock has to start at intake instead of at dispatch. An SLA measured from when the vendor was notified is a different number than one measured from when the tenant submitted the request. The gap between intake and dispatch, the time the job sat in the queue before anyone acted, stays invisible in the first model. That gap is often where the real delay lives.

The integrations are not the prerequisite. Email and SMS intake are straightforward to build. The vendor roster is the prerequisite: every property, every trade, every active contractor, the contract they are under, and the SLA attached. That document rarely exists in one usable place before the build conversation. Building it surfaces problems fast, like vendors who retired, contracts that expired, and properties that changed management with a vendor list nobody ever updated.

The second prerequisite is a working trade taxonomy. Before the system can classify an inbound request and match it to the right vendor, it needs a finite set of trade categories and someone to review the first two weeks of classifications for corrections. The first pass through historical requests usually turns up two or three categories the initial taxonomy missed.

The third prerequisite is knowing what an exception should look like. Not every routing system needs to wake someone at midnight. For most commercial property portfolios the thresholds are plain: a standard job not acknowledged in 24 hours, an urgent job not acknowledged in 4 hours, a job on-site for more than twice the expected service window. Set those thresholds before the build and the exception queue stays useful instead of turning into noise.

The discovery conversation for any work order routing build opens with the vendor roster, not the software. Pull it into a document, check that it is current for every active property, and note the gaps. That process usually takes a day, and it tells you more about the operation's maintenance management maturity than any software discussion will.