Skip to content

E-commerce and retail blueprint

E-commerce returns and refunds

A return request read, matched to its order, checked against the policy, approved or escalated, with the label issued and the refund released when the parcel is scanned.

At a glance

The job

Return requests sit in the inbox for three days and then arrive as a chargeback

Systems

Store platform · Shared inbox · Carrier account · Payment processor · Help desk

Steps

8, of which 1 stay with a person

Build time

2 to 4 weeks

Free to use, adapt and build from. No email needed and no attribution asked for.

How it works now

  • Return requests arrive by email, through the contact form, and as replies to the shipping confirmation. Nobody is sure which inbox has the current list.
  • Whoever picks one up searches the store admin for the order, usually by name, which fails whenever the customer emails from a different address than the one they ordered with.
  • Policy is applied from memory, so two customers with the same situation get different answers depending on who read the email.
  • A slow reply turns into a card dispute. The bank takes the money back, adds a fee, and the parcel comes back anyway.

The workflow

Every step, in order, including where it forks and where a person stays.

  • Trigger
  • Automated
  • Decision
  • Person
  • Done
  1. TriggerStep 1 of 8Within a minute

    A return request arrives

    From the returns form, an email to the support address, or a reply to the shipping confirmation. All three land in one queue, so there is one process rather than three.

  2. AutomatedStep 2 of 8Seconds

    Find the order

    Matched on order number first, then email, then name plus postcode. What it will not do is guess: an unmatched request goes to a person with everything it tried already written down.

  3. DecisionStep 3 of 8

    Does the policy cover it?

    Days since delivery, whether the item is in a returnable category, and whether this order has been refunded already. Your policy, written down as rules, applied the same way every time.

    • Inside the window, ordinary itemApproved automatically and a label issued.
    • Outside the window, or a marked categoryGoes to a person with the policy line and the order history attached. The workflow does not say no on its own.
    • Already refundedStopped and flagged. This is the check that prevents paying for the same return twice.
  4. AutomatedStep 4 of 8Under two minutes from the request

    Issue the label and tell the customer

    A prepaid label from the carrier account, sent with what to do and when the money comes back. The same message, at the same speed, whoever the customer is and whenever they wrote.

  5. PersonStep 5 of 8

    A person decides the awkward ones

    Out of window, damaged on arrival, a high-value item, or a customer who is unhappy about something other than the product. These are judgement calls and a rule engine has no business making them.

  6. DecisionStep 6 of 8

    Has the parcel been scanned?

    The carrier's first scan, not the label being created. A label sitting unused for two weeks is a return that is not happening.

    • Scanned into the networkRefund released on the original payment method.
    • Nothing after ten daysOne reminder to the customer, then the request closes and the label is voided so it is not paid for.
  7. AutomatedStep 7 of 8

    Refund, restock, record

    The refund is issued, inventory is put back if the item is resaleable, and the reason the customer gave is written to the order so the pattern is visible later.

  8. DoneStep 8 of 8

    Closed, with the reason attached

    Every request ends refunded, declined by a person, or expired. The reasons accumulate into the only honest answer to why things come back.

What breaks

Every one of these has happened. A workflow that has not been designed against them is a demo rather than a system.

The customer writes from a different email than the order

They ordered as a guest at work and emailed from a personal address, or a partner placed the order.

The match falls through to name plus postcode, and if that is not conclusive it goes to a person rather than guessing. Refunding the wrong order is much worse than a slow reply.

The refund call succeeds but the reply times out

Payment APIs return slowly under load, and a retry on a timeout is how a customer gets paid twice.

Every refund carries an idempotency key derived from the order and line items, so a retry is the same request rather than a second one. Then the processor is read back before the record is written.

A carrier scan arrives before the parcel physically moves

Some drop-off points scan on acceptance and then hold parcels for a collection that is a day or two out.

Refund on first scan is a policy choice, not a technical one. Where a store would rather wait for arrival, the trigger moves to the delivered scan and the customer is told which rule applies.

A burst after a sale hits the store platform's rate limit

Every platform has one, and a returns wave after a promotion is exactly when it is found.

Requests queue and retry with backoff rather than failing. Nothing is dropped, the queue depth is visible, and a queue that is not draining raises an alert.

Rules that bear on this

The FTC Mail, Internet, or Telephone Order Merchandise Rule, United States

Federal rules govern how quickly a seller must ship or, where they cannot, offer the buyer the choice of a refund, and they require that refunds be prompt when one is due. State law adds its own requirements on disclosing a returns policy before purchase.

What the workflow does. The workflow timestamps every request and every refund, so the record of what was promised and when it was paid exists without anybody keeping it. Timers are set to your stated policy rather than to a default. This describes what the workflow does; it is not legal advice, and your policy should be reviewed by a lawyer in the states you sell into.

What changes

Time to first reply

Minutes rather than days

Mechanical. The reply is sent when the request arrives rather than when somebody next opens the inbox.

Same situation, same answer

Every time

Because the policy is rules rather than recollection. This is the part customers notice and staff stop arguing about.

Hours on return admin

Most of them

Ordinary returns stop reaching a person at all. What it is worth depends on your volume, and the ROI calculator will do that arithmetic with your numbers.

Before it is worth building

  • A returns policy written down. If it only exists as what the team usually does, that is the first job, and it is worth doing whether or not anything is automated.
  • A store platform with an API that can read orders and issue refunds.
  • A carrier account that can generate labels programmatically.

How it changes by business

Made to order or personalised goods
The policy branch does more work, and far more requests reach a person. That is correct: a bespoke item is a conversation, not a rule.
Selling on marketplaces as well as your own store
Each marketplace has its own returns rules and its own clock. They become separate rule sets feeding the same queue, never one averaged policy.
High-value items
Automatic approval comes off entirely above a threshold you set. The workflow still does the finding, matching and label, and a person still presses approve.

Want us to build this one?

Three weeks or so, then a flat monthly fee to run it. Or take the specification above and build it yourself, which is genuinely fine and is why it is up here.

Start with the auditor email contact@zhorx.com