Returns and refund exception ownership board
Track the actual return and payment milestones, the customer's next promised update and the owner who has accepted each exception through to evidenced completion.
“Refund issued” can describe an internal action while the customer is still waiting for money. A return label, warehouse scan, approval and payment event each answer a different question. This board keeps those milestones and the customer's promise in one place.
Use it for exceptions that cross support, stores, warehouses, carriers or payments. It extends the ecommerce and retail operating guide and peak-season checklist into a daily case record. It does not set refund eligibility, legal deadlines, processor timings or compensation authority.
1. Map your actual states
Ask the relevant owners which system is authoritative for each milestone. Keep observations separate from assumptions. Do not mark a parcel received because a label exists, or money received because an initiation request was accepted.
| Milestone | Evidence your operation accepts | System / owner | Customer-facing wording approved |
|---|---|---|---|
| Return requested | [request and applicable policy] | [system / owner] | [what has been requested] |
| Label or instructions provided | [delivery record] | [system / owner] | [what the customer can do next] |
| Parcel received or exception identified | [scan / warehouse evidence / investigation] | [system / owner] | [what is known and uncertain] |
| Remedy approved | [decision and authority] | [system / owner] | [approved remedy / conditions] |
| Refund initiated | [payment request and actual response] | [system / owner] | [action initiated, not assumed receipt] |
| Payment outcome observed | [processor status / trace / permitted confirmation] | [system / owner] | [exactly what that evidence establishes] |
| Customer case complete | [agreed outcome evidence and remaining obligations checked] | [support owner] | [outcome / how to return if needed] |
A processor status may not show when the customer's bank displays funds. State that visibility limit. If confirmation cannot be observed, preserve uncertainty and a reachable next step rather than inventing completion.
2. Copy the exception board
Use approved internal references; keep payment details and customer documents in their controlled systems.
| Case / order / item reference | Actual milestone / evidence | Exception and impact | Customer-update owner | Dependency owner / accepted when | Next action / due | Next customer update |
|---|---|---|---|---|---|---|
| [IDs] | [state / timestamp / record] | [missing event / contradiction / urgency] | [name or duty role] | [owner / acceptance time] | [action / timestamp + zone] | [promise / timestamp + zone] |
Add the decision record when a remedy or exception needs authority:
| Case | Policy and version | Requested decision | Authorized decision owner | Decision / evidence | Completion check | Remaining obligation |
|---|---|---|---|---|---|---|
| [ID] | [approved reference] | [what is needed] | [name / role] | [approved / declined / pending] | [evidence / not observed] | [owner / next step] |
Sending a message to another team does not transfer customer-update ownership. Obtain acceptance and record who will keep the customer informed. Follow the escalation handling checklist when the next owner has not acknowledged the case.
3. Run the handover review
Review promises due before the next staffed handover, aged exceptions, contradictory states and cases waiting for authority. Sort by impact and elapsed waiting as well as count. A small board can still contain a customer with an urgent missing-money problem.
For each case, the incoming owner should answer: what do we know, what remains uncertain, who can act, when did they accept it, and when will the customer hear from us? If one answer is missing, create the next action before ending the handover.
Do not request sensitive evidence repeatedly or collect more than the approved process needs. A payment or identity concern goes to the qualified owner with access to the relevant records.
4. Fictional worked examples
The cases, timing and decisions below are invented. They illustrate recordkeeping, not merchant policy.
| Case | Observed state | Ownership and action | Customer update |
|---|---|---|---|
| R101: missing carrier scan | Label delivered; no received-parcel evidence | Support keeps updates; logistics accepts investigation and checks permitted evidence | “We have the return request. Receipt is not confirmed. We will update you tomorrow at 14:00 Lisbon time.” |
| R102: refund pending | Refund request accepted; processor still reports pending | Payments owner investigates the recorded status; support retains the next update | “The refund has been initiated and is still pending in our payment system. We have not confirmed receipt.” |
| R103: store/digital handoff | Store receipt exists; online case lacks the return match | Store operations accepts matching the receipt to the order; no second remedy is issued while the first is checked | “We have your store receipt and are checking the order match. You do not need to restart the return.” |
For R102, the promised update is a commitment support controls. It is not a promise that the bank will complete a refund by that time. If the investigation remains open, send the update with the current state and next owned action.
5. Complete and learn
Close the exception when the agreed evidence is present, obligations are accounted for and the customer has a usable outcome or next route. If an approved process closes a case with an unobservable bank milestone, record that limit explicitly and keep the trace and recontact path.
Group recurring failures by source: carrier events, warehouse matching, policy ambiguity, payment failure or store integration. Give the pattern an improvement owner rather than reopening the same investigation from scratch next week.
Sources and limits
Stripe's refund documentation illustrates why payment initiation, pending and failed states need different handling; it describes Stripe, not every processor. Consult your own provider and approved policy for the actual state model. This original board combines that distinction with the retail guide. No example authorizes a refund, promises a settlement time or determines a customer's legal rights.
Continue exploring