Reducing Hardware Tickets: Standards, Refresh and Lemons

Friday, 15:30, at Castlemead Surveyors. Elena runs a desk of three and has the quarter's hardware tickets on one screen. There are seventy-one of them, across a fleet of a hundred and twenty laptops. That is more than the quarter before and the quarter before that. On the other screen is a message from the head of the field team asking whether the surveyors could have "something lighter". That would make the fleet's tenth laptop model. Elena has a diagnostic ladder on the wall, a spares pool she fought for, and a claim note in the knowledge base. She has used all three well all quarter. What she has not done is make the tickets stop arriving. And seventy-one is the number that tells her the desk has been getting very good at a job it should be getting smaller.

Reducing hardware tickets means changing the fleet and the habits around it so that fewer machines fail in users' hands, rather than getting faster at fixing the ones that do. It rests on four things. These are fewer kinds of machine and a refresh cycle that retires machines before their failing years. They also include the honest retirement of a model that has proved itself a lemon. Finally, there is a short list of handling habits that users will follow if they are told why. This article is part of our Hardware Troubleshooting Workflows series. It is the last one because the first five are about the ticket in front of you. This one is about the tickets that need not arrive.

It covers where hardware tickets come from, then standard models and the refresh cycle as a worked example in hours. Next come the lemon model and handling and care, including the faults a desk can catch before they are tickets. Then come the dock standard, measuring the drop, a short war story and the hardware standard sheet to copy.

Where Hardware Tickets Come From

Before anything is changed, the quarter's hardware tickets are cut four ways. The cuts say which of the four levers to pull first. Cut by model: a fleet of nine models where two of them produce half the tickets has a model problem. Cut by age: tickets that cluster in the oldest third of the fleet have a refresh problem. Cut by fault type: tickets that are mostly cracked screens, broken hinges and frayed charging cables are a handling problem. Tickets that are mostly dock-shaped are a dock problem. Cut by the device the fault was actually in, not the one the user named. A laptop blamed for its dock inflates the model cut and hides the dock one. The method for the cuts is in Volume by Category Over Time. The model cut in particular is the subject of Device and Model Hotspots. This article assumes the cuts have been made and says what to do about each answer.

Elena's seventy-one cut like this. Twenty-six were on two models bought three and four years ago. Between them, those models were a third of the fleet. Eighteen were docks, cables or dock power supplies and had been logged as laptop tickets by the user. Eleven were screens, hinges and charging ports on the field team's machines, which travel in car boots. The rest were the ordinary scatter of batteries, drives and keyboards that any fleet produces. Four levers, four numbers, and a Friday afternoon's reading. The cuts do not fix anything. They say where the fixing goes.

The cut needs the device on the ticket to work. That is the one piece of hardware discipline this series keeps coming back to. A ticket with a device tag and a model can be cut. A ticket that says "my laptop" cannot. And a desk that cannot cut its tickets cannot reduce them except by guessing. Most small-team help desks have no inventory module. A field on the ticket form that carries the tag is enough. The thread of linking a device to its tickets without an asset system is in the asset-data series. Put the tag on the form. Everything in this article depends on it.

Standard Models: Fewer Kinds, Fewer Tickets

A fleet with two or three models produces fewer tickets than a fleet with nine. The reasons are mechanical rather than mysterious. Fewer models means the desk knows each one's faults and first checks by heart. So diagnosis is faster and parts are swapped less often on guesswork. It means the spares pool can be small, because one spare covers everyone. The sum in The Loaner and Spares Strategy gets smaller with each model removed. It means one image, one dock, one charger, one set of drivers to keep current, and one vendor relationship to run. And it means the lemon shows itself quickly. A model that is a third of the fleet reveals its fault pattern in a quarter rather than hiding in a scatter of five machines each.

The standard is two or three models, chosen by role rather than by preference. There is an ordinary office machine for most people, and a lighter or tougher one for people who travel or work in the field. A more powerful one is for the few whose work needs it. At a surveying firm, that is the people running the mapping software; at an insurer, it is nobody. The roles and the kit that goes with each are designed in Role Profiles and Standard Kits. The hardware standard only names the models each profile gets and refuses to name a fourth. The field team's request for "something lighter" is a request to review the field profile's model, not to add a tenth. That is the answer Elena sent, with a date for the review.

The standard needs an exception route, or it will be broken by the first manager who asks nicely. The route is a request with a reason. It is decided by whoever owns the hardware standard, recorded on a ticket, and reviewed when the model is next chosen. Most exceptions, read in a batch at the review, turn out to be the same need expressed by several people. The standard changes to meet that need. The exceptions that do not reflect a shared need are a single person's preference. They are declined with the reason the standard exists. (The reason is seventy-one tickets. Keep the number to hand.)

