A support team reports that its median response time has fallen and more tickets are being closed each week. At the same time, account managers hear from customers who have contacted support several times about the same unresolved problem. The two accounts need not contradict each other. The team may be responding faster while still struggling to complete the work customers need.
The useful management question is what the combination means and what should happen next. Perhaps a product defect is generating repeat contacts. Perhaps a new closure rule changes how tickets are counted. Perhaps the team has genuinely improved one part of the service while a different problem has worsened.
Metrics support judgment when their meaning, limitations, and relationship to decisions remain visible. They can mislead when a convenient indicator becomes sufficient evidence of success, or when a change in the number is treated as an explanation for itself.
Begin With the Decision the Measure Will Inform
A metric should have an intended use. Response time can help managers assess whether customers receive timely attention and whether the queue needs additional capacity. It cannot, on its own, establish that customers’ problems are resolved or that staff are giving appropriate advice.
The distinction between a process measure and an outcome measure helps. Acknowledging a request is an event in the process. Restoring a customer’s access is an outcome the service may be trying to achieve. Both can matter, and the organisation needs to understand the connection rather than assume one establishes the other.
The US Government Accountability Office’s guide to performance measurement and evaluation distinguishes ongoing performance tracking from studies designed to investigate how and why a programme works. The same distinction is useful in a business review. A dashboard can reveal a pattern that warrants investigation without establishing its cause.
For each prominent measure, record the decision it supports and what additional evidence may be needed. If a response-time alert could lead to hiring, routing changes, or a review of product defects, the manager needs information that helps distinguish those interventions.
Write Down the Definition Before Comparing Results
The name of a metric rarely supplies its full definition. Does response time begin when the customer sends a request or when it reaches the support queue? Does it stop at an automated acknowledgement or the first substantive reply? Are weekends, transferred tickets, and reopened cases included?
Changes in these rules can move the result without changing the customer’s experience. Keep the calculation, source, exclusions, and relevant versions accessible. A reporting change should be marked in the trend so readers do not interpret it as an operational improvement.
Denominators deserve particular attention. A completion rate among cases accepted for processing answers a different question from completion among all attempted cases. The GOV.UK guidance on completion rates illustrates why a service needs defined start and end points and an explicit denominator, including unsuccessful attempts where applicable.
The support team should also distinguish cases from customers. One person opening five tickets contributes differently to workload and customer experience than five people opening one each. Neither view is inherently correct for every question. The definition should match the decision under discussion.
Examine How Targets Change the Work
A target is intended to influence behaviour. The assessment should ask whether the encouraged behaviour serves the underlying purpose and whether the target creates an easier alternative route to a favourable number.
If staff receive credit for each closed ticket, merging related requests or keeping a complicated case open may appear less productive than closing several simple ones. That is a possible incentive effect to investigate, rather than evidence that staff will inevitably act in bad faith. People may be following a reporting rule or responding to workload constraints they cannot change.
For the support team, examine whether closure criteria reflect an actual resolution, a documented next step, or merely the end of the team’s current action. Those are different states. If waiting for a product fix is treated as closure, the report should still show the unresolved customer problem elsewhere.
The discussion of algorithmic warnings explains the related problem of optimising an indicator. The operational response here is to inspect the workflow and incentives directly. Rotating metrics on a schedule does not necessarily fix the underlying problem and can remove useful continuity from reporting.
Compare Speed With Quality, Workload, and Longer-Term Outcomes
A small group of complementary measures can reveal trade-offs that one target hides. The right combination depends on the service. Adding every available number makes a review harder without necessarily improving the decision.
For this support operation, the comparison might look like this:
| Measure | What it helps assess | What needs further investigation |
|---|---|---|
| Time to substantive reply | How long customers wait for useful attention | Whether the reply advances resolution |
| Repeat contact for the same issue | Problems that persist or return | Whether contacts are correctly linked |
| Old unresolved cases | Work that may be accumulating | Complexity, ownership, and external dependencies |
| Sampled case quality | Whether handling meets agreed standards | Reviewer consistency and sample coverage |
Consider the time horizon as well. Faster replies may be visible immediately, while repeat contacts emerge later. Compare groups of cases with sufficient follow-up rather than judge recently opened cases against older cases that have had more time to develop problems.
Capacity measures can explain another part of the picture. Work may move from initial response to specialist investigation, creating a queue elsewhere. A service improvement should be assessed across that handoff, especially if one team’s result improves while another absorbs more exceptions.
Investigate Variation Before Ranking People or Teams
An average can hide a long wait experienced by a smaller group. A median describes the middle case but says little about the longest delays. Percentiles, counts of old cases, and suitable breakdowns can add context, provided the samples are large enough to support the comparison.
Team comparisons also depend on case mix. A specialist team handling complex disputes may take longer than a team handling password resets. Ranking them on closure speed without accounting for that difference can reward the assignment of work rather than the quality of performance.
Small movements need cautious interpretation. A change may reflect ordinary variation, a holiday period, a changed customer mix, or a small sample. More decimal places do not resolve these issues. Report the relevant counts, collection period, and known limitations, and use appropriate analytical methods where the decision requires them.
Missing data is part of the evidence. If dissatisfied customers are less likely to complete a survey, the responses may not represent everyone served. If transferred cases disappear from one team’s reporting, its apparent improvement may need reconciliation with the receiving team’s records.
Give Qualitative Evidence a Defined Role
An individual complaint can identify a serious failure without establishing how common it is. A trend can establish a pattern without explaining the experience behind it. Using both forms of evidence helps a review ask better questions.
Read a sample of cases that includes ordinary work as well as complaints and outliers. Establish review criteria and retain examples of disagreement between reviewers. Staff close to the work can help identify ambiguous categories, repeated workarounds, or customer problems that do not fit the reporting structure.
For instance, several comments about a failed identity check might prompt a targeted investigation of that route. The comments do not prove a service-wide defect, but they identify what to inspect and which records may help establish its extent. The next review can then assess findings rather than repeat the anecdote as a settled conclusion.
Automated summaries and sentiment analysis can assist with this volume. Keep access to source material and assess whether the summaries preserve the issues relevant to the decision. A favourable sentiment trend should not close an investigation into a documented service failure.
End the Review With a Decision and a Way to Revisit It
A performance review should identify what the evidence supports, what remains uncertain, and who can act. The support manager may control staffing and routing but need a product owner to resolve a defect. Assigning the number to one person does not give that person control over all its causes.
The action record should connect the proposed change to a testable expectation. If better routing is expected to reduce repeat contacts, specify the cases affected, the observation period, and the other outcomes that should remain acceptable. A later review can then examine whether the change helped and whether work moved elsewhere.
Keep the measure itself open to review. Revise it when its definition no longer matches the service or when evidence shows it misses a consequential part of the work. Preserve enough history to explain the change and avoid presenting incompatible figures as one continuous series.
The team can retain its response-time metric while recognising that it measures one part of service quality. Connecting that number to resolution, case evidence, and operational authority makes the review more useful. The purpose of measurement is to help the organisation choose and assess its actions with a clearer view of the work.
