Use case · Orders and returns
Order status and returns, with refunds left to your team
“Where is my order?” and “Can I return this?” fill most store inboxes. An assistant on your website and WhatsApp answers them from live order data once the customer proves the order is theirs, checks each return against your written policy and drafts it for staff. Money moves only when a person approves it.
At a glance
- What it takes on
- Confirm who is asking
- Report status in plain words
- Make simple changes
- Check returns against policy
- Connects to
- Your store or order system
- Carrier tracking
- Your helpdesk
- WhatsApp Business Platform
- Your returns policy
- OpenAI, Anthropic Claude or Google Gemini
- Typical rollout
- Week 1 → Weeks 5–6See the plan
The problem
Where the work gets stuck today
Order-status questions are simple, repetitive and urgent to the customer, yet each one means opening the store admin, finding the order, checking the carrier site and copying the latest scan into a reply. Returns take longer: someone checks dates, category, condition and exceptions, then explains the decision in words the customer will accept.
A generic chatbot fails here in two ways. Without an ownership check it can reveal another customer’s address or order. Without the written policy in front of it, it invents return windows or promises a refund the store never agreed to.
| Question | Data it reads | Who finishes it |
|---|---|---|
| Where is my order? | The order record and the carrier’s latest tracking event | The assistant |
| Can I change the address? | Whether the order is packed or shipped yet | The assistant before packing, staff after |
| Can I return this? | Order and delivery dates, item category, your returns policy | The assistant checks, staff approve |
| Where is my refund? | The return status and the refund record | The assistant reports, staff issue refunds |
| My parcel arrived damaged | The order and the photos the customer sends | Staff, with the case already prepared |
Task catalog
What the system takes on
Task 01
Confirm who is asking
Before any order detail is shown, the customer confirms the order number with the email or phone used at checkout, or a one-time code sent to it. Customers signed in on your website skip this step.
Task 02
Report status in plain words
The assistant reads the order and the carrier’s latest event and turns them into a sentence with the carrier’s delivery window, a tracking link and what happens next, instead of a raw status code.
Task 03
Make simple changes
Address corrections, delivery notes and cancellations are offered only while the order status still allows them, through your order system’s own API, and confirmed back to the customer.
Task 04
Check returns against policy
Each request is checked against your written policy: the window, the item category, its condition and final-sale flags. The reply quotes the rule that applied and links to the policy page.
Task 05
Draft the return for staff
Eligible requests become a draft return with the reason, photos and the checks already run, waiting in your helpdesk. Staff approve, edit or decline it in one place.
Task 06
Keep the customer posted
When staff approve a return or issue a refund, the customer gets the label, next step or refund status on the channel they used.
Step trace
One run, step by step
- 00:00NOTECustomerCustomer › On WhatsApp: “Order A-1042 hasn’t arrived, and I want to return the jacket.”
- 00:01PLANPlannerPlanner › Two intents: order status, then a return request. Confirm ownership before reading the order.
- 00:01TOOLVerifyVerify › Sender’s number is not the one on the order, so a one-time code goes to the order email. Code entered.
- 00:02OKOrder APIOrder API › Order A-1042: two items, shipped Monday. Carrier: out for delivery today.
- 00:03OKAssistantAssistant › Replies with the carrier’s delivery window and tracking link. Customer confirms the jacket return.
- 00:03TOOLPolicy checkPolicy check › Returns policy v4: window starts on delivery, outerwear is returnable, item not marked final sale.
- 00:04NOTEPolicy checkPolicy check › Not delivered yet: the return is drafted now and released once the carrier scans the parcel as delivered.
- 00:04TOOLReturn draftReturn draft › Draft return created in the helpdesk: reason “size”, checks attached, refund amount left for staff.
- 00:04APPROVALStore supportStore support › Waiting for staff. The assistant cannot issue refunds or credit, or change amounts.
- +1 hAPPROVEDStore supportStore support › A staff member approves the return; the store system generates the return label.
- +1 hDONEAssistantAssistant › Label and drop-off steps sent on WhatsApp. The refund update follows when staff issue it.
Policy checks
How a return request is checked
| Check | Reads | Passes when | If it fails |
|---|---|---|---|
| Ownership | Order number with the checkout email or phone, or a one-time code | The details match the order | Nothing about the order is shared; the customer can retry or ask for a person |
| Return window | The delivery date from the carrier | Today falls inside the window your policy states | The reply quotes the window and offers a person for exceptions |
| Item category | Product category and the final-sale flag | The category is returnable | The reply names the rule, such as hygiene items or final sale |
| Condition | The customer’s answer and optional photos | Unused with tags, as the policy describes | Used or damaged items go to staff with the photos attached |
| Earlier returns | Return history on the order | The item has not been returned already | Sent to staff instead of drafting a second return |
| Refund route | The payment method on the order | Always: the route is noted for staff | Does not apply, because the assistant never issues the refund |
Who may do what
Enforced by the assistant’s tool permissions, not only by its instructions.
The assistant does alone
- Order status and tracking links
- Delivery notes and address fixes before packing
- Return checks, with the rule quoted
- Draft return requests
- Status updates after staff act
It asks staff
- Every refund and store credit
- Returns outside the policy
- Damaged, wrong or missing items
- Cancellations after packing
- Anything the customer disputes
It never does
- Issue money or change an amount
- Share order details before the ownership check
- Promise a date the carrier has not given
- Apply a rule that is not in the current policy
Systems involved
What it connects to
- Your store or order system
- Orders, items, fulfilment status and returns, read through its API. Writes are limited to the actions you switch on.
- Carrier tracking
- The latest tracking events, from the carrier’s API or your shipping tool.
- Your helpdesk
- Where draft returns and handoffs land for staff, with the conversation attached.
- WhatsApp Business Platform
- The WhatsApp channel, on a number registered to your business.
- Your returns policy
- The published policy, versioned, so every reply cites the rule in force.
- OpenAI, Anthropic Claude or Google Gemini
- The model that reads requests and writes replies, on accounts in your name.
Guardrails
- No order detail before ownership is confirmed. An order number on its own is never enough.
- Refunds, store credit and amounts are outside the assistant’s permissions. It can only draft.
- Return decisions quote the policy version in force. A case the policy does not cover goes to staff.
- Order changes go through your order system’s own rules. If the API refuses a change, the assistant says so and offers a person.
- Addresses and phone numbers are masked in replies, showing just enough for the customer to recognise them.
- Text inside customer messages and photos is treated as data, never as instructions to the assistant.
Human checkpoint
Your support team decides every refund, store credit and exception. A draft return reaches the helpdesk with the order, the items, the policy checks that passed or failed, the customer’s reason and any photos, so a routine approval takes one click and an exception arrives with the facts gathered. The assistant also hands over any conversation where the customer asks for a person or sounds upset.
What we plan for
Typical targets
Typical target
50–70%
Order-status questions answered without an agent
Basis: “Where is my order” has a deterministic answer in your order and carrier data; the range allows for unverified customers, stale tracking and complaints. Confirmed from a sample of your recent tickets before launch.
Typical target
Under a minute per request
Staff time to approve a routine return
Basis: Drafts arrive with the checks and photos attached; timed on a sample of past returns during the pilot
Typical target
None, by design
Refunds issued without a person
Basis: The assistant’s tool permissions exclude refunds and amounts; only staff accounts can issue them
Rollout
Week by week
Week 1
Review a ticket export to size the question mix, write the returns policy as rules, and get read-only access to orders and tracking.
Weeks 2–3
Ownership check, order lookup and status replies built and tested on past questions. Policy checks and draft returns connected to your helpdesk.
Week 4
Pilot on website chat with staff reading every conversation. Masking, tone and handoff rules tuned.
Weeks 5–6
WhatsApp added, address and cancellation actions switched on where your order system allows them, and reporting handed over.
FAQ
Frequently asked questions
Could the assistant ever refund small orders automatically?
Not in this build: every refund waits for a person. Some stores later choose automatic refunds under a value cap. That is a separate change with its own rule, permission and audit trail, and we suggest running the approval flow first so the cap is set from real requests.
What happens when a customer checked out as a guest?
Guest orders work the same way. The customer gives the order number and the email or phone used at checkout, or enters a one-time code sent to it. Customers signed in on your website skip the step, because their session already shows whose order it is.
How do you turn our returns policy into rules the assistant can check?
We go through the policy with you line by line and write each condition as a check: the window and when it starts, excluded categories, condition requirements, exchange or refund. Ambiguous lines come back to you to decide, and the published page is updated to match, so customers and the assistant read the same rules.
Can customers ask for an exchange instead of a return?
Yes, where your order system supports exchanges through its API. The assistant checks stock for the new size or colour, drafts the exchange with the same policy checks, and staff approve it like a return. Where exchanges are manual today, it drafts the request and staff complete it.
Which conversations go straight to a person?
Damaged, wrong or missing items, disputes about a charge, anything outside the written policy, customers who ask for a person, and messages that read as angry or urgent. The handoff carries the order, the conversation and the checks already run.
What access does the assistant need to our order system?
Read access to orders, items, fulfilment status and returns, and write access only for the actions you switch on, such as creating a draft return or fixing an address before packing. It uses its own API key with those scopes, so its access can be reviewed or revoked separately.
Can it answer order questions on WhatsApp and our website at once?
Yes. Both channels share the same ownership check, order lookup and policy rules. On WhatsApp, updates sent after the customer service window has closed must use message templates approved in advance, so return and refund updates are written as templates you sign off.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment