Should every exception require manual review?
No. Known recoverable cases can retry or resolve automatically within clear limits. Manual review is appropriate when money, customer choice, uncertain state, or policy judgement is involved.
Websites & Commerce
Designing an Exception Workflow for E-commerce Orders
Structure the queues, statuses, ownership, and customer communication needed when an order cannot follow the normal fulfilment path.
How the workflow connects
- 1Detect a mismatch or blocked transition
- 2Classify the exception
- 3Assign an owner and response target
- 4Resolve or choose an approved alternative
- 5Update the customer and source systems
Most store diagrams end at a successful payment and shipment. Real operations also contain inventory mismatches, payment reviews, invalid addresses, split fulfilment, partial refunds, and carrier failures. An exception workflow keeps those cases visible and assigns a next action before they become support tickets.
List the failures that change fulfilment
Begin with events that stop or alter the order: payment authorization needs review, inventory is unavailable, the address cannot be validated, one item must ship separately, or the carrier rejects a label. Record where each condition originates and whether it can clear automatically.
Avoid one catch-all exception status. A warehouse shortage and an uncertain payment require different access, information, and resolution choices.
Build a queue around decisions
Each queue item should state what happened, which system reported it, what has already been attempted, who owns the next action, and which actions are allowed. The operator may substitute stock, request a corrected address, cancel one line, retry a label, or escalate a payment review.
- Reason and source event
- Affected order lines and amounts
- Customer-contact status
- Allowed resolutions
- Owner and response deadline
Protect against conflicting updates
A delayed warehouse update can arrive after an operator changes the order. Keep version or timestamp information and reject transitions that no longer apply. Resolution actions should be idempotent so a retry does not issue a second refund or create another shipment.
Store the source response beside the normalized status. That record makes reconciliation possible when an external system uses different terminology or later changes its result.
Close the loop with customer communication
Messages should be triggered by confirmed decisions, not by every internal warning. Define which events require immediate notice, which require operator review, and which can remain internal. The support view should show what the customer was told so the next conversation starts from the same record.
Follow one order with conflicting payment and inventory facts
A customer places an order for the last available item. The payment provider authorizes the charge, but the inventory system reports that another channel reserved the unit moments earlier. The order should not jump directly to failed or fulfilled. It enters an inventory review state while preserving the payment authorization deadline and the customer's selected alternative or cancellation preference.
A staff member may release another reservation, substitute an approved variant with the customer's agreement, or cancel before capture. The workflow records the decision and then sends the appropriate command to payment and fulfilment. Customer communication is based on the confirmed outcome, not on the first system response that arrived.
Visual guide
Normal order flow with a controlled exception branch
The order record coordinates several systems while a review queue owns decisions that cannot be made safely by rule.
- 1
Order received
Create a stable order and retain the customer's requested items and terms.
- 2
Payment checked
Record authorization, decline, timeout, or review without assuming capture.
- 3
Inventory reserved
Confirm the stock fact from its authoritative system.
- 4
Exception review
Assign conflicts with decision options and deadlines.
- 5
Outcome applied
Update fulfilment, payment, and customer communication once.
Define recovery without creating a second order
Payment and fulfilment APIs can time out after accepting a request. Store an idempotency key for each intended action and query the provider before repeating an uncertain command. A customer refreshing the confirmation page must not create another order, and a repeated webhook must not trigger another shipment or email.
Give staff safe actions that reflect the current state: retry a temporary sync, correct an address before dispatch, request customer confirmation, release a reservation, cancel an uncaptured authorization, or escalate a fraud review. Record who acted, which facts they saw, and which external operations were confirmed afterward.
| Exception | Owner | Safe next action | Confirmation |
|---|---|---|---|
| Payment result unknown | Payments queue | Query by idempotency key | Provider transaction state |
| Stock conflict | Inventory team | Review reservation or alternative | Inventory reservation |
| Invalid address | Customer service | Request correction before dispatch | Validated delivery address |
| Fulfilment timeout | Operations | Check shipment before retry | Warehouse or carrier record |
Practical questions
Questions that often come up
Where should the exception queue live?
It can live in the commerce platform, an operations dashboard, or a connected fulfilment system. The important part is one authoritative owner and a complete event history.
Continue exploring
Related projects and tutorials
Work with Sun Cluster
Planning a similar system for your organization?
Sun Cluster develops commerce experiences and the operational integrations needed to manage orders beyond checkout.