Returning problems can reveal incomplete resolution, unclear expectations, or failure outside customer service. The measure only works with case linkage and a fixed window.
Reopen, repeat contact, and FCR are different
A reopen occurs when the same case returns to an active state. Repeat contact occurs when the customer returns for the same outcome, even through another channel or a new record. Contacts per case measures total effort. FCR asks whether the need was resolved on the first contact, but depends on case policy and available confirmation.
AWS documentation keeps separate metrics for reopened cases, cases resolved on first contact, and average contacts per case. Treat that distinction as a warning that one rate cannot represent every customer return.
Use a cohort and a fixed window
Reopen rate = cases first resolved in the cohort that reopened within the window ÷ eligible resolved cases in the cohort. Repeat-contact rate uses the same denominator but includes a new contact linked to the same reason or outcome. Choose a window that fits the service cycle and never compare different windows as if they were equivalent.
A recent cohort has not had enough time to return. Mark it incomplete and wait for it to mature. Exclude spam and technical duplicates, but do not remove difficult exceptions to improve the result. Document how identity, case, and reason are linked across channels.
| Measure | Observed event | Use |
|---|---|---|
| Reopen | The same case becomes active again | Evaluate closure and completion |
| Repeat contact | A new contact seeks the same outcome | Find needs that persist across channels |
| Contacts per case | Number of interactions linked to the case | Understand effort and complexity |
| FCR | Case resolved on first contact under the defined rule | Monitor initial resolution carefully |
Investigate causes, not agent names
Separate returns caused by an incomplete answer, external deadline, untracked promise, unclear instruction, product defect, billing issue, integration failure, or early closure. Segment by queue, reason, channel, and stage, then read a sample.
ISO 10002 calls for analysing and evaluating complaints to improve products and services and reviewing process effectiveness. The action may belong in knowledge, product, routing, or communication—not necessarily with the person who closed the case.
Write the metric contract before comparing results
Record the name, management question, numerator, denominator, start event, end event, observation window, calendar, exclusions, and owner. If two people cannot reproduce the same result from the same cases, the definition is not ready.
Keep the formula version with the report. A change in status, channel, business hours, or reopen policy can break historical comparability. Preserve the previous series or mark the break clearly whenever the rule changes.
- A management question written in one sentence
- An explicit numerator and denominator
- Documented eligible population and exclusions
- An observation window long enough for the measure to mature
- Segments for channel, queue, reason, and period
- A conversation sample that explains the change
- A named owner, expected action, and next review date
How to apply this with Signaldesk without claiming more than the data proves
In Signaldesk, use queues, owners, history, states, and conversation context as the operating record. Consistent fields let a manager trace a number back to the conversations behind it. AI can suggest reasons, summarise history, and flag review candidates, but people should validate classifications and decisions that affect customers or staff.
Confirm which events, reports, and exports are available in your workspace before making a formula depend on them. If a calculation needs financial cost, cohorts, or an external rule, combine the operating record with the right source and document the reconciliation. The aim is traceability, not artificial precision.
A four-week pilot
In week one, freeze definitions and establish a baseline. In week two, inspect a conversation sample and correct events or states. In week three, choose one priority cause and test a small change. In week four, compare the same segment, record side effects, and decide whether to keep, adjust, or remove the change. Four weeks is not a promised outcome; it is a practical period for validating the method and the team’s ability to act.