Swap, Repair or Retire: The Decision Rules

Thursday, 14:40, at Stonebridge Insurance. Nadia has a laptop on the bench with a screen that flickers whenever the lid passes a certain angle. She has cleared the cheap rungs: it does it bare, it does it on a clean image, and it does it with the external screen unplugged. It is the display cable or the panel, which on this model means the same job. Carl, the underwriter it belongs to, is on a loaner and has already asked twice whether he can have his own machine back. That is because the loaner "feels different". Carl's manager has sent a one-line message: "Can't we just fix it rather than buying another one?" Nadia can fix it. She can also swap it, or retire it. What she does not have is a rule that tells her which. So she is about to decide by feel, and feel is what everyone in the building has an opinion about.

Swap, repair or retire are the three things a desk can do with a machine that has a confirmed hardware fault. A swap means the user gets a different machine from the pool and keeps it. A repair means the faulty machine is mended and returned to the user. To retire means the machine leaves the fleet for good and the user's replacement comes from the next refresh rather than the spares. The decision between them is made with two numbers, hours and age. It is never made with the one everybody reaches for first, which is the price of the part. This article is part of our Hardware Troubleshooting Workflows series. And it is about turning that decision into rules a technician can apply at a quarter to three on a Thursday without calling a meeting.

It covers the three words and what each one costs and why the user's downtime is the real cost. Next comes the rule that a working machine goes in front of the user before anything is decided. Then we cover the warranty path, the age at which repair stops making sense, and the repeat offender. We include a worked example from a fictional desk, recording the decision, a short war story, and the decision table to copy, in that order.

The Three Words and What Each Costs

Each of the three options costs something different. And the costs are in hours rather than money, because hours are what the desk controls and what the user actually loses. A swap costs the desk the time to issue a pool machine and move the user onto it. On a well-imaged fleet, that is under an hour. A swap also costs the pool one machine until the faulty one is mended or replaced. A repair costs technician time, the wait for a part, and a second move if the user was on a loaner meanwhile. A retirement costs the paperwork of taking a machine out of the fleet and the pull-forward of a refresh that was going to happen anyway. None of those is free, and the cheapest one depends on the machine's age, its warranty, and how long the user would otherwise be waiting.

The word people reach for is "repair" because it feels thrifty, and it often is not. Carl's manager is picturing the cost of a new laptop against the cost of a screen cable. That is the right comparison if the only cost is the part. It is the wrong comparison the moment you add Nadia's two hours and the four working days for the cable to arrive. Add the second hour to move Carl back off the loaner. Then add the fact that the machine is three years into a four-year life. It will be retired in nine months whatever happens to its screen. Thrift that ignores hours is not thrift; it is a feeling about money with a clock running behind it.

The opposite mistake is the desk that swaps everything because swapping is quick, and runs its spare pool dry by the second week of the quarter. A pool of loaners is a shared resource, and every swap that could have been a one-hour repair while the user waited is a loaner that is not on the shelf when the next machine dies. The rules below exist to keep both mistakes out of the building. Repair when repair is quick and the machine is young. Swap when the user would otherwise wait. Retire when the machine is old or has proved itself a lemon. (The lemon rule, as you will see, is the one managers argue with and the one that saves the most hours.)

The User's Downtime Is the Real Cost

The number that decides most of these cases is how many hours the user cannot do their job. And it is the number most desks forget to write down. A technician hour is visible because the technician is on the payroll of the desk. A user hour is invisible to the desk because it lands on another department's budget, and that is exactly why it gets ignored. Carl without a working machine is an underwriter who is not underwriting. Four working days of that is thirty-odd hours of a skilled person's work not done, against two hours of Nadia's. The economics of waiting are the subject of The Cost of Waiting. This article leans on that arithmetic rather than repeating it. Here it is enough to say that the user's hours go in the ledger first and largest.

Downtime has a second component that is easy to miss, which is the time the user spends getting a replacement machine to feel like their own. A swap or a loaner costs the user an hour or two of signing back in, finding the printer, reinstalling the one tool nobody standardised, and discovering that their browser bookmarks lived on the old machine. On a well-managed fleet where settings follow the account and documents live on the file service, that cost is small. On a fleet where every machine is a snowflake, it is half a day. That cost is paid twice if the user goes onto a loaner and then back. The desk that reduces this cost reduces every decision in this article, which is one of the arguments for standards in Reducing Hardware Tickets.

Put both numbers in the ticket before the decision: hours the user would wait under each option, and hours of re-setup under each option. They are estimates, in ranges, and that is fine. "Repair: user waits four to six working days without a loaner, or two re-setups with one. Swap: user waits one hour, one re-setup." Written that way, the decision usually makes itself. When it does not, the written numbers are what you show the manager who asked whether you could just fix it.

Rule One: A Working Machine First, Then the Decision

The first rule is that the user has a working machine in their hands before the swap-repair-retire decision is made at all. The rule exists because the decision is made badly under the pressure of a user who is waiting. Once Carl is on a loaner, his machine can sit on the bench for a day while the part is priced in hours and the age is checked. In that case, nobody is harmed. While Carl is standing at the desk, the decision is "whatever gets him away from the desk". That is how machines get repaired that should have been retired and swapped that should have been repaired. The working machine buys the decision time, and the decision is worth an hour of thinking.

