The Loaner and Spares Strategy for a Small Desk

Tuesday, 08:50, at Bellweather Logistics. Jonah has two dead laptops on the bench, one belonging to a dispatcher and one to the transport planner. Both users are standing in the corridor outside the desk pretending not to look in. Bellweather owns one loaner. It is with Priti in finance, who borrowed it eleven weeks ago when her own machine went for a screen. Her own machine came back eight weeks ago and has been sitting, mended, in the cupboard behind Jonah. Nobody asked for the loaner back and Priti had got used to it. Jonah has a mended laptop he cannot issue because it is Priti's, and a loaner he cannot issue because Priti has it. He has two users who need a machine before the morning's routes go out. He is about to learn that a loaner pool is not a number of machines. It is a number of machines on the shelf.

A spare is a machine the desk keeps imaged and ready so that a user whose machine has failed can be working again within the hour. A loaner is a spare that has been issued to a user with a date for its return. The two words describe the same machine at different moments, and the whole of a spares strategy is keeping enough of them in the first state. This article is part of our Hardware Troubleshooting Workflows series. It exists because every other article in the series says "put a working machine in front of the user first". This is the one that says where that machine comes from.

It covers why spares are the price of fast resolution, and how many a fleet needs, as a worked example in ranges. Then come what "imaged and ready" has to mean, the loaner log, and chasing loaners back. It covers where spares come from without a budget line, and making the case in hours. It ends with a short war story and the loaner log and spares plan to copy, in that order.

Spares Are the Price of Fast Resolution

A hardware ticket is resolved, from the user's point of view, at the moment they have a working machine. Nothing the desk does to the broken one changes that moment. The repair can take a week; the vendor can take three; the retirement can wait for the next refresh batch. None of it matters to the dispatcher if she is working on a loaner by nine. The spare is what separates the user's resolution from the machine's. Once the two are separated, every hardware decision in Swap, Repair or Retire can be made calmly at the bench instead of in a corridor.

A desk without spares, by contrast, is a desk where every hardware fault costs the user the whole repair time. There, the technician diagnoses under pressure with the user watching. The ladder gets skipped. Parts get swapped on hunches because a hunch is faster than a method when somebody is waiting. The repair that should have been a warranty claim is done at the bench because the vendor's week is unthinkable. Every one of those is a cost in hours, user and desk. The spares budget is the cheapest thing the desk will ever buy to remove them. I have run a desk with no spares and a desk with six, and the second one was a different job. The faults were the same. The corridor was empty.

The strategy has three parts and the first is the one people skip. The number of spares matters, but a spare that needs two hours of setup before it can be issued is not a spare. It is a project. A spare that is out with a user for eleven weeks is not a spare either. Imaged and ready, logged out with a return date, and chased back: those three habits make four machines do the work of eight. Without them eight machines do the work of two.

How Many Spares: A Worked Example

The number of spares a fleet needs is the number of machines that will be away at the same time on an ordinary week, plus a margin for a bad one. It can be estimated from two figures the desk already has. The first is how many hardware faults a month take a machine out of a user's hands. Count them from the ticket history, by the method in the volume-analysis series rather than from memory. The second is how long each machine is away on average. That runs from the day the fault is confirmed to the day the user is back on a permanent machine. It is also in the ticket history if the tickets were closed honestly.

Here is Bellweather Logistics put through it, with its numbers stated as a fictional desk's rather than anyone's benchmark. The fleet is 160 laptops and 40 desktops. Over the last six months the desk logged between six and nine faults a month that took a machine away. So call it seven or eight in a typical month and twelve in the worst one. Warranty repairs took five to eight working days door to door; bench repairs took two to four; replacement from stock took two to three while a machine was imaged. Weighted by how often each happened, the average time away was a little over one working week. Machines away at once is faults per week multiplied by weeks away. Seven or eight faults a month is roughly two a week. Two a week times a week and a bit away is two to three machines out at any moment on an ordinary week. In the bad month it was three a week, so four to five out. The table below lays the arithmetic out so that it can be copied with your own figures in the right-hand column.

