A box arrives at the loading dock with a customer's return address and nothing else. Nobody knows what is inside, which order it relates to, whether it was authorised, or who was dealing with it. Somebody opens it, finds a product, and starts working backwards through a shared inbox looking for the email that started this. That search takes twenty minutes and it happens several times a week.
The purpose of an RMA process is to make that search unnecessary. A return merchandise authorisation is not paperwork for its own sake. It is a promise that by the time a box reaches the dock, the warehouse already knows what it is, why it came, and what is supposed to happen to it. Everything in the request form exists to deliver on that promise.
What the RMA number is actually doing
The number is the single point where three separate systems agree about one physical object.
The customer writes it on the outside of the box. The warehouse reads it on arrival and pulls up the case without opening anything. Finance quotes it when the credit note is raised. Support quotes it when the customer asks where things stand. Without it, each of those parties identifies the return by a different handle: an order number, a name, a product code, an email thread. Reconciling those handles is the twenty minutes described above.
This has a consequence for the form. Nothing should ship before the number exists. A form that collects a request and then goes quiet has not authorised anything, and the customer, having filled it in, will post the item anyway. The number has to be generated and sent back automatically, in the reply that goes out on submission, not by a person who will get to it on Tuesday.
It also means the number needs to be short enough to write on a box by hand and unambiguous when read back over the phone. Avoid characters that are confusable in handwriting. A date prefix plus a sequence, such as 2609-0142, is easier to read out than a long random string and sorts usefully in a spreadsheet.
The fields the request form needs
Return forms bloat quickly, because every department has a question. The discipline that keeps them short is to ask only for what changes the decision or the handling.
| Field | Why it earns its place |
|---|---|
| Order number or invoice number | The only reliable link to what was sold, at what price, when |
| Email address | The identity of the case and the route for every later message |
| Product and quantity being returned | Partial returns are common and a whole order assumption causes credit errors |
| Reason for return, as a fixed list | Free text cannot be counted, and counting reasons is how product problems get found |
| Condition of the item and of the packaging | Decides restocking versus scrap before the box is opened |
| Serial or batch number, where products carry one | Warranty and recall handling both depend on it |
| Photographs | Settles damage and wrong item cases without a physical inspection |
| Preferred outcome | Refund, replacement or repair changes which team handles it |
| Return address | Needed for a replacement, and it is not always the delivery address |
The reason field deserves the most thought, because it is the field that pays for itself. A fixed list of six to eight options, with an other field beneath, turns returns into data. Damaged in transit, faulty on arrival, wrong item sent, not as described, no longer needed, ordered in error: those six categories separate a carrier problem from a picking problem from a listing problem, and each points at a different fix. A free text box produces six hundred unique sentences and no insight.
Two fields that are usually asked for and rarely used: the purchase date, which the order number already implies, and a phone number, which is collected as insurance and almost never dialled.
Photographs, and the thing to check before relying on them
Photographs resolve more RMA cases than any other field. Damaged in transit is obvious from an image of the carton. Wrong item sent is obvious from an image of the label. Both would otherwise require the item to travel to the warehouse before anybody could decide anything, which is a week of shipping spent on a question a phone camera answers in ten seconds.
There is a practical constraint worth checking before building this on a free tool. Google documents that to answer a file upload question, responders need to sign in to a Google account, and that uploaded files are stored in a new folder on the form owner's Drive. It also notes that the question type cannot be used if the form is stored in a shared drive, or if the administrator has turned on Data Loss Prevention. For an internal process that is fine. For consumer returns it is a meaningful drop off, because a customer who is already annoyed about a faulty product will not create an account to complain about it.
If uploads are to be part of the process, the requirements are narrow but firm: no account for the person uploading, a size allowance that survives modern phone cameras, and files that are visible to staff on the case rather than scattered across a drive. Storage allowances differ by plan on most tools, so the number to check on a pricing page is the total upload space rather than the per file limit.
Asking for three specific shots beats asking for photographs in general. The item, the damage or fault, and the shipping label. Named shots come back usable. An open request comes back as one blurry picture of a box.
The statuses a return passes through
A return is not a message. It is a case that moves, and the states it moves through are what makes the process legible to everyone who touches it.
A workable minimum: Requested when the form arrives, Authorised when the number is issued and the label sent, In transit when the customer says it has shipped, Received when the warehouse books it in, Inspected when the condition is confirmed, and one of Refunded, Replaced, Repaired or Rejected at the end.
The value of naming these is not tidiness. It is that every question anybody asks about a return is answered by a status plus a date. How many returns are waiting for a decision. How long the average return sits between Received and Inspected. Which returns have been authorised but never arrived, which after thirty days is money that can be released. None of those questions can be answered from an inbox, because an inbox has exactly two states, read and unread.
Alongside the status sits an owner. A return that nobody owns is one that two people will chase and nobody will close. On a small team this feels unnecessary until the day somebody is on leave and a case sits untouched for a week because each person assumed the other had it. The features that matter for this are the ones on the response screen: a status, an owner, and a history of what was sent.
The authorisation email is the real output of the form
Whatever the customer receives on submission is the part of the process they judge. It has five jobs.
It confirms the request was received, which stops the follow up email that would otherwise arrive the next day. It carries the RMA number in a form that can be copied or written down. It states the return address, which is frequently not the address on the original parcel. It gives the instructions: what to include, how to pack, whether the original packaging is required, and where to write the number. And it sets a deadline, because an authorisation that never expires leaves returns arriving months later against orders that have long since been closed in the accounts.
Sending this by hand is where most RMA processes quietly fail. It is a five minute job per return, which is manageable at three returns a week and impossible at thirty, and the failure mode is not that the email is never sent. It is that it is sent inconsistently, so half of the boxes arrive labelled and half do not, which is the same as none of them arriving labelled from the warehouse's point of view.
An automatic reply carrying the customer's own answers and a generated number solves this completely, and it is the single highest value piece of automation in the whole process.
Where the returns get lost
Once the authorisation is out, the case still needs somewhere to live. The common arrangement is a shared inbox plus a spreadsheet, and it has three predictable failures.
The customer replies to the authorisation email with a tracking number, and that reply lands as a new message unlinked to anything. The warehouse books the box in but updates a different sheet, so support still shows it as in transit. And nobody can answer the question of which returns are older than a week without reading every thread, so the question stops being asked.
The alternative shape keeps the request, the status, the internal notes and every message on the same record. The warehouse updates the status on the record rather than emailing support. Support opens the same record to answer the customer. Finance filters on the refunded status to produce the month's credit notes. The support and returns use case describes this flow, and the important property is not any single feature but the absence of a handover between systems, because every handover is a place where a return goes quiet.
What to measure once it works
Three numbers, all available once returns carry a status and a date.
Return rate by reason, which separates a carrier problem from a picking problem from a product problem. Time from Received to a decision, which is what the customer experiences as the length of the process. And the count of authorisations issued that never arrived, which is both a cash figure and a signal about whether the instructions are clear enough.
All three come out of an export if the internal fields sit alongside the answers in the same CSV. If producing them requires joining two spreadsheets by hand, they will be produced once, presented in a meeting, and never produced again.
What to change first
Find the last box that arrived without a number on it and work out what would have had to happen for the number to be there. In almost every case the answer is an automatic reply carrying a generated number, sent the moment the form is submitted. Build that one thing before touching anything else. Halict issues the reply on submission and keeps the return's status, owner and messages on the same record afterwards.
Q1. What information should an RMA request form ask for?
The order number, the email address, the specific product and quantity, a reason chosen from a fixed list, the condition of the item and packaging, a serial number where one exists, photographs, the preferred outcome, and the return address. Anything beyond that should be justified by a decision it changes.
Q2. Does the RMA number need to be issued automatically?
In practice, yes. Customers post items as soon as they have filled in the form, so a number that arrives days later reaches the warehouse after the box does. An automatic reply on submission is what keeps authorisation ahead of shipment.
Q3. Can Google Forms be used to collect return photographs?
It can, with a caveat. Google documents that responders must sign in to a Google account to answer a file upload question, and that the files land in a folder on the form owner's Drive. For consumer returns that sign in requirement causes meaningful drop off.
Q4. How long should an RMA authorisation stay valid?
Long enough to be reasonable and short enough to close the books, commonly two to four weeks. The deadline belongs in the authorisation email itself, because an authorisation with no expiry produces boxes arriving against orders that have already been settled.
Q5. Why use a fixed list for the return reason instead of free text?
Because reasons are only useful when they can be counted. Six to eight fixed options separate transit damage from picking errors from listing problems, and each of those points at a different fix. Free text produces a unique sentence per customer and no pattern.