Working With Warranty and Repair Vendors

Monday, 10:20, at Acme. Sofia has been on hold with a repair vendor for nineteen minutes. She is listening to a recording that thanks her for her patience at intervals. She is holding because Malik from sales has asked, for the third time, where his laptop is. The ticket says "sent for repair" with a date three weeks ago and nothing after it. There is no claim reference in the ticket, because the technician who sent it has since left. There is no courier tracking number, because it went in a box with a handwritten label. And when the vendor finally answers, they will ask for the serial number. That is on the machine, which is with them. Malik has been on a loaner for three weeks and has stopped asking politely. Sofia is about to discover that a repair claim is not a thing you send. It is a thing you run.

A warranty claim is a request to the machine's maker, or to whoever the maker has appointed, to repair a fault that the warranty covers. The repair is at no charge, within whatever turnaround the warranty promises. A repair vendor is anyone the desk pays to mend a machine the warranty does not cover, or no longer covers. The desk's job in both cases is the same. Prove the fault and hand over the machine with everything the vendor needs. Keep the ticket honest about who is waiting on whom, chase on the promised date, and keep the user informed while the box is away. This article is part of our Hardware Troubleshooting Workflows series. It names no vendors, because the method is the same for all of them and the ones that need naming change their names.

It covers what must be done before a claim is logged, what the vendor needs from you, and logging the claim. Next come the ticket in a waiting state, chasing without being chased, and the no-fault-found return. Then come keeping the user informed, what happens when the box comes back, a short war story, and the vendor claim note to copy.

Before the Claim: What Must Already Be Done

A machine goes to the vendor only after the desk has climbed the ladder. The vendor will ask what was tried and the honest answer "nothing" sends the machine back unrepaired with a note that it worked fine. The rungs in The Diagnostic Order are the vendor's evidence as much as the desk's. Those rungs are known-good charger, bare machine, clean image, built-in diagnostics run with their result recorded. A fault that has survived a clean image is one the vendor can believe in. A fault that was reported by the user and forwarded by the desk is one the vendor will try to reproduce for ten minutes, fail, and return.

The vendor's own diagnostic deserves a paragraph, because most makers build one into the firmware and most warranties expect it to have been run. It takes a few minutes and produces a code or a short report. That code is what the claim form or the support line will ask for first. Run it, photograph the result if the machine cannot save it, and put the code in the ticket. A claim logged with the maker's own diagnostic code is a claim that skips the first round of "have you tried". On a busy support line, that round can take a day.

Before the box is sealed, the data question is answered once, by policy, not per ticket. A machine leaving the building carries whatever is on its drive. The desk's standard should say what happens to it. The drive is encrypted and the key is held by the organisation, or the drive is removed and kept. Or the drive is wiped before despatch and the user's files were on the file service anyway. Which of those applies is the organisation's decision. The desk's job is to apply it every time and to write on the claim note which one was done. A vendor that reimages a drive, which many do as routine, has done the user a favour only if the files were somewhere else first.

What the Vendor Needs From You

Every vendor asks for the same handful of things. A desk that has them ready logs a claim in a quarter of an hour instead of an afternoon. The table below lists them, says why each one matters, and says where the desk should be keeping it so that it is to hand on the day. The last column is the one to check against your own desk. The usual reason a claim takes an afternoon is that one of these things lives in a filing cabinet, a leaver's mailbox, or a spreadsheet nobody has opened since the machines were bought.

Two of these need a word of defence, because desks skip them. The photographs feel like fuss until a machine comes back with a different cracked corner from the one it went out with, or with less memory than it left with. Then the vendor's records say it arrived that way. Four photographs cost two minutes and settle the argument before it starts. And the reproducible fault description feels like duplication of the ticket. Then you remember that the vendor's engineer has never seen the ticket and has fifteen other machines on the bench. The engineer will give yours the ten minutes its description earns. "Screen flickers" earns ten minutes. "Screen flickers when the lid passes about sixty degrees, reproduced on a clean image with no peripherals, external monitor unaffected, see photo" earns a new cable.

Logging the Claim

