> ## 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 first-reply-time metrics: what the number includes, and how to move it > Distinguish first reply time from resolution time, find the 30-day first-reply metric in Inbox → Analytics and the SLA report, and read how channel mix and dispositions change what the number includes — with worked example calculations. # Read first-reply-time metrics: what the number includes First-reply time (also called first-response time) is the single most-referenced SLA number in the inbox, and the most misread. This page is the semantic: what the metric actually measures, where the 30-day figures live, and what does and does not count toward it. Once you read it correctly, the [SLA timers engine](/guides/inbox-sla-timers) and the [SLA report](/guides/inbox-sla-report-reading) pages take over the mechanics and the live breach view. ## 1. First reply time vs resolution time Two clocks measure different promises: * **First reply time** — elapsed time from the customer's first inbound message to the first reply your team sends. It measures *how long a customer sat with no answer at all*. * **Resolution time** — elapsed time from the conversation opening to the moment it closes. It measures *how long the whole issue took*. A five-minute resolution on an old thread can still be a first-reply breach; a one-minute first reply followed by a three-day resolution is a resolution breach. Read them separately, always. (Third clock, for completeness: **next-response time** — the wait after the customer's follow-up message — restarts each re-contact.) One predicate decides whether the first-reply clock exists at all: it starts only on an **inbound** message. An agent-initiated thread the customer never answered — a campaign, a proactive note, an outbound call — carries no first-reply clock, so it can never count as a first-reply breach and never dilutes the metric. This matters in the denominators below. ## 2. Where the 30-day first-reply metric is read Three surfaces, three different questions: * **Inbox → Analytics → Team performance** — the review surface. The **First-response SLA** card shows the *share* of first replies inside target as a percentage (green above 95%, amber 80–95%, red below 80%); the **Per-agent breakdown** table carries the same percentage per agent, and expanding **More metrics** adds **Avg first reply** — the raw seconds behind the percentage. Pick **Last 30 days** in the window selector and the row you screenshot in the weekly review is the standard 30-day first-reply figure. * **Inbox → SLA report** — the live surface. Answers "how many threads are over the first-reply line *right now*," plus a per-channel breakdown. It always shows the current state, not the historical average. See [Read the inbox SLA report](/guides/inbox-sla-report-reading). * **[SLA escalation policies](/inbox/sla-escalation-policies)** — not a metric reader, but the place that consumes the same breach logic at queue level: a per-digital-queue escalation policy decides what happens when first-reply breaches keep landing. Read the metric in Analytics or the SLA report; act on it with escalation policies. The discrepancy to expect: the Analytics percentage is a 30-day *attainment* figure; the SLA report count is a live *breach* snapshot. They will not match, and both are right. ## 3. How channel mix widens or narrows the window The first-reply average is a mix, and the mix moves when channel volume moves. If your WhatsApp policy runs a 30-minute target and email runs a four-hour target, a week of heavy WhatsApp volume pulls the aggregate average **down** even if per-channel speed is unchanged — and a late-night-hours SMS surge pulls it **up** when `business_hours_only` policies overnight the clock. Practical rule: before calling a trend real, open the **SLA by channel** row on the SLA report and compare per-channel attainment, and re-read the aggregate only after channel mix is stable. A drill into the Per-agent table's **More metrics** resolves whether the raw average moved for one channel or for all of them. ## 4. How dispositions affect first-reply accounting Dispositions are conversation-level outcome labels (Resolved, Refund issued, Escalated). They attach to the **close** of a conversation — that is, to resolution, not to first reply. First-reply time starts at the first inbound message and stops at the first outbound reply, regardless of how the conversation is later dispositioned. Where dispositions *do* enter the first-reply picture: * **The label is stamped at close**, so a conversation closed without a first reply ever sent (spam, a wrong-number thread) still counts toward resolution time but leaves the first-reply clock unanswered. If you disposition these into their own label (for example, "No response needed"), filter your reading to exclude them — otherwise they inflate the resolution average while the first-response percentage stays clean. * **Re-opened conversations** (a reopen within your re-contact window) start the resolution clock again, but the first-reply clock was already answered once and stays answered. Cleanup dispositions keep these threads out of the reopened set. For designing those label sets so reporting stays clean, see [Design inbox dispositions](/guides/inbox-dispositions). ## 5. Example calculations Worked from the case style used in [Unified inbox SLA engine](/guides/inbox-sla-timers). Synthetic default thresholds apply until you attach a policy (4h first response, 24h resolution, business hours only): **Example A — first reply inside target, resolution over.** A customer writes at 09:12; the operator answers at 09:37 (25-minute first reply), and the conversation closes at 11:47 (2h35m resolution). Result: first response *not* breached (under 4h), resolution *not* breached (under 24h) — but read the clocks apart, because a longer resolution would have been a resolution breach while the first reply stayed clean. **Example B — agent-initiated thread, no first-reply clock.** An outbound campaign message goes out at 14:00; the customer never replies. Result: no first-reply clock exists, so no first-response breach can ever fire; resolution time runs from open to close against the 24h default (or your policy target). Do not let such threads dilute your first-response percentage — they are excluded by the inbound-message predicate, not by you. **Example C — business-hours policy freezes the first-reply clock.** A customer writes Friday 17:40; your workspace posts business hours of Mon–Fri 09:00–18:00 and the policy has `business_hours_only: true`. The operator replies Monday 09:05. Result: first reply counts only the business hours between the message and the answer — 17:40–18:00 (20 minutes) plus 5 minutes Monday morning = 25 minutes against a 30-minute target: inside. **Example D — 30-day attainment percentage from raw data.** On the Team performance page at Last 30 days: 1,842 inbound conversations with a first reply; 1,774 sent inside target. First-response SLA = 1,774 / 1,842 = 96.3% — green. The **Avg first reply** column reads the raw seconds of those 1,842 first responses; the percentage and the average answer different questions and both appear on the page. ## See also * [Unified inbox SLA engine](/guides/inbox-sla-timers) — the timer mechanics this page reads semantically * [Read the inbox SLA report](/guides/inbox-sla-report-reading) — the live breach surface * [Team performance analytics](/guides/inbox-team-performance) — the 30-day review deck where First-response SLA and Avg first reply live * [Per-digital-queue SLA escalation policies](/inbox/sla-escalation-policies) — act on recurring first-reply breaches at queue level * [Design inbox dispositions](/guides/inbox-dispositions) — label sets that keep close-time reporting clean