RMA Process for a Small Manufacturer: Returns, Repairs, Credits

A small manufacturer's RMA (return merchandise authorisation) process needs seven stages: log the request, issue an RMA number, triage the fault, inspect the item, choose repair, replace or credit, close the case, and recover cost from your own supplier. AI can draft each reply and keep the case log tidy, but a person inspects and approves the outcome.

The number is the part people skip, and it is the part that stops a factory filling with unexplained parcels. Nothing should be accepted at goods-in without an RMA reference written on the outside, and nothing should be credited until someone has looked at the item and written down what they found.

Follow me on Instagram@sagnikteaches

The process below is sized for a business with a handful of staff and a few dozen returns a month. It needs no new software: a shared spreadsheet for the case log, a one-page returns policy, and a chat assistant on a business plan for the drafting. The decisions that cost money, such as whether a unit is repaired, replaced or credited, stay with a named person.

Connect on LinkedInSagnik Bhattacharya

Why one numbered record per return beats an email thread

Most small factories handle returns in a shared inbox. A customer writes, someone replies, a parcel arrives a fortnight later with no paperwork, and nobody can say whether it is the unit from the email on the third or a different one. Three weeks on, the customer chases a refund that nobody knew was owed.

Subscribe on YouTube@sagnikteaches

A numbered record fixes three things at once. The parcel can be matched to a promise you made. The decision has a named owner and a date. And the data afterwards tells you which products and which batches fail, which is the information you actually need to stop the returns. If you have not looked at patterns yet, the tutorial on spotting patterns in complaints, returns and defects with AI picks up where this log leaves off.

The record does not need to be elaborate. Fourteen entries (seventeen columns, since three entries hold two fields) will carry you a long way, and they are set out below.

The seven stages, with who does what

Everything in the last column is drafting or tidying. Nothing in it decides. That split is deliberate, and it is the same reasoning behind the limits suggested in automating returns and refunds with clear AI rules: the machine writes, the person signs off.

The case log: fourteen entries and nothing more

Create one sheet with a row per case. Keep the columns plain so any member of staff can fill them without training.

1. RMA number (sequential, with a prefix such as RMA-0412).
2. Date opened and expiry date.
3. Customer and order or invoice number.
4. Product code and serial or batch code.
5. Reported fault, in the customer's words.
6. Fault category, from a fixed list (see triage below).
7. Date received at goods-in.
8. Inspection finding, in the workshop's words.
9. Outcome: repair, replace, credit, reject.
10. Cost: parts, minutes of labour, carriage.
11. Credit amount and credit note number, if any.
12. Supplier claim: yes or no, with reference.
13. Date closed.
14. Owner: the person responsible today.

An illustrative row for an imaginary maker of garden irrigation controllers reads: RMA-0412; opened 3 March, expires 2 April; trade customer; order 88213; controller C4, serial 2208-1731; reported "stops watering after power cut"; category: electrical, firmware; received 14 March; finding: "memory battery at 0.4 V, programme lost"; outcome: repair; cost: battery $1.10 plus 12 minutes bench time; supplier claim: yes; closed 17 March; owner: workshop lead.

Issuing the number: the eligibility checks that save you money

Before a number goes out, three questions get a yes or no, and each answer is written into the log.

• Did we sell it? Match the serial or batch code to your sales records. Resold and grey-market units are common in trade products.
• Is it inside the period you promised? Compare the invoice date to the warranty or return window in your terms.
• Is the reason one the policy covers? Faulty, wrong item sent, damaged in transit, changed mind. Each has its own route.

If the answer to any of them is no, you still reply, but the reply explains the reason and what the customer can do next, such as a paid repair. That is a rejected case and it still gets a row, because the pattern of rejections shows where your policy is unclear.

If you already hold your terms and warranty wording in a document, paste them into the assistant's context with every case so it quotes you rather than inventing. Keeping that document current is a process job rather than an AI job, and documenting your processes before adding AI is the right preparation.

A prompt for the RMA reply, with sample output

Here is a prompt that produces the first reply. It goes into a chat assistant on a business plan, with your policy text pasted above it.

