Metrics · SupportRoadmap Docs
Customer-support metrics explained
Customer-support metrics are operational measurements—such as first response time, resolution time, CSAT, NPS, and CES—that help software support teams understand speed, quality, and customer effort. Definitions are generic; exact calculation rules are product- and vendor-specific.
By Tom Ulman · Published · Last reviewed
This page is for people doing customer-facing software and SaaS support. It is not a generic call-centre KPI catalogue, and it does not claim universal benchmarks.
Scope
Software support teams use metrics to understand queue health, customer experience, and investigation quality. The same label can mean different things in Zendesk, Intercom, Salesforce Service Cloud, Jira Service Management, or an internal tool. Treat vendor docs as the source of truth for how your product calculates a metric.
Core metrics software support teams usually track
| Metric | What it usually measures | Useful for |
|---|---|---|
| First response time | Time to the first meaningful reply | Queue responsiveness |
| Resolution time | Time to resolve or close the issue | Investigation depth and handoffs |
| CSAT | Satisfaction with a specific interaction | Interaction quality |
| NPS | Likelihood to recommend the company or product | Broader loyalty signal |
| CES | How much effort the customer says they spent | Friction in the support path |
CSAT vs NPS vs CES
- CSAT asks about a recent interaction or resolution. It is the most common support-survey metric.
- NPS asks about overall recommendation intent. Product, sales, success, and brand can all move it; support alone rarely owns it.
- CES asks how hard it was to get help or complete a task. High effort can coexist with a polite “satisfied” CSAT score.
Some SaaS teams also track a product satisfaction score (sometimes called PSAT) for the product itself rather than the support interaction. Treat that as a related but different signal; do not mix it with ticket CSAT without checking how your organisation defines it.
Realistic SaaS example
A B2B analytics product has a Monday spike in tickets about dashboard exports. First response time stays under the team’s target because macros acknowledge the issue quickly. Resolution time rises because engineering must confirm a regression. CSAT dips on tickets that waited for the fix, even when agents communicated clearly. The metric set tells a coherent story only when you read FRT, resolution time, and CSAT together.
Practical application
- Learn which timers and survey rules your ticketing tool actually uses.
- Separate “waiting on customer” from “waiting on engineering” if your tool supports status categories.
- Use first response time versus resolution time deliberately; do not optimise one while ignoring the other.
- Connect metric literacy to the Support Metrics that Matter roadmap skill.
Limitations and common mistakes
Do not treat industry blog “averages” as targets for your product or queue.
Do not assume every ticket type should share one resolution-time goal.
Do not blame agents alone when a metric moves because of a product incident.
Related concepts
Primary sources
Prefer an ordered path? Open the related roadmap skill and work through it with the curated resources.
Learn this in order