Map an approved policy to customer steps
Organize the actual approved policy around eligibility, timing, preparation, request and next step. Keep each exception beside the rule it qualifies and preserve the policy’s meaning. Without that source text, the table is an annotation plan; it cannot define a return window, label entitlement or refund commitment.
Worked example — illustrative data.
| Customer step | Policy detail to insert | Page treatment |
|---|---|---|
| Check the item qualifies | Exact approved scope and exceptions | Plain eligibility explanation with source |
| Check timing | Owner-supplied timing rule | Keep start point and unit explicit |
| Prepare the request | Required order/item information | Short preparation checklist |
| Send the request | Supported contact or return portal | Accurate action and confirmation state |
| Understand what follows | Approved review/refund process | Explain known steps without new promises |
Ask the policy owner to supply the current approved text before drafting factual terms. Map each sentence that changes a customer’s action to the corresponding step. Preserve exceptions beside the relevant rule rather than hiding them in an unrelated paragraph. Test a normal return and one excluded or uncertain case as a reading exercise. Ask the responsible reviewer to confirm that the simpler wording has not broadened the policy.
Decision: Until approved policy text is supplied, keep this as an annotation worksheet. Publish the actual page only after policy review and the request destination are verified.
Damage claims may need a different return route: A damaged item may follow a different process from a change-of-mind request. Make the distinction only when the approved policy supports it, and show the correct route instead of forcing both through ambiguous instructions.
Continue with Guides for stores, software teams and local businesses, eCommerce website design and development and Explain subscription products before checkout.