# Post-Purchase Issue Resolution

Page: https://alidemirbas.com.tr/en/lab/journeys/post-completion-issue

Issue reported → route by issue type → resolve → follow up or escalate

## Purpose

Route a post-purchase issue to the right resolution path without making the customer repeat the same explanation.

Goal: Compensation & Remedy · Category: Transactions, Delivery & Support

## Steps

- **Trigger**: Customer reports a problem after delivery / purchase
- **Decision**: What type of problem is it?
  - Damaged / wrong item: Route to the exchange / refund team
  - Not working / usage issue: Route to product support / troubleshooting
  - Incomplete delivery: Route to missing-item delivery resolution
- **Action**: Route to the exchange / refund team
- **Action**: Route to product support / troubleshooting
- **Action**: Route to missing-item delivery resolution
- **Wait**: Wait for the selected resolution SLA
- **Decision**: Was the issue resolved?
  - Yes: Email: Follow up on the resolution and close the case
  - No: Escalate to a person / specialist
- **Action**: Email: Follow up on the resolution and close the case
- **Action**: Escalate to a person / specialist
- **Exit**: Journey ends

## Guardrails

- Route damaged, technical and missing-delivery issues differently.
- Escalate when the selected resolution misses its SLA.

## Core rule

Classify the issue first; do not delay obvious resolution paths with a generic holding sequence.

## When to set it up

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.

## How to set it up

- **Trigger and entry**: A 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 enter**: Failed 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 channels**: With 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 handoff**: A 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 consent**: The 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.

## How to measure success

**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. 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 path**: Cases 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 time**: Track 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 complaints**: Customers 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 share**: Tasks 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.

## What to watch when reading the result

- Read 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.
- If 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.
- To 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](https://alidemirbas.com.tr/en/calculators/ab-test); repeat contact is a rare outcome, so if the gap is not significant, wait for more cases to accumulate.
- Escalate 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.

## Frequently Asked Questions

### Which team should receive a post-purchase issue?

Route by issue type to a team able to resolve it. This example separates exchanges or returns, product support and missing deliveries. Transfer the history so the customer does not have to explain everything again.

### Does transferring an issue to support mean it is resolved?

No. Handoff is a step toward ownership. This flow waits for the chosen service window and checks actual resolution. Do not count transfers as solved cases. Track response and resolution times separately.

### Should an unresolved case close when its promised time expires?

No. This example escalates to human support or specialists. The end of automation does not resolve the customer's issue. Confirm the remedy before explaining closure to the customer.