A worked example: after-sales for an appliance manufacturer

This is a worked example, not a customer account. The manufacturer described does not exist, nothing below was observed at any business, and every number is an assumption written down so you can substitute your own. Re-run the arithmetic with your figures; the method is the transferable part.

The archetype

A mid-sized appliance manufacturer. It makes a handful of product lines in production batches, sells almost entirely through independent retailers and a small number of national chains, and relies on subcontracted engineers for in-home service.

It has never had a direct relationship with the people who own its products. Every unit passes through at least one other company on the way, and often two.

That single fact generates almost every problem below.

The assumptions

Assumption	Value
Units produced and sold per year	60,000 (5,000 per month)
Production batch size	2,500 units
Warranty period	24 months
Claim rate across the full warranty life	3% of units
Units registered for warranty today	20%
Claims arriving in the first 90 days after sale, normally	0.5% of units
Cost of a planned, route-batched service visit	60
Cost of a reactive breakdown visit	110

Currency is whatever you work in; the ratio between the last two is what matters. From the above: 60,000 × 3% = 1,800 claims a year, about 150 a month.

Problem 1: there is no line to the end customer

The manufacturer knows how many units it shipped to each retailer. It does not know who owns them, where they are installed, or when they were sold.

The practical consequences are specific:

• It cannot notify owners of anything — a safety notice, a firmware update, a known fault — except through retailers, who may or may not pass it on.
• It cannot tell whether a claim is inside coverage, because coverage starts at the sale and it does not know the sale date. In practice it accepts the retailer's invoice, or the production date, and the difference between those two can be months.
• It has no idea how long units sit in a warehouse or on a shop floor before selling.

That last point is quietly expensive. If coverage is computed from the production date because nothing better exists, the manufacturer is giving away every week of shelf life as free warranty.

Problem 2: registration depends on someone with no incentive

The registration problem is not technical. A retailer's sales assistant is paid to sell, not to enrol your warranty, and any step you add competes with the next customer in the queue.

There are four places registration can happen, and they fail differently:

Who registers	Why they would	Why they do not	Realistic ceiling
Retailer staff at sale	Relationship with you	No incentive, adds time, staff turnover	Low unless contractual
End customer, after purchase	Extended cover, proof of ownership	Requires them to act	Moderate, if the prompt is on the product
Installer at commissioning	Already on site, already recording work	Needs a tool that works on a phone in a kitchen	High, where installation happens
Nobody — you infer from invoices	No effort	Wrong sale dates, no customer contact	Not registration

For appliances, the installer is the most underused of these, because commissioning already involves someone standing in front of the unit with the serial plate visible. The practical mechanics of making that fast enough are in QR code warranty registration.

If you use the customer route, be honest that you are asking for something. A registration prompt works better when it exchanges something concrete — a longer coverage period, a verifiable certificate they can pass to a buyer if they sell the appliance — for thirty seconds of their time.

Problem 3: service is subcontracted, so the service record is too

Engineers are paid per visit. Their job is to fix the appliance and close the job. What they record is whatever the invoice requires: usually a fault code, the parts used, and the hours.

What nobody records in a retrievable form is the rest: which symptom the customer described, what was ruled out, whether this engineer has been to this unit before, whether the replacement part was the same revision as the one that failed.

So three things stay unknowable:

1. Repeat-failure rate per unit. A second visit to the same appliance looks like a new job.
2. First-time-fix rate per engineer. You cannot tell a thorough subcontractor from one who replaces boards until the symptom stops.
3. Which parts actually fix which symptoms, which is the single most useful thing a service network can learn.

The fix is not a new contract. It is that the engineer's job closure attaches to the serial number, and that the fields required to close it are the ones you need — symptom, action, part number and revision — rather than only the ones the invoice needs.

Problem 4: batch defects surface late, then get over-scoped

This is where the money is, so it is worth doing the arithmetic properly.

Suppose a component change affects one batch of 2,500 units, and 8% of that batch will eventually fail because of it. That is 200 units. Suppose 60% of those failures happen within 90 days of sale, because the defect is a manufacturing fault rather than a wear issue: 120 claims in that window.

Normal expectation for the same batch over the same window, from the assumptions above, is 2,500 × 0.5% = 13 claims.

So the batch generates roughly 133 claims where 13 were expected — a signal about ten times the baseline. Whether you can see that signal depends entirely on one thing: whether a claim can be attributed to a batch.

	Without serial-to-batch mapping	With serial-to-batch mapping
What you observe	Total monthly claims rise from about 150 to about 194	One batch's 90-day claim rate is 5.3% against 0.5% elsewhere
How it reads	A 30% increase, attributed to "the model" or to seasonality	An unambiguous outlier, visible in the first weeks
Who you can warn	Nobody specifically	The registered owners of that batch
Recall scope if you act	All units of the model shipped over the period — at 5,000 a month for three months, 15,000 units	2,500 units
Cost driver	Scope	Speed

A 30% rise on a base of 150 is real but ambiguous. It can be explained away by a cold snap, a promotional push three months earlier, or a retailer clearing old stock. The batch view cannot be explained away, because you are comparing batches of the same model at the same age — the cohort discipline described in the after-sales metrics worth tracking.

The recall scope line is where the difference becomes expensive. Six times the units, six times the logistics, six times the customers inconvenienced — all because the units cannot be told apart.

What registration at the point of sale is worth

Take the same defective batch: 2,500 units, 200 of which will fail. Compare acting proactively at two registration rates.

At 20% registration, you can contact 200 × 20% = 40 owners:

• 40 planned visits × 60 = 2,400
• The other 160 fail in service: 160 × 110 = 17,600
• Total: 20,000

At 70% registration, you can contact 200 × 70% = 140 owners:

• 140 planned visits × 60 = 8,400
• The remaining 60 fail in service: 60 × 110 = 6,600
• Total: 15,000

A difference of 5,000 on one batch, before counting the reputational cost of 100 additional in-home breakdowns. Note what is doing the work: not the software, but the fact that you can reach the owner. Registration rate is the lever, and everything else is downstream of it.

Substitute your own visit costs and your own registration rate. If your planned and reactive visit costs are closer together, the case weakens — which is worth knowing before you build anything.

What this does not fix

Three things, stated plainly, because a worked example that only lists benefits is marketing.

• Registration rate is a channel problem, not a software problem. A platform makes registering fast; it does not make a retailer care. Expect the rate to move in months, not weeks, and expect it to need commercial reinforcement.
• Historical units stay dark. Everything already sold remains unregistered. The population improves only as new units replace old ones.
• Batch attribution needs manufacturing to cooperate. If your serial scheme does not encode or map to the batch, none of the batch arithmetic above is available. That mapping is the prerequisite, and it is covered in serial number tracking.

The order of work

1. Make the serial-to-batch mapping exist and be correct. Everything else depends on it, and it is entirely within your own four walls.
2. Capture the sale date from whichever party will reliably give it to you, and stop computing coverage from the production date.
3. Put registration in the installer's hands where installation happens, and on the appliance itself for everyone else.
4. Change what closes a service job so the engineer's record attaches to the serial.
5. Then, and only then, report claim rate by batch at a fixed age — 90 days is a sensible first cut — and set a threshold at which someone is told.

Step five is the one that pays for the other four. It is also the one you cannot do first, which is the usual reason it never gets done at all. There is a broader list of what this data makes visible in the warranty data you are not collecting.

---

Warranlytics binds a warranty to the serial number at registration, holds the terms that applied at that sale, and records every service visit against the same unit — so claim rate by batch at a given age is a report rather than a project. See how a claim runs end to end, or talk to us about your channel.