How to Build an After-Sales Warranty and Repair (RMA) System: Serial Registration, Tickets, Parts and Replacements

Sixty Requests a Day, Eighteen Days to Close

A distributor in central Taiwan carries three appliance brands and ships 24,000 units a year. After-sales runs on one support inbox, an Excel workbook with 11 tabs and three LINE accounts. In August peak season, 60 repair requests arrive daily. To decide whether a unit is still under warranty, support asks the customer for the invoice, opens the dealer shipment file, then cross-checks the model table: about seven minutes before the first reply goes out. Average time to close that year was 18 days, of which bench repair accounted for 40 minutes. Four complaints escalated to the Consumer Protection Officer, each costing a manager roughly six hours. The money was not going into fixing products. It was going into looking things up.

Who Should Build This, and Who Should Wait

Good fit

• You ship more than 2,000 warrantied physical units a year, or you have more than 300 machines running in the field.
• Warranty runs a year or longer and outcomes branch at least three ways: repair, replacement, part swap.
• More than 40 repair requests a month, and support opens three or more systems to produce one answer.
• After-sales consumes parts and labour, and you need to know what each case actually costs.
• Dealers or authorised service centres need scoped access to view and update their own cases.

Wait if

• Fewer than 15 requests a month and nine out of ten end in a straight swap. A Google Form plus a Notion board is enough.
• The product carries no warranty obligation at all (food, consumables, fast fashion); channel-native returns flows are faster.
• Your shipment data is a mess: no serial numbers, ship dates that do not map to customers. Clean the data first, or the system just digitises the chaos.
• The goal is to make the complaint count look smaller without changing the product or the manual. A system will only show you the same defect more clearly.
• After-sales is fully outsourced to a third-party repair company and you have no intention of taking the case data back.

Four Paths, With Costs and Trade-offs

The pragmatic route is staged: run support SaaS first to get tickets and SLA under control, and clean up serials and shipment files in parallel. In year two, decide whether warranty logic and the parts module deserve a custom build. Building custom first and then discovering the serial field is empty is the most expensive possible order.

From Requirements to Launch: Four Phases

• Phase 1: Warranty rules and serial-number audit (5–8 working days). Write a matrix of product line by warranty months by start date by exclusion, and measure serial coverage across the last three years of shipments. Deliverables: warranty policy matrix, serial coverage report, return/replace/repair decision tree. Tools: Google Sheets, Notion.
• Phase 2: Flow and state machine design (8–12 days). Turn request, warranty check, intake, diagnosis, quote, repair or replacement, dispatch and close into a state machine. Every state defines its SLA, who can change it and what happens on timeout. Deliverables: high-fidelity Figma screens for three roles (consumer, support agent, service centre), state machine diagram, notification copy table. Tools: Figma, FigJam.
• Phase 3: Build and integration (25–40 days). Serial lookup, automatic warranty adjudication, tickets and parts consumption, online quoting and payment, reverse-logistics pickup labels, e-invoicing. Deliverables: a system that can run real cases, repair cost reporting. Tools: Laravel, ECPay, the Ministry of Finance E-Invoice Platform, T-Cat or HCT logistics APIs, LINE Messaging API, Cloudflare R2 for fault photos.
• Phase 4: Pilot and backfill (12–20 days). Lock to one product category and one service centre, run 100 real cases, and backfill the last 12 months to establish a baseline. Deliverables: support SOP, Metabase dashboard, Sentry and UptimeRobot monitoring.

Real Costs: Three Budget Tiers and the Hidden Items

• Entry, NT$300,000–500,000. Serial registration page, automatic warranty adjudication, online repair request form, tickets with status notifications, admin back office. No payments, no parts inventory.
• Mid, NT$650,000–1,100,000. Adds parts inventory and consumption postings, online quoting and payment, e-invoicing, reverse-logistics labels, per-branch service centre permissions, SLA and repair cost dashboards.
• Advanced, NT$1,400,000–2,500,000. Multi-brand and multi-country, dealer portal, IoT remote diagnostics, loaner and spare allocation, warranty reserve estimation, two-way sync with ERP and CRM.