The range that falls out of this for an office fleet is somewhere between two and four spares per hundred machines. The honest thing to say about that range is that it is Bellweather's and that yours moves with three things. Older fleets fail more, so the fault count rises in the last year before a refresh. Slower vendors stretch the time away, so a desk whose warranty turnaround is three weeks needs roughly twice the pool of one whose turnaround is one. And remote workers, whose machine must be shipped both ways, add days at each end. A desk with half its users at home sizes the pool from the shipping time. The routine for that is in Shipping and Swapping Hardware. Do the sum with your own figures, write the answer on the spares plan, and redo it when the fleet changes.

Two small adjustments finish the sum. Hold at least one spare of each kind the fleet actually uses. A pool of six standard laptops is no help to the one department on a different model with a different dock. The fewer models in the fleet, the smaller the pool, which is one more argument for standards. And hold one spare more than the sum says, because the sum assumes every loaner comes back on time. The next sections are about why it does not.

Imaged and Ready, or Not Spares at All

A spare is ready when a user can be signed in and working on it within the hour of the fault being confirmed. The test is whether the technician has to do anything to it beyond opening the lid. That means it carries the standard image with the standard applications. It has had its updates applied within the last month, and it has a charger and a bag. It is labelled with a pool tag that the log can refer to. It is sitting on the shelf, charged. A spare that is missing its charger, or that needs an hour of updates before it can safely join the network, fails the test. So does a spare that was last imaged before the current standard. A pool of six that fails the test is a pool of none on the morning that matters.

Readiness is a routine, not a state, and the routine is a monthly half hour. Take each spare off the shelf, power it on, and apply whatever updates have accumulated. Confirm the sign-in works and check the charger and bag are with it. Note the date on its tag and put it back. On a pool of six that is a morning a month, and it is the morning that makes the other twenty-nine work. The desk that skips it finds out which spare was broken on the day two users are waiting in the corridor. That is also the day it has least time to find out.

Readiness extends to the user's side of the hour. A spare is ready to issue. The user is ready to receive it only if their documents live somewhere other than the old machine's disk and their settings follow their account. On a fleet where that is true, moving a user onto a loaner is twenty minutes of signing in. On a fleet where it is not, it is half a day and a worried question about the files on the desktop. The loaner pool cannot fix that. Standards can, which is the subject of Reducing Hardware Tickets. A spare pool and a standard image are the same project seen from two ends.

The Loaner Log

The loaner log is the record of which spare is with whom, since when, why, and when it is due back. It is the difference between a pool and a rumour. It has one line per issue: the pool tag, the user, the date out, and the reason (the ticket number of the fault that caused it). That line also holds the agreed return date, the date it actually came back, and its condition on return. These are seven columns, filled in at the moment of issue and the moment of return, in whatever the desk has. That can be a spreadsheet, a page in the knowledge base, or the ticket itself. What matters is that the log exists in one place and that nobody issues a loaner without a line in it.

The return date is the column that does the work, and it is set from the fault, not from the user's convenience. A warranty repair at this vendor takes five to eight working days, so the loaner is due back in two weeks. A swap decision means the loaner becomes permanent and the log says so. A retirement means the loaner is due back the day the replacement is imaged. Tell the user the date when the machine is handed over, in a sentence, and write it on a card in the bag. The user will forget and the card will not. A loaner issued without a return date is a gift. The user will treat it as one, as Priti did, in good faith, for eleven weeks.

Many desks keep the log inside the ticketing tool rather than beside it, and the method is simple. The loaner issue is a ticket of its own, linked to the fault ticket, with the return date as the thing it is waiting for. It stays open until the machine is back on the shelf. The pool is then visible as a filter on open loaner tickets. The overdue ones are the stale ones. The chase in the next section is an ordinary follow-up rather than a separate chore. If you run QuerySolv, the loaner ticket linked to the fault ticket keeps the two stories together. That link lets the fault close when the user is sorted and the loaner stay open until the machine is home. Any tool that links tickets will do the same; a spreadsheet will do it with more typing.

Chasing Loaners Back

