SLAs that don't lie: how breach detection actually works

Most SLA countdowns I've used lied to me in small ways: they kept ticking at 2am on a Sunday, or while a reply was sitting in the customer's court, or on a public holiday nobody remembered to configure. A number your team stops trusting stops being useful, so SLA state gets treated as a first-class thing to get right, not a badge that turns red.

Business hours are first class

SLA targets are aware of business hours and timezones per team, so a target set for "respond within 4 hours" means 4 working hours, not 4 hours of a clock that doesn't know it's the weekend. Away mode syncs into the same calculation automatically.

Pause states

A clock that keeps running while you're waiting on the customer to reply isn't measuring your team, it's measuring how fast the customer answers. SLA tracking pauses in those states and resumes the moment the ball is back in your court.

Automated breach detection

A scheduled check runs against every open thread's SLA target and tier, and a breach is flagged the moment it happens rather than discovered when someone happens to look. That's what makes escalation rules — in the workflow engine — able to act on "about to breach" instead of "already broke a promise."

Per-tier targets

An enterprise account and a standard account shouldn't share a target just because they share a product. Targets are set per tier, so the countdown a thread carries actually reflects the contract behind it.