Returns and Exchange Workflow

Most retailers treat a return as an accounting event. A customer emails or calls, somebody finds the order, a refund goes out, and the transaction is closed. Nothing is recorded about why the item came back, nobody offers an alternative, and the customer who was two minutes from buying the correct size instead receives their money and leaves. The sale is gone, the restocking cost is absorbed, and the reason the product failed the customer is never written down anywhere a buyer or a merchandiser can read it.

The money leaks in four places at once. First, in the refund that should have been an exchange: a wrong size, a wrong color, or a product that was simply not what the photo suggested is an exchange opportunity, but only if somebody offers the alternative in the first reply. Second, in handling time: when returns arrive by email and phone, the queue is invisible, requests sit for days, and the customer chases. Third, in fraud and policy drift: with no structured window check, staff approve returns outside the policy because it is easier than arguing. Fourth, in missing reason data: if nobody tags why items come back, the same product keeps generating returns forever.

The fix is not a stricter policy. It is a defined intake form, a visible pipeline, a save-the-sale offer that fires before the refund path opens, a label and tracking step the customer completes themselves, and an inspection gate that releases the refund or dispatches the exchange. Every request leaves behind a reason code and a resolution type, so returns stop being a pure cost and become a feedback loop and a second chance at the order.

Pipeline and stages

One pipeline, Returns and Exchanges, with every request as an opportunity card named with the order number and the customer surname.

• Request Received - form submitted, nothing checked yet.
• Eligibility Check - order located, return window and condition assessed.
• Save Offer Sent - exchange, replacement or store credit offered; awaiting the customer.
• Exchange Approved - customer chose a swap; replacement item reserved.
• Return Authorized - RMA issued and label sent; goods not yet in transit.
• In Transit - tracking shows movement toward the warehouse.
• Received and Inspecting - goods booked in, condition being confirmed.
• Resolved - Exchanged, Resolved - Credit, Resolved - Refunded - three closed-won variants so the reporting separates saved revenue from refunded revenue.
• Declined and Abandoned - closed-lost variants for out-of-policy requests and requests the customer never shipped.

Calendars

• Returns Desk Callback - 15-minute slots for disputed or high-value requests, used when BO escalates.
• In-Store Dropoff - 10-minute slots per location for customers returning in person, so the counter is staffed and the item is logged on arrival.
• Courier Collection Window - half-day blocks offered for bulky items that need a booked pickup.

Custom fields

Create these on the contact or opportunity record so every automation can branch on them.

• Order Number, Order Date, Order Value, Fulfillment Channel (online, in-store, marketplace)
• Return Window Days and Days Since Delivery - the second calculated from the delivery date, used by the eligibility branch
• Return Reason Code - wrong size, wrong item sent, not as described, damaged on arrival, faulty in use, changed mind, late delivery, duplicate order
• Item SKU, Item Description, Quantity Returning, Condition Declared (unopened, opened unused, used, damaged)
• Preferred Resolution - exchange, store credit, refund, repair
• RMA Number, Return Label Sent, Return Tracking Number, Carrier
• Condition On Inspection, Inspection Notes, Restockable
• Resolution Type, Refund Amount Authorized, Credit Code Issued, Exchange Order Number
• Save Offer Accepted - the single field the save-rate report is built on
• Lifetime Returns Count - incremented on every closed request, used to flag repeat high-volume returners for manual review

Tags

• return-requested, return-in-policy, return-out-of-policy
• save-offer-sent, save-offer-accepted, save-offer-declined
• exchange-path, credit-path, refund-path, warranty-path
• reason-wrong-size, reason-damaged, reason-not-as-described, reason-changed-mind, reason-faulty - one per reason code, so segments and reports need no filters
• label-sent, goods-received, inspection-failed
• repeat-returner, manual-review, vip-customer

Forms and surveys

