Returns and complaints
Ecommerce returns and complaints: a workflow that keeps the full context
How to design returns and complaint support: intent, order data, store policy, ownership, AI, and safe actions.
Faboxi product team · 8 min read ·
Short answer
A good return or complaint workflow separates the customer's request from confirmed operational state, collects required data once, assigns ownership, and shows the next step. AI can summarise and draft communication, but acceptance, refund, or order changes must follow policy, permissions, and commerce-system confirmation.
Returns and complaints are different processes
A customer may want to withdraw, report a defect, flag a wrong item, or ask about an existing case. Misclassification causes the team to collect the wrong data and send irrelevant instructions.
Context that belongs in one case
- Current intent and affected item.
- Reliable order and line-item binding.
- Previous messages, photos, and attachments.
- Store policy and human-decision exceptions.
- Active return, complaint, or refund status when supported.
- Owner, next response time, and decision history.
AI should organise, not adjudicate
AI can classify the current request, summarise the issue, identify missing information, and draft policy-aligned communication. It should not approve a complaint or claim a refund completed without confirmed operational evidence.
Quality metrics
- Time to the first complete instruction.
- Repeated requests for already-provided data.
- Return-versus-complaint reclassification rate.
- Time waiting for an internal decision.
- Repeat contact caused by an unclear next step.
Decision tools
Triage: return, complaint, or case status?
Identify the latest message goal first. The word ‘return’ does not always mean a new withdrawal request.
| Intent | Minimum data | Next step |
|---|---|---|
| New return / withdrawal | Order, item, delivery date, policy exceptions | Give the correct procedure without adjudicating an uncertain case. |
| Defect complaint | Product, problem description, evidence already supplied | Do not request existing data again; route for assessment. |
| Wrong or missing item | Ordered versus received line item | Identify fulfilment error and correction owner. |
| Existing case status | Return/complaint/refund identifier | Query the correct surface; do not treat it as an order number. |
A state model for customer and operator
Every state needs an owner, evidence, and next step. ‘In progress’ without these is not useful.
| State | Operational evidence | Message |
|---|---|---|
| Request received | The message exists; a case may not yet | Confirm receipt, not acceptance. |
| Waiting for data | A specific list of missing facts | Request only what is actually missing. |
| Under review | Assigned owner and next update deadline | Explain what happens next and when. |
| Refund completed | Confirmed commerce/payment result | Only then state completion and expected settlement timing. |
Common questions
Can AI decide to accept a complaint?
Not in the default safe workflow. It can organise facts and draft communication, while the decision remains in the store's authorised process.
Does an empty result prove there was never a return?
Not always. Some integrations expose only active cases. No active return does not prove there is no historical return.
Sources and methodology
- Your Europe: returns and withdrawal rights
Official EU information on the 14-day withdrawal right and exceptions; store policy still needs legal review.