Service Request Workflows That Do Not Leak
A service request workflow that survives contact with reality: one intake, one owner, five states, closure on evidence, and metrics that expose repeats.
Key takeaways
- One intake channel, one owner and one status field: that is the service request workflow. Everything else is decoration.
- A request is not closed when the work is done; it is closed when there is evidence and the requester has been told.
- Five states are enough: new, triaged, assigned, in progress, closed. Add a sixth only if you can explain it in a sentence.
- Watch first response, time to close, reopen rate and repeat rate by area. A request that reopens twice is a diagnosis problem.
- Verify a sample of closures yourself, roughly one in ten, chosen by you rather than by the vendor.
What does a service request workflow have to do?
It has to answer four questions without anyone opening an inbox: what was asked, who owns it, what state is it in, and what proves it is finished.
Most building operations run on email and memory, which works while the portfolio is small and the manager has been there for years. It stops working the moment either changes, because requests arrive by phone, text, a tenant meeting, a walkthrough note and a remark in the lobby, and each channel has a different chance of being remembered.
Keep three things distinct. A service request is what someone asked for, in their words. A work order is the instruction to a trade. An inspection finding is what you observed yourself. All three can feed each other, but only the request carries the requester's expectation, which is why the closure rule has to respect it. Where findings become work is covered in turning inspections into work orders.
Where do requests leak between intake and closure?
At three points, and each leak has a different cause.
Intake sprawl. The request is taken in whichever channel the caller chose, and the channel becomes the system. Two weeks later nobody can say how many open items exist, because they live in four places.
Ownership float. The request moves from coordinator to supervisor to vendor and nobody is named as owner. The work may even get done; the record does not travel with it.
Silent closure. The trade tells the person who called them, the person who raised the request never hears, and the item stays open until someone archives the year. Who raised it matters, which is why tenant reported issues versus inspections belongs beside this.
Each leak is a missing field, an owner or a verification step, not a people problem.
What should intake capture in the first 60 seconds?
Six fields, and the person taking the call should complete them while the caller is still talking. Intake that takes five minutes gets skipped under pressure.
| Field | Why it matters | Example |
|---|---|---|
| Location | Sets the trade, the access route and the floor | Level 4 women's washroom, second stall |
| What is happening | Separates a fault from a preference | Water pooling at the base of the bowl |
| When it started | Sets urgency and rules out a long-running leak | This morning, around 7:30 |
| Who is reporting | Needed for closure and repeat detection | Tenant contact, suite 410 |
| Impact | Drives triage and who gets called first | One fixture out, floor usable |
| Access | Prevents a wasted trade visit | Key card at reception, 8 to 5 |
A photograph at intake beats three of these fields. If the caller can send one, ask; when the request comes from staff, take it before you leave the area. Two photos, not five: the problem, and the location in context.
Intake is also the moment to state the promise aloud: "We will respond within four business hours and tell you who owns this."
How do you assign ownership so nothing floats?
One owner, named at triage, and the owner is a person rather than a department. "Maintenance" is not an owner; the building operator on shift is. The owner need not do the work, but they own the state of the request until it closes.
Define the handoffs. A request that goes to a vendor stays owned by the internal person until the vendor's evidence is received and checked. When a request moves from day shift to after-hours, the on-call person becomes the owner for that period, which is why an on-call rota needs a handover field in the same log — the pattern in after-hours coverage and on-call rotas.
One practical rule: no request is reopened by email. If a requester replies to say the problem persists, that reply becomes a new state in the same record, with the previous closure evidence still attached.
What does a good status model look like?
Five states, each with an entry condition and a time limit. Anything more elaborate is abandoned in the first busy week.
| State | Entry condition | Escalation point |
|---|---|---|
| New | Captured, not yet assessed | Respond within 4 business hours |
| Triaged | Urgency set, owner named, category chosen | Assign within 1 business day |
| Assigned | Trade or team has the instruction | Confirm attendance within 1 day |
| In progress | Started, or booked and waiting | Update every 3 business days |
| Closed | Evidence received, requester told | Close within 1 day of evidence |
Urgent items skip states, not steps. A burst pipe goes from new to assigned in minutes and still gets an owner, a category and a closure evidence line. Skipping the record is how a serious event disappears from the history that would have shown it was the third this year.
When should a request become a work order?
When it needs a trade, a purchase or a scheduled slot. Keep the two linked but separate, because a request answers "what did the building ask for" and a work order answers "what did we send someone to do".
Set a threshold. Any request needing a person with tools on site becomes a work order, and anything above a set dollar value needs a recorded approval; below that, a supervisor authorises directly.
One request generating three work orders in two months is an undiagnosed defect; the better response is a second look, not a third trade visit.
How do you close a request so it stays closed?
Three conditions, all required. The work is evidenced — a photo from the same angle as the intake photo, or a signed service sheet for a licensed task. The requester is told in writing that it is closed. And the record carries the closure date, the closing owner and what was actually done.
Then verify a sample. Take one in ten closed requests at random and look yourself: does the photo support the claim, does the location match, did the timestamp line up. Verification is not distrust of the trade; it is why an audit works, and it changes behaviour once people know it happens.
Scope note: Closing a request that involved licensed work requires the contractor's certificate or test report, not a photograph. Electrical, gas, elevator, fire system and suppression work are verified by the licensed party's documentation. The manager's role is to receive it, file it and check that the recommendation was acted on.
What does reporting reveal?
Four metrics, reviewed monthly, by building and by area. The value is rarely the number; it is the comparison.
| Metric | Target band | What a bad reading suggests |
|---|---|---|
| First response | Under 4 business hours | Intake sprawl, or nobody watching the queue |
| Median time to close | 5 days routine, 24 hours urgent | Trade capacity, approval delay, lost request |
| Reopen rate | Under 10% | Closure evidence accepted without checking |
| Repeat rate by area | No area in the top three two months running | An unresolved root cause, not a service gap |
Repeat rate is the one portfolios ignore and the one that pays. Three washroom requests from the same floor in eight weeks is rarely a cleaning frequency problem; it is usually a fixture, a drain or a door that does not close. CCOHS guidance on incident investigation makes the same point about root cause: stopping at "the task was missed" almost always misses why it was missed.
How do you keep the workflow honest across a portfolio?
Standardise the shape, not the detail. The same six intake fields, five states, four metrics and closure rule at every building, with categories adjusted for building type. A regional manager who can read four buildings in one format finds the shared failure in an afternoon; four formats guarantee nobody looks.
That is part of the wider operating model in property management operations, and it depends on the inspection side producing a comparable record. Where findings and requests meet in one deficiency record, repeats stop hiding — the principle behind deficiency tracking.
The last discipline is a weekly 20-minute review with whoever owns the queue. Three questions: what is older than its state allows, what reopened, and what are we not fixing this week and why. A request deliberately deferred and documented is a decision; one quietly dropped is next month's complaint.
Frequently asked questions
What is the difference between a service request and a work order?
A service request is what someone asked for, in their words, with a location and an impact rating. A work order is the instruction issued to a trade or team. One request can produce several work orders, and the two should link to each other.
How many statuses should a workflow have?
Five: new, triaged, assigned, in progress and closed, plus cancelled with a reason if you need it. Every extra state is a place where a request can sit unnoticed.
Who should own a service request?
A named person, not a department, accountable until the request closes even when a vendor does the work. The owner changes only at a documented handover, such as day shift to on-call.
How long should a routine request take to close?
Five business days for routine work, 24 hours for urgent items, with a first response inside four business hours. Measure the median rather than the mean; a few very old requests distort an average badly.
Do we need software, or will a shared spreadsheet do?
A spreadsheet works for one building and one person. It fails when two people edit it, when photos must sit beside the record, and when a regional manager wants the same view across sites.
Close the loop, then prove it
A workflow that does not leak is unglamorous: one intake, six fields, one owner, five states, closure on evidence and a sample you verify yourself. NeatScore handles the inspection half of that loop — checklist items with critical flags, a photo per item, offline inspections that sync from a basement with no signal, branded PDF reports for owners, deficiency tracking across sites, and dashboards that show which building keeps producing the same finding. Try it free for 14 days, or see pricing.