The Refresh Cycle as a Worked Example

The refresh cycle is the number of years a machine serves before it is replaced as a matter of routine rather than because it failed. The right length is the one at which the hours spent on an ageing machine's tickets start to exceed the hours a new one would cost to issue. Machines fail more as they age, which nobody disputes. The question is only where the curve turns. A desk can read the curve from its own tickets by cutting them by the machine's age in years. The figures below are Castlemead's, from the age cut of two years of tickets. They are stated as one fictional desk's rather than as anyone's benchmark. The curve depends on the model, the users and how the machines are carried.

Read the table down and the curve is plain. The fourth year costs roughly twice the third and the fifth roughly twice again, in both desk hours and user hours. Castlemead had been refreshing at five years because five was the number somebody had chosen once. A quarter of its fleet was in the fifth year at any time, producing a third of its tickets. Moving the cycle to four years takes the fifth-year machines out of the fleet. The arithmetic in hours, per hundred machines, is the fifth-year row of the table every month. That is somewhere between twenty-four and forty desk hours and between thirty-six and sixty user hours a month. Compare that with the hours to image and issue twenty-five new machines a year. On a standard image, that is one to two hours each. The cycle paid for itself in hours in its first quarter. Whether it paid for itself in money is a question for the budget holder, who should be shown the hours and allowed to do the multiplication.

The refresh is staggered, a quarter of the fleet each year on a four-year cycle, not the whole fleet at once. A fleet refreshed all at once ages all at once and has a terrible fourth year together. A staggered fleet has a flat age mix, a predictable monthly ticket count, and a predictable annual purchase that the budget can see coming. It also has a steady supply of one-year-old machines retiring into the spares pool, which is where most desks' pools come from. The year a machine was issued goes on its tag and on its record. The refresh list for next year is a filter on that date, not a walk round the building.

The cycle is a rule with a pull-forward, not a calendar. A machine in its final year that fails is retired then, under the decision rules in Swap, Repair or Retire. Its refresh is brought forward. A machine in its final year that has not failed serves out the year. The cycle sets the age at which the desk stops investing hours in a machine. The decision table reads that age at the bench. Neither works without the other, which is why the two articles cite each other.

The Lemon Model

A lemon model is a model whose fault rate is out of proportion to its share of the fleet. It is found by the model cut, not by reputation. For example, it could be a model that is a third of the fleet and half of the tickets. Or it could be one that is a tenth of the fleet and a quarter of them. The analysis that confirms it, with the sample sizes that stop a desk calling three bad machines a bad model, is in Device and Model Hotspots. This article does not repeat it. What this article adds is what to do once the hotspot analysis has said "lemon". The analysis ends in a finding and the desk has to end in a decision.

The decision has three parts. The desk stops buying the model, today, and the standard sheet says so. The aim is that the next refresh order does not add to the problem. The desk brings the model's refresh forward, retiring its machines a year early or at their next fault, whichever comes first. A machine of a known lemon model that is in its third year is behaving like a fourth-year machine and should be costed like one. And the desk takes the fault pattern to the vendor, in writing, with the counts. A model with a known weakness often has an extended warranty, a recall or a revised part behind the scenes. The vendor will offer it to a customer who can show the pattern and will not mention it to one who cannot. The claim note from Working With Warranty and Repair Vendors is what the vendor conversation is built from, multiplied by the number of machines.

The lemon conversation inside the organisation is the harder one. The model was chosen by somebody, the somebody may be in the room, and the machines look fine. Lead with the hours: this model has cost the desk this many hours and its users this many over the year against this many for the rest of the fleet, per hundred machines. That makes the comparison fair. Do not lead with the model's name, the vendor's name or anyone's judgement. A model is not a mistake; it is a purchase that turned out worse than the information available at the time suggested. The evidence that it turned out worse is the only thing the meeting needs. Castlemead's two old models were not lemons, as it happened; they were simply old. The field team's current model was, with hinges that failed in the second year in a third of its machines. It took one page of counts to stop buying it.

Handling and Care: The Tickets Users Can Prevent

