A closed conversation is only one piece of evidence.
Suppose a customer asks for a refund, receives an explanation and leaves the chat. Two days later, they email because the refund never arrived. The first conversation can look complete while the customer’s task is still unfinished. This is an invented situation, but the measurement question is real: a public support practitioner asked Intercom to track new contacts after assumed resolutions, including contacts that start a new conversation.[S4]
Start by reading what your system calls resolved. Intercom distinguishes positive customer feedback from an assumed resolution when the customer leaves without asking for further help.[S2] Zendesk’s current verified-resolution tier includes an LLM assessment of the conversation text.[S3] These are product definitions. Neither label, by itself, is a record that a refund reached the customer.
We would keep three fields beside each other: the system’s label, the customer’s response and the evidence of the requested outcome. For the refund, that last field needs an appropriate transaction status. For an explanation, a reviewer can check whether it was correct and answered the question. Define the needed evidence with the person responsible for the service before scoring cases.
Follow ten original issues, even when the next contact has a new number.
Our example begins with ten invented issues initially marked resolved by a chatbot. Each has a full seven-day observation period starting at that mark. We follow the initial issue, rather than counting every message as a separate success or failure. The chosen number and period explain the calculation; they are not a sample-size recommendation or a service target.[S1]
Issue 01 returns in the same chat on day two. Issue 02 returns in a new email on day four; a reviewer confirms that it concerns the same unresolved problem. A later contact potentially related to issue 03 cannot be linked reliably. Issue 04 has a new, unrelated question. For issues 05–10, no further contact is observed in the available records. These are assumed observations, not records from a MING client.
The two same-issue returns count once each. The unclear link stays visible, and the unrelated question does not become a failure of the original answer.
| Initial issues | What the full seven-day window shows | Count |
|---|---|---|
| 01–02 | Confirmed return about the same unresolved issue | 2 |
| 03 | Follow-up cannot be linked reliably | 1 |
| 04 | Return concerns a different issue | 1 |
| 05–10 | No return observed in the available records | 6 |
| All initial issues | Initially marked resolved, each with complete follow-up | 10 |
The observed same-issue repeat share is 2 ÷ 10 = 20%. Seven issues have no observed same-issue return and one has an unclear link. Do not rename the remaining 80% “success”: an unobserved return or a customer who gives up can remain invisible. This is our proposed issue-cohort measure, not a reproduction of either vendor’s dashboard metric.[S1]
Keep the evidence that connects a return to the original problem.
A new ticket number can hide a repeat; the same customer can also have several unrelated problems. Use the identifiers and records already authorised for your service, and inspect the reason for contact. A matching topic label is a clue, not sufficient proof of the same unresolved issue. If the connection cannot be established, keep it unknown.
A short review record makes the denominator and the judgement inspectable. The same fields work for both a reopened conversation and a new contact.
| Record | Why it matters |
|---|---|
| Initial issue and requested outcome | Defines the unit counted once and what a solution would mean. |
| Resolved mark, window end and included channels | Shows whether the full period has elapsed and what could be observed. |
| Follow-up reference and same-issue judgement | Separates a repeat, another topic and an unclear connection. |
| Outcome evidence and reviewer | Links the conclusion to a record and a responsible person. |
Keep cases whose window is still open in a waiting group. They enter the calculation when their full period has elapsed. Also retain counts for all incoming issues, including those the chatbot never handled or passed to a person. A strong result on a narrow, easy subset does not describe the whole service. For the wider evidence chain, use our audit-trail guide .
Repair the reason customers have to come back.
Return to the refund example. If the answer promised a payment that was never initiated, inspect the action and its confirmation. If the payment is still within an agreed processing time, the next improvement may be a clearer expectation and a visible status. If the chatbot cannot safely handle the request, the service needs a working handover. A lower repeat percentage is not a reason to make it harder to reach a person.
Review the confirmed returns and unclear links with the service owner, then choose one correction. Compare equivalent issue types, channels and completed windows after that change. Keep correctness, waiting time and human effort beside the repeat share; our quality-metrics answer explains those separate checks. Start with one recurring customer request and establish what would prove it finished.
Evidence and limits
- The ten issues, events and seven-day period are invented. The calculation illustrates a proposed MING review; it does not establish a customer result, reliable sample size or recommended threshold.
- Missing channels, uncertain identity and customers who stop trying limit what repeat contact can establish. No observed return is not verified resolution.
- The public practitioner question supports the usefulness of asking; vendor documentation explains its own labels as read on 23 October 2026. We have not tested those products or compared their accuracy.
