Warranty tracking: a promise with an expiry date

A warranty is a promise with a date on it, and the date is the part nobody records. Honouring one needs four facts tied to the unit that failed: which unit, who bought it, when coverage started, how long it runs. Most businesses hold three of them between an invoice and a message thread, then find at the counter that the fourth was never written.

What has to be attached to a unit before it leaves the shop?

A serial number that is unique, recorded when the unit moves, and printed on the customer's receipt — everything else is guesswork.

Four fields do the work, captured at the sale rather than rebuilt later: the serial, the model and batch, the buyer as something searchable (a phone number or an account, not only a name), and the date the unit left your control. Batch matters more than model, because a defect usually belongs to a shipment rather than a product line — when three units from one batch fail, the batch is what you stop selling.

Keep the typing to a minimum. A serial keyed from a photo at the till eventually carries one wrong character, and that is a claim you lose politely.

Does coverage start at the sale, the delivery, or the installation?

Whichever your terms name — and they must name exactly one, because all three are defensible and each moves the end date by weeks.

The invoice date is the easiest to compute and the least honest for equipment: a unit that sat in a warehouse has spent part of its promise before anyone used it. Delivery confirmation suits a courier carrying the unit, where transferring risk is the moment that matters. Activation — first power-on, installation by your technician, a first service call — is the honest start for anything installed, and it is what customers assume.

Pick one, compute the end date when the sale is recorded, and store which rule produced it. A hand-typed expiry will one day disagree with the card in the customer's hand.

What should a claim record contain?

More than the fault: the unit, the date reported, the channel it arrived through, the symptom in the customer's own words beside your category, who is handling it, what was tested, and the decision with the date the customer was told.

The customer's words matter because the category is your vocabulary, not theirs. One defect arrives described five ways, and only the original sentence lets you recognise the sixth. The tested field matters because it separates "broken on arrival" from "broken in use", and that decides who pays.

Is repair, replacement or a credit the right answer?

The decision belongs in the terms, not in the mood of the person at the counter.

Outcome	When it fits	What it commits you to
Repair	The fault is understood and the part exists	A loan unit, and a second date
Replace	The fault is unexplained, or the unit is new	A serial to retire and stock to move
Credit	The unit is gone, or was bought elsewhere	A finance entry, not a stock one

Repair is the default: it keeps the unit and its history, and the history tells you whether the fault is yours. Replacement wins when the fault is not understood and the customer cannot wait for a diagnosis; it also costs a unit of stock, a number that belongs in the same report as the claim count. A credit is the only honest answer when the unit cannot be produced, and the only one that leaves you no data about what failed — so somebody should sign it, not use it to end a conversation.

How do you track a serial you did not print?

Record the supplier's serial in a field of its own and never overwrite it with an internal one. Two identifiers are cheap; a merged one is unrecoverable. W3C makes the same point about datasets — an identifier must persist and mean one thing.

For imported stock with no marking, label at receiving rather than at sale: that step already touches every unit, and the label carries the batch and arrival date the till never sees. Where a supplier refuses to give serials, record batch and quantity and accept that claims settle per batch.

Does the promise follow the unit when it is resold?

Decide, write it, and make the record carry the answer. If coverage transfers, the new owner inherits the remaining period and the original start date; it does not restart. If it does not transfer, say so on the receipt — kinder than saying it at the counter.

The same question arrives when you replace a unit: does the new serial inherit the old expiry, or start fresh? Both are defensible, and whichever you choose will be quoted back at you. A replacement that resets the clock quietly doubles the promise.

How do you set this up?

1. Write the coverage rule in one sentence: starts at X, runs for Y, ends on a date the system computes.
2. Make the serial a required field at invoice, not an optional note, and choose one identifier per unit — yours or the supplier's — with the other kept as a second field.
3. Define repair, replacement and credit with one example each from your own history, and who authorises each.
4. Settle transfer and replacement before the first claim, not during it.
5. Print the end date on the receipt, so the customer and the record say the same thing.
6. Open every claim as a numbered record with an owner, and close it with a cause.
7. Review claims monthly by cause and by batch; that list is your next recall notice.

Where this goes wrong

• The card in the drawer. Coverage lives on paper nobody can search, so every claim starts with a request for a photo.
• The expiry typed by hand. One digit wrong and the unit is out of coverage a year early, or covered for a year it should not be.
• The serial read from a photo at the till. Recognition is right most of the time, which is the failure a spot check misses.
• The claim closes when the part is ordered. The record says resolved, the customer has nothing, and the second call starts from zero.
• Coverage counted in two systems. The till and the accounts package each compute an end date, differ by a month, and neither is wrong enough to fix.

What this does not cover

This is about the record, not the law: consumer rights in your market may outlive any printed term, and whether your wording holds is a lawyer's question. It also leaves out the accounting treatment of a replacement and recovering costs from a manufacturer.

We build the warranty into the sale record: a serial committed at the invoice, coverage computed by one stated rule, and a claim list showing what is open, what was replaced, and which batch keeps coming back.