Why this matters
EXCHANGE-ELIGIBILITY-OPTION-SOURCE-CONTROL-READY
Exchange wording often sits across policy pages, product pages, order records, inventory systems, support macros, warranty notes, and manager exception rules. If AI reads only one source, it may promise an option the business cannot safely honor.
Exchange eligibility source card
| Field | What to capture | Safe wording rule |
|---|---|---|
| Customer/order context | Order ID, purchase channel, purchase date, item/SKU, serial/model if relevant, warranty or plan status, customer location, and support ticket owner. | Never imply eligibility based only on the customer request; use the verified order and policy record. |
| Requested option | Exchange, replacement, repair, store credit, refund, upgrade, downgrade, warranty path, parts-only option, or manager exception review. | Name options as “being reviewed” until a qualified owner approves the exact route. |
| Eligibility proof | Return window, condition, restocking or usage rules, product category exclusions, inventory availability, compatibility, warranty terms, and required customer evidence. | Do not invent stock, compatibility, fee amounts, policy exceptions, or timing. |
| Approval owner | Support lead, ecommerce manager, warranty owner, warehouse/inspection owner, finance/bookkeeper, or legal/compliance reviewer if sensitive. | Public wording should identify the next review step, not the final result, until the owner approves. |
| Customer-safe next update | One verified next action, evidence needed, owner, and realistic update window from the source record. | Give one safe next step; avoid pressure, blame, guaranteed approval, or unsupported deadlines. |
Copy/paste customer-safe snippets
1) Eligibility is being checked
Thanks for checking on exchange options for {order_id}. I am reviewing the item, order source, policy record, and available options before I promise a result. The next update will be {next_update_time} from {owner}.
2) Customer evidence needed
To route this accurately, we need {evidence_needed}. Once that is attached to {ticket_or_return_id}, {owner} can confirm whether exchange, replacement, repair, store credit, or another option applies.
3) Inventory or replacement depends on review
I do not want to guess about replacement availability or eligibility. We are checking {inventory_or_policy_source} and will confirm the approved option before sending any exchange or credit instructions.
4) Internal source note
Exchange option review: order={order_id}; item/SKU={sku}; requested option={exchange/replacement/repair/store-credit/refund/exception}; eligibility source={policy/version}; inventory/source proof={link_or_note}; owner={person}; customer-safe next update={date/time}. STOP PUBLISHING until owner confirms final wording.
AI audit prompt
You are auditing exchange eligibility and customer-option wording for a small business support page, chatbot, FAQ answer, email, or AI-search snippet. Use only the source card below. Do not invent exchange approval, stock availability, replacement compatibility, repair eligibility, store-credit amount, refund routing, shipping labels, restocking fees, legal rights, timing, or exception approval.
Return:
1) unsafe or unsupported claims,
2) missing source fields,
3) customer-safe wording,
4) owner/inventory/policy questions,
5) STOP PUBLISHING decision if eligibility is not verified.
Source card:
- Order/customer context:
- Requested option:
- Policy/version:
- Item condition/evidence:
- Inventory/replacement status:
- Fee/credit/refund path:
- Approved customer wording:
- Owner/next update:Product signal for SEO After AI
This adds another source-control pattern for policy-sensitive ecommerce and service pages. Monitor engagement before editing the buyer ZIP; repeated demand would justify a dedicated exchange/option-control appendix with source cards, AI audit prompts, and FAQ/schema review examples.