Designing an SLA system that reflected reality — not assumptions

When SLAs exist, but accountability doesn't

The client had a service platform in place and an SLA framework defined on paper. Tickets were created, assigned and tracked. Reports existed.

Yet the experience on the ground told a different story:

• SLA breaches were inconsistent and hard to explain.
• Escalations depended more on human follow-ups than system behaviour.
• Ownership shifted across teams without clear accountability.
• Leadership couldn't reliably say whether SLAs were actually being met.

On the surface, this looked like a configuration problem. It wasn't.

Why the obvious fix fell short

Native SLA tooling assumes a linear model: one ticket, one owner, one resolution path, one clock. That works when responsibility stays inside a single team.

This reality was different. Tickets routinely needed cross-team involvement, and escalations triggered work that lived in other systems entirely.

Forcing that complexity into native SLAs produced artificial ownership, manual overrides, and a widening gap between what the system said and what actually happened.

The insight: SLAs are about accountability, not timers

The key insight wasn't technical. The client didn't need another way to start and stop clocks. They needed an operation that preserved SLA responsibility even when work left the primary system — and made escalations explicit and auditable.

The design: let each tool do the right job

The solution was deliberately hybrid — not because any one tool was weak, but because no single tool should be asked to do everything.

What changed

The most important changes weren't numerical — they were behavioural. Teams trusted the reports again. Escalations became proactive. Ownership stayed clear even during handoffs. The system stopped looking correct and started being correct.