The line items most often missed

• Serial data cleanup: the most expensive item on the list. If three years of shipments carry no serial mapping, manual backfill runs 30 seconds to 2 minutes per record. Twenty thousand records is 170 to 670 hours.
• Notifications: SMS at NT$0.7–1.2 per message, four to six messages per case; LINE push messages beyond the free tier are billed separately.
• Reverse logistics: NT$120–200 per door-to-door pickup, with an 8–15% re-return rate from poor packaging in practice.
• Payments: for out-of-warranty repair charged online, the ECPay fee schedule puts standard sellers at 2.75% for domestic credit cards plus NT$1 per order.
• E-invoicing: value-added centre fees of NT$500–2,000 a month plus NT$0.3–1 per invoice.
• Support seats: Zendesk and Zoho Desk both price per agent per month (see Zendesk pricing); five seats typically lands at NT$60,000–200,000 a year.
• Fault photo storage: three to eight images per case, NT$500–2,000 a month.
• Annual maintenance at roughly 15–20% of the build cost.

What Clients Imagine vs What Actually Happens

• Imagined: moving Excel into a system makes it fast. Actual: Excel is slow because the ship date and serial cannot be found, not because of the interface. Below 70% serial coverage, any system falls back to manual judgement.
• Imagined: customers will register their warranty online. Actual: with no incentive, registration lands at 5–15%. Attach three extra months of warranty or a free first on-site inspection and you reach 35–60%.
• Imagined: repair time is the bottleneck. Actual: the days go into waiting for the customer to approve a quote and waiting for parts. Bench time is often 40 minutes. Those two waits are what the system should attack.
• Imagined: complaints will drop after launch. Actual: month one looks worse, because grumbles that used to live in LINE threads finally get recorded. Watch the repeat-repair rate, not the total count.
• Imagined: authorised service centres will fill in the system. Actual: external centres fill it in only when filling it in is how they get paid. Tying invoicing to the ticket is the only mechanism that works.

Seven Common Traps and How to Avoid Them

• No defined warranty start date. Fix: hard-code the priority order, invoice date over ship date over manufacturing date plus a channel-inventory buffer, and publish it on the warranty policy page so agents never have to improvise.
• Missing or duplicated serial numbers. Fix: encode category, year-month, sequence and a check digit; write the serial to the database at the moment the label is applied on the line. Keep an invoice-plus-model-plus-purchase-date fallback path for legacy units.
• Treating the seven-day consumer right as a warranty. Fix: keep them completely separate. Under Article 19 of the Consumer Protection Act, a distance-selling consumer may rescind within seven days of receipt without cause (subject to the reasonable exceptions regulation). That is a different rule set from product warranty, so system states and agent scripts must be independent.
• Quotes stalling on customer silence. Fix: give quotes a 72-hour validity plus two automatic reminders over LINE and SMS. On expiry, auto-convert to "return as-is" with a diagnostic fee, disclosed in the terms up front.
• Parts inventory living outside the system. Fix: at minimum, put your top 20 fast-moving parts under safety stock with consumption postings. Those 20 usually account for more than 70% of consumption; leave the long tail manual.
• Replace-or-repair decided by goodwill. Fix: write it as a rule that fires automatically. Third occurrence of the same fault within 30 days, repair cost above 60% of product cost, or a discontinued part all trigger a replacement recommendation.
• A status page that requires login and loads slowly. Fix: build a public status lookup that needs only a serial plus the last three digits of a phone number, and keep LCP under 2.5 seconds. That single page typically absorbs 30–40% of inbound support calls.

Success Metrics and the 90-Day Roadmap

• Day 30: the data foundation. Serial coverage at or above 85%, automatic warranty adjudication at or above 80% of cases with no manual verification, and 100% of cases inside the system with nothing leaking into LINE direct messages. Do not look at satisfaction scores yet.
• Day 60: cycle time. Average turnaround time down 30% from baseline, first response within four working hours, quote approval rate within 72 hours at or above 70%. If TAT will not move, the constraint is almost always parts lead time rather than headcount.
• Day 90: cost and quality. Average repair cost per case, in-warranty versus out-of-warranty case mix, repeat-repair rate (same unit back within 90 days, target under 8%), and which part number or manual revision each of the top five fault codes maps to. Only once you have these three numbers should you touch warranty policy or spare-parts stocking levels.

