Why the Ticket Needs to Know the Device It Is About

Tuesday, 10:40, at Meridian Parts. Ticket 2281 arrives from Jonas in the warehouse office: "Laptop really slow again, can someone look when you get a minute?" Ada opens it, searches the queue by Jonas's name and finds two earlier tickets, both closed with "cleaned up startup items, restarted, user confirmed OK". She does the same again, because it worked twice, and closes 2281 in twenty minutes. The queue does not tell her that the laptop on Jonas's desk belonged to Dana in dispatch until the spring. It does not tell her that Dana raised two "slow" tickets of her own on it. Nor does it tell her that the fan has been audible from the corridor since the summer. The machine has had five tickets in a year under two names. Every one of them was closed as a first.

An asset is any piece of equipment the organisation owns and the desk is expected to keep working. That could be a laptop, a desktop, a monitor, a printer, a barcode scanner, a phone, or a network switch. Asset data is the small set of facts about that equipment that the desk needs to make decisions. Those facts are what it is, who has it, where it lives, how old it is, when the warranty ends, and what has gone wrong with it before. This article is part of our Asset Data Inside Tickets series. It is about why a ticket that knows only the requester is a ticket that cannot answer the three questions every hardware fault raises.

It covers why ticketing tools identify the person and not the machine, then the three questions that need the device, taken one at a time. The repeat that hides because the machine changed hands follows, then the repair-or-swap decision and the arithmetic behind it. Next come which devices deserve a record at all and how to write the device into the ticket before any field exists. A short war story and the device facts list to copy come last, in that order.

The Ticket Knows the Person, Not the Machine

Almost every ticketing tool identifies a ticket by who raised it, because that is how the ticket arrived. An e-mail has a sender, a web form has a logged-in user, a chat has a name at the top. The requester is free, reliable and already on the ticket before anyone reads it. The device is none of those things. It is somewhere under a desk, it has a label the requester has never looked at, and the tool was never told it existed. So the tool files by person, and the technician searches by person. The desk's whole memory of its hardware is indexed by the one thing about hardware that changes most often: who is sitting in front of it.

This works perfectly until the device and the person part company. People change teams and take their laptop. People leave and the laptop goes to a new starter. A spare is lent for a week and kept for a year. A desktop stays at a desk through four occupants. Every one of these moves breaks the link between the ticket history and the machine, silently, because nothing in the ticket ever said which machine it was. The history is still there. It is simply filed under someone who no longer has the problem.

I learned this the way most people do, by being confidently wrong in front of a requester. I told a finance clerk her laptop had "never had a ticket" while standing next to the laptop. It had three, under the name of the man who had retired from her desk the previous year. The tool had not lied. I had asked it about the wrong thing. The device is the stable object in a hardware ticket, and the desk needs a way to ask about it directly.

Question One: Is This the Third Time?

The first question that needs the device is whether this fault has happened before on this machine. The answer changes what the technician should do. A first "slow laptop" gets the standard clean-up. A third "slow laptop" on the same machine in six months is not a software problem that keeps recurring by coincidence. It is a machine with a failing disk, a thermal problem, or something the clean-up never touched. The right move is to stop cleaning and start diagnosing. The same fix applied a third time is a fix the desk has stopped believing in and is applying anyway.

The count matters because it is the cheapest diagnostic the desk has. It costs nothing to collect, it is already in the queue, and it separates the one-off from the pattern better than any single symptom does. The difficulty is that the count is only available if the tickets can be found together. Tickets about one machine under two or three requesters cannot. Searching by requester finds Jonas's two. Searching by the words "slow" finds four hundred. Only a search by the device finds the five that matter.

The question also has a sharper edge, which is that a repeat on the same machine is a different problem from a repeat across many machines. Five slow laptops in five places is a problem with the software everybody runs, and belongs to the method in Finding the Repeat Tickets. Five slow tickets on one laptop is a problem with the laptop. The two look identical in a queue indexed by person and are told apart in seconds once the device is on the ticket.

Question Two: Is It Under Warranty?

