Returns and Exchanges in ChatGPT and Claude: From Order Item to Return Reference
A customer says, “These shoes are too small. Can I exchange them for the next size?” A returns app can find the purchased item, check the retailer’s recorded policy, and guide the customer to a return request. A helpful answer distinguishes eligibility, approval, shipment, and refund status.
This is an illustrative MCP app workflow. Model Context Protocol tools connect ChatGPT or Claude to a retailer’s systems; this article does not announce a ready-made Kernel Apps returns integration.
Find the purchase before applying a policy
After sign-in, show the customer’s relevant orders and ask them to select the item and quantity. Use the actual purchase date and item-specific policy from the retailer. Do not generate a deadline from general knowledge about returns.
An order may contain several products with different conditions. A personalised item, a gift, or an item sold by another merchant may follow a separate process. When the system has no clear eligibility decision, explain the uncertainty and route the request to the retailer’s support team.
Separate an exchange from a refund
For an exchange, check the replacement size and whether the retailer reserves it during processing. Show any price difference or delivery charge returned by the service. An available replacement today is not necessarily a replacement that has been secured.
Before creating the request, summarise the original item, reason, requested outcome, return method, and policy conditions. Let the customer review those details. The service response should supply a return reference and explain whether approval is automatic or still pending.
Make the next physical step clear
If a label is available, provide the link issued by the retailer. If a store visit is required, identify the location and required proof of purchase. Avoid claiming that a parcel has been collected or an item inspected until the operational system records that event.
- Keep return approval separate from refund authorisation.
- Keep refund authorisation separate from a completed refund.
- Identify who must act next when the request is waiting.
- Check an existing request before retrying a timed-out submission.
What happens when the customer returns later?
Retrieve the same return reference and display its latest recorded event. A clear timeline helps explain why a request is awaiting inspection without inventing a delivery or refund date. Evaluate whether customers can locate the same request again, not merely whether the first conversation sounds complete.
Explore customer support tickets and private customer data. Join the waitlist to discuss your returns process.