SLA Tracking That People Actually Follow

Most teams already have an SLA policy. It's usually a paragraph in an onboarding document, or a line in a client contract: "scripts will be reviewed within 24 hours," "revisions turned around within one business day." The policy is almost never the problem. The problem is that a written policy has no mechanism to enforce itself, and a deadline nobody can see is really just a suggestion.

Why written policies fail quietly

A written SLA is a promise about behavior, but it doesn't change anyone's daily view of their work. A reviewer doesn't wake up and check a document that says "24 hours" — they check their inbox, their chat, their task list, and none of those surfaces tell them "this specific ticket is now 20 hours into its 24-hour window." Without that visibility baked into the tool people actually use, the SLA exists in theory and gets missed in practice, usually without anyone noticing until a client asks why they haven't heard back.

This isn't a discipline problem. It's a visibility problem. Even conscientious, well-organized people can't act on a deadline they can't see at the moment it matters.

Stage-level, not just ticket-level

The first real fix is tracking SLAs at the stage level, not just for the ticket as a whole. A "review this script within 24 hours" clock needs to start the moment a specific stage activates and a specific person is notified — not when the overall project began, and not as one vague deadline covering five different handoffs. A ticket that's been open for a week might still be well within SLA if four of its five stages were completed quickly and the current stage just started. Ticket-level tracking hides that nuance; stage-level tracking makes it precise.

This also means the clock should start on notification, not creation. If a ticket sits unassigned for six hours before someone is actually notified, that shouldn't count against the assignee's response window — the SLA is a measure of how the person is performing against their window, not a measure of how long the ticket has technically existed.

Pre-breach escalation is the mechanism that actually changes behavior

The single highest-leverage change is warning a supervisor before a breach happens, not after. A configurable threshold — say, alert a supervisor when a stage is 80% through its SLA window with no movement — turns a silent, invisible countdown into an actual prompt for someone to intervene while there's still time to do something about it. After-the-fact breach reports are useful for a monthly retro, but they don't save the ticket that's currently late. Pre-breach alerts do.

The combination of these two ideas — stage-level clocks that start on notification, and pre-breach warnings routed to a supervisor — is what actually changes day-to-day behavior. It's not about writing a stricter policy. It's about making the existing policy impossible to silently ignore.

What this looks like rolled up

Once SLA data exists at the stage level, it becomes genuinely useful for spotting patterns, not just individual fires. A dashboard that rolls performance up by workflow, by stage, and by team member turns "we feel like reviews are slow lately" into "the Client Approval stage on the Radio Ad workflow has missed SLA four times this month, all with the same reviewer" — a specific, actionable finding instead of a vague impression.

Crystal Desk's SLA & Alerts feature was built directly around this — the clock, the pre-breach warning, and the rollup dashboard — because a deadline that isn't visible in the moment isn't really a deadline. It's a document.