DEV Community

Cover image for Refund Request Form: Policy, Status, and the Customer-Facing Timeline
Lovanaut
Lovanaut

Posted on

Refund Request Form: Policy, Status, and the Customer-Facing Timeline

A refund request looks like an ordinary service request on the form. Operationally it is different, because the outcome is a decision, not just completed work.

Fields the request needs to be reviewable

A refund category cannot go through review without a verifiable reference. Make these required for that category even if they are optional elsewhere:

order_reference   (required)
purchase_date
reason            (required, free text or short list)
amount_requested
Enter fullscreen mode Exit fullscreen mode

Skip the reference field and every refund request stalls at intake while someone chases down which order it belongs to.

The customer-facing timeline

"In progress" tells a customer nothing about a refund. What they are actually waiting on is a decision, then money. Model it as a decision-state track, not a progress bar:

received -> under_review -> approved -> processed
                          -> denied
Enter fullscreen mode Exit fullscreen mode
received:     "We received your request and will review it within N business days."
under_review: no message needed if the review window was already stated
approved:     "Approved. You will see the refund within N business days."
denied:       state the reason plainly, and any alternative offered
processed:    "Completed," with confirmation details
Enter fullscreen mode Exit fullscreen mode

Two consequences follow. First, approved and processed must be distinct states -- a customer told "approved" who then hears nothing for two weeks will file a second request. Second, denied deserves the same care as approved; a denial with a stated reason closes the loop, a vague one generates an angry follow-up.

You do not need a separate form for this. A refund category, a required reference field, and this status track on the operations side are enough. What this does not require, and what a form tool should not claim, is an automated policy engine that approves or denies refunds on its own -- the decision stays human, the form and status model only make it trackable and visible.

The full guide, including intake design for general service requests, is in the Customer Service Request Form guide.

Top comments (0)