Nobody loses a contract over one late job
They lose it over a pattern they didn't notice until the client did.
Most facilities management contracts run on service level agreements that look simple on paper — respond to a P1 fault within two hours, resolve within eight; respond to a P3 within 48 hours, resolve within five days. What's not simple is proving, week after week and site after site, that you actually did it. And when you can't prove it in real time, the first time you find out you missed an SLA is usually when a client raises it at a quarterly review, or worse, deducts it from an invoice.
By then it's not one missed SLA. It's a run of them, hidden inside spreadsheets, engineer texts and a helpdesk inbox nobody has time to audit.
Why SLA tracking quietly falls apart
Most FM businesses aren't tracking SLAs badly because they don't care. They're tracking them badly because the information needed to prove compliance is scattered across places that don't talk to each other:
- A ticket comes in by phone, email or portal
- It gets logged somewhere — sometimes a spreadsheet, sometimes a helpdesk tool
- An engineer is told about it by call or WhatsApp
- The engineer's actual arrival time isn't recorded anywhere reliable
- Job completion gets confirmed verbally, then written up later, if at all
Every gap in that chain is a gap in your evidence. When a client asks for proof that a P1 was resolved within SLA, "the engineer said he got there quickly" isn't an answer that survives a contract review.
What actually needs tracking
Forget tracking everything. Track the handful of things that determine whether you're inside or outside the terms you signed:
- Time from ticket raised to acknowledged — the clock usually starts the moment the client logs it, not when your team gets round to reading it
- Time from acknowledged to engineer on site — this is the number most SLAs actually penalise
- Time from on site to job closed — resolution time, separate from response time
- Priority tier applied — P1/P2/P3 or whatever tiering the contract uses, because the SLA window changes with it
- Contract-specific terms — some clients have their own variations on standard tiers, and treating every contract the same is how breaches happen
- Evidence of completion — timestamped photos, sign-off, parts used, so a dispute isn't a matter of opinion
The businesses that manage this well aren't doing more admin. They're capturing the same information once, at the point it naturally happens, instead of writing it down twice — once for the engineer, once for the client report.
The margin erosion nobody puts on a spreadsheet
SLA penalties are the visible cost. They're rarely the biggest one.
The bigger cost is the time your office team spends manually chasing engineers for updates, manually building SLA compliance reports before a client meeting, and manually reconciling three different logs to work out what actually happened on a job from six weeks ago. That's paid hours going into proving the work was done, instead of doing more of it.
And the reputational cost compounds. A client who has to ask twice for an SLA report starts wondering what else they'd have to ask twice for. Contract renewals in facilities management are rarely lost because the work was bad — they're lost because the relationship felt uncertain.
What good SLA tracking looks like day to day
In a connected system, the SLA clock starts the moment a job is logged, not when someone remembers to start a timer. Priority is set once, on the job, and every downstream view — dispatch, engineer app, client report — reflects it automatically.
With Field Operations, a job raised against a site carries its SLA window with it, so the team dispatching engineers can see at a glance which jobs are closest to breaching, not just which ones came in first. The Dispatch Board makes priority visible in real time, so urgent jobs don't sit in a queue behind easier ones simply because nobody flagged them.
When the job's done, the evidence — timestamps, photos, notes — sits against that job permanently, not in a separate folder someone has to go looking for. And when a client review comes round, Reports can show SLA performance by contract, by site, or across the whole portfolio, without anyone building it from scratch the night before.
That's the real value of connected tracking — not better-looking reports, but the confidence that the number in the report matches what actually happened, because it was captured once, automatically, at the time.
Treating every contract the same is the mistake
One detail worth stating plainly: SLA terms are rarely identical across your portfolio. One client's P1 is a two-hour response; another's is four. Some contracts carry financial penalties for breach; others don't, but still factor SLA performance into renewal decisions.
Running all of that through one spreadsheet template, or worse, through memory, is how a business ends up applying the wrong window to the wrong client. Tracking has to be built around the contract, not a generic average of "how we usually do it."
Where to go from here
If SLA compliance currently depends on someone remembering to check, chase or calculate it, the risk isn't hypothetical — it's just not visible yet. See how N Six Hub for facilities management connects ticket logging, dispatch and reporting so SLA performance is something you can see, not something you find out about after the fact.