Track SLA compliance in Analytics

The SLA system records every assignment, every state transition, and every Met / Breached outcome. Analytics turns that history into trend data so you can see whether your team is keeping its promises and whether the targets you set are realistic.

Before you start

• At least a few weeks of conversation history under the relevant policies (sample sizes below 50 conversations don’t tell you much)
• Permissions to view Analytics — typically admin and supervisor roles

What’s tracked

For every policy, the SLA dashboard surfaces:

• Breach rate — Percentage of conversations under this policy that breached at least one tracked metric
• Met rate — Inverse of breach rate — percentage with all metrics Met
• Average compliance — How far inside target the team typically responds (e.g., “average First Reply at 12% of target window”)
• Trend — Movement of the above over the last 7/30/90 days

Per metric type (First Reply, All Messages, Resolution Time):

• Median response time — The middle of the distribution — half of replies were faster, half slower
• P90 response time — The 90th percentile — only 10% of replies took longer
• Distribution by band — How many landed in SLA / At risk / Urgent / Breach

Where to find it

1. Open Analytics.
2. Navigate to the SLA dashboard (or the SLA section of the overview).
3. Filter by date range, team, channel, policy, or customer tier as needed.

The dashboard shows aggregate numbers at the top, with per-policy and per-team breakdowns below.

What to look for

Breach rate over 20%

Either the team is under-staffed for the volume on that channel, OR the policy’s targets are unrealistic for the volume / complexity. Pick one:

• If breaches are concentrated in specific time windows (e.g., always between 9am-noon), the issue is likely staffing — the team can’t cover the peak.
• If breaches are evenly distributed across hours, the targets are too tight.

Breach rate below 2%

The targets are too loose. The SLA isn’t acting as a meaningful signal. Tighten until the breach rate sits in the 5–15% band — high enough to matter, low enough to be reasonable.

A specific metric type breaches more than others

If First Reply is fine but Resolution breaches a lot, the team is acknowledging quickly but cases are dragging out. Common causes:

• Cases routinely depend on third parties (engineering, vendors) — the SLA isn’t measuring something the team controls
• Cases are getting blocked on customer responses — All Messages might be a better signal here
• The Resolution target is unrealistic for the actual case complexity

One policy breaches but others don’t

Open the policy. Common causes:

• Targets are tighter than peer policies without commensurate staffing
• Channel scoping pulls in conversations the team isn’t actually equipped for
• A specific team assigned to it is over-loaded

Drill into individual conversations

Every breached conversation is clickable from the dashboard. Open it and review:

• When the timer started, when it tipped to At risk / Urgent, when it breached
• Whether the team or channel changed mid-conversation (the assignment audit trail shows which policy was active when)
• Whether the conversation reopened (and if so, what the SLA looked like before reopen)

Use this for retro reviews — pick the worst breaches of the week and walk through them as a team.

Report cadence

• Daily — Team lead — Same-day breaches, anything still open and Urgent
• Weekly — Support manager — Per-policy breach rate, per-team performance
• Monthly — Leadership — Trend analysis, target calibration

Troubleshooting

• Symptom: Dashboard shows no data. Fix: Confirm policies are active and that conversations have actually been created during the date range. Empty dashboards usually mean the date range is before any active policy existed.
• Symptom: Numbers don’t match what agents see in the conversation list. Fix: The conversation list shows live state; Analytics shows historical state at conversation close. A conversation currently in At risk may eventually close as Met (no breach) — both are correct but at different points in time.

See also

• Risk states reference
• Tie an SLA to a customer tier