Decision Checklist

• ☐ Do you take at least 40 repair requests a month, consistently?
• ☐ Can shipments from the last three years be mapped to customers via serial numbers?
• ☐ Is serial coverage already at 70% or better?
• ☐ Is the warranty start date defined in writing?
• ☐ Are the exclusions (physical damage, water ingress, unauthorised opening) spelled out?
• ☐ Do you need separate flows for in-warranty and chargeable repairs?
• ☐ Do external authorised service centres need scoped access?
• ☐ Do you need to collect repair payments online and issue e-invoices?
• ☐ Do you need reverse-logistics pickup integration?
• ☐ Do you know your current average turnaround time?
• ☐ Can you calculate parts cost and labour cost per case?
• ☐ Is someone responsible for maintaining the fault-code and part-number mapping?
• ☐ Can the replacement policy be written as a rule rather than case-by-case discretion?
• ☐ Can you accept that complaint counts will look higher in month one?

Nine or more ticked and the mid-tier budget usually pays for itself. Fewer than six, spend two weeks cleaning serials and shipment files and come back to this list.

FAQ

Which date should the warranty actually start from?

The three candidates in Taiwan are invoice date, ship date and manufacturing date. Hard-code a priority: invoice date when one exists, ship date when it does not, and manufacturing date plus a channel-inventory buffer (appliances usually assume three to six months) only as a last resort. What matters is not which one you pick but that you pick one, publish it on the warranty policy page and encode it as a rule so agents never adjudicate on the spot. Note also that a commercial warranty is separate from statutory warranty against defects under the Civil Code; your terms cannot be written so as to waive the statutory liability.

Can we build this without serial numbers?

Yes, but it degrades to manual adjudication. Provide a fallback path: the customer uploads an invoice photo or supplies an order number, and an agent matches model and purchase date before flagging warranty status manually. That path costs three to seven extra minutes per case. In practice, start serialising new production at the line and writing to the database at label time, then let the fallback carry legacy units until they age out. Do not build inference logic for old stock that will never be accurate.

Should we buy Zendesk or build custom?

It depends which side hurts. If the pain is scattered conversations, no SLA and unfindable history, support SaaS solves it in two weeks and it is cheap. If the pain is that you cannot adjudicate warranty, cannot cost parts and cannot reconcile with service centres, that is a data-model problem and SaaS custom fields will not hold. For most Taiwanese SMEs the best answer is hybrid: SaaS for conversation and SLA, plus a thin custom warranty-and-parts service sitting in front of the ERP.

What if authorised service centres refuse to use the system?

Do not rely on persuasion, rely on cash flow. Change the payment rule so only system-generated tickets are accepted for invoicing, and let each centre see its own closed-case count and pending payment inside the system. Compliance typically goes from around 30% to above 90% within two months. Also make the interface one-handed on a phone with photo upload in three taps: nobody in the field is opening a laptop.

How long before we see results?

Data in 30 days, process in 60, cost in 90. Month one should only be expected to deliver "every case is in the system." From month two, average turnaround and first response time improve visibly. Month three is the first point at which repeat-repair rate and per-case repair cost are trustworthy enough to renegotiate spare-parts stocking and warranty policy. If TAT has not moved at all after three months, the problem is in the parts supply chain, not the software.

Next Step

ScriptWalker's After-Sales Warranty and Repair (RMA) System build starts at NT$300,000 and includes the warranty policy matrix, a serial coverage audit and an MVP capable of running real cases. If you already have an after-sales Excel workbook in daily use, send us three months of case records (de-identified is fine) and we will return a free After-Sales Flow Health Check showing where your days are being lost and how far serial coverage needs to climb before automatic adjudication is worth building.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p