Request closed. Has the customer been helped?
Your team closes more service requests, yet customers keep calling about work that appears complete. How can you tell whether the service is improving? Define the customer outcome first, then choose a few measures that reveal unfinished work, customer effort and the support employees need. Each measure should help someone make a practical decision.

Decide what completion means to the customer
A closed job is a useful administrative fact. The customer may still need an explanation, a replacement part or a decision before they can continue. If reporting ends at job closure, that remaining work becomes difficult to see.
Consider a fictional technical service that inspects and adjusts pumps. A technician completes the visit and sends the report. The customer remains unsure which setting suits their application. The visit is finished, but the agreed support may still be incomplete. This example illustrates a design question; it is not an IndustrylinQ client case.
Describe the promised result in language that the team and customer can recognise. For this service, completion might require an inspection, an explanation of the findings and clarity about the next action. It should not imply a guarantee of uninterrupted operation if the offer never included one. Measures need to reflect the actual agreement.
The GOV.UK Service Standard connects performance measures to the problem a service is intended to solve. We apply that principle here to business operations. The requirements for UK government services are not requirements for your company.
Write a definition before building a dashboard
Ask the people delivering the service to work through several real jobs. When did each request start? What evidence supported closure? Did a later phone call concern a new request or the original problem? Without shared definitions, repeated customer effort can appear as additional work successfully completed.
Give each measure a short specification: what is counted, what it is compared with, the period covered and the source record. Include missing information and responsibility for resolving ambiguous cases. If the definition changes, record the change so the next report does not imply an improvement that came only from different counting.
The GOV.UK guidance on completion rates explains why start and end points matter. Submitting an application can count as completing a digital transaction even when the eventual decision is unsuccessful. For your business, distinguish the completion of an administrative step from delivery of the agreed outcome.
A small set of measures for the fictional pump service could be:
On a small screen, scroll horizontally to read the full table.
| Measure | Working definition | Decision it supports |
|---|---|---|
| Agreed outcome reached | Confirmed completions within a defined group of jobs | Can the service deliver its promise? |
| Work past its promised date | Every overdue job, including its current reason for waiting | Where should someone intervene? |
| Further contact about the same request | Follow-up linked to the original job | Is information or support missing? |
| Additional team effort | Specialist help and recovery work beyond planned delivery | What support should change? |
This is a starting point, not a universal scorecard. An advisory engagement or subscription service needs its own definitions. Add a measure only when somebody can explain what decision it will inform.
Keep the comparison consistent
Suppose twenty jobs start in a fictional month and eighteen jobs close. Ten of those closures relate to earlier months. Dividing eighteen by twenty does not establish that ninety per cent of the new jobs are complete. To answer that question, follow the original twenty jobs together and assess their status at a defined date.
Show open, cancelled and unknown outcomes alongside completed work. An absent customer confirmation is neither proof of success nor proof of failure. Identify what remains unconfirmed and what evidence could resolve it. For longer engagements, also show how long open jobs have been waiting. Reporting only on closed jobs can hide the longest delays.
Compare similar work before drawing conclusions. A routine inspection and an investigation into an intermittent fault make different demands. If the balance between them changes, an average can move even when working practices remain the same. Review the numbers with a few complete cases and the people who understand them.
Ask for feedback when the outcome is usable
A positive response after a helpful phone call tells you something about that interaction. It may tell you little about a solution the customer has not tried. Choose a later moment, where appropriate, to ask whether the customer could proceed and what remained difficult.
The GOV.UK guidance on user satisfaction distinguishes the end of a digital transaction from the end of the whole service. This distinction is useful when your service combines a portal, a conversation and an on-site visit. Place feedback within that full journey.
Record how many customers were invited to respond and how many did. Keep unsolicited comments, complaints and structured follow-up recognisable as different sources. A handful of responses can suggest valuable questions, but should not be presented as representative of all customers. Include stalled work in the review and acknowledge where customers' experiences remain unknown.
Give employees a way to act on the findings
An overdue-work report helps only if someone can respond. Decide who takes ownership of a missed commitment, what discretion they have to provide further explanation and when specialist support is available. Better measurement should make the next action clearer.
Review results with employees who know the work. Ask what helped them deliver and what made additional effort necessary. Someone handling complex requests may close fewer jobs while helping customers achieve more. Raw closure counts are therefore a poor basis for ranking individuals without understanding their responsibilities and circumstances.
Choose one improvement with a clear expectation. The fictional pump service might add an explanation of relevant settings to its inspection report. The team would look for fewer follow-up questions without making preparation unreasonably time-consuming or introducing new confusion. Examine subsequent cases as well as the totals. A change in a measure does not, by itself, establish its cause.
Make recording part of delivery
Start with information already produced during the job. Connect subsequent contact to the same request. Where the distinction matters, separate work performed from findings explained and decisions still required. Let employees correct an inaccurate status with a brief reason, rather than creating a parallel reporting spreadsheet that nobody trusts.
Software can bring the agreement, remaining actions and evidence together. Its design depends on what those records mean and who can act on them. Before commissioning a dashboard, bring an existing report and several complete customer journeys to the table. Through business process analysis, we can help establish which measures, responsibilities and supporting changes will make your next decision better informed.
Your next step
What do you want to make possible?
You do not need a software specification to start.