You write RMA replies for a small manufacturer. Use only the policy text I have pasted. If something the customer needs is not in the policy, say "I need to check" and list the question for me instead of guessing.

Case details:
- Customer first name: [first name]
- Product and serial: Controller C4, serial 2208-1731
- Invoice date: 2 November (inside 24-month warranty)
- Reported fault: "Stops watering after a power cut and I have to re-enter every programme"
- RMA number: RMA-0412, valid for 30 days

Write a reply of under 150 words that: confirms the RMA number and expiry date, gives the return address placeholder [address], asks them to pack the unit with the power supply but without the sensor cables, asks for one photo of the label, states who pays the carriage under the policy, and says when they will hear from us after the unit arrives. Plain, friendly, no apologies beyond one.

Illustrative output: "Hello [first name], thanks for the details. Your RMA number is RMA-0412 and it is valid until 2 April. Please write it on the outside of the parcel and send the controller with its power supply to [address]; the sensor cables are not needed. Could you reply with one photo of the label on the back so we can match it to our records? Because the unit is inside its warranty period, we cover the return carriage if the fault turns out to be ours; keep the receipt. We aim to tell you what we found within five working days of the parcel arriving. Sorry for the trouble."

What to fix: the output promises five working days. If your workshop cannot do that, change the number in the prompt, not in the reply, so every later reply carries the right figure. And check that "we cover carriage if the fault is ours" really is your policy. The AI repeated the pasted wording, so if the wording was loose, the reply is loose.

Fault triage: five categories and what each triggers

Triage is where you decide whether a parcel is needed at all. A fixed list stops the log filling with a hundred slightly different fault descriptions. These five cover most small-manufacturer work.

1. Fixable remotely. A setting, a reset, a missing step in the instructions. Send the fix; no RMA unless it fails.
2. Part fault. A component has failed. The customer can sometimes fit a spare, which saves two postage legs.
3. Workmanship. Something we made wrongly: a loose joint, a missed test, a mislabelled variant. Always inspect, and always trace the batch.
4. Transit damage. The item arrived broken. Photos of the outer box matter; the carrier claim runs on a clock.
5. Misuse or wear. Outside the warranty terms. Offer a paid repair or a trade-in rather than a flat no.

Ask the assistant to suggest a category from the customer's wording, with the one question that would confirm it. A message such as "it smells hot and tripped the breaker" should come back as a probable electrical part or workmanship fault with the question "does the smell come from the unit or the plug?" That last step is worth testing on twenty past cases before you rely on it. Pull twenty closed cases, hide the outcome, and see how often the AI's category matches what the workshop found. If it agrees fifteen times or more, it is useful for suggestions; if not, tighten the category descriptions and try again.

Example: a customer who sends a photo of a split casing

A customer writes that a plastic casing has split near a screw boss on a unit bought five weeks ago, and attaches a photo. Triage might ask the AI to compare the photo description and the order notes with three possible causes: over-tightened screw, moulding flaw, or knock damage.

The sensible output is not a verdict but a question: "Is the crack at the screw boss or away from it, and is there a witness mark on the outside?" The office sends that question back with the RMA number, so the customer can reply while the unit is in the post. When the casing arrives, the workshop checks the crack against the mould batch. Two cracks from the same batch inside a month is not a customer problem; it is a supplier problem, and it belongs in the supplier column.

Goods in and inspection: what the person writes down

The inspection is the stage that cannot be delegated. Whoever opens the parcel should do four things the same way every time.

• Book it in against the RMA number and photograph the parcel and the item before touching it.
• Check the serial or batch code matches the case. Mismatches go straight to the owner.
• Run a fixed bench test, written as a short checklist: power on, run a cycle, check the reported fault, check the one other thing that commonly fails.
• Write a rough finding in a few words.

The assistant then tidies the note. Rough input: "batt dead, programme gone, no corrosion, pcb ok, 12 min." Cleaned output: "Memory backup cell measured 0.4 V; programme storage lost on power interruption. No corrosion or board damage visible. Estimated repair: replace cell, retest, 12 minutes." The workshop reads it, corrects anything wrong, and signs it into the log. The tidy-up is useful because the same finding then goes into the customer message and the supplier claim without anyone rewording it twice.

