Churn Diagnosis
Part of Customer experience problems that reduce retention
Linking unresolved complaints to later inactivity
A complaint that is marked “solved” in a ticket system may still feel unresolved to the customer.
A ticket marked “solved” does not establish that the customer received the promised remedy. Join complaint records to order history through a shared customer identifier, then compare later purchasing for unresolved and remedy-completed cases.
Define unresolved in operational terms
Record each case’s complaint date, issue type, final recorded action date and remedy status. Use the same customer identifier in the case and order records to link them; if there is no confident match, do not infer one. Zendesk tags can be added to tickets, users, organisations and chats, and a ticket can have multiple tags, so a tag alone is not a reliable customer join key.
Use case states such as awaiting customer, awaiting supplier, promised remedy, remedy completed and reopened. For the comparison, classify a case at its final recorded action: a promised remedy not completed, an outstanding supplier matter or a reopened case remains unresolved. Keep awaiting-customer cases distinct until the remedy outcome is known; a “solved” label alone does not prove that a remedy occurred.
Zendesk Explore can report on tags, but tag changes can take up to an hour to synchronise with Explore. Allow for that delay when checking reports against current case records.
Customer Journey from Complaint to Inactivity
- Complaint Date
- Recorded in Zendesk via customer identifier
- Final Recorded Action Date
- When case state is 'promised remedy', 'awaiting supplier', or 'reopened'
- Follow-Up Window (e.g., 90 days)
- Fixed period post-final action date to measure subsequent orders
- Inactivity Determination
- No order placed by end of follow-up window
Act on the case, not the segment label
Use the final recorded action date as the start of follow-up. Define later inactivity as no subsequent order by the end of a fixed follow-up window that suits the product’s purchase cycle, and apply the same window to unresolved and remedy-completed cases. Compare customers with equivalent follow-up time, grouped by complaint date or first-order date.
Measure repeat-purchase rate in each group: the share of customers with at least one subsequent order during the follow-up window. A lower rate among customers with unresolved cases is an association, not proof that the complaint caused inactivity; account for purchase cycle and whether the customer consented to contact.
Route linked unresolved cases to an owner with the order and promised remedy visible. Confirm the remedy was delivered before closing the case, and avoid sending a promotional win-back message while a complaint is active.
Review resolution time alongside later customer behaviour, and protect access to case details when joining support and marketing data.
Key Steps to Accurately Link Complaints to Inactivity
- Use a consistent customer identifier across support and order systemsEnsure match accuracy; avoid inferred links without confidence
- Classify cases based on final recorded action, not status labelsDo not treat 'solved' as proof of remedy delivery
- Route unresolved cases to owners with full contextInclude order history and promised remedy details
- Confirm remedy delivery before closing the caseAvoid sending win-back messages while complaint is active