This rule is why the diagnostic ladder in The Diagnostic Order puts the loaner before rung four: everything above the cheap rungs is done with the user elsewhere. It is also why the loaner pool matters more than any other hardware investment the desk makes. And the sizing of that pool is the next article in this series. A desk with no loaners cannot follow rule one and will make every decision in a hurry, in front of the user, with the user's manager on the phone. The rule is cheap to state and expensive to follow without spares. State it anyway, and let the gap make the case.

The working machine is a loaner, not a swap, until the decision is made, and the difference matters. A loaner is issued with a return date and logged; a swap is permanent and the faulty machine's fate is already settled. Issuing the machine as a loaner keeps the decision open, keeps the pool's accounting honest, and lets the desk change its mind when the vendor says the part is six weeks away. Many desks blur the two. The blur is how a "loaner" becomes the user's machine for three years while the mended original sits in a cupboard. I have seen that more than once and once caused it.

Rule Two: The Warranty Path Decides Repair

If the machine is under warranty, the repair is the vendor's problem and the only decision is how the user is covered while it is away. A warranty repair costs the desk the hours to log the claim, pack the box and chase. And the detail of that is in Working With Warranty and Repair Vendors. A warranty repair does not cost a part and it rarely costs more than two or three technician hours spread over the claim. A machine under warranty is therefore repaired, nearly always, with the user on a loaner for the duration. And the exceptions are the ones the warranty does not cover: the dropped machine, the drink, the screen cracked in a bag. The vendor will quote for these as chargeable repairs. They then fall under the age rules below.

Knowing whether the machine is under warranty is the whole of this rule, and it is surprising how many desks cannot answer in under ten minutes. The warranty end date belongs on the ticket, next to the device tag, from the moment the fault is confirmed. Where it lives and how to keep it findable is the subject of Warranty and History at a Glance. A desk that has to look up a serial number on a vendor's site every time will skip the lookup when it is busy. Skipping it means paying in hours for a repair the vendor would have done for the price of a courier.

The warranty's last months deserve a note of their own. A machine that fails a month before its warranty ends is repaired under warranty and then enters its final year with a new part. A machine that fails a month after is a chargeable repair on a machine that is, by definition, past the age where the vendor thought it worth covering. The same fault on the same model, a few weeks apart, can land on different sides of the table, and that is not inconsistency. It is the warranty doing what warranties do, and the rule simply reads the date.

Rule Three: Age Sets the Ceiling on Repair Hours

The third rule is that the older the machine, the fewer hours the desk will spend repairing it, down to zero at the point where it is retired instead. The reasoning is plain: a repair buys the machine the rest of its working life. The rest of a young machine's life is long while the rest of an old one's is short. Two hours and a part on a machine with three years ahead of it is a good trade. The same two hours and the same part on a machine with four months ahead of it buys four months. The desk will spend the hours again at the refresh anyway. The rule puts a ceiling on repair hours that falls as the machine ages.

The ceiling is the desk's to set, and here is how one fictional desk sets it, on a fleet refreshed every four years. In the first year, every fault is a warranty repair with no ceiling, because the vendor is doing the work. In years two and three, out-of-warranty repair is allowed up to a ceiling of four technician hours including the wait for a part, provided the part arrives within a week. Above that, the machine is swapped from the pool and the faulty one is assessed at leisure for repair as a future spare. In the final year, nothing is repaired that takes more than an hour and a part from the drawer. Anything else retires the machine and pulls its refresh forward. The ranges are that desk's, chosen to fit its pool and its refresh. Yours may be stricter or looser, and the point is that they are written. That way, Nadia does not have to invent them at a quarter to three.

Age is read from the date the machine entered service, not from the date it was bought, and not from how it looks. A machine that sat in a cupboard for eight months before issue is eight months younger than its invoice. A machine that has been dropped twice looks older than its date. The date lives with the device tag on the ticket, alongside the warranty end. And the two together answer most of this rule in thirty seconds. The refresh cycle that sets the age bands is designed in Reducing Hardware Tickets; the decision rule here only reads it.

Rule Four: The Repeat Offender Retires Early

A machine on its third hardware ticket in a year is retired at the next confirmed fault regardless of its age. That is because a machine that keeps failing is costing hours every time it does. The repair that fixes the current fault has a poor record of fixing the next one. This is the rule managers argue with, because the machine is young and the part is cheap. It is also the rule that saves the most hours, because every repeat ticket costs the user a day and the desk an afternoon. The pattern does not stop on its own. Three strikes is the fictional desk's number. Pick yours and write it down. Read it from the machine's ticket history rather than from memory, because memory is kind to machines that have been around a while.

The repeat offender is sometimes one machine and sometimes a whole model, and the difference changes what the desk does next. One machine that keeps failing is a lemon, and it retires. A model where a third of the fleet has had the same fault is a model hotspot. And it changes the standard, the spares, and the conversation with the vendor. The analysis that tells the two apart, by cutting the hardware tickets by model and fault, is in Device and Model Hotspots. And this article does not redo it. The desk's job at the decision point is only to count this machine's strikes and look up whether its model is already on the list.

