A customer calls for a copy of an invoice. The voice assistant says it has sent it, the customer says thank you, and the call appears in the dashboard as resolved. The following morning, the customer calls again.
Should the first call lose its resolved status?
There is no useful answer until someone asks what the second call was for. The invoice might never have arrived. It might have arrived but failed to solve the customer’s problem. Or the customer might have received exactly what they wanted and now need a different invoice.
Those possibilities require different decisions. Treating all three as a failed resolution punishes useful service. Treating all three as fresh demand hides unfinished work.
For a service manager, the next contact is a chance to check the first outcome. It needs a short review that compares the customer’s request, the action taken and the reason they returned.
Start with the job the customer wanted done
In CSM’s recent article on resolution rates, Joseph Kim argues that avoiding a human handoff does not establish that an agent completed the right task. That leaves a practical question after the call closes: what should the team do when later evidence challenges its original decision?
Consider this hypothetical request to an office supplier. A customer needs the August invoice for their company’s expense records. They ask for a copy at the email address already verified on the account. The assistant identifies the invoice, requests its delivery and tells the customer it has been sent.
Before reviewing the next call, write down the original job in one sentence: provide the customer with a usable copy of the August invoice.
That sentence matters. If the job is defined as sending an email, a successful dispatch event can end the review. If it is defined as providing the invoice, dispatch is one piece of evidence. It does not establish that the attachment was the right document or that the customer could access it.
The review should also distinguish a completed action from a promise. A delivery request accepted by a system is evidence that work was requested. A confirmation that the document reached its destination supports a stronger claim. Neither should be silently substituted for the other in the case record.
Read the next contact before choosing its label
Imagine three versions of the following morning’s call.
In the first, the customer says: “I still haven’t received the August invoice.” The delivery record shows that the request failed. The original need remains open. The team should correct the outcome recorded against the first request and assign someone to complete the delivery. This is a service failure with an identifiable cause, rather than unexplained repeat demand.
In the second, the customer says: “The email arrived, but the attachment won’t open.” The dispatch worked. The customer still cannot use the invoice. Here the original request is also unfinished, but the remedy is different: repair access or provide a usable copy, then check whether the problem is fixed. Telling the team simply that the customer called twice would conceal this distinction.
In the third, the customer says: “I received August’s invoice. Could you send July’s as well?” The first task was completed and the customer now has a new request. The same account, document type and contact channel do not make it the same unresolved issue.
There is a fourth possibility worth keeping visible. “I’m calling about my invoice” is not enough to decide. The customer might mean the missing copy, a question about its contents or a different month’s document. The correct temporary label is uncertain, followed by a clarifying question. A dashboard does not become more accurate when a reviewer guesses.
Keep the comparison small enough to use
A manager does not need a second transcript summary full of every detail. The review needs a concise comparison that another colleague can check.
Record the original request, including the relevant invoice or case reference. Record what the service promised, what the available action evidence establishes, and what the customer wants on the next contact. Then record the decision and the person responsible for any unfinished work.
For the inaccessible attachment, that might read:
Original request: usable copy of the August invoice. Delivery confirmed; customer reports that the attachment will not open. Same need remains unresolved. Billing support to provide an accessible copy and confirm access. Review the attachment failure separately from the voice assistant’s wording.
This record makes both the service decision and the operational problem visible. It avoids blaming the assistant for a failed downstream service without checking the evidence. It also avoids declaring success just because the assistant used the delivery tool correctly.
Link contacts through verified account and request context under the team’s existing access rules. A matching telephone number can help locate a record; it should not, by itself, establish which person’s request is being discussed. Shared numbers and incomplete references should lead to a check, not a confident merge.
Do not turn every related question into a failure
Some customer journeys require more than one step. A customer may receive an invoice and then ask how to submit it through an employer’s expense system. That follow-up can reveal a gap in the information provided without showing that invoice delivery failed.
Keep two questions separate. Was the original agreed task completed? Did the customer need further help to achieve their wider purpose?
Both are useful. The first supports a fair review of the original service. The second can suggest better instructions or a clearer explanation of what happens next. Combining them into one failed-resolution label makes it harder to decide what to improve.
The boundary should come from the recorded request and the customer’s account of it. If the customer originally asked for an invoice they could upload and the supplied format prevents that upload, the agreed task may still be unfinished. If they asked for a copy, received a usable one and later need help with a separate process, record the completed task and the related next step.
This is why a short sentence describing the original job is more useful than a broad category such as “billing”.
Report what the team actually observed
Marija Jovanović’s earlier CSM article recommends examining same-problem returns alongside the reported resolution rate. A return review makes that measure more useful by explaining which contacts belong in it and what evidence supports their inclusion.
Choose an observation period appropriate to the service before reviewing a batch of closed requests. Say which channels are included and which cannot be linked reliably. A request closed yesterday has had less opportunity to generate a return than one closed last month. Comparing them as if their follow-up periods were equal can mislead the team.
Use the original request as the unit when reporting reopened outcomes. Three later calls about one missing invoice are three contacts, but one original request that remained unresolved. Keep the contact count as a separate measure of the work created. It helps staffing decisions without multiplying the number of failed original tasks.
Report confirmed same-need returns, related next steps, new requests and uncertain cases separately. Show the raw counts and the number of original closed requests with the full observation period available. If some contacts cannot be matched, make that limit visible rather than assigning them to the most convenient category.
An absence of observed returns is still only that. A customer might solve the problem another way or choose not to call again. The review can identify failures it observes; it cannot prove satisfaction from silence.
Use the finding to change one part of the service
The point of the review is to give someone a specific job. A failed delivery needs a delivery fix. An inaccessible attachment needs an access fix. A repeated question about the next step may call for better instructions. A new request needs ordinary service, without a retrospective penalty on the first call.
For a first review, choose one recurring task and examine a small, manageable set of closed requests together with their later contacts. Have colleagues independently classify the same cases, then discuss disagreements against the original request and action evidence. If they disagree about what completion means, settle that definition before turning the classifications into a performance target.
A resolved label records a decision made with the evidence available at the time. The customer’s next call can supply evidence that changes it. The team should be able to make that correction and explain why, while leaving genuinely completed work marked complete.
About the Author
Written by Andreas Kromann, founder of Speechdata.ai and Spirelight.ai.
This is a Sponsored Post.