A share of hardware tickets are caused by how machines are carried, charged and stored. That share can be cut by telling users what breaks and why, once, in plain words, without a trace of blame. Screens crack when a laptop is carried by its lid or packed in a bag with a charger pressed against the glass. Hinges fail when the lid is opened from one corner. Charging ports fail when the cable is pulled out by the lead or left at an angle under strain. Drives fail when a machine is moved while it is running, on the models that still have moving drives. Batteries age fastest when they are kept at full charge in a hot bag, and keyboards die of coffee. None of this is obscure. Nearly none of it is known to the people who do it, because nobody told them.

The telling is a one-page guide, written for users, with a sentence of why beside each habit. The guide is delivered at the moment it will be read: with the machine, on the day it is issued, and again in the knowledge base where the ticket form can point to it. "Carry it closed, by the body, in the padded sleeve" with "the lid is the most expensive part and the easiest to crack" beside it is a sentence people follow, because it respects them enough to explain. If you run QuerySolv, the guide is a knowledge base article visible to everyone, linked from the hardware request form. That way, a user meets the care guide before they meet the desk. In any tool, the test is whether a new starter has read it before the first week is out.

Care extends to the faults a desk can catch before they become tickets. That is the subject of Failing Hardware Signals and is only mentioned here for completeness. A drive reporting errors, a battery reporting a capacity well below its original, a fan running hot at idle: each is readable from the machine before the user notices anything. A desk that reads them once a month replaces the part at a convenient time rather than at the user's worst one. The ticket count falls by exactly the number of faults caught early, and the user hours fall by more. A planned swap costs the user an hour and an unplanned one costs the day.

The field team gets a stronger version of the guide and a padded bag that fits the machine. That is because eleven of Elena's seventy-one were field machines broken in transit. A bag is cheaper than a hinge, and a hinge is cheaper than a screen. The guide for people who carry machines in vehicles says so in those words. It also says that a laptop left in a car on a hot afternoon or a freezing night is a laptop with a shortened battery and a dimmed screen. The field team did not know that and was glad to be told. They had assumed the machines were simply bad. The machines were partly bad. The boots of the cars were the rest.

The Dock Standard

Eighteen of Elena's seventy-one tickets were docks. That is why the dock gets its own section. The cure for dock tickets is a standard as strict as the one for laptops. It calls for one dock model, with one cable, powered by its own supply at the rating it needs. Docks are bought in a batch and each labelled with a tag of its own. A fleet with four dock types has four sets of symptoms, four cables that look alike and are not, and a steady trickle of tickets where the fault is that the wrong one is plugged in. A fleet with one dock type has one set of first checks and a known-good dock on the bench that fits every machine. The monitors, cables and the rest of the desk-side kit are standardised in Standards That End the Monitor Debate. The dock standard is the hardware sheet's half of the same agreement.

The dock standard includes the power, because the dock's power supply is the part that fails most and is noticed least. Use one supply per dock, the dock's own, never a near-match from a drawer. Put a label on the supply with the desk location, and keep a spare supply or two on the bench. A dock supply that is replaced in two minutes is a ticket that never reached the laptop's history. Docks are tagged and faults are logged against the dock's tag, so that the laptop cut stays honest and the dock cut can be read. A desk that logs dock faults against laptops will conclude that its laptops are lemons and its docks are fine, and will retire the wrong thing.

Measuring the Drop

The number that says whether any of this is working is hardware tickets per hundred machines per month, read by model, by age and by device. It is read quarterly against the same figure from the quarter before. Use per hundred machines because the fleet changes size and a raw count would mislead. Use by month because a quarter is enough to see a change and short enough to act on. Use by model and age because the drop should appear where the lever was pulled. A drop that appears somewhere else is either luck or a different cause. The counting method, including how to keep the figure honest when the fleet grows, is in Volume by Category Over Time. The hardware figure is simply one line of it.

The hours go beside the count, because the count is the desk's number and the hours are everyone's. Desk hours per hardware ticket, in a range, and user hours per hardware ticket, in a range, multiplied by the count, give the quarter's hardware cost in hours. The drop in hours is what goes in the report. One line, in the shape the monthly report already uses: "Hardware tickets fell from twenty-four to fifteen per hundred machines a month after the dock standard and the field bags; about ninety desk hours and two hundred user hours a quarter returned." The report's shape, and why one line is the right length, is in The Monthly Report They Will Read. The hardware line is one of the few on it that nobody argues with, because every reader has had a laptop fail.

Expect the first quarter after a change to show less than the second. Standards take a refresh cycle to reach the whole fleet and a care guide takes a few months to reach the people who needed it most. Expect the figure to rise again if the refresh slips, and read a rise as a warning rather than a failure. A fleet that has drifted into its fourth year will say so in the age cut a quarter before the users say so in the queue. The figure is not a scorecard. It is the fleet talking, and the desk that reads it quarterly is the one that hears it first.

