Analyze repeat contacts as linked attempts to complete the same customer task, not simply multiple interactions from one account. Separate unresolved work from expected follow-up, duplicate records, and unrelated new requests before interpreting a repeat-contact rate.
Level AI describes customer-interaction insights. Amazon Connect documents contact categorization. Neither description establishes that all cross-channel contacts can be linked reliably to the same customer task; that matching needs explicit validation.
What is a customer-task episode?
A customer-task episode is a proposed grouping of interactions concerning one unresolved goal. An order-status question followed by a request to change a different order should not automatically count as failed resolution. Conversely, a caller returning through chat may still be pursuing the original task.
Choose identifiers appropriate to the operation, such as a case or order reference, and record the limitations of identity matching. Do not infer a person solely from a shared phone number or merge different tasks because their transcripts contain similar words. Mark ambiguous links rather than pretending every relationship is certain.
Which return reasons should reviewers distinguish?
| Return reason | Evidence to inspect |
|---|---|
| Unresolved initial issue | Same goal remains incomplete |
| Promised update missing | Prior commitment and actual update record |
| Expected next step | Workflow deliberately requires a later interaction |
| Different new request | Goal or relevant record has changed |
| Duplicate or uncertain link | Insufficient evidence of another genuine attempt |
Use the first interaction's record and the returning customer's explanation together. A disposition saying “resolved” can conflict with a later account of unfinished work. Investigate the discrepancy rather than declaring either record universally correct.
How should the follow-up window be chosen?
Choose an observation window that fits the task's expected completion and communication cycle. Show its definition beside the rate. Very recent initial contacts have not had the same opportunity to produce a repeat, so compare cohorts that have completed the agreed window.
- Fix the initial-contact cohort and eligible task definition.
- Link subsequent interactions using reviewed matching rules.
- Separate automatic notifications from customer-initiated attempts.
- Review likely repeats and a sample of apparent non-repeats.
- Report uncertain links, incomplete observation, and missing channels.
What should change after the investigation?
Group confirmed repeats by a controllable cause, such as unclear next steps, failed follow-up, missing information, or a difficult system action. Give the receiving team concrete examples and a bounded proposal. Avoid attributing every return to an individual agent when the record points to a process dependency.
After a change, compare the same task cohort and completed follow-up window. Pair repeat-contact reduction with correct resolution so deflecting or discouraging returns cannot masquerade as improvement. Use the action register to assign follow-up and effort analysis to inspect the work left for customers.
How should one episode be classified when several contacts occur?
Set an episode rule before counting repeats. For this illustrative method, match contacts to a customer and task identifier within a predeclared seven-day follow-up window; seven days is an example, not an industry standard. Classify the return reason using records and customer context.
| Illustrative return | Episode label | What to investigate |
|---|---|---|
| Customer asks again because a promised update never arrived | Potential unresolved work | Promise, due event, delivery record and responsible owner |
| Customer provides an attachment requested in the first contact | Planned follow-up | Whether the attachment request was clear and necessary |
| Same person contacts support about a different order | Separate task | Whether identifiers genuinely separate the requests |
| Anonymous chat resembles an earlier call | Uncertain link | Preserve uncertainty; do not infer identity from wording alone |
Report repeat-task contacts divided by episodes whose observation window has closed. Show immature episodes and uncertain links separately. Counting yesterday's episodes alongside last month's complete windows can create a false improvement because recent customers have not yet had time to return. Compare the same completed windows after a workflow change and inspect representative returns before attributing the result.
Limits
This is an analysis design, not a vendor repeat-detection capability claim or a universal first-contact-resolution formula. Identity, task matching, missing channels, and delayed outcomes can limit conclusions. State unresolved links and do not infer causation from contact counts alone.