Skip to main content

​
Read the inbox SLA report and act on breaches

The SLA report (Inbox → SLA report) is the operational answer to how fast are we responding and resolving, and where are we over the line right now. It shows your workspace’s SLA policies, the current breach state of your open conversations, and a per-channel breakdown, in one page. This guide walks through what the report measures, how to set targets per channel, how to read the numbers, and what to do when a breach lands. The report requires an owner or admin role — the policy settings live on the same page as the breach digest. If a teammate only needs to see whether a thread is overdue, the inbox list’s SLA badge covers that without this page.

​
1. What the SLA report measures

The report tracks two kinds of response-time targets against your open conversations:
  • First response — the time from a customer’s first inbound message to the first reply your team sends. An outbound-only thread (a campaign, an agent-initiated message the customer never answered) has no first-response obligation, so it never counts as a first-response breach.
  • Resolution — the time from a conversation opening until it is closed.
A conversation counts as breached when one of its clocks passes the resolution target from the matching policy — or the platform defaults (4 hours for first response, 24 hours for resolution, counted in business hours only) when no policy matches. Timers with business_hours_only pause outside your workspace’s posted hours. Targets are your own policy. Set them to match whatever your team has committed to — the report is a response-time tracker, not a record of contractual SLA terms. For the timer mechanics themselves (the three clocks, breach actions, escalation tiers), see Unified inbox SLA engine.

​
2. Configure per-channel policy

Open Inbox → SLA report, flip Enable SLA timers for this workspace on, and click Create policy.
  1. Give the policy a name — e.g. WhatsApp: 30-min first response.
  2. Set the scope. per_channel applies the targets to one channel only (SMS, WhatsApp, email); org_wide is the fallback for every channel without its own policy. One policy can be marked as the default.
  3. Enter the first-response and resolution targets in minutes, and decide whether the clocks should count business hours only (pausing outside your posted hours) or run 24/7.
  4. Save. The policy takes effect on the next SLA sweep, and per-channel rules override the org-wide default from that point.
You can stack policies freely — a 30-minute first-response target on WhatsApp, an hour on SMS, and a 4-hour org-wide fallback on everything else. Editing or deleting a policy falls back any conversations that followed it to the next-most-specific match, then to the defaults.

​
3. Reading the report

The top of the page is the current breach state of your open conversations:
  • Stat cards — total open conversations, and how many are currently over the first-response target, resolution target, and the next-response target respectively. A conversation is counted in each card it breached.
  • SLA by channel — the per-channel breakdown. Each channel gets its on-time share (the share of sampled conversations not currently breached, colour-banded), its breach count, the effective target that resolves for that channel, and whether a breach action (reassign, notify, Slack/Teams, webhook) is armed on it. This is the view to use when you ask which channel is dragging the aggregate down.
  • Active breaches — one row per breached conversation, sorted newest-first: the contact, its channel, which clock breached, and how long it’s been overdue. Open this table to pick up a breach by hand.
Two things to read right. First, the report is a snapshot of open conversations — it refreshes every 60 seconds and shows what’s over the line now, so it always answers “what needs attention,” not “how did we do last month.” Second, when your workspace has more open conversations than the report loads, the breach counts are labelled as a sample of the most recent ones — the cards then describe that sample, not the whole queue, so interpret them accordingly.

​
4. Acting on breaches

A breach is an operational signal, not an alarm to snooze. The response loop, in rising order of weight:
  1. Route the queue away from the breach. If a channel or queue keeps landing in the Active breaches table, point its routing rules at a team with headroom — set up a rule that matches that channel and assigns incoming threads to your senior queue, or to a dedicated escalation queue. Configure it under Inbox routing rules.
  2. Coach the workload, not just the individual. When the SLA by channel view shows one channel’s on-time share sagging while its breach action is quiet, the fix is usually staffing and priority, not finger-pointing — the Supervisor coaching loop (live monitoring, whisper, and quality review) is the cadence to run that on.
  3. Arm a breach action. The SLA policy itself can fire the first response for you — reassign to an escalation queue, notify supervisors, or post to Slack/Teams the moment a clock crosses the line. See the breach-action table in Unified inbox SLA engine.
  4. QA-sample the breaches. When a breach closes, sample a few of those conversations in Quality evaluations (and tune the sample rate in QA sampling settings) to check whether they were handled well or merely closed — a recovered SLA number hides poor handling, not poor speed.

​
5. Worked example — a 30-minute first-response target on WhatsApp

Say your WhatsApp queue is the busiest and you want it answered inside 30 minutes:
  1. Set the target. On Inbox → SLA report, click Create policy. Scope it per_channel with the channel set to whatsapp, set the first-response target to 30 minutes, and save. From the next sweep on, WhatsApp conversations measure against 30 minutes while everything else keeps the org-wide default.
  2. Read a breach. An hour later the report’s cards show First-response breached: 3, the by-channel row for WhatsApp drops to an 82% on-time share, and three WhatsApp rows sit in Active breaches with the longest 25 minutes overdue. That tells you it’s a queue problem, not a one-off.
  3. Route to the senior queue. Open Inbox routing rules and add a rule that matches inbound WhatsApp conversations and assigns them to the senior queue. New threads now land where they get answered first, and the on-time share recovers on the next refresh cycles.
The same pattern generalises — read the per-channel row, follow it with a routing change, and only after the queue settles tune the target itself.

​
See also