The second question is whether the manufacturer will fix this for free. It is the question that decides whether the next step costs an hour or a week. A warranty is the maker's promise to repair or replace a device that fails within a stated period after purchase. That is usually one to five years for business equipment, often with an option to extend. Inside the period, a failed component is a claim: the desk reports the fault with the serial number and a replacement part or a courier arrives. Outside it, the same failure is a purchasing decision, a quote, an approval, and a conversation with the requester about how long they will be without a machine.

The technician needs to know which side of that line the device is on before touching it, for a practical reason. The warranty is tied to the device, not to the fault, and nearly every maker voids it for a device that has been opened by someone else. A technician who swaps a disk in a laptop with eight months of cover left has turned a free repair into a paid one. They have done it with the best of intentions. The check takes a minute if the purchase date or the warranty end date is on the ticket. It takes an afternoon if someone has to find the invoice, and in my experience it takes nobody an afternoon, because nobody has one. The device is opened, the repair is made, and the warranty is remembered at the next failure.

The warranty question also decides what to tell the requester. "It is covered, the part arrives Thursday" and "it is out of cover, I need a quote approved, call it a week" are different conversations. Both are better than "I'll look into it". That is what a technician says when they do not know which conversation they are in. The honest estimate depends on the device fact. The craft of giving an honest estimate is its own subject in this library; the fact that feeds it is the subject here.

Question Three: Who Else Has This Model?

The third question is whether this fault belongs to the device or to the model. It is the one that turns a single ticket into a fleet decision. A model here is the exact make and specification the organisation bought in a batch. Examples are the same laptop ordered forty times for the sales team and the same label printer in every dispatch bay. If one of forty shows a cracked hinge, that is a laptop. If six of forty show the same cracked hinge in the same year, that is a batch, and the other thirty-four are going to crack too. The desk that knows this can plan. The desk that does not will meet the hinge thirty-four more times, each as a surprise.

Answering it needs two facts joined: which model this device is, and which other devices are the same model. Neither is on a ticket that knows only the requester. Both are on a ticket that knows the device, once the device has a row somewhere that names its model. That is the whole point of the inventory sheet in Linking Devices Without an Asset System. With the join made, the question is a filter: show me every ticket on every device of this model, in the last year. The pattern either jumps out or it does not.

The model question is also the one that pays for the whole exercise, because it is the one management will eventually ask. "Should we keep buying these?" is a question a desk with device data answers in ten minutes with a count and a desk without it answers with an anecdote. Anecdotes lose budget meetings. The count, and the case built from it, are the subject of Tickets as Asset Intelligence later in this series.

The Repeat on the Same Machine

The repeat on the same machine is the failure this whole series exists to catch. So it is worth being exact about how it hides. A machine develops an intermittent fault: a disk that is slowly failing, a memory module that errors under load, a dock that drops the network when warm. Each episode produces a ticket with a different symptom in the requester's words: "slow", "froze", "network keeps dropping", "blue screen once". Each ticket is triaged on its own symptom, fixed with the standard remedy for that symptom, and closed when the symptom goes away. Intermittent faults obligingly go away. Nothing about the queue connects them. They have different subjects, often different categories, and if the machine has changed hands, different requesters.

The connecting thread is the device, and it is the only one. A technician who can see "five tickets on LT-0147 in eleven months" reads the symptoms together and sees a disk. A technician who sees "slow laptop, Jonas" sees a slow laptop. The difference is not skill. Ada would have found the disk on the first visit if the ticket had told her it was the fifth, and she is not an unusual technician. Tickets hide repeats from very good people by filing each one as the first.

The repeat also costs more than it looks, because each episode is charged to the desk as a separate small job. Five twenty-minute clean-ups are a hundred minutes of desk time, five interruptions to Jonas's day, and five occasions on which the desk said "fixed" about something it had not fixed. That is the quiet kind of trust loss a reopen represents. But none of these count as reopens because each was a new ticket. The disk, meanwhile, was failing the whole time and will finish failing on a Monday. (They always finish on a Monday. I have no theory.)

The Swap Decision

The swap decision is the choice, on a hardware fault, between repairing the device in front of you and replacing it with another one. It is the decision all three questions feed. Repair keeps the requester's machine, their files and their settings, and costs the time to diagnose and fix plus any part. Swap gives the requester a working machine today and costs a spare from the cupboard and the time to move their work across. It leaves the faulty device to be dealt with at leisure. Most small desks make this decision by feel, which means they make it differently every time and cannot explain any of them.

