E-commerce returns portal MVP: make order states explicit

A returns portal connects a customer request to an operational process that may involve support, a warehouse and a payment system. Its first release should make those handoffs clear. A polished request form is insufficient if staff cannot determine whether an item has been received or a refund has been processed.

1. 01

   Define the unit of a return. One order may contain several items with different quantities and eligibility. Record what the customer is returning and preserve the decision that was made at the time of the request. If the policy later changes, staff should still understand the earlier decision.

2. 02

   Separate requested, approved, received and resolved states. Decide which actor may change each state and what evidence is required. Do not describe an approved return as refunded unless the payment workflow has actually confirmed that outcome. Customer-facing status should reflect the operation, not an optimistic assumption.

3. 03

   Handle repeat submissions and delayed external updates. A customer reopening a confirmation page should see the existing request rather than create another return. A repeated payment notification should not produce a second adjustment. Test a partial return and a failed external request as well as the straightforward success case.

4. 04

   Keep the first integration small. Staff may manually review eligibility while the portal provides a consistent request record and status view. Document the manual step, its owner and the expected turnaround rather than hiding it behind an automated-looking progress indicator.

5. 05

   Measure the proportion of requests that reach a clear resolution and the number of support contacts asking for status. A faster form completion rate is useful only if the downstream process remains accurate. Expand into labels, exchanges and complex rules after the team can trace a single item from request to resolution without reconstructing the story across disconnected messages.