Loaners do not come back on their own, and the reason is not carelessness but comfort. A user who has been on a machine for two weeks has settled into it. The mended original now feels like the strange one. The handover back is a small chore with no deadline that nobody has mentioned since the day of issue. The desk that waits for the user to return a loaner waits a long time. The chase is the desk's job. It starts on the return date, and it is kinder to everyone if it is routine rather than personal.

The cadence is three touches. On the return date, a message: the original is ready, here is when and where to swap back, it takes twenty minutes. Three working days later, if nothing has happened, a second message that proposes a specific time and copies nobody. A week after the return date, send a third message that copies the user's manager, not as a complaint but as information. The pool is a shared resource and the manager's other staff are the ones who will be in the corridor next. The wording that gets a reply rather than a sigh is the subject of Follow-Up Messages That Get Replies. The loaner chase is the same craft: specific, short, with the next step and the time in it.

Two situations need their own rule. A user who leaves the organisation while holding a loaner is an offboarding problem. The equipment return in that process should list the pool tag beside the user's own machine. The routine is in Getting the Equipment Back. The loaner log is where the offboarding checklist finds out the loaner exists. And a user who asks to keep the loaner permanently, because it is newer or lighter or simply theirs now, gets a plain answer. The pool machine goes back. If the user's own machine is genuinely worse, that is a refresh question for their manager, not a loan that forgot to end. Loaners that quietly become permanent are how a pool of six becomes a pool of two with six on the books.

Where Spares Come From

The pool does not have to be bought in one go, and on most desks it is not. It is assembled from three sources over a year. The first is the refresh. When a batch of new machines is issued, the best of the machines they replace are wiped, re-imaged and shelved as spares rather than disposed of. Those are the ones with a year or so of life left and a clean history. They will not last as long as new ones, but a one-year-old spare on the shelf beats a new one on order. The second is the leavers. A machine returned by someone leaving goes into the pool rather than to the next starter by default, if it is on the standard model and under the final-year threshold. The next starter then gets a new one from the batch. The third is the small deliberate purchase, one or two extra machines added to every refresh order. Nobody notices it on the order, and it replaces the pool's oldest members each cycle.

The pool has to be tracked like stock, because it is stock. It shares its habits with every other thing the desk keeps on a shelf. It is counted, has a minimum below which the desk reorders or pulls from the refresh, and is checked for condition. The counting method for a small desk's stock, from chargers to docks, is in Stock Management for a Small Desk. The laptop pool is simply the most valuable line on that sheet. Spares that are not counted are spares that are quietly borrowed. A borrowed spare with no log line is a loaner the desk does not know it has issued.

Retired machines are not spares, and the line matters. A machine retired under the swap-repair-retire rules left the fleet because it was old or a lemon. Putting it on the spares shelf brings it back as the machine most likely to fail in a user's hands on the day they most need it not to. A retired machine can be a parts donor, labelled as such and kept apart from the pool. It cannot be a loaner. (The spares shelf has standards, even if nobody else in the building has noticed.)

Making the Case in Hours

The case for spares is made in user hours, and the desk already has the evidence in its tickets. Take the last six months of hardware tickets where a machine was away and no loaner was available. For each one write down the working hours between the fault being confirmed and the user being back on a machine. That is the hours the pool would have returned to the business. Bellweather's six months showed nineteen such tickets with an average of about three working days each. That is roughly four hundred and fifty user hours, against a pool of six machines and the half-day a month to keep them ready. The sum is not subtle once it is written down. The way to present it, with the evidence drawn from tickets rather than from the desk's impressions, is in The Tooling Case, which this article leans on for the shape of the request.

Make the case with ranges and with the names of the hours. "Between three hundred and five hundred user hours over six months, most of them in dispatch and finance" is a sentence a budget holder can picture. It names the departments whose staff were in the corridor. "Reduced hardware downtime" is a sentence nobody can picture and nobody funds. Hours are the currency; departments are the faces on it. The pool is the price, stated as machines and as the half-day a month to keep them ready. Ask once, properly, with the table above filled in.