A claim is logged through whatever route the vendor offers. That is usually a web form, a support line, or an account manager for larger customers. Whichever route it is, the desk comes away with four things or it has not logged a claim. Those are a claim reference, the name of the service promised, the date by which something will happen, and the name or identifier of whoever at the vendor accepted it. Write all four in the ticket within the hour. A claim without a reference is a conversation. A claim without a date is a hope. A claim without a name is a reference nobody at the vendor will own when it is chased.

The service promised comes in three shapes. The desk should know which it has agreed to. Collect and return means a courier takes the machine to the vendor's workshop and brings it back. The time quoted is door to door. On-site means an engineer comes to the building with a part. The time quoted is until the visit. Carry-in means the desk delivers the machine to a nominated repair centre and collects it. The time quoted starts when it is handed over. Each has a different place where time disappears. Collect-and-return loses days in transit; on-site loses days waiting for the part to reach the engineer; carry-in loses days waiting for somebody at the desk to make the trip. Write which one it is next to the date, because "five working days" means different things under each.

Chargeable repairs, where the warranty has ended or does not cover the fault, add a quotation step. The quotation is a decision point rather than a formality. The vendor says what the repair will cost in time and in a figure. The desk takes that back to the rules in Swap, Repair or Retire. It decides, in hours and age, whether to accept, to decline and have the machine returned, or to decline and have the vendor dispose of it. The quotation goes in the ticket with the decision and who made it. The vendor is told the decision by the date they asked for. A quotation nobody answers is a machine sitting on a shelf in somebody else's building at the desk's expense.

The Ticket in a Waiting State

While the machine is with the vendor, the ticket is waiting on the vendor. It should say so in a way that the queue can see, with the date the vendor promised attached. The whole point of a waiting state is that it tells the desk who is next to act and when. The distinction between waiting on the user, waiting on a vendor and genuinely on hold is the subject of Pending User vs Pending Vendor vs On Hold. This article only insists that the vendor's promised date is written where the sweep will find it. A waiting ticket without a date is a ticket that is forgotten until the user shouts.

Most desks find it cleaner to split the work in two. The user's ticket is about the user: fault reported, loaner issued, resolution when the user has a permanent machine. The vendor claim is its own ticket, linked to the user's. It carries the claim reference, the courier tracking, the chase log and the promised dates. It is the one that sits in the waiting state. The user's ticket can then close when the user is sorted, by swap or by return. Meanwhile, the claim ticket runs on until the box is back and the pool is whole again. A desk that keeps both stories on one ticket ends up with a user's ticket that stays open for a month and a resolution note full of courier references. In that case, the user receives every chase as if it were addressed to them.

Whichever shape the desk uses, the audiences stay separate. The vendor's reference, the chase log and the quotation go in internal notes that the desk reads. The user gets public replies that say what matters to them. That is when they will have a machine and what to do meanwhile. If you run QuerySolv, the internal note and the public reply sit on the same ticket but go to different readers. In that setup, the claim's paperwork accumulates where the technician needs it without the user receiving a courier's tracking number as a status update. The user does not want the tracking number. They want Thursday.

Chasing Without Being Chased

The desk chases the vendor on the promised date, not after the user has asked. The difference is who is running the claim. A chase on the date is a routine check: "claim reference such-and-such, promised for today, where is it?" A chase three days after the user's third message is an apology dressed as a question, and the vendor can hear the difference. Put the promised date on the claim ticket as the thing it is waiting for. Let the sweep surface it on the morning, and make the call before ten.

Each contact with the vendor goes in the chase log with the date, the person spoken to, what they said, and the new date if the old one moved. The log is the claim's memory and the only leverage the desk has when a repair drags. A vendor that has promised three different dates in writing to a desk that has written all three down is a vendor that escalates the claim when asked. A vendor talking to a desk that remembers "someone said next week, I think" is a vendor with time on its side. The escalation path inside a vendor, when the first line has run out of dates, is the subject of the article on escalating to vendors and other teams. The chase log is what that escalation is built from.

Know the vendor's turnaround before you need it, and know it from your own log rather than from their brochure. A desk that keeps the claim tickets can read, once a quarter, how long each vendor actually took from despatch to return. That figure, in working days and in a range, is the one that sets the loaner's return date and the one that goes into the spares sum in The Loaner and Spares Strategy. Acme's log, when Sofia eventually built it, said eight to fourteen working days for the main vendor's collect-and-return against a promised five. That was not a surprise to anyone who had used the service and was news to everyone who had bought it. Vendor turnaround figures are optimistic documents. The log is not.

