# Return request prototype — reviewable draft

Purpose: test whether a clear request-and-review flow helps customers act without treating eligibility as refund approval. This is a screen specification, not a connected service.

## 1. Check a return

Returns are available for unused items within 30 days. We can help you check whether you can request a return. HarborMug must review your request before any refund is approved.

- Order reference: [text]
- Delivery date: [date]
- Item: [select item]
- Is the item unused? [Yes] [No] [Not sure]

[Check return options] [Ask support]

Require all answers before checking. Missing answer: “Please complete this field so we can check your options.” Invalid date or delivery date after request date: “Please check the delivery date.” Preserve answers when correcting an error. Do not infer a refund amount.

## 2A. Appears eligible

Your item appears to meet the return-request conditions.

Example summary: HarborMug mug; delivered October 20, 2026; return requested November 3, 2026; customer confirms unused. Your request is 14 days after delivery, within the 30-day window.

You told us the item is unused. This is not refund approval. Send a request for HarborMug to review.

[Send return request] [Edit answers] [Ask support]

The input says unopened; the prototype still asks the customer to confirm unused. Merchant review verifies the facts. Calculate elapsed calendar days for screening; route disputed dates and boundary interpretation to review.

## 2B. Needs review

For No, Not sure, a date beyond the window or unavailable order information:

“We can't confirm eligibility from these details. Returns are available for unused items within 30 days. You can ask HarborMug to review your situation. Sending a request does not approve a return or refund.”

[Request a review] [Edit answers] [Ask support]

Label these cases as needing review, rather than eligible, in the staff queue. Exactly 30 elapsed days can proceed to merchant review with the boundary noted; do not silently make a final policy decision.

## 3. Receipt and failure

After durable queue creation:

“Your return request has been sent for review. Your refund has not been approved. HarborMug will confirm the next steps after reviewing your request. Please wait for return instructions before sending the item.”

[View submitted details] [Ask support]

While sending, disable repeated submission and show “Sending your request…” A retry must reconcile the earlier attempt before creating another request. If sending fails, preserve answers and display: “We couldn't send your request. Please try again or ask support.” Never show the receipt for an unrecorded request. For an existing pending request: “You already have a request awaiting review. You can view its details or ask support.”

## 4. Staff review and escalation

Mia's queue entry includes the order reference, item, delivery date, stated unused status, elapsed days, screening result and pending-review state. Access only the order details needed to check this request. Check order and existing requests; record the reason and next step. Alex handles uncertain policy interpretation, disputed eligibility and routing failures. Refund execution is outside this prototype and requires a separate merchant-approved process.

No refund, label, shipping charge or return address is generated here. The supplied policy does not settle return postage, inspection rules, review timing or refund amounts. Ask the merchant to define these before any production journey needs them; do not fill the gaps with customer promises.

## 5. Acceptance and research script

Operations rehearsal cases: unused at day 14; unused at day 30; unused at day 31; used; uncertain condition; missing order; invalid date; duplicate submission; queue failure and retry. All must preserve explicit review status, retain an accountable owner and cause zero automatic refunds. Confirm staff can see and resolve the pending record before testing a connected pilot.

Participant prompt: “You have an unused mug delivered 14 days ago and want to return it. Use this draft to decide what to do next.” Do not coach or ask them to submit. Before their final action, ask: “What would happen if you continued? Has a refund been approved?” Record unprompted understanding, elapsed time and submission separately. Then ask: “What led you to take that action?” Capture declines without trying to persuade. Use other scenarios separately for branch usability; do not mix them into the eligible-request demand denominator.

Pass the supplied concept gate only if at least 4/5 distinguish eligibility from approval, at least 4/5 finish within two minutes and at least 3/5 submit. This draft has not been tested. The supplied earlier concept records pass the first two criteria and fail the third.