Collect only decision-relevant information
Use the store's current approved process to identify the order, item, request reason and relevant dates. Ask for missing information only when it changes the next decision. Do not request payment-card details in a support message. The purpose of intake is to route a complete case, not to invent a return policy or decide a disputed entitlement.
Distinguish intake, review and execution
Write separate statuses for request received, awaiting review, authorized and completed. An AI-generated explanation of the published policy should not imply that a refund has been executed. Requirements may differ by market and product, so route policy exceptions and disputed cases to the authorized team. Use the policy that applies to this transaction rather than assuming all customers share the same terms.
Fictional worked example
Fictional acknowledgment: 'We received your request for the item in DEMO-411. The team will review the order date and the reason you provided against the applicable policy. We have not issued a return authorization or refund yet.' This message is an intake example, not a legal policy or a statement of customer rights in the US or Saudi Arabia.
Action checklist
- Use the applicable, approved policy and capture its version.
- Collect the minimum facts needed for review.
- Keep received, authorized and completed statuses distinct.
- Escalate exceptions and disputed eligibility without promising payment.