Customer experience
Fast replies are not enough: reading customer service metrics fairly
Worked examples distinguish average from median and respondent satisfaction from the whole customer base, then connect metrics to conversation review.

A response-time report can improve while customers still repeat their problem to several people. A satisfaction score can rise when only a small group answers the survey. This does not make metrics useless. It means every number needs a definition, a sample and context before it becomes a decision.
The calculations below are hypothetical. They are not UCaaS performance results or customer data. They provide a method a team manager can apply to available reports.
Define the clock first
First response time measures the wait between a request arriving and the first response under your system's definition. In Zendesk's definition, the clock stops at the agent's reply, not an automated acknowledgement. State explicitly whether your measure includes automated responses and whether it uses business hours or elapsed calendar time.
Suppose opening hours end at 17:00 and resume at 09:00. A request arrives at 16:55 on Sunday and receives an agent reply at 09:10 on Monday. Elapsed time is 16 hours and 15 minutes; business time is 15 minutes, assuming no holiday or other working period intervenes. Both numbers can be correct under their definitions. Substituting one for the other changes the meaning of the experience.
Inspect the distribution before celebrating the average
For five requests, response times in minutes are 2, 3, 4, 5 and 46. Their total is 60 minutes, their average is 12 minutes and their median is 4 minutes. The median describes the middle of this sample. The request that waited 46 minutes still needs its own review; a good median does not make it disappear.
Display the case count alongside both measures. Then open the longest-waiting case. Was it assigned correctly? Was the request understood? Was a missing piece of information responsible for the delay? The next question should lead to a repairable operating step, rather than blame based on a single figure.
80% satisfaction: among whom?
For a positive-response CSAT percentage, divide positive ratings by ratings received and multiply by 100. Decide beforehand what counts as positive, such as 4 or 5 on a five-point scale. The CSAT guide explains this measurement approach and the problem of non-response.
In our example, 80 customers receive the survey, 20 answer it and 16 give a positive rating. Satisfaction among respondents is 16 ÷ 20 × 100 = 80%. Survey response rate is 20 ÷ 80 × 100 = 25%. “80% of all customers are satisfied” would be an unsupported conclusion: the other sixty customers have not supplied ratings.
When comparing weeks, keep the survey question, invitation timing and positive-response definition consistent. Changing “Was your request resolved?” to “Was the agent helpful?” changes what you measure, even if the answer scale still has five points.
Connect responsiveness to the outcome
Read three things together: how quickly a useful response arrived, whether the request progressed to resolution, and what the customer thought of the experience. If you measure reopened cases, define them first. Do they include the same issue returning within seven days, for example, or any new contact? Seven days is an illustrative choice here, not a universal standard.
Consider a hypothetical case answered in two minutes that passes through three agents and later returns for the same reason. Better information or clearer ownership may help more than demanding a one-minute reply. When comparing performance, also distinguish straightforward enquiries from cases that need approval or another team's intervention.
A repeatable review meeting
- Start with one request type, one channel and a defined period. Record excluded cases and the reasons for exclusion.
- Show case count, average, median and longest wait, followed by satisfaction and response counts where available.
- Open a small conversation sample covering an ordinary case, a delayed case and one that returned for the same issue.
- Record the information or step that could have prevented the delay and assign an owner to improve it.
- Use the same definitions next time, noting changes in request volume or mix.
In UCaaS, available call logs and message and conversation reports can provide a starting point. If a chosen metric requires data outside a report, calculate it from an appropriate source and document its definition. Do not assume that every metric discussed here is a ready-made field in the platform interface.
Take four things to your next meeting: a clearly defined number, the count it represents, a conversation that explains it and one owned improvement. Together they make reporting the start of a discussion about actual service.
%20(3).png)