How to Build a Chatbot Flow for Refund and Return Requests

Encode the return policy as checkable conditions covering the return window, item category, condition requirements and any exclusions.

The return window

Calculate the window from the correct date, which is usually delivery rather than order date, and state clearly how many days remain or how many have passed.

Being specific about the calculation prevents the dispute that arises when a customer counts from a different starting point.

Category exclusions

Perishables, personalised items, hygiene products and digital goods are commonly excluded, and the flow needs to recognise these before offering a return.

Explaining why an item is excluded, rather than simply declining, prevents a large share of the escalations these cases otherwise generate.

Condition requirements

Where the policy requires original packaging or unused condition, the flow should ask rather than assume, since a customer told at the depot is a complaint waiting to happen.

Asking the customer to confirm condition also creates a record if the returned item arrives differently.

Handling near-miss cases

A customer a few days outside the window is precisely the case where rigid automation produces an avoidable complaint and a lost customer.

Routing these to a person with authority to make an exception, rather than declining automatically, is worth the escalation cost.

Explaining rather than declining

Where a return is not possible, stating the specific reason and what the customer can do instead converts a large share of would-be complaints into accepted outcomes.

A bare refusal generates an escalation almost every time, which costs more than the explanation would have.

Return reasons drive both the correct resolution and valuable product feedback, so they should be captured as structured options rather than free text.

Reason options that route

Distinguishing did not fit, not as described, damaged on arrival, arrived late and changed my mind matters because each leads to a different resolution and a different cost owner.

Free text produces better sentiment and worse routing, so structured options with an optional comment captures both.

Faults change everything

A damaged or faulty item is not a standard return, since the customer should not pay postage and the resolution may be replacement rather than refund.

Recognising this in the reason step and branching accordingly is the single most important routing decision in the flow.

Feeding reasons back

Aggregated return reasons are among the most direct product feedback a business receives, particularly sizing and description accuracy problems.

Reporting these by product rather than only in aggregate is what makes them actionable for merchandising and product teams.

Present the resolutions policy allows for this specific case, which frequently includes options better for both parties than a straightforward refund.

Exchange and credit as first options

Where the reason is sizing or a wrong variant, offering an exchange first retains the revenue and frequently suits the customer better than a refund.

Store credit with a small bonus is another option customers accept more often than businesses expect, provided it is offered rather than imposed.

Keep and refund for low-value items

For items where return postage and handling exceed the item value, refunding without requiring a return is cheaper and produces a noticeably better experience.

This threshold should be encoded in the flow rather than decided case by case, which is exactly the kind of rule automation applies consistently.

Being clear about costs

State who pays return postage, whether a restocking fee applies and when the refund will arrive, since these are the three questions that follow every return decision.

Answering them proactively removes the follow-up contact that otherwise arrives within a day.

Issue whatever the customer needs to act, confirm what happens next, and set expectations about timing.

Return labels and instructions

Generating a label within the conversation removes the most common friction point, since a customer told to print a label from an email frequently does not.

Include packaging instructions and drop-off options, as these generate follow-up questions when omitted.

Setting refund expectations

State when the refund is processed relative to the return arriving, and how long it takes to appear, since payment processor timing is outside your control and inside the customer's frustration.

Being explicit here prevents a substantial volume of where is my refund contacts a few days later.

Proactive status updates

Notifying the customer when the return is received and when the refund is issued removes almost all remaining contacts on the topic.

This is the highest-return automation attached to the returns process and is frequently omitted.

Handling partial returns

Multi-item orders frequently produce returns of some items rather than all, and the flow must handle partial returns without treating them as a full order reversal.

Confirming exactly which items are being returned, and what the refund covers, prevents the disputes that partial returns otherwise generate.

Some return cases should always reach a person, and configuring these before the flow goes live is what makes automation safe here.

Value and volume triggers

High-value items and customers with an unusual pattern of returns warrant human review, both for fraud reasons and because the decision may be commercially significant.

The thresholds should come from the same policy your team uses rather than being invented for the automation.

Safety and defect reports

A report that an item was dangerous, caused injury or failed in a way suggesting a wider defect must reach a person immediately, not enter a returns flow.

These are rare and consequential, which makes conservative recognition rules entirely appropriate.

Complaints and disputes

A customer expressing frustration, threatening a chargeback or referencing consumer rights should be routed to a person regardless of where they are in the flow.

Continuing a policy-driven automated flow at that point reliably escalates the situation rather than resolving it.

Chatboq connects order data, applies policy as eligibility conditions, issues labels and escalates the defined exception cases.

Connecting order and returns systems

Order lookup and label generation both require integration, and configuring these first means the flow can complete rather than collecting a request for someone to process.

A flow that captures a return request and hands it to a person has moved the work rather than removing it.

Policy encoded once

Return window, exclusions, condition requirements and cost rules are configured as conditions, so a policy change updates the flow rather than requiring flow edits.

Using the same rules the playbook gives agents keeps automated and human decisions consistent.

Measuring the flow

Track completion rate, escalation rate by reason, exchange versus refund split and follow-up contacts about refund status.

Follow-up contacts are the clearest signal that expectations were not set clearly enough during the flow.

Starting with eligibility only

A first version answering whether a return is possible, and explaining the process, deflects substantial volume before any label generation is integrated.

Adding label issue and refund processing afterwards extends the same flow rather than requiring it to be rebuilt.