The decision gets easy once the device facts are present. A machine in warranty with a clean history gets the covered repair, because it is free and it will probably hold. A machine out of warranty with a clean history gets a repair if the part is cheap in hours and a swap if it is not. A machine with three or more tickets in a year gets swapped whatever the warranty says. That is because the desk has already spent more hours on it than a swap costs and there is no reason to expect the fourth visit to be the last. And a machine past the organisation's normal replacement age gets swapped and retired, because repairing it is buying a few more months of a thing already scheduled to go. Four rules, two facts and an age, and the decision is made before the technician has stood up.

Put the arithmetic in hours, because hours are the unit the desk actually spends. At Meridian Parts a swap costs about ninety minutes. This includes fifteen to fetch and image a spare, and an hour to move Jonas's files and sign him in to everything. The last fifteen are to label the faulty machine and update the sheet. A diagnostic visit on an intermittent fault costs thirty to sixty minutes and, by its nature, may not end in a diagnosis. By the third ticket the desk has spent longer not fixing the laptop than swapping it would have cost. That is before counting Jonas's time, which the desk does not pay for and should still count. Treat these figures as this one desk's worked example; your own hours will differ, but the shape of the comparison will not.

The decision also has a requester in it, and the facts make that conversation shorter and kinder. "This machine has had five faults in a year, so rather than try a sixth fix I'm going to give you a different one this afternoon" is a sentence a requester is pleased to hear and a technician is pleased to say. It replaces "let me try one more thing", which is the sentence that has been said on the previous four visits. Nobody enjoys the fifth one. The decision table for making this call in thirty seconds, with warranty and history in front of you, is in Warranty and History at a Glance.

Which Devices Deserve a Record

Not everything the desk touches needs a device identity, and a desk that tries to tag the mice will give up before it has tagged the laptops. The test for whether a device deserves a record is whether any of the three questions would ever be asked about it. Laptops and desktops, yes: they are expensive, they fail in repeating ways, and they have warranties worth claiming. Printers, scanners and label printers, yes: they are shared, they move, and the model question is sharp because they are bought in batches. Monitors, usually yes, because they are swapped between desks constantly. The "is it the third time" question is the one that catches a flickering panel that three people have each reported once. Network switches and access points, yes, though they rarely raise tickets by name and are more often found through monitoring than through a requester.

Docks, phones and tablets are a judgement call. I would include them if the organisation owns more than a handful. That is because docks in particular are the cause of a remarkable share of "laptop" faults and are invisible until they have a name. Keyboards, mice, headsets, cables and the little adapters that live in a drawer, no. They are replaced rather than repaired. Nobody will ever ask who else has this model of mouse, and a record for each costs more than the device. Draw the line at "would I ever claim a warranty on it or count its faults" and stop there. The line will move as the desk grows, and that is fine; the point is to have one.

Shared devices need one more thought, because they have no requester to stand in for them. A meeting-room screen, a dispatch-bay label printer or a ward workstation is reported by whoever happened to be standing in front of it. That means its history is scattered across every person who ever used it. These are the devices where the identifier matters most and the requester matters least. They are the first place the desk should put a sticker. That is because "the printer in bay three" is a phrase that has started more wrong-device visits than any other in the trade. The identifier is the only name a shared device has.

Writing the Device Into the Ticket Today

The full answer to "how" is the next article, with a field on the form, a naming convention and an inventory sheet. The short answer is that the desk can start this afternoon with no field at all. It can do that by writing the device identifier into every hardware ticket at first touch in a fixed place and a fixed form. The first touch is the moment a technician reads the ticket for the first time and decides what it is. It is already the moment when they ask whatever the requester left out. Adding "which device?" to that moment costs one question or one lookup, and the answer goes on the ticket before any work begins.

Put the identifier where the search will find it. If the tool has a custom field, use the field, because a field can be filtered and a note cannot. If it does not, put the identifier in the first internal note on the ticket, on its own line, in a fixed form such as "Device: LT-0147". That way, a full-text search for "LT-0147" finds every ticket that ever carried it. The fixed form is the whole trick. A search for a tag written three ways finds a third of the history. A search for a tag written one way finds all of it, and finds it on the first try, which is the only try a busy technician makes.

