> ## 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.

# Team performance analytics for the digital inbox: supervisor KPIs, per-agent breakdown, weekly review

> Read the Inbox → Analytics → Team performance deck like a supervisor: the six headline KPIs, the per-agent table with health-coded badges, the day presets, and how to wire the page into a weekly staffing review.

# Team performance analytics for the digital inbox

Voice queues have had per-agent analytics for a while; the digital inbox now has the same surface at **Inbox → Analytics → Team performance**. It answers the questions a supervisor asks every day: how many tickets is each agent carrying, how fast are they replying and resolving, are SLA targets holding, and how satisfied are the customers they close. Everything on the page rolls up from ticket SLA clocks and CSAT responses you already have — there is nothing to switch on.

Visibility is role-scoped. Owner, admin, and supervisor roles see every agent in the workspace; any other role sees its own numbers only. Reading the page requires the `inbox:read` scope, same as the rest of the inbox.

## 1. The headline KPI deck

Six cards sit at the top of the page. Each answers one numbered question, and the four that carry a target threshold are colour-coded so a failing number stands out on the row:

* **Active agents** — how many agents handled tickets in the selected window.
* **Open workload** — tickets currently open across the team.
* **First-response SLA** — the percentage of first replies sent inside the SLA target. Green above 95%, amber at 80–95%, red below 80%.
* **Resolution SLA** — the percentage of tickets resolved inside the SLA target, on the same bands.
* **First-contact resolution (FCR)** — the percentage of tickets resolved on the first contact with no reopen, measured inside the re-contact window shown in the card label (for example, "First-contact resolution (24h)").
* **CSAT** — the average satisfaction rating out of 5, across all survey responses in the window.

The colour bands are the same ones the per-agent badges and the trend chart use, so a card and a badge never disagree about whether a value is healthy. Until a policy exists, attainment is measured against the workspace's synthetic defaults (four-hour first response, 24-hour resolution); the percentages are real either way.

Two volume cards — Active agents and Open workload — are deliberately neutral. Colour implies a threshold, and there is no right answer to "how many agents" or "how much backlog."

## 2. The per-agent breakdown

Below the cards, the **Per-agent breakdown** table opens on a tight core column set: Agent, Tickets, Open, First reply SLA, Resolution SLA, First-contact resolution, and CSAT. That is the at-a-glance comparison row — who is carrying what, and whether the outcome metrics hold.

Health-coded badges carry the signal. First-response SLA, Resolution SLA, FCR, and CSAT each tint green (on track), amber (watch), or red (at risk) against fixed thresholds, so you scan colours first and numbers second. A "—" means the agent has no data for that metric in the window — no CSAT responses yet, or no FCR-eligible tickets — not a zero. The row for the signed-in viewer is tagged "You."

Expand **More metrics** (top right of the table) to add the secondary detail set: Resolved and Reopened counts, plus the raw time metrics — Avg first reply, Avg resolution, Avg handle (active handle time per ticket), and Total handle. Handle time is active focus time accrued from the ticket-detail view, not elapsed queue time, so it stays "—" until the agent accumulates focus time on a ticket. Collapse back with **Fewer metrics**.

Two footnotes that save confusion. The table virtualizes, so it renders every agent the API returns without the page slowing down; raise or lower the API `limit` (default 50, max 200) if you need a different slice. And the secondary columns are where the raw first-reply time lives — the core view keeps the outcome percentage (First reply SLA) because that is what you compare across agents.

## 3. Window presets and refresh

The **Time window** selector in the header picks the look-back: Last 7 days (spot check), Last 30 days (default, the standard review window), or Last 90 days (seasonal trend). The API accepts any value from 1 to 90 days; the presets just cover the common cases. The selector applies to everything on the page — cards, table, and the trend chart. A refresh button next to it re-runs the queries without a page reload.

For anything beyond the presets, the REST endpoints return the same rows the dashboard renders:

```bash theme={null}
curl -G "https://api.orbit.devotel.io/api/v1/inbox/team-performance/agents" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  --data-urlencode "days=14" \
  --data-urlencode "limit=200"
```

`GET /inbox/team-performance/agents` returns the per-agent rows plus un-paginated team totals, and `GET /inbox/team-performance/trends` returns the daily SLA-attainment series. Both honour the same role-scoped visibility: an API key owned by a non-elevated role gets its own agent's rows only.

## 4. The trend chart

The **Resolution SLA-attainment trend** card plots one bar per day: resolution-SLA attainment on the days tickets were opened, with the count of opened tickets beside each bar. Use it to separate "we had a bad Tuesday" from "the line is drifting down." A consistent drift beats any single red bar.

## 5. Reading the numbers when staffing shifts

Metrics react at different speeds, so read them in order:

1. **First-response SLA moves first.** When staffing drops, the first failure is the queue waiting longer for a first reply — days before resolution quality degrades. Call-off risk lives here.
2. **Open workload rises next.** Ticket inflow stays roughly constant while throughput falls, so the backlog builds even while resolution quality still looks fine.
3. **Resolution SLA erodes over days.** Agents rushing the backlog start closing late; average resolution time climbs with it.
4. **FCR and CSAT move last and slowest.** These are trailing quality measures. A CSAT dip two weeks after a staffing change is still probably the staffing change.

The inverse also reads: when a new hire or a routing change lands, First-response SLA and Open workload confirm the improvement inside a week; do not wait for CSAT to move before calling a staffing bet.

## 6. Wire it into the weekly review

One page view, five minutes, same agenda every week:

* **Screenshot the KPI cards and the per-agent table at the 30-day window.** That snapshot is the review artifact; compare week over week.
* **Walk red and amber badges top-down.** For each at-risk agent, decide whether it is a coaching conversation or a workload rebalance — high Open plus falling SLA is a routing problem; low Open plus falling SLA is a coaching problem.
* **Decide one staffing action from the table.** Shift a queue assignment, rebalance the routing rules, or schedule a coaching session. Record it so next week's trend bar shows whether it worked.
* **Close the loop on CSAT.** An agent whose CSAT badge is red gets an auto-CSAT/NPS follow-up review — check the queue and agent scorecards from the auto-dispatch guide rather than sampling tickets by hand.

The SLA percentages this page measures come from the same policy engine that fires breach alerts. If you have not attached a policy yet, attainment is scored against the workspace defaults below; attach one so the alerts your team watches and the attainment you review mean the same thing.

Until a policy is attached, the workspace still scores against the synthetic defaults described in the SLA guide, so this page works from day one — it just works on defaults, not your real targets.

## See also

* [Unified inbox SLA engine](/guides/inbox-sla-timers) — the policies whose targets this deck measures attainment against
* [Auto-CSAT/NPS dispatch](/guides/auto-csat-nps) — close-triggered survey dispatch and the queue / agent scorecards behind the CSAT column
* [Operate the Inbox Tickets queue](/guides/inbox-tickets-workflow) — assignment and workflow that generate the tickets being measured
* [Omnichannel Inbox setup](/guides/inbox-setup) — channels, routing, and the queue around the analytics
* [Inbox API reference](/api-reference/inbox) — request and response schemas for the team-performance endpoints