RMA Request Intake & Authorization

The problem this kills

Returns start as a mess of emails, DMs, and "can I send this back?" phone calls. Someone copies an order number into a spreadsheet, eyeballs whether it's still within the return window, guesses if the item was final-sale, and types out instructions by hand. Two reps issue an RMA for the same order line. A customer ships back something that was never eligible. Receiving has no clean list of what's actually coming.

The judgment isn't the problem - the chaos around it is. You need every request to land in one place, get checked against your actual policy automatically, and wait for a real person to approve before an RMA number ever goes out.

What you'll build

A small, private web app for your team and your customers:

• A submission form where a customer or sales rep enters the order number, the item/line, a return reason, and notes.
• An automatic eligibility check that confirms the order exists, the item is within your return window, and it isn't final-sale - and flags anything questionable.
• A coordinator review queue where a returns coordinator sees the request, the policy check results, and approves or denies it.
• RMA issuance that fires only after approval: a unique RMA number plus return instructions emailed to the customer.
• An RMA register CSV export in the exact columns your receiving team or system expects.

What's inside the Implementation Plan

The plan is a single file you paste into Claude Code, and it builds the whole thing with you step by step.

It opens by interviewing you about your business - your current returns process, where your order history lives, how your order numbers and SKUs are formatted, your real return window and final-sale rules, your typical and peak return volumes, and your messy edge cases. It reflects a short tailored spec back to you and waits for your thumbs-up, so the tool fits how you actually work instead of a generic template.

Then it walks you through, one copy-paste prompt at a time:

• Setting up the database, login, and per-organization data isolation.
• Loading your order history (CSV/Sheet now, an API later).
• Building the submission form and the automatic eligibility checks from your own rules.
• Building the coordinator approval queue and the RMA-issuance step.
• Wiring up the approval email and the RMA register CSV export.

The governance it includes (this is the point)

This isn't a toy form. The plan bakes in the controls that make a returns process trustworthy:

• Login so only your team and authorized submitters can use it.
• Row-level security so each organization only ever sees its own returns and orders.
• A full audit trail - who submitted, who approved or denied, and exactly when.
• A hard human approval gate - the tool drafts and checks, but no RMA number is issued until a coordinator approves.
• Duplicate guards - the same order line can't get two open RMAs, so you never double-authorize a return.

Who it's for

Customer service teams, returns coordinators, and warehouse receiving crews who are running returns out of email and spreadsheets and want one controlled intake-to-authorization flow - without hiring a developer or buying another SaaS seat.

You've got this. Paste the first prompt and let the plan interview you.