• Start a Return - the public intake form: order number, email, item picker, quantity, reason code (required), condition declared, free-text detail, photo upload for damage and fault claims, and preferred resolution. The reason question drives the whole build, so it is a required single-select and never free text.
• Exchange Selection - a short form sent after the save offer: the replacement size, color or variant, plus the delivery address to confirm.
• Inspection Checklist - internal form for the warehouse: condition on arrival, all accessories present, restockable yes or no, notes, photo.
• Post-Resolution Survey - two questions sent after close: ease of the return on a one-to-five scale, and whether the customer would buy again.

BO's role and guardrails

• BO answers the returns chat widget and the returns inbox, locates the order by number or email, states the policy window in plain language, and walks the customer into the intake form.
• BO presents the save offer and records the answer, collects the exchange variant, and sends tracking and status updates on request.
• BO may not authorize a refund, approve an out-of-policy return, waive return shipping, issue a credit code, or confirm a fault as covered under warranty. Each of those routes to a human and moves the card to Manual Review.
• BO never argues. Two customer messages expressing dissatisfaction, or any mention of a chargeback, a legal complaint or a regulator, hands over immediately and tags manual-review.
• BO quotes no amounts. Refund values come from the order record and are stated by staff or by the payment gateway receipt, never estimated in conversation.

Numbers and channels

• A dedicated returns sending number for SMS status updates, separate from the marketing number so transactional messages are never caught by a marketing opt-out.
• The returns email address routed into the platform inbox so email, SMS and chat threads sit on one contact timeline.
• Web chat on the returns policy page, the order confirmation page and the help center.
• Payment gateway connection (for example Stripe) for refunds and for charging any price difference on an exchange.
• Shipping or label provider connection for RMA labels and return tracking, and the store platform (for example Shopify) for order lookup and exchange order creation.

1. A customer who ordered a jacket in the wrong size opens the returns page and starts a chat. BO asks for the order number, finds the order, and confirms the delivery date and the days remaining in the return window.
2. BO sends the Start a Return link. The customer selects the jacket, picks the reason wrong size, declares the condition as unopened, and chooses refund as the preferred resolution.
3. On submission the platform creates the contact if new, writes every field, tags return-requested and reason-wrong-size, and creates a card at Request Received.
4. The eligibility workflow compares Days Since Delivery against Return Window Days. It is inside the window, so the card is tagged return-in-policy and moves to Eligibility Check, then straight through to the save offer because the reason is a swappable one.
5. Within two minutes the customer gets the save offer: the correct size in stock, shipped free, no need to wait for a refund to clear. The message offers store credit as a second option and a plain refund as the third.
6. The customer taps the exchange link and completes Exchange Selection, choosing a large. Save Offer Accepted is set to yes, the card moves to Exchange Approved, and the tag exchange-path is applied.
7. The RMA workflow generates the RMA number, requests a prepaid label from the carrier integration, emails and texts the label, and moves the card to Return Authorized. The replacement is reserved against the exchange order.
8. The customer drops the parcel off. Tracking updates arrive, the card moves to In Transit, and a reminder sequence that would have chased an unsent parcel exits on the first scan.
9. Goods arrive. The warehouse completes Inspection Checklist: unopened, all tags on, restockable yes. The card moves to Received and Inspecting, then clears inspection and tags goods-received.
10. The exchange order is released to fulfillment. The customer gets a dispatch note with the new tracking number, and the card moves to Resolved - Exchanged.
11. Three days later the Post-Resolution Survey goes out. A four or five triggers a review request on the store's chosen review platform; a one or two creates a task for the returns lead instead.
12. Fourteen days later a size-confidence email goes to everyone tagged reason-wrong-size for that product line, pointing at the fit guide. In parallel the weekly reason report shows the SKU's wrong-size rate to whoever buys it.
13. Had the same customer declared a faulty item instead, step 5 would have branched to the warranty path: photos requested, card routed to Manual Review, a human assessing before any label is issued.
14. Had the request arrived outside the window, the card would have been tagged return-out-of-policy and held at Eligibility Check for a human decision, with a goodwill-credit option the manager can release but BO cannot.

1. Return Intake and Eligibility Check

Trigger: Start a Return form submitted.

