> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Read the inbox SLA report and act on breaches > Read the inbox SLA report — current breach counts, per-channel breakdown, active breach rows — and follow the response loop: configure per-channel first-response and resolution targets, then route, coach, and QA-sample your way back under the line. # 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](/guides/inbox-sla-timers). ## 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](/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](/guides/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](/guides/inbox-sla-timers). 4. **QA-sample the breaches.** When a breach closes, sample a few of those conversations in [Quality evaluations](/guides/quality-evaluations) (and tune the sample rate in [QA sampling settings](/guides/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](/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 * [Unified inbox SLA engine](/guides/inbox-sla-timers) — timer mechanics, breach actions, escalation tiers, and acknowledging breaches * [Inbox routing rules](/inbox/routing-rules) — route breaching channels to a queue with headroom * [Supervisor coaching](/guides/supervisor-coaching) — the coaching loop for response-workload issues * [Quality evaluations](/guides/quality-evaluations) and [QA sampling settings](/guides/qa-sampling-settings) — sample the recovered breaches for handling quality * [Per-digital-queue inbox SLA escalation policies](/inbox/sla-escalation-policies) — escalate when a whole digital queue's backlog stalls past its own target * [On-call alerting](/guides/oncall-alerting) — page a rotation when breaches need an on-call response