Picture this. It is the last week of a three-year facility management contract for a Grade A office tower. The building owner sits across from the FM director and asks one question: "Show me your SLA performance for the past quarter." The director pulls out a spreadsheet his supervisor stitched together the night before, half from WhatsApp screenshots, half from technician memory. The numbers look fine. The owner does not believe them. Two weeks later, the contract goes to a competitor who can prove their numbers. That is not a software story. That is a workflow story.

Most facility teams I have worked with do not lose contracts because their technicians are slow. They lose contracts, and roughly 10 to 15 per cent of recoverable revenue, because they cannot produce credible SLA evidence to invoice against. A complaint becomes a work order only when it has an owner, a location, an asset, a priority, an SLA clock, and a defined response path. Everything before that is just noise in someone's inbox, and noise does not survive contract renewal.

Key Takeaways
  • SLA reports written manually at month-end are not evidence; they are reconstructions, and clients can tell.
  • Every work order needs structured fields the day it is raised, not the day someone asks for proof.
  • Technician evidence at the point of work is the only billing defence that holds up in a dispute.
  • The same timestamps that feed your SLA dashboard should feed your invoice line items, untouched by human hands.

Step 1: Capture the Complaint Without Losing the Detail

Requests rarely arrive in tidy form. A tenant rings the management office about a lift trapping passengers. A security guard messages the duty supervisor at 2am about an AHU tripping in the data hall. A hospital nursing sister emails three people at once because the operating theatre temperature is climbing. The channel will always be messy. The intake record cannot be.

What every intake record must carry

The job of intake is not to interrogate the caller. It is to capture, in under sixty seconds, the fields that downstream people, billing clerks, contract managers, root cause analysts, will need three months from now. Skip a field at intake and someone is going to invent it later, which is exactly how SLA disputes start.

  • Requester name, role, and a contact number that actually answers.
  • Precise location: building, floor, zone, room, and asset tag where possible, not "near the lift lobby".
  • Complaint category and observable impact (a leaking pipe is not the same as a flooded server room).
  • Priority band and the exact received timestamp, system-generated, never typed.
  • Photos, short video, or voice note attached at source rather than chased later.

If those five things land cleanly, the rest of the workflow has a chance. If they do not, every stage downstream is built on a shaky foundation, and your SLA report inherits that weakness.

Step 2: Convert the Request Into a Real Work Order

This is where most facility teams quietly leak revenue. A request sitting in a WhatsApp group is not a work order. It has no owner, no SLA clock, no asset link, and no audit trail. The moment it becomes a structured work order, with a team assigned, a scope defined, an SLA target attached, and a link to the asset's service history, the entire system starts working for you instead of against you.

Take a real example. An aircon escalation comes in on a Saturday night for a shopping mall tenant. If the on-call supervisor accepts it as a work order with priority P2 and a four-hour SLA, the clock starts, the technician is paged, the parts store sees the demand, and the tenant gets an automated acknowledgement. If the supervisor instead replies "noted, sending someone", you have just lost the timeline. Monday morning, no one can say when it was acknowledged, when the technician arrived, or what was actually fixed. The tenant remembers it as "took ages". You remember it as "we sent someone quickly". Without a work order, both versions are equally undefendable.

Request

What the tenant, security guard, or building user reports. Free-form, often emotional, sometimes incomplete. Useful, but not yet actionable.

Work order

What the service team formally accepts. It carries an ID, an asset link, an SLA target, an assigned technician, a status that can be reported on, and a closure rule. This is the unit your business actually runs on, and the unit your invoices should reference.

Step 3: Triage and Assign With Judgement, Not Just Rules

Auto-assignment by category is fine for routine requests, but real facility operations need human triage on the edge cases. A "lift not working" complaint at 9am on a weekday in a fifty-storey tower is a different beast from the same complaint at 10pm in a half-empty car park. Same category, completely different priority, completely different SLA.

The supervisor doing triage needs three things on one screen: the asset's recent history, the contractor or in-house team rota, and the current backlog by priority. With those three views, triage takes thirty seconds and lands the work order with the right person at the right SLA. Without them, triage becomes guesswork, and guesswork is what produces the "why did this take six hours to assign" question at the SLA review meeting.

Step 4: Capture Technician Evidence at the Point of Work

This is the single highest-leverage point in the whole workflow, and the one most teams treat as an afterthought. Technicians on site should be capturing arrival timestamp, work status changes, parts consumed, root cause, before and after photos, and resolution notes on a mobile device, not on a paper job sheet that gets keyed in three days later by an admin who was not there.

Why on-site evidence is the billing argument

When a contractor SLA dispute lands on your desk at month-end, and they will, it is the photo with a GPS-tagged timestamp that wins the argument. Consider an AHU breakdown in a hospital plant room. If the technician logs arrival at 22:47, attaches a photo of the failed contactor at 23:05, logs parts swap at 00:18, and closes with a before-and-after photo of the supply air temperature reading at 01:02, you have a defensible four-hour resolution against a four-hour SLA. If instead the job sheet just says "fixed AHU-03, all good", you have nothing. The hospital will deduct, and you will pay.

Step 5: Verify and Close Properly