The No-Fault-Found Return

A no-fault-found return is a machine that comes back unrepaired with a note saying the vendor could not reproduce the problem. It is the most frustrating outcome a claim has. The fault is still there and the user has waited a fortnight to be told it is not. It happens for three reasons. Either the fault is intermittent and did not show in the vendor's ten minutes. Or the fault description was too thin to point the engineer at it. Or the fault depends on something at the user's desk that did not travel in the box. The first two are the desk's to prevent, and the third is the desk's to catch before the machine ever goes.

The response to a no-fault-found is not to argue with the vendor. It is to reproduce the fault again, at the bench, with the conditions written down, and to send the machine back with the reproduction attached. An intermittent fault gets the diary from Common Faults by Symptom for a week on the user's desk. The diary goes in the box, with a note asking for the machine to be run under those conditions for longer than ten minutes. A fault that the desk can show on video, with the lid at the angle and the flicker visible, is a fault the vendor will not return twice. The second despatch references the first claim, so that the vendor's own record shows the pattern.

A second no-fault-found on the same machine is a decision, not a third attempt. The fault may depend on the user's surroundings. In that case, the dock, the cables and the desk are the suspects and the laptop is innocent. Or the fault is real and the vendor cannot find it. In that case, the machine is swapped from the pool and the user is sorted. The machine itself is then either kept as a bench curiosity or argued over with the vendor at the desk's leisure. What does not happen is a third fortnight of the user on a loaner for a repair that has failed twice. The user's time has already paid for this machine's diagnosis several times over.

Keeping the User Informed While the Box Is Away

The user is told three things at the moment the machine leaves. Tell them the date the desk expects it back, and that the desk will update them on that date whether or not there is news. Also tell them what to do about anything on the machine they need meanwhile. After that, the user hears from the desk on a cadence the desk chooses and keeps, and never has to ask. The craft of an honest estimate, and of the update that goes out when the estimate moves, is the subject of When the Fix Is Weeks Away. Vendor repairs are its commonest case on a small desk.

The cadence that works is one message at despatch, one on the promised date with the truth, and one whenever the date moves, with the new date and one sentence of why. "The vendor has moved the return to next Thursday because the part is on back order; your loaner stays with you until then, and I will update you on Thursday either way." Three sentences, no apology beyond the facts, and a date the user can plan around. The message that loses users is the one that does not come. Having heard nothing for a week, the user writes "any news?" and discovers that the desk has none and had not noticed.

Tell the user the truth about the no-fault-found too, in plain words, with what happens next. "The vendor could not reproduce the fault in their test and have returned it; I have reproduced it here and it is going back with a recording of the fault and a request for a longer test. You keep the loaner." A user who hears that trusts the desk more, not less, because the desk is visibly running the claim rather than relaying the vendor's verdict. (The vendor's verdict was "works for us", which has never comforted anyone.)

When It Comes Back

A returned machine is tested before it goes near the user. The test is the original reproduction. Whatever made it fail before is tried again, under the same conditions, and then once more the next morning. The vendor's repair note says what was replaced; the test says whether the fault is gone, and the two are not the same thing. A machine that passes is re-imaged if the vendor touched the drive, or if the desk's standard says every returned machine is re-imaged regardless. The latter is the simpler rule and the safer one. The photographs from despatch are compared with the machine on the bench. Any difference goes in the claim ticket the same day, with its own photographs, while the vendor's record of the return is still warm.

Then the user is moved back and the loaner comes home. The claim ticket closes with the repair recorded against the device: what failed, what was replaced, when, under which claim reference. That record is the device's history. It is what the lemon rule in the decision table reads when the same machine fails again. A repair that is not written against the device is a strike that nobody can count. The user's ticket, if it is still open, closes with the plain resolution. The user is asked to reply if the fault returns. A returning fault after a vendor repair is the clearest signal there is that the repair treated the wrong part.

A Short War Story: The Box at Pinecrest Dental

