Product
Metrics and KPI Framework
Proposed metrics and an explicit instrumentation-gap inventory.
Source: support-system: proposed metrics checked against internal/modules/analytics and the ticket model
Support System: Metrics and KPI Framework
A proposal. There are no users, so no metric here has a value, a target, or a baseline. The point of the document is to say what should be measured, why, and, for each metric, whether the system can already produce it. Anything marked "Not instrumented" cannot be reported today.
North Star
Tickets resolved within SLA that the customer did not have to reopen or repeat.
This combines three things the product is designed around: the SLA clock is fair, a solved ticket stays solved, and a customer does not explain twice. It is a proposal, and it is not computed anywhere today. Its parts are listed below.
How to read the status column
| Status | Meaning |
|---|---|
| Instrumented | The analytics module returns it today |
| Data exists | The ticket data holds what is needed, but no report computes it |
| Not instrumented | The data is not captured |
Quality of service
| Metric | Why it matters | Status |
|---|---|---|
| First response time, average and median | The first thing a customer notices | Instrumented |
| Resolution time, average and median | How long a problem lasts | Instrumented |
| Resolution SLA breaches | Missed commitments | Instrumented |
| First-response SLA breaches | Missed commitments | Data exists (breach timestamp stored per ticket) |
| SLA warnings acted on | Whether warnings change outcomes | Data exists |
| SLA breach rate by queue and priority | Where the problem is | Data exists (the breakdown gives volume and median first response by queue and priority, not breaches) |
| One-touch resolution rate | Efficiency and customer effort | Instrumented |
| Customer satisfaction, average and share positive | The customer's verdict | Instrumented |
| CSAT response rate | Whether the satisfaction score can be trusted | Instrumented |
Ticket integrity
| Metric | Why it matters | Status |
|---|---|---|
| Reopen rate | Whether solved means solved | Data exists (reopen count stored per ticket) |
| Follow-up ticket rate | Customers who write after closure | Data exists (follow-up links stored) |
| Time spent in pending | Whether pending is used honestly | Data exists (pause timestamp stored; no history of durations) |
| Time spent on hold | The same, for third parties | Data exists |
| Auto-closed share of solved tickets | Whether agents or the timer close tickets | Data exists (close reason recorded on the event) |
Time in pending is the metric the SLA design most needs. The rule that pauses the clock is fair, and it also lets an agent stop a clock. The only counterweight is a metric that makes it visible. At present only the current pause timestamp is stored, so durations across a ticket's life need the event history.
Routing quality
| Metric | Why it matters | Status |
|---|---|---|
| Time in queue before assignment | Customer wait that no agent owns | Data exists (queued and assigned timestamps) |
| Tickets queued, by reason | Which constraint is binding: staffing, skills, capacity, or shift | Data exists (reason stored); a live count appears on the wallboard |
| Sticky assignments, share of eligible tickets | Whether continuity works | Data exists (reason stored) |
| Sticky skipped, by reason | Why continuity failed | Data exists |
| Rebalanced tickets per run | Whether load is uneven | Data exists (reason stored) |
| Load per agent against capacity | Fairness | Instrumented (agent table) |
| Backlog and its age | Work accumulating | Instrumented |
Operations and platform
| Metric | Why it matters | Status |
|---|---|---|
| Volume, solved count, and median first response by channel, priority, type, category, or queue | Where customers come from and where the pressure is | Instrumented (breakdown) |
| Webhook delivery success and retry rate | Integration health | Data exists (delivery log) |
| Bot containment, share of bot conversations that end without a handoff | Whether bots help | Not instrumented |
| Bot handoff rate by flow | Where flows fail | Not instrumented |
| API error rate and latency | Platform health | Not instrumented |
Adoption
| Metric | Why it matters | Status |
|---|---|---|
| Active agents per day | Whether people use it | Not instrumented |
| Settings changes per workspace | Whether supervisors can configure it without help | Data exists (audit log) |
Guardrail metrics
Metrics that stop a target from being gamed.
| If you push | Watch |
|---|---|
| First response time down | CSAT, and reopen rate (fast but empty replies) |
| Resolution time down | Reopen rate, follow-up rate |
| SLA breaches down | Time in pending (clocks stopped rather than met) |
| One-touch resolution up | CSAT |
| Even load across agents | Sticky share and CSAT (continuity traded away) |
What to build first
- Reopen rate and follow-up rate, which need only a query.
- Time in pending and on hold, built from the event history.
- SLA performance by queue and priority.
- Bot containment and handoff.
- Adoption and API health, which only matter once the system is hosted.
Limitations
- No value, target, or baseline exists for any metric.
- "Instrumented" was checked against the fields the analytics module returns. It does not mean the figure has been validated.
- "Data exists" was inferred from the ticket model and was not confirmed with a query.
- The North Star is a proposal and has not been computed.