Retiring a lemon early is where the ledger has to be shown, because the objection is always about the part and the answer is always about the hours. "It only needs a new keyboard" is true; "it has needed a new keyboard, a new battery and a new screen in eleven months, and each time the user lost a day" is also true. The second sentence is the one with the arithmetic in it. Write the hours each strike cost, user and desk, in the retirement note. Then nobody has to argue, which on a Thursday afternoon is worth a great deal.

A Worked Example From a Fictional Desk

Here is Carl's laptop at Stonebridge Insurance put through the rules, with the hours written as the desk would write them. The machine is three years and three months into a four-year cycle, so it is in its final year. The warranty ended at three years. The fault is a confirmed display cable or panel, which is a bench repair of about two technician hours once the part arrives. The part is four to six working days away. It is the machine's first hardware ticket, so rule four does not bite. Rule one is already satisfied: Carl is on a loaner. The ledger below is what each option costs in hours, user and desk. And it is a table of estimates in ranges, not a quotation.

Read across and the decision is the bottom row. Carl keeps the loaner for a day or two while a machine from the next refresh batch is imaged. He moves once, and the flickering laptop leaves the fleet with a note that says why. The part was never the question. Nine months of remaining life, two bench hours and a week's wait were the question. Once they were in a table the manager's "can't we just fix it" answered itself. He agreed in one message. The table had done the arguing.

Change one fact and the row changes, which is the test of a rule. If Carl's machine were eighteen months old, the second row would win: repair under the ceiling, with the loaner covering the wait. If it were eleven months old, the warranty would cover it and the only decision would be the loaner. If it were the machine's third fault, the bottom row would win at any age. The rules are not a flowchart that always lands in the same place. They are four questions whose answers land in different places for different machines, and the table is where the answers are seen together.

Recording the Decision

The decision goes in the ticket with its reasons in one short note. That is because the question "why did we replace that laptop?" will be asked in three months by someone who was not there. The answer "Nadia thought it was best" will not satisfy them. The note has four lines. The first is the confirmed fault and how it was confirmed. The second is the machine's age, warranty state and strike count. The third is the hours under each option, in ranges. The fourth is the decision with the rule it followed. It takes five minutes to write and it ends every later argument before it starts. That is a return on five minutes that few other notes can claim.

A hardware decision usually spawns more than one piece of work, and the ticket should show that without becoming a tangle. The user's original ticket is about the user: the fault, the loaner, the resolution. The repair of the old machine, the vendor claim, and the retirement paperwork are each a job with its own clock. Each one is a separate ticket linked to the user's. That way, the user's ticket can close when the user has a working machine while the vendor's ticket waits on the vendor. If you run QuerySolv, linking those tickets to the user's original keeps the whole story on one thread while each job keeps its own owner and its own waiting state. With those linked tickets, the user never sees the courier's reference number in their own updates. In any tool, the principle is the same: one ticket per thing that can finish on its own.

A Short War Story: The Keyboard at Ashgrove Housing

At Ashgrove Housing, a technician called Dev was asked by a housing officer called Ruth to fix the keyboard on her laptop. The keyboard had lost its space bar. Dev had been told by his manager that the desk was over budget on hardware. He ordered the keyboard and kept Ruth waiting on her own machine with an external keyboard plugged in. She carried it between the office and the tenant visits for nine working days until the part came. The same laptop came back six weeks later with a battery that would not hold a charge, then eleven weeks after that with a hinge that had cracked. And each time Dev repaired it, each time Ruth waited, and each time the manager approved the part because the part was cheap. When Dev finally added up the ticket history for a quarterly review, the machine had cost about nine technician hours and about thirty of Ruth's working hours across the year. That was against the single hour a swap from the pool would have cost in the first week. The laptop was retired the following Monday to nobody's surprise except the manager's. Dev wrote the three-strikes rule into the desk's hardware standard that afternoon. The part is never the cost; the hours around it are, and nobody counts them until somebody does.

The Swap-Repair-Retire Decision Table

The table below is the rule set, filled in with one fictional desk's numbers so that you can see the shape. It is meant to be copied with your own numbers in the right-hand column. The rows are read top to bottom: the first row that matches the machine decides. And the strike rule sits at the top because it overrides age. Set the numbers once, with the desk lead and whoever owns the hardware budget in the room. Write them into the knowledge base beside the diagnostic order card. The technician at the bench then reads a row instead of making a case.

Nadia filled in the table for Carl's machine in about four minutes, with the hours from the worked example in the note. She sent the manager one line: "Final-year machine, first fault, two bench hours and a week's wait for a part against a refresh due in nine months; retiring it and bringing the refresh forward, Carl keeps the loaner until Monday." The reply was "fine". Carl got a machine from the refresh batch on the Monday, moved once, and stopped mentioning that the loaner felt different, because he no longer had it. The flickering laptop went into the retirement cupboard with a note on the tag saying which rule had sent it there. That is more than most laptops get.

Frequently Asked Questions