• Create or update the contact by email. Write every form answer to its custom field. Tag return-requested and the matching reason- tag.
• Create an opportunity in Returns and Exchanges at Request Received, named with the order number and surname.
• Calculate Days Since Delivery from the delivery date. Move to Eligibility Check.
• Branch A - inside window and condition declared unopened or opened unused: tag return-in-policy, continue to workflow 2.
• Branch B - reason is damaged on arrival, faulty in use or wrong item sent: tag warranty-path and hand to workflow 7 regardless of window.
• Branch C - outside window: tag return-out-of-policy, hold at Eligibility Check, assign a task to the returns owner due in 4 hours, and send: "Thanks for getting in touch about order {{order number}}. Your delivery date falls outside our standard return window, so a member of the team is reviewing it personally and will come back to you today."
• Branch D - Lifetime Returns Count above the agreed threshold: tag repeat-returner and manual-review, hold for a human.
• Acknowledge on every branch within 2 minutes by email and SMS: "We have your return request for order {{order number}}. Reference {{opportunity id}}. We will confirm the next step shortly."
• Exit: card leaves Eligibility Check, or the contact is tagged manual-review.

2. Save the Sale Offer

Trigger: tag return-in-policy added.

• Condition: run only where Return Reason Code is wrong size, wrong color, changed mind or not as described. Faults skip to workflow 7.
• Wait 2 minutes, then check live stock for the same SKU in an alternate variant.
• Branch A - alternate variant in stock. Move to Save Offer Sent, tag save-offer-sent, and send SMS plus email: "Before we process a refund - we have the {{item description}} available in another size and we will ship the swap free and send you a prepaid label for the one you have. Want to pick your replacement? {{exchange selection link}} Prefer store credit or a straight refund? Reply EXCHANGE, CREDIT or REFUND."
• Branch B - out of stock. Offer credit first: "We are out of stock in the size you need. We can issue store credit today, valid on anything in the range, or refund you to the original payment method. Reply CREDIT or REFUND."
• Wait 24 hours. If nothing accepted, send one follow-up: "Just checking on order {{order number}} - would you like the swap, store credit, or a refund? Reply with one word and we will set it up."
• Wait a further 48 hours. If still silent, treat silence as a refund request, tag save-offer-declined and refund-path, and continue to workflow 3 on the refund branch. Never let a request sit unresolved because the customer did not answer a sales question.
• On EXCHANGE or form completion: set Save Offer Accepted to yes, tag save-offer-accepted and exchange-path, move to Exchange Approved.
• On CREDIT: tag credit-path, assign the credit-issue task to a human, who holds the code authority.
• Exit: any of the three resolution tags applied, the contact tagged manual-review, or the card reaching a Resolved stage.

3. RMA Issue and Label Despatch

Trigger: card enters Exchange Approved, or tag refund-path or credit-path applied.

• Generate the RMA Number and write it to the record.
• Call the carrier integration for a prepaid return label. On an API error, retry once after 10 minutes, then assign a task to the returns owner and notify the internal channel. Never leave the customer waiting on a silent failure.
• Set Return Label Sent to the current date, tag label-sent, move to Return Authorized.
• Email with the label attached: "Your return is authorized. RMA {{rma number}}. Print the label, attach it to the parcel with the item in its original packaging, and drop it at any {{carrier}} point. Keep the receipt. Once it scans we will track it for you."
• SMS 5 minutes later: "Return label for order {{order number}} is in your inbox. RMA {{rma number}}. Reply HELP if it did not arrive."
• On the exchange branch, reserve the replacement variant against an exchange order and write Exchange Order Number. Do not despatch yet.
• Exit: first carrier tracking scan, or the card reaching Abandoned.

4. Unshipped Parcel Chase

Trigger: tag label-sent added.

• Condition: no carrier scan recorded against Return Tracking Number.
• Wait 3 days. SMS: "Quick nudge on order {{order number}} - we have not seen your parcel scan yet. Label and instructions are in your email under RMA {{rma number}}. Need a new label or a collection booked instead? Reply LABEL or COLLECT."
• Wait 4 days. Email: "Your return window on RMA {{rma number}} stays open for {{n}} more days. If something is in the way - packaging, a printer, getting to a drop-off point - reply and we will sort it."
• Wait 7 days. Final notice: "This is the last reminder on RMA {{rma number}}. If the parcel is not with us in 7 days we will close the request. Reply and we will reopen it any time."
• Wait 7 days. Move the card to Abandoned, release the reserved exchange stock, and notify the returns owner.
• Exit immediately on any carrier scan (move to In Transit), on a reply to the thread, or on tag goods-received.