A Short War Story: The Nine Models at Harbor Street

At the Harbor Street store, a retail head office with a desk of two, each department head had chosen their own laptops for years. By the time a technician called Priya inherited the desk, that meant nine models across ninety machines and five dock types. The spares cupboard contained one of nothing in particular. The hardware ticket count ran at about thirty a month. Each ticket took Priya an average of three hours because she had to learn the machine before she could mend it. The marketing team's model, a fifth of the fleet, had a charging port that failed in most machines inside two years. The port had been replaced in some of them three times under a warranty that nobody had noticed was about to end. Priya spent a weekend cutting a year of tickets by model, age and device. She took one page of counts to the operations director. She came away with a two-model standard, a dock standard, a four-year staggered refresh and permission to stop buying the marketing model that afternoon. The port pattern went to the vendor with the counts and came back as a free replacement for every remaining machine under warranty. That was all but four. A year later the figure was eleven a month, at under two hours each. The cupboard held three imaged spares that fitted everyone. Nine models had cost the store roughly four hundred desk hours a year over the two it needed. Nobody had chosen them so much as failed to choose.

The Hardware Standard Sheet

The sheet below is the one-page hardware standard. The desk lead and the hardware budget owner fill it in once. It is reviewed once a year or when a model is withdrawn. It is kept in the knowledge base beside the diagnostic card, the decision table and the claim note. Section A names the models and refuses a fourth. B is the dock and the kit. C is the refresh cycle and the pull-forward. D is the lemon rule and what happens when it fires. E is the care guide's delivery. F is the quarterly measurement that tells the desk whether the sheet is working. The right-hand blanks are the desk's own numbers. The sheet is not finished until they are filled.

HARDWARE STANDARD SHEET — ONE PAGE
Owner: ______________   Budget owner: ______________   Reviewed: __________   Next review: __________

A. STANDARD MODELS (no more than three; exceptions by request, reviewed in batch)
   Office profile:    model ______________   warranty ____ years   image ______________
   Field/travel:      model ______________   warranty ____ years   image ______________
   Power user:        model ______________   warranty ____ years   image ______________
   Exception route: request with reason -> decided by ______________ -> recorded on ticket
   Exceptions reviewed at the annual review: [ ]

B. DOCK AND KIT
   One dock model: ______________   own power supply, rating ______   tagged: [ ]
   Spare dock supplies on the bench: ______   Known-good dock on the bench: [ ]
   Dock faults logged against the dock's tag, never the laptop: [ ]
   Bag or sleeve issued with every laptop: [ ]   Field bag for field profile: [ ]

C. REFRESH CYCLE
   Cycle: ____ years, staggered ____ of the fleet per year   Issue year on every tag: [ ]
   Final year begins at ____ years (feeds the swap-repair-retire table)
   Pull-forward: a final-year machine that fails is retired, not repaired: [ ]
   Retiring machines with ____ months of life or more and a clean history go to the spares pool

D. THE LEMON RULE
   A model is reviewed when its share of hardware tickets exceeds its share of the fleet by ______
   over ____ months with at least ____ machines (see the hotspot analysis for sample size)
   When it fires: stop buying today [ ]  bring its refresh forward by ____ year [ ]
                  pattern and counts sent to the vendor in writing [ ]  standard sheet updated [ ]

E. CARE GUIDE
   One page, plain words, a "why" beside every habit; visible to everyone in the knowledge base
   Delivered: with the machine on issue [ ]  linked from the hardware request form [ ]
   Field version with transit and temperature guidance: [ ]

F. MEASUREMENT (quarterly)
   Hardware tickets per hundred machines per month: this quarter ______  last quarter ______
   Cut by: model [ ]  age in years [ ]  fault type [ ]  device actually at fault [ ]
   Desk hours per ticket: ____ to ____   User hours per ticket: ____ to ____
   Hours returned this quarter, in a range: ______ to ______   Report line sent: [ ]

Elena filled the sheet in over the following fortnight. She had the field team's manager in the room for section A and the budget holder in the room for section C. The first thing the sheet did was stop the tenth model before it was ordered. The two old models went into a refresh brought forward a year. The four dock types became one over two quarters, with dock faults logged against docks from the Monday. The field team got bags and the stronger guide. Two quarters later the count was forty-four, then thirty-one. Per hundred machines, that was less than half of where it had started. The report line said so in hours. The desk had not got any faster. It had got smaller, which was the point.

Frequently Asked Questions