Get the identifier from wherever it is cheapest today. A logged-in requester can usually be matched to a machine from the login record or the device list, which takes the technician twenty seconds and the requester none. Where that is not possible, ask once, with directions: "Is there a white sticker on the underside with a code starting LT? If you can't find it, no problem, I'll come and look." Never make the requester's answer a condition of helping them, for the reasons in Required Fields Without the Revolt. A tag field that blocks the ticket collects extension numbers and the word "laptop". Asked kindly and filled by the desk when the answer is "not sure", the field fills itself within a month.

Then use it. The point of the identifier is the search. A desk that writes "Device: LT-0147" on every ticket and never searches for it has built a filing system and never opened the drawer. At first touch on any hardware ticket, search the identifier before deciding what to do. Read the last three subjects. If there are none, proceed as a first. If there are three, you are not reading a ticket; you are reading a chapter, and the earlier chapters say what the fix is not.

A Short War Story: The Travelling Laptop at Meridian Parts

At Meridian Parts, a laptop later known as LT-0147 passed through three owners in two years: Dana in dispatch, a temporary planner called Ravi, and then Jonas in the warehouse office. It raised seven tickets in that time under three names. There were two "slow", one "froze during stocktake", one "blue screen", two more "slow" and one "battery dies at lunch". Each was closed within the hour by a clean-up, a restart or a driver update. Each requester confirmed it was better. Each ticket was recorded as a first, because no ticket mentioned the machine and each search was by the person. The disk failed completely on a Monday during the month-end stock count. Jonas lost four hours of unsaved reconciliation and the warehouse ran its count on paper for the afternoon. The operations manager described that in the review as "avoidable". Ada added up the seven tickets afterwards at roughly four hours of desk time, against the ninety minutes a swap would have cost at ticket three. There were also the two days of warranty cover the laptop had still had at the time of the fourth ticket. Nobody had checked that. The desk began writing the device tag on the first line of every hardware ticket the following week. A machine with seven tickets and no name is a machine the desk has met seven times and never once recognised.

The Device Facts List

The list below is the set of facts a hardware ticket should carry or be able to reach, written as a one-page sheet a technician can fill at first touch. Fill the identifier first and always; fill the rest from the inventory sheet and the ticket search where they exist, and leave a line blank rather than guess. The "decision" section at the bottom is for the technician, not the requester. It is there so that the repair-or-swap call is written down with the facts that made it. Copy it into the first internal note on the ticket, or into the custom field and note together, in the same form every time.

DEVICE FACTS — ON EVERY HARDWARE TICKET
Ticket: ________   Requester: ______________   Date: ________

The device
  Identifier (tag / hostname / serial): ______________
  Type (laptop / desktop / printer / monitor / other): ______________
  Model and specification: ______________________________
  Usual user or location: ______________________________
  Shared device:  [ ] yes   [ ] no

Age and cover
  Purchased or in service since: ________   Age: ____ months
  Warranty ends: ________    [ ] in cover   [ ] out of cover   [ ] unknown
  Where the warranty fact came from: ______________

History
  Previous tickets on this device (last 12 months): ____
  Last three subjects:
    1. ______________________   ticket ______   closed ________
    2. ______________________   ticket ______   closed ________
    3. ______________________   ticket ______   closed ________
  Last swap, reimage or repair on this device: ______________

Decision on this ticket
  [ ] repair (in cover: claim raised)      [ ] repair (out of cover: quote ______)
  [ ] swap from spares                      [ ] swap and retire
  Reason, in one line: ______________________________________
  Inventory sheet updated:  [ ]    Requester told the plan:  [ ]

Ada now fills the top half in about a minute and the history section with one search. The decision section takes longer than that only on the tickets where it should, which are the ones with three subjects already in the list. If you run QuerySolv, the device identifier sits in a custom field on the department's form. In QuerySolv, the rest of the facts live in the first internal note. The event history keeps them with the ticket for as long as the ticket exists. In any tool, the test is the same: can the next technician open this ticket in a year and know which machine it was about, without asking anyone? If yes, the ticket knows the device. If no, it knows a person who once sat near one.

Frequently Asked Questions