Post-Purchase Issue Resolution

Post-delivery support records that show the same problem being explained again to a second team, damaged and non-working items landing in one queue, and resolution times swinging by issue type call for this journey. You will need the issue report tied to a completed purchase or delivery, a classifiable issue type, a team and SLA of its own for each resolution path, and resolution status written back to the case. If most reports are one type, say damaged items, routing only speeds up the remedy; look at the source of that damage first.

Verified resolution rate within SLA

Because the only customer message is the post-resolution email, the routing has no control group; the outcome is read against every case that entered the journey, and a transfer to a team does not count as a resolution.

How it is counted: Among all issue cases that enter the journey, the share verified as resolved when the selected path's SLA runs out; an escalated case counts as unresolved, and neither a transfer nor an opened closing email changes the count. Compute the rate separately for the damaged / wrong item, not working and incomplete delivery paths.

Also track

• Escalation share by pathCases on each path that miss their SLA and escalate to a person or specialist, as a share of that path's entries; a rise on one path points at that team's capacity or its SLA definition.
• Response and resolution timeTrack how long a team takes to pick up the task and how long the actual resolution takes, by path; a fast transfer with a slow resolution means the team, not the routing, is the bottleneck.
• Repeat contacts and complaintsCustomers who open a new support contact or complain about the same issue after the closing email, as a share of all closed cases; compare it with the group you withheld the closing email from.
• Misrouted shareTasks moved from the team they opened in to another team, as a share of all tasks; a rise means the issue type classification at report time does not separate well enough.

• Trigger and entryA problem reported against a completed purchase or delivery starts the journey; only cases whose type can be classified enter. Routing is a service, so there is no control group: every reported issue is routed. If you want a holdout, withhold only the post-resolution closing email from a random group.
• Who must not enterFailed delivery attempts, where nothing arrived, belong to Failed Delivery Recovery. General feedback about an experience with no concrete problem is Feedback Follow-Up's territory. While a case is open on an order no second flow opens; one issue is the scope, and the customer does not explain the same problem twice.
• Timing and channelsWith no wait, a task opens by issue type: a damaged or wrong item goes to the exchange / refund team, a non-working or usage issue to product support, an incomplete delivery to missing-item resolution. The selected path's SLA runs, resolution is checked, and if resolved an email follows up and closes the case.
• Exit and handoffA case leaves through its own exit, either after the closing email or after escalation to a person or specialist when the SLA is missed; no other journey takes it over. Escalation is not closure: never auto-close an unresolved case, and explain closure to the customer only once the remedy is confirmed.
• Frequency and consentThe customer receives one email at most, after the issue is resolved, at the address on the case. Teams receive a task with the issue type, the customer's earlier description and the case history; the path changes with the issue type, and there is no generic holding sequence.

1. 1Read the resolution rate against the entry population: if teams pick up tasks fast but verified resolutions at SLA end do not rise, the routing worked and the remedy did not. Do not count transfers, opened tasks or opens of the closing email as success.
2. 2If the three-path split or a path's SLA changes, start the measurement again; the result belongs to this structure. An escalated case's outcome is credited to the person or team that took it; an undelivered shipment belongs to Failed Delivery Recovery and feedback without a concrete problem to Feedback Follow-Up, so keep both out of the resolution rate.
3. 3To read the closing email's effect, enter the case and repeat-contact counts of the emailed and non-emailed groups into the A/B test significance calculator; repeat contact is a rare outcome, so if the gap is not significant, wait for more cases to accumulate.
4. 4Escalate a case that misses its SLA instead of closing it; the end of automation does not end the customer's problem. Merging damaged, technical and incomplete-delivery issues into one resolution rate hides one path's delay behind the others.