How to Measure Work Order Response Time
Work order response time is the time from the moment a request is logged to the moment someone first acts on it: a technician arrives, or someone contacts the person who asked. Measure it separately from completion time, set a target for each priority, and take both timestamps from the system as they happen, not from dates typed in afterwards. Then report the share of jobs that missed the target, because an average hides the misses.
That is the whole method. The rest of this post is the detail: the definitions that keep the number honest, the targets real facilities owners publish, and the two ways the measurement usually breaks.
Response time, completion time and the other clocks
A single request runs several clocks at once. Most arguments about "slow maintenance" come from people reading different ones.
| Metric | Clock starts | Clock stops | What it tells you |
|---|---|---|---|
| Time to assign | Request logged | A person or vendor owns it | Whether intake and dispatch keep up |
| Response time | Request logged | First visit or first contact with the requester | Whether people feel heard |
| Completion time | Request logged | Work finished and closed | Whether the problem actually got fixed |
| Backlog age | Request logged | Today, for every open request | What is quietly going stale |
Write down what counts as a response before you measure it. The University of Texas Medical Branch puts it in one line on its Property Services page: response is "the maximum wait time prior to a technician making a site visit or communicating with the service requestor." A phone call counts. A ticket silently changing status does not.
What targets do facilities teams actually publish?
There is no single industry standard number. We looked for a published response time benchmark from IFMA, BOMA or APPA and did not find one in public material. What does exist is a set of targets that real owners publish for their own buildings, and they line up more closely than you might expect.
| Owner | Emergency | Urgent or high | Routine |
|---|---|---|---|
| UTMB Property Services | Response under 30 minutes on campus | Response under 8 hours | Response under 72 hours |
| William & Mary | Response within 30 minutes | 4 hours to stabilize, three days to repair | Completion in 20 business days |
| City of Glasgow College contract | Urgent: 1 hour response, 4 hours to fix | Important: 4 hours, 8 hours to fix | 8 hours, 2 working days to fix |
| GSA ordering guide sample | Response within 2 hours | Same day, or by 11 AM next workday if called in after 3 PM |
Two patterns stand out. Every owner separates response from repair once the job is serious, and every owner sets the routine target in hours or days, not minutes. If your routine target is tighter than your urgent one in practice, your priorities are not doing any work.
The GSA row comes from a sample clause in an appendix of its building maintenance ordering guide, so read it as an example of contract wording, not a federal standard.
How to measure it in five steps
- Pick the start. The clock starts when the request is logged in your system, whether a tenant typed it, a front desk entered a phone call, or a technician logged something they spotted on a round.
- Define a response. A site visit or a direct contact with the requester, as UTMB does. Write it into your procedures so every technician closes the same gap.
- Set a target per priority. Three or four levels is enough. Each level needs a response target and a completion target, and the definitions of each level need examples so people classify the same leak the same way.
- Capture timestamps when things happen. Assignment, first visit and completion should be stamped by the system at the moment someone taps the button, with the person's name. Dates entered later are where the data goes wrong (more on that below).
- Report the miss rate, not only the average. For each priority, show the share of requests that missed the target, plus the age of everything still open.
A worked example
The demo below is a request in MAFM, with sample data. A conference room has no cooling. Each step carries a time and a name: created at 8:41 AM, priority raised at 8:47, assigned at 8:52, work started at 9:26, completed at 10:38.
Read the same request against the clocks in the table above and you get three different answers, all correct:
- Time to assign: 11 minutes (8:41 to 8:52).
- Response time: 45 minutes, if your definition is the technician starting work on site (8:41 to 9:26).
- Completion time: 1 hour 57 minutes (8:41 to 10:38).
This is why the definition comes first. A team that reports "11 minutes" and a team that reports "45 minutes" for this same job are both telling the truth, and their dashboards will never agree until they pick one.
Why the average hides the misses
The clearest public example is the District of Columbia's Department of General Services. In a 2022 review for the DC Auditor, routine work orders had a completion target of less than 45 days and high priority ones less than 10 days unless placed on hold. Across all priorities, the review found an average of 55 days between request and completion. More useful than that average: 35% of 39,439 routine work orders and 62% of 7,939 high priority work orders were completed outside their target.
An average of 55 days tells you things are slow. "62% of high priority jobs missed" tells you exactly where to look, and it is the number that changes when you fix something.
Where the measurement breaks
The method fails in the data long before it fails in the math. Two public audits show the two usual ways.
Dates entered after the fact. City of Glasgow College's 2023 internal audit tested a sample of 30 reactive repair jobs. All 30 were completed within the contract's response and rectification times, which is a good result. But the auditors also noted four instances where the completion date had been left as the default date, the day the job was entered, instead of being changed to the day the work was actually done. Four of thirty is enough to make any average wrong.
Fields left empty. A 2025 UT System audit of UTMB Facilities Management found that 17% of one division's work order records and 27% of another's were missing key fields, such as the due date, the classification or the priority. One data set had no completed date field at all, which, as the auditors put it, limits management's ability to monitor timely completion.
The fix for both is the same: the system stamps the time when the step happens, and closing a request without its completion step is not possible. Nobody has to remember to type a date.
What to put on the dashboard
An IFMA Facility Management Journal article on maintenance dashboards lists the common indicators as the volume of open service requests, the age of outstanding work orders, completion rates and backlog trends. Add response time by priority and you have one screen that answers most of the questions a building owner will ask:
- Response time by priority, as the share inside target this month
- Completion time by priority, same treatment
- Open requests by age: under a week, one to four weeks, over a month
- Requests per building or floor, to spot a failing asset before it fails again
If you are still scheduling recurring work by hand, our post on preventive maintenance scheduling covers the other half of the work order queue.
Frequently asked questions
What is a good work order response time?
It depends on priority. Published targets from facilities teams cluster around 30 minutes for emergencies, 4 to 8 hours for urgent work and one to three days for routine requests. Set your own per priority, then track the share of requests that meet it.
Is response time the same as resolution time?
No. Response time ends at the first site visit or contact with the requester. Resolution or completion time ends when the work is finished and closed. Track them separately, because a fast response with a slow fix is a different problem from a slow response.
How do you calculate average response time?
For each request in a period, subtract the logged time from the first response time, then average the results by priority. Report the share of requests that missed the target next to the average, because the average alone hides the outliers.
Should requests logged after hours count?
Yes, but say how. Some contracts pause the clock outside working hours. The GSA's sample clause, for example, lets a routine call received after 3 PM be answered by 11 AM the next workday. Write the rule down so every request is measured the same way.
MAFM stamps every step of a request with a time and a name, so response and completion times come straight from the record. See how it works on the operations page, or talk to an operator who runs their own buildings on it.
