A shopper asks whether a discounted item can be returned. An assistant that confidently repeats an outdated policy can create a promise the store did not intend to make. A useful answer begins with the policy that applies to the relevant store and purchase, identifies any missing facts, and gives the shopper a clear next step without inventing an approval.
Separate policy guidance from a return decision
A public policy can explain general time limits, exclusions, condition requirements and how to request a return. Whether a particular item qualifies can depend on the order, date, product type, condition and applicable store rules. Treat a request to return, an authorization, receipt of goods and a refund as separate steps. When order-specific information is unavailable or the case is an exception, explain the uncertainty and offer the store's support route.
Adobe Commerce documents an RMA workflow in which a request may be authorized fully or partially, or declined; customer requests depend on configuration and supported product types. This is a description of Adobe Commerce's documented workflow, not a promise that every Magento installation or assistant can create a return.
Make the source and scope explicit
Maintain an approved policy for each relevant store view and market, with an owner, publication date, effective date and review date. Record which source is authoritative if a help article, promotion and main policy disagree. A translated page should reflect the applicable local policy, not just translate a policy from another market. Do not assume a product is returnable merely because its category usually is.
When a policy changes, update the customer-facing page and the assistant's source through the store's normal publishing process. Check when the assistant last refreshed its copy and retest both the changed rule and an unchanged rule. If freshness or the applicable version cannot be established, route the question to a person instead of presenting the older text as certain.
Design the answer around the evidence
For a general question, cite or link the current policy and explain the relevant condition in plain language. For example: “The policy says discounted items may be returned within the stated period if the listed conditions are met. Check the policy for exclusions or contact support if your item is an exception.” That is a hypothetical wording pattern; actual terms must come from the merchant's policy.
For a specific order, request only the information needed for the next step and use the store's existing customer verification and authorization process before exposing order data. Do not ask a shopper to put payment credentials into chat. A shopper's description of an order is useful context, but it is not proof of ownership or of the order's current status.
Test before and after launch
Prepare test cases with synthetic orders and known expected outcomes. Include a standard return, an excluded product, a sale item, a missing purchase date, an expired policy, a different store language, contradictory documents, an unavailable order lookup and an explicit request for a person. For each, record the source and version used, the answer, the next step, and whether the assistant avoided an unsupported eligibility or refund promise. Repeat the changed-policy cases after each update.
Measure quality with a reviewed sample: count policy answers that match the approved source, unsupported commitments, unresolved questions and successful handoffs. Define each denominator and keep exceptions visible. A lower handoff rate is not a success if incorrect answers increase.
A returns assistant is useful when shoppers can understand the policy and reach the right next step. Keep decisions tied to verified facts, and make uncertainty clear whenever the evidence is incomplete.