A work order is not closed because the technician says so. It is closed when the requester or a designated verifier confirms the issue is resolved, or when a verification rule (sensor reading back in range, photo evidence, supervisor sign-off) is satisfied. This sounds bureaucratic. It is the difference between a 4 per cent reopen rate and a 22 per cent reopen rate, and reopens are what make tenants stop trusting you.

Step 6: Generate the SLA Report From the Workflow, Not From Memory

Here is the part most teams get backwards. The SLA report is not a document someone writes on the 28th of the month from spreadsheets and recollection. It is a view, generated automatically, from the timestamps already sitting in the workflow data. If your workflow captured the moments cleanly, the report is a query. If it did not, the report is fiction.

The metrics that matter, the ones building owners actually check, are these.

  • Time to acknowledge, from request received to work order created.
  • Time to assign, from work order created to technician accepted.
  • Time to arrive, from acceptance to on-site check-in.
  • Time to resolve, from arrival to verified closure.
  • Pending reasons and ageing, broken down by cause (awaiting parts, awaiting tenant access, awaiting approval).
  • Reopened requests and repeat complaints by asset and by location.

Each of those numbers needs to be defensible down to the individual work order. When the building owner queries the 3.2 per cent SLA miss rate, your director should be able to drill into the seven offending work orders and explain each one in a sentence. That is what credibility looks like.

From Request to Invoice: A Real Workflow Walk-Through

Let me walk through one job end to end, because the abstract version is easy to nod along to and miss the point.

Tuesday, 14:32. A tenant in a commercial tower reports through the portal that meeting room L18-04 is uncomfortably warm. The system creates request R-44821 with a system timestamp, auto-categorises as "HVAC comfort", and routes to the M&E duty supervisor.

14:33. Supervisor reviews, links to asset FCU-L18-04 (which has two recent comfort complaints in the past month, flagged automatically), sets priority P3, four-hour SLA, and assigns to technician Aziz. Work order W-29104 is created. Tenant gets an SMS with the work order number and estimated arrival window.

15:18. Aziz arrives, scans the FCU's QR tag (arrival timestamp captured automatically), and finds the filter is heavily loaded and the return air sensor is reading 4 degrees high. He takes two photos, replaces the filter from his van stock (part consumption logged), recalibrates the sensor, and runs the unit for fifteen minutes.

16:02. Aziz logs resolution with a final photo showing the room temperature at 23.1 degrees. The system sends the tenant a one-tap verification: "Is the room comfortable now?" Tenant taps yes at 16:11. Work order auto-closes.

End of month. The SLA report generates. W-29104 shows: acknowledged in 1 minute, assigned in 1 minute, arrived in 46 minutes, resolved in 44 minutes, verified by tenant. The recurring fault analysis flags FCU-L18-04 as a repeat offender and recommends preventive replacement of the sensor. The invoice line for "reactive HVAC, L18, October" cross-references the work order ID, the part consumed, and the labour hours. When the tenant's facilities manager queries the bill, you send them the work order summary with the photos. Conversation over in under two minutes.

That is what "generated from the workflow" actually means. No one wrote that report. No one assembled that evidence. The workflow did it, because the workflow captured the right fields at the right moments.

What a Healthy SLA Report Actually Contains

If you are reviewing your current SLA report and wondering whether it is doing its job, here is the anatomy I look for.

  • An executive summary in plain English: total requests, SLA achievement rate, top three categories, top three locations.
  • A breakdown by priority band, because a 95 per cent overall achievement rate can hide a 60 per cent miss rate on P1.
  • Trend lines over the past six months, not just the current month, so patterns become visible.
  • An exceptions list: every SLA miss, with the work order ID, the reason code, and a one-line root cause.
  • Asset reliability flags: which equipment generated the most reactive work, ranked by cost.
  • Contractor performance, if you use sub-contractors, with the same metrics applied consistently.

If your current report has the first item and nothing else, you have a marketing document, not an SLA report. Building owners and asset managers have seen enough of those to recognise one at a glance, and it actively damages your credibility at renewal time.

Step 7: Close the Loop Back to Operations

The final step, and the one that separates mature operations from ones that just survive, is feeding the report back into the workflow. If three FCUs on level 18 keep appearing in the exceptions list, that is a preventive maintenance trigger. If a particular contractor misses SLA every Saturday night, that is a roster conversation. If approval delays are causing 30 per cent of your P3 backlog, that is a workflow rule that needs changing, not a technician problem.

Bottom line: the facility teams that retain contracts and recover the missing 10 to 15 per cent of revenue are not the ones with the fastest technicians. They are the ones whose SLA reports are a by-product of a disciplined workflow, not a month-end reconstruction. Every timestamp captured cleanly at the point of work is a future invoice you can defend and a future contract renewal you can win.

If you take one thing from this article, take this: stop treating the SLA report as a document to be written and start treating it as a query to be run. The moment you make that shift, the entire workflow upstream has to tighten, and the tightening is what produces the revenue recovery. It is uncomfortable for the first three months, particularly for supervisors used to managing through WhatsApp, and then it becomes the only way you would consider running an operation.

The teams I have seen do this well typically recover the lost billing within two quarters and start winning competitive tenders within a year, because they can walk into a procurement meeting and show, on screen, exactly how their last quarter performed against SLA, with the underlying evidence one click away. That is a very hard thing to argue against, and it is built entirely on workflow discipline rather than any particular piece of software.