5. Goods Received and Inspection Gate

Trigger: carrier status delivered-to-warehouse, or Inspection Checklist submitted.

• Move the card to Received and Inspecting. Notify the customer once: "Good news - your return for order {{order number}} has reached us. We check items within one working day and will confirm the next step as soon as it clears."
• Assign the inspection task to the warehouse queue, due in 1 working day. If the checklist is not submitted in 2 working days, escalate to the operations lead.
• Branch A - condition on inspection matches the declaration. Tag goods-received. On exchange-path, release the exchange order to fulfillment. On refund-path, continue to workflow 6. On credit-path, assign the credit-issue task.
• Branch B - condition worse than declared, or accessories missing. Tag inspection-failed, hold the card, assign a human task, and send: "We have inspected the item from order {{order number}} and the condition differs from what was recorded on the request. A member of the team will contact you today to agree the next step." No automated partial refund, ever.
• Branch C - wrong item received back. Hold, tag manual-review, notify operations, send nothing automated.
• Exit: card reaches a Resolved stage or is tagged manual-review.

6. Refund Release and Confirmation

Trigger: tag goods-received present and tag refund-path present.

• Condition: inspection passed and Refund Amount Authorized is populated by a human. The automation never writes that figure itself.
• Create the refund task in the payment gateway queue for the authorized amount. Wait for the gateway confirmation event rather than assuming success.
• On confirmation, move to Resolved - Refunded, increment Lifetime Returns Count, and send: "Your refund for order {{order number}} has been issued to the original payment method. Your bank usually shows it within a few working days. Your receipt is attached."
• If no gateway confirmation within 24 hours, notify finance and assign a task. Never send a refund-issued message that the gateway has not confirmed.
• Exit: refund confirmed, or the card moves to Manual Review.

7. Damage, Fault and Warranty Triage

Trigger: tag warranty-path added.

• Move the card to Eligibility Check and tag manual-review. BO stops answering substantively from here.
• If no photo was uploaded, request one immediately: "Sorry to hear the {{item description}} arrived damaged. Could you send two photos - one of the item and one of the outer packaging? Reply to this message with them attached and we will fast-track it."
• Wait 24 hours. One reminder if no photo. Wait 48 hours more, then assign to a human to call.
• On photo received, notify the quality channel, assign assessment to the named product owner due in 1 working day, and offer a Returns Desk Callback booking link.
• Human sets the outcome: replacement, repair, refund or declined. That decision applies the matching path tag and re-enters workflow 3 or 6.
• Independently, for a reason of damaged on arrival, add the SKU and carrier to the weekly packaging-failure report.
• Exit: outcome recorded by a human.

8. Post-Resolution Survey, Review and Reason Feedback

Trigger: card enters any Resolved stage.

• Wait 3 days. Send Post-Resolution Survey: "How easy was it to return your order, one to five? One tap is all we need - and it genuinely shapes how we run this."
• Branch A - score 4 or 5. Wait 1 hour, then request a review on the store's review platform: "Thank you. If you have a moment, a short review would help other shoppers know what to expect when something needs to go back. {{review link}}"
• Branch B - score 1 to 3. No review request. Create a task for the returns lead due in 1 working day, and send: "Thank you for the honest answer. Someone from the team will read your feedback and come back to you."
• Wait 14 days from resolution. For contacts tagged reason-wrong-size, send one targeted email with the fit guide for that range and a single-use incentive the client defines. For reason-not-as-described, send nothing and instead add the SKU to the product-content review list.
• On a 60-day schedule, report return rate and reason mix by SKU to the buying channel.
• Exit: survey answered and the branch completed, or the contact unsubscribes from marketing - which stops the 14-day email but never the survey.

