A return policy is ready for a new user only when the public wording matches what the business can actually do. The person handling requests needs to know the eligibility rules, deadlines, condition requirements, refund method, shipping responsibility, exceptions, and escalation path. They also need to distinguish a voluntary return from an unshipped order, damaged delivery, warranty claim, or payment dispute.

This guide describes an operational handoff, not a universal legal policy. Consumer rights and disclosure requirements vary by product, transaction, and jurisdiction. Have qualified counsel review terms that create legal or regulatory uncertainty.

Build a policy matrix before editing prose

Create one row for each product or order category. Record:

  • whether returns are accepted and the time window;
  • when the window starts;
  • the required condition and packaging;
  • excluded or final-sale items;
  • who pays return shipping;
  • whether fees apply and how they are disclosed;
  • the refund destination and expected processing time; and
  • who may approve an exception.

Test the matrix against actual fulfillment capabilities. If the business cannot inspect a returned item, generate a label, receive a parcel, or send a refund through the original payment route, the public promise is not operational. Resolve that gap before publishing a broader guarantee.

Separate returns from shipment delays

An order that has not shipped is not the same as merchandise a customer received and wants to return. For U.S. online merchandise orders covered by the FTC's Mail, Internet, or Telephone Order Merchandise Rule, a seller needs a reasonable basis for the promised shipment time. If no shipment period is stated, the seller needs a reasonable basis to ship within 30 days. The FTC's prompt-delivery guidance says that when the seller cannot ship on time, it must provide a delay notice, a revised date, and the customer's cancellation and refund option.

The FTC's more detailed business guide to the rule explains that covered Internet sales require a reasonable shipping basis and documentary proof of the systems used to support that expectation. It also describes when customer consent is needed for a delay and when a full prompt refund is required.

Add an internal decision branch for `not shipped`, `delayed`, `delivered`, `damaged or incorrect`, and `ordinary return`. Do not force every situation through the ordinary return window. The public page should tell customers how to contact the business; the internal runbook should tell the operator which process and authority apply.

Write the public version for a real customer

Put the direct answer near the top: whether returns are accepted, the deadline, and how to start. Define the starting event with a date the business can verify, such as delivery confirmation. Explain what information the customer must provide without demanding unnecessary sensitive data. List exclusions close to the main rule rather than hiding them in a separate page.

State whether the refund goes to the original payment method, store credit, or another approved form. Do not promise instant posting if the business controls only the time it initiates the refund. Describe return-shipping responsibility and any fee before the customer begins the process. If an item has its own warranty or hygiene restriction, link the relevant terms and explain which route applies.

Keep shipping estimates consistent across product pages, checkout, confirmation emails, and the policy. A new operator should not have to reconcile one promise at checkout with a different rule in the support script.

Give the operator a case record

Each request should have an order identifier, request date, delivery or shipment status, stated reason, applicable policy version, decision, approver when needed, customer notice, tracking or receipt, refund initiation evidence, and closure date. Record facts rather than opinions about the customer. Limit access to people who need it and follow the business's retention rules.

Prepare response templates for approval, denial with a specific policy reason, request for necessary information, delayed shipment, and escalation. Templates are starting points; the operator must check the order and current terms before sending. An unusual safety issue, legal threat, chargeback, suspected fraud, or accessibility problem should route to the designated owner instead of being improvised in chat.

Verify the handoff with sample cases

Walk the new user through at least four invented orders: an eligible unopened return, an excluded item, an order that has not shipped by the promised date, and a damaged delivery. Ask them to find the applicable rule, state the evidence needed, choose the response path, and identify any approval gate. Do not use real customer data for training.

Finally, record the public policy URL, version date, approver, systems used for labels and refunds, escalation contact, and test results. A prepared return policy is not just readable copy. It is a consistent promise connected to an executable process and a record that shows how each decision was made.

Sources

  1. Selling on the Internet: Prompt Delivery Rules — Federal Trade Commission
  2. Business Guide to the FTC's Mail, Internet, or Telephone Order Merchandise Rule — Federal Trade Commission

Related reading