After the pool exists, keep the same figure going as its justification: hours the users would have waited, now not waited. Read it from the loaner log's issue dates and the fault tickets' confirmation dates. It is the only number the pool needs to defend itself at the next budget round. It is also the number that tells you the pool is too small. That happens when the log shows loaners being issued to the second user on a day before the first has returned. The pool's size is not a decision made once. It is a line in the plan, revisited when the log says so.

A Short War Story: The Single Loaner at Harbourview Clinic

At Harbourview Clinic, a desk of two technicians kept one loaner laptop. A technician called Aisha issued it to a practice manager called Gordon when his own machine went to the vendor for a board fault. There was no return date and no log line because the desk had never needed one. Gordon's machine came back in nine days and went into a cupboard. Gordon had by then set the loaner up the way he liked it and nobody raised the subject. The loaner stayed with him for the best part of four months. In that time three clinicians had hardware faults, and none could be given a loaner. Each worked from a shared desktop in the records office for between two and six working days. The practice later costed that at roughly seventy clinical hours of rebooking and delay across the three. The fourth fault was Gordon's loaner, which failed with a disk error on a Monday morning. It reached the desk with four months of his files on it that had never been backed up anywhere else. Loaner machines were not in the backup set. Aisha recovered most of the files over two days and wrote the loaner log that afternoon. Aisha bought two more spares from the next refresh with the seventy hours as the argument. A loaner without a return date is a machine the desk has given away without noticing, and it will come back when it breaks.

The Loaner Log and Spares Plan

The template has two halves. The plan at the top is filled in once a year, or whenever the fleet changes. It records the sum from the worked example with your own figures, and the standard models the pool holds. It also records the monthly readiness routine with a named owner, and the minimum below which the pool is topped up. The log at the bottom is one line per issue, filled in at the desk at the moment the machine changes hands. It is the half that is used every week. Keep both in the knowledge base or in the ticketing tool, in one place that the whole desk can see. Put the return date in the user's hands as well as in the log.

SPARES PLAN — REVIEWED ______________   OWNER: ______________

A. THE SUM
   Fleet size: ______   Faults a month taking a machine away: ______ (worst month: ______)
   Average time away: ______ working days   Machines away at once: ______ (bad week: ______)
   Margin for overdue loaners: ______   SPARES TO HOLD: ______ laptops  ______ desktops
   Models in the pool (one of each the fleet uses): ______________________________
   Minimum on the shelf before top-up: ______   Top-up source: refresh / leavers / order

B. READINESS ROUTINE (monthly, half a day, owner: ______________)
   [ ] every spare powered on, updates applied, sign-in tested
   [ ] charger and bag present, pool tag legible, date written on the tag
   [ ] standard image current; re-image if older than the standard
   [ ] loaners overdue chased (see log); overdue count this month: ______

C. ISSUE RULES
   Loaner in the user's hands within ______ minutes of a confirmed fault
   Return date set from the fault: warranty ______ days / bench ______ days / retire: on replacement
   Return date told to the user and written on the card in the bag
   Chase: on the date; +3 working days; +1 week with the user's manager copied

LOANER LOG
Pool tag | User | Out (date) | Fault ticket | Due back | Returned | Condition / notes
________ | __________ | ________ | ________ | ________ | ________ | ______________________
________ | __________ | ________ | ________ | ________ | ________ | ______________________
________ | __________ | ________ | ________ | ________ | ________ | ______________________
________ | __________ | ________ | ________ | ________ | ________ | ______________________
________ | __________ | ________ | ________ | ________ | ________ | ______________________

Jonah's Tuesday ended better than it began. He walked to finance at nine, collected the loaner from Priti with an apology that was really a request, and handed her back her own mended machine. He had the dispatcher working on the loaner by twenty past. The transport planner worked from the leaver's laptop in the cupboard, re-imaged over lunch, and kept it. By Friday Jonah had the six months of tickets in a table, the sum in the plan, and a request for five spares from the next refresh. The request had the hours beside it. The operations director approved it on the strength of the dispatch department's name appearing in the evidence four times. The log went up the same week. Priti, to her credit, asked what the return date on her next loaner would be before Jonah had finished issuing it.

Frequently Asked Questions