At Pinecrest Dental, a practice with two sites and one technician called Hana, a reception laptop went to the vendor with a cracked hinge in a box labelled by hand. There was no claim reference in the ticket because the vendor's web form had produced one on a screen Hana had closed. There was no tracking number because the courier's label had been stuck to the box and the box was now in a van. The vendor had the machine for five weeks. For the first two, nobody chased because the ticket had no date on it. For the next two, Hana chased by phone and was asked each time for a reference she did not have and a serial number that was inside the box. In the fifth week, the vendor returned the machine no-fault-found. The hinge, in the engineer's view, "operated within tolerance". The receptionist had been sharing a colleague's machine across the front desk for twenty-five working days. Meanwhile, the receptionist had missed enough appointment confirmations that the practice counted about forty hours of rebooking and chasing. Hana photographed the hinge at the angle where it crunched. She sent it back under a new claim with the photographs, the reference, and a tracking number written in the ticket before the box left the building. She had it back repaired in nine working days. A claim is a set of references with a date on it. A box without them is simply a laptop somebody else has.

The Vendor Claim Note

The note below is the claim ticket's first entry, filled in before the box is sealed and updated at each contact. It is written so that a technician who has never seen the machine or spoken to the vendor can pick the claim up from it alone. Section A is the evidence that earns the vendor's attention. B is the four things without which no claim has been logged. C is the despatch record that protects both sides. D is the chase log, one line per contact. E is the return check that closes the claim. Keep it joke-free and keep it in the ticket, not in a drawer.

VENDOR CLAIM NOTE — ONE PER MACHINE, LIVES ON THE CLAIM TICKET
Claim ticket: ________   Linked to user ticket: ________   Device tag: ________
Serial / service tag: ________________   Warranty ends: __________   Covered: Y / N / quote needed

A. EVIDENCE (before logging)
   Fault, reproducible: __________________________________________________
   Conditions (bare machine, clean image, mains/battery, docked?): ________________
   Rungs cleared (from the diagnostic card): 1 [ ] 2 [ ] 3 [ ] 4 [ ] 5 [ ]
   Maker's diagnostic run: Y / N   Code or result: ____________   Photo attached: [ ]
   Intermittent? Y / N   Diary attached: [ ]   Video attached: [ ]

B. THE CLAIM (none of these blank = no claim)
   Logged via: web form / phone / account manager   On: __________ by: ______________
   Claim reference: ______________   Accepted by (name or id): ______________
   Service type: collect and return / on-site / carry-in
   Promised: ______________ (what will happen) by: __________ (date)
   Quotation needed? Y / N   Quote received: __________   Decision: accept / decline / dispose
   Decided by: ______________ under rule: ______________

C. DESPATCH
   Data decision applied: encrypted / drive removed / wiped   Done by: ______________
   Photographs (all sides, screen on): [ ]   Accessories sent: charger Y / N  other: ________
   Courier / tracking: ______________   Sent on: __________   Return address: ______________
   Loaner issued to user: tag ______  due back __________ (see loaner log)

D. CHASE LOG (one line per contact)
   Date       Spoke to            They said                                New date
   ________   _________________   ______________________________________   ________
   ________   _________________   ______________________________________   ________
   ________   _________________   ______________________________________   ________
   User updated on: ________  ________  ________  (at despatch, on the date, on every change)

E. RETURN
   Received: __________   Repair note says: ______________________________
   Condition matches despatch photos: Y / N   (if N: photos and note to vendor same day)
   Original fault reproduced after repair: N / Y   Re-tested next morning: [ ]
   Re-imaged: [ ]   User moved back: __________   Loaner returned: [ ]
   Repair written against the device history: [ ]   Outcome: repaired / no fault found / swapped

Sofia got through to the vendor at 10:41 and, lacking a reference, gave them Acme's account name and the approximate date. The machine was found on a shelf awaiting a part that had been on back order for a fortnight. Nobody at the vendor had told anybody because nobody at Acme had been named as the contact. Sofia wrote the reference, the new date and the engineer's name into the ticket in a note. She told Malik the truth in a public reply with the Thursday in it, and had the machine back the following week. The claim note went into the knowledge base the same afternoon, next to the diagnostic card. The next machine that left the building did so with a reference in the ticket before the tape was on the box. Malik kept the loaner nine working days longer than he should have, which Sofia also wrote down. Everything gets written down now.

Frequently Asked Questions