Returns stop being invisible. Every request is a card on one board with an owner, an age and a stage. Nobody searches an inbox to find out what is outstanding, and the oldest unresolved request is on screen rather than in somebody's memory.

A real share of refunds become exchanges or credit. The save offer fires before the refund path is even visible, within minutes of the request, with the correct variant and its stock position already checked. Customers who would have taken a refund by default take a swap because it is the easier option in front of them.

The reason data becomes an asset. Because the reason code is a required single-select, the business can finally answer which SKUs, which suppliers and which product descriptions generate returns. That feeds the fit guides, the photography brief and the buying decisions.

Policy is applied consistently. The window check is arithmetic, not judgment. Out-of-policy requests still reach a human, but as a deliberate exception with a goodwill decision attached, not as a tired yes.

Metrics to watch

• Save rate - share of requests where Save Offer Accepted is yes, split by reason code.
• Resolution mix - exchanged against credit against refunded, as a share of all closed requests.
• Time to first response and time from request to resolution, measured in hours.
• Abandonment rate - requests authorized but never shipped, which signals friction in the label step or a policy that is scaring people off.
• Return rate by SKU and by reason code, reviewed monthly with whoever buys the stock.
• Inspection failure rate - items arriving in worse condition than declared, which tells you whether the declared-condition question needs tightening.
• Repeat returner concentration - share of all returns coming from contacts tagged repeat-returner.
• Post-return repurchase rate at 60 and 90 days, the number that proves a return handled well is not a lost customer.

Data and systems

• A written returns policy with a stated window in days, the condition requirements, who pays return shipping in which circumstance, and the exclusions. The build encodes the policy; it cannot invent one.
• Order data reachable from the platform: order number, order date, delivery date, line items with SKU and variant, and order value. Either a live store connection (for example Shopify or WooCommerce) or a scheduled import via Zapier or Make.
• A payment gateway connection such as Stripe for refunds and for charging a price difference on an upward exchange. Confirm who holds refund authority in the gateway and keep that permission off the automation.
• A carrier or label provider that can issue prepaid return labels by API, plus the tracking webhook that drives the In Transit stage.
• Stock visibility for the exchange offer. Offering a swap for an item that is out of stock is worse than offering nothing, so the save offer must read live or near-live availability.
• A review platform connection if the post-resolution survey is to feed public reviews.

Numbers, messaging and compliance

• Provision a dedicated returns number and complete A2P 10DLC registration in the United States before any SMS is sent. Register the brand and a transactional campaign, and expect the review to take time; start it in week one, not on launch day.
• Keep transactional return updates on a separate number and separate consent basis from marketing. A customer who opts out of marketing still needs their RMA label.
• Honor STOP, UNSUBSCRIBE, HELP and the platform's standard opt-out keywords on every number, and make sure an opt-out halts marketing sequences without halting the fulfillment of an open return. Document the fallback: if SMS is suppressed, the label and status updates go by email.
• Set quiet hours so no automated SMS sends outside roughly 08:00 to 20:00 in the recipient's local time, and hold queued messages to the next permitted window rather than dropping them.
• Decide the retention period for returns photographs and inspection images, and where they are stored. Damage photos can contain more than the product.
• Where you operate under GDPR, UK GDPR or similar regimes, the intake form collects personal data for a stated purpose; confirm your lawful basis, your privacy notice wording, and your retention schedule. Consumer-law return rights in some jurisdictions override a shorter shop policy, and distance-selling cooling-off periods may apply.
• None of the above is legal advice. Have the client's own counsel confirm the policy wording, the consumer-law position in every market they sell into, and the messaging consent approach before launch.

People and process

• A named returns owner who works the board daily and holds the goodwill and out-of-policy decisions.
• A warehouse or counter routine for completing Inspection Checklist on arrival, with a service standard for how quickly it happens; the whole build stalls at that gate if it is not worked.
• Agreed escalation rules: value threshold above which a human reviews, and the keywords that force immediate handover.
• Scoping and pricing are per build. Book a call at bookings.appbo.io to work through the policy, the integrations and the stock-visibility question.