A customer asking to return an item has not necessarily met the merchant’s return rules, and a return request is not the same as an approved return or completed refund. A good call workflow captures the facts needed by the team that owns the policy and keeps those decision states visible.
Shopify’s public guidance separates return requested, return in progress and returned states, and describes eligibility, inspection and refund actions as different steps. Treat that as an example of why a support script should not compress the entire process into “refund approved.”
Collect the minimum facts for review
- 1Confirm the order using the merchant’s approved verification method.
- 2Ask which item and quantity the customer wants to return; preserve the customer’s stated reason without recoding it into a policy outcome.
- 3Ask whether the item has shipped, arrived or been used only if that information is needed by the merchant’s published policy.
- 4Check the current return window and policy in the approved source. If the policy cannot be accessed, record “policy check needed” and route the request.
- 5Read back the request and explain the next action and responsible team without saying the return or refund is approved unless the authorized system says so.
Keep the request lifecycle explicit
- Request captured: customer intent and item details recorded.
- Eligibility review pending: an authorized person or system must apply the merchant’s current rules.
- Return instructions issued: the merchant has provided the required next step; do not imply the item was received.
- Item received and inspection pending: physical receipt and any required inspection remain separate evidence.
- Refund initiated, pending or completed: use the payment or order system’s exact status and timestamp.
Worked example: request accepted is not refund sent
Illustrative case: a customer requests a return for one item from a delivered order. The intake record includes the verified order reference, item and quantity, stated reason, delivery/condition facts supplied, policy source checked and review owner. If the rules allow self-service but the caller has not completed the required step, the status remains “instructions needed,” not “return approved.”
If the merchant approves the request and later receives the item, record those as separate transitions. Do not tell the customer that money has been returned until the payment system confirms the refund state.
Build the handoff around the next decision
A useful handoff contains the order reference, requested item and quantity, customer’s reason in their words, policy rule or exception to review, source and check time, current state, requested resolution, owning queue and named follow-up owner. Remove payment details and unrelated personal data from the note.
Review a sample of requests that were denied, delayed, partially refunded or escalated. Check whether the handoff preserved the customer’s facts and whether the final resolution came from the team with authority.
Limits and source notes
Return policies, legal duties, timing and refund methods vary by merchant, country, item and payment method. This guide is an operations checklist, not a statement of law or a refund decision. Shopify’s workflow is a source example, not a HeyRik feature claim; verify the current merchant system and policy before using it in a live process.
A little more before you begin.
Can an intake workflow promise a refund date?
Only if the authorized merchant or payment source confirms the applicable status and timing. A request alone does not establish either.
Is a return request the same as an approved return?
No. Keep request, eligibility review, item receipt, inspection and refund statuses separate.
Start here
Review a returns handoff workflow
Build a voice agent, upload your list or connect your leads, and run your first campaign on HeyRik — free to start, no credit card required.