The repair-versus-credit sum

This is the main worked example, with illustrative figures, using the irrigation-controller maker from the log row above. The C4 controller sells at $120 retail and $78 to trade customers. Parts and labour to repair a typical fault cost between $4 and $60.

Write the rule once, in words, so nobody argues case by case: repair if the total repair cost is under 40% of the amount the customer paid; otherwise offer a replacement or a credit, and scrap or strip the returned unit for parts. Then apply it.

The labour rate of $0.60 a minute is the figure you choose, for example from fully loaded hourly cost; use your own. Notice what the rule does not cover: goodwill. A long-standing trade customer with a 59% case might still get a free repair, but that is the owner's call and it is logged as an exception with a reason. Having the rule makes exceptions visible, which is the whole point.

Prompt for the sum, so you are not doing arithmetic at the bench:

Rule: repair if total repair cost is under 40% of the amount the customer paid; otherwise recommend replace or credit.
Case: customer paid $78. Parts: $31 board. Labour: 25 minutes at $0.60 a minute. Carriage back to the customer: $6.
Show the sum step by step, give the share as a percentage, state the recommended outcome, and list any assumption you made.

A good answer shows $31 + $15 + $6 = $52, then 67%, then credit or replace. Check one thing: whether carriage belongs in the repair cost. If your rule says it does not, the assistant should have said so as an assumption. The habit of making it list assumptions is what catches this.

Replace, credit or refund: three different pieces of paper

These get confused and then booked wrongly. A replacement sends a new unit, and the old one comes back for stripping. A credit note reduces what the customer owes you or can be spent on a later order. A refund returns money to the original payment method. Say which in every reply, and say it in a sentence that cannot be misread: "We will send a replacement unit; no payment is due." Your accountant will want the credit note number in the log. The assistant can draft the closing message, but the credit amount is typed by a person.

Closing messages that stop the second email

A closing reply answers four questions before the customer asks them: what we found, what we did, what happens now, and whether anything else is needed from them. Example for a repaired unit:

Hello [first name], RMA-0412 is closed. We found the memory backup cell had failed, so the controller lost its programme after a power cut. We replaced the cell and tested a full cycle. The unit is on its way back by tracked post today; the tracking number is [tracking number]. Nothing else is needed from you. If the same fault returns, quote RMA-0412 and we will pick up the case from here.

Compare that with the version most inboxes produce: "Fixed and sent back." The longer reply costs thirty seconds to write and often saves a follow-up. For a rejection, include the reason and one practical alternative, such as a paid repair price. Ask the assistant to keep the tone matter-of-fact and to avoid words like "unfortunately" three times in one message.

Recovering cost from your own supplier

If a bought-in part failed, the case is also a claim. Most small factories skip this and absorb the loss. The claim needs the same few things every time: your purchase order and delivery date, the part number and batch, the failure description, the test result, the count of failures against the quantity bought, and what you want (replacement parts, credit, or a contribution to labour).

Ask the assistant to draft the claim from the log row, then add the quantity yourself: "3 failures from 200 bought in July" carries weight where "some failed" does not. Keep a count per supplier in the log. If you begin to see a pattern, the same technique used in AI quality control for small manufacturers gives you an incoming-inspection check to add at the dock.

When the whole process runs on one afternoon of preparation

To set this up, take an afternoon.

1. Write the policy on one page: warranty period, eligible reasons, who pays carriage, RMA validity, repair-versus-credit rule, credit approval limit.
2. Create the log sheet with the fourteen entries and a drop-down for fault category and outcome.
3. Save three prompts somewhere the team can paste from: the RMA reply, the inspection tidy-up, and the closing message. Put the policy text at the top of each.
4. Add a rule that goods-in refuses unlabelled parcels, and print a sign for the dock.
5. Run last month's returns through the log retrospectively. You will find the gaps in your own policy within an hour.

Expect the first week to feel slower. The saving shows up in week three, when a customer phones about an old case and anyone in the office can answer from the row.

What goes wrong with AI-drafted RMA replies

Four failures are worth guarding against from the first reply.

• Invented promises. The assistant adds "we will ship a replacement immediately" because it sounds helpful. Fix: the instruction "use only the pasted policy" and a human read before sending, at least for the first fifty replies.
• Wrong warranty arithmetic. Models are poor at counting months across dates. Calculate the end date yourself in the sheet and give the assistant the result.
• Customer data in the wrong place. Use a business plan whose terms say your content is not used for training, and keep names and addresses out of prompts where a row ID would do. Check the vendor's current data terms before you start.
• A confident fault diagnosis from a photo. Treat any cause the AI names as a question to ask, never as a finding.

How to tell the process is working after a quarter

Pick four numbers from the log and check them once a month. Average days from RMA issue to parcel received. Average days from received to closed. The share of cases ending in credit rather than repair. And the top two fault categories by product code. If the first number is long, your replies are not clear about packing and postage. If the second is long, the workshop queue is the bottleneck, not the paperwork. If credits dominate, your repair-versus-credit threshold may be too tight, or your design is failing in a way that is not repairable. The category count tells you where to look first, and a single product with a quarter of the cases is worth a conversation with the people who make it.

If you would rather map the stages against your own order system and see what is worth automating first, that is what my AI implementation consultation covers.

Questions small manufacturers ask about RMAs

Should the customer pay to send a faulty item back?

Decide by fault type and write it down before the first case. One approach is to pay inbound freight when the fault is yours, which you only know after inspection, so a workable compromise is that the customer ships and you refund the carriage with the credit if the unit proves faulty. Whatever you choose, state it in the RMA reply.

How long should an RMA number stay valid?

Set a window that matches your transport times and enforce it in the reply, for example 30 days from issue. An open window protects you from parcels arriving months later with no record. Put the expiry date on the RMA form and in the reply so nobody has to guess.

Can AI decide whether to repair or credit?

It can apply a rule you wrote, such as repair if the estimated cost is under 40% of the unit's selling price, and show its working. It cannot see the item. A person inspects, confirms the numbers and approves any credit, because the money and the customer relationship are yours.

What if the returned item is not ours or was never sold by us?

Log it as a rejected case, photograph the label or serial area, and reply with the reason and what the sender can do next. Keep the parcel for the period your policy states. The case log should show who decided and when, so a later dispute has a trail.

Do I need special software for RMAs?

No. A shared spreadsheet or a free-tier table tool with one row per case is enough for the first few hundred cases. Move to your accounting or order system's returns module when you spend more time copying data between tools than deciding cases.

Further reads

• How to Handle Warranty Claims Faster With AI Triage — Triage warranty claims before they become RMAs.
• Where Should a Small Manufacturer Start With AI? — See where else in a small factory AI pays off first.
• Best AI for Ecommerce Operations: Orders, Stock, Returns, Suppliers — Compare tools that handle returns beside orders and stock.
• AI Systems for Manufacturing: MRP Add-On or Chatbot on Your Own Data? — Choose between an MRP add-on and a chatbot on your own data.
• HVAC Warranty Claims: Document the Failed Part and File With AI — See how another trade documents a failed part for a claim.
• Can an AI Chatbot Handle Order Tracking and Returns? — Decide whether a chatbot should take first-contact return requests.
• AI for Small Manufacturing Companies: Build a Weekly Production Schedule — A spreadsheet-based production schedule with worked capacity maths, changeover checks and a daily review routine.
• Capacity Planning Template: Can You Take That Order? Check With AI — Compare a new order's machine hours, setups and existing load with real capacity, then set a promise date you can keep.
• Capture Tribal Knowledge With AI Before Your Best Machinist Retires — Interview prompts, voice-note transcription and a sign-off loop that turn a retiring machinist's know-how into usable work instructions.
• Sublimation Printing Business: Price Jobs and Proof Designs With AI — A worked 24-mug quote built from blank, ink, paper, press time and spoilage, plus the proof email and AI prompts that keep both honest.
• Supplier Corrective Action Request: Draft a SCAR With AI — A SCAR built around one failed bracket lot: evidence pack, containment ask, root-cause questions, due dates and a closure test the supplier can meet.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: the author's process design; no vendor prices or product claims are quoted in this tutorial.