Linking Devices to Tickets Without an Asset System

Thursday, 08:15, at Harbourview Clinic. Ticket 5190 from Carys, a nurse in outpatients: "The computer in bay 4 won't log in, says the trust relationship failed." Femi walks to bay 4, finds a workstation that logs in perfectly, and walks back. Carys meant bay 4 in minor injuries, two corridors away. Minor injuries has its own bay 4, its own workstation, and, it turns out, its own two previous tickets about the same login fault. Those were filed under two other nurses. Femi fixes it on the second walk. The clinic has about two hundred devices, no asset system, and a desk of three who have each made that walk. Nobody has written down which workstation is which. Writing it down sounds like a project, and the desk does not have a project.

Linking a device to a ticket means that every ticket about a machine carries one identifier for that machine. That way, the desk can find the machine's history, its facts and its whereabouts from the ticket, and the ticket from the machine. A CMDB, a configuration management database, is the large version of this. It is a system that holds a record for every device, every piece of software and every relationship between them, kept current by automatic discovery. This article is part of our Asset Data Inside Tickets series. It is about getting most of the value of a CMDB with a field, a sticker and a spreadsheet. The case for wanting the link at all, the three questions no hardware ticket can answer without it, is made in Why the Ticket Needs to Know the Device. This is the how.

It covers why most help desks have no asset module and why that is fine. Then come choosing the identifier, tag, serial or hostname, and a naming convention that does the work for you. Next are the asset tag field on the form and how to word it, the inventory sheet and its columns, and the lookup at first touch. Then it covers where the simple setup breaks and what to do there. A short war story and the asset field specification to copy come last.

Most Help Desks Have No Asset Module, and That Is Fine

Most small-team help desks have no asset module, and QuerySolv is one of them. A custom field on the department's form carries the tag, and the device facts live in a sheet the desk owns. This is not a gap to apologise for. An asset module is a second database with its own upkeep, its own permissions and its own way of being wrong. A desk of three with two hundred devices does not need a second database. It needs one field that is always filled, one sheet that is always right, and the habit of looking at both before walking anywhere. Every asset system I have seen at a small organisation was either empty or wrong within a year. The empty ones were in better shape.

The honest framing is that the link between a device and a ticket is a small amount of data with a large amount of discipline attached. The discipline is the expensive part whichever tool holds the data. A CMDB does not make technicians record the device; it makes it possible for them to. A field on the form does the same thing at a tenth of the weight. When the organisation outgrows the field and the sheet, the signals are clear and the move is described in When You Need a Real Asset System. Until then, the field and the sheet are not a stopgap. For a desk this size they are the right design.

Choosing the Identifier

The identifier is the one string that names a device everywhere: on the sticker, in the sheet, in the ticket field and in the search box. There are three candidates, and the desk must pick one as the key and record the other two against it. The asset tag is a short code the organisation assigns and prints on a label, such as LT-0147. The serial number is the maker's unique code, printed on the device by the factory and usually long. The hostname is the name the machine announces on the network and shows on its own screen. A fourth candidate, the user's name, is the one most desks use by default. It is the one that fails, because people move and machines stay.

Choose the asset tag as the key, for three reasons. It is short enough to read over the phone and type without error, which a serial is not. It is yours, so it exists before the device is unboxed and survives the device being replaced under warranty with one that has a different serial. And it can be printed large, in a consistent place, in a form the requester recognises as "the IT sticker". A serial is tiny, on the underside, and indistinguishable from the other six codes next to it. Record the serial in the sheet beside the tag, because the warranty lookup wants it. Make the hostname equal the tag, so that two of the three names are the same string. The machine then tells the technician its own tag the moment they connect to it.

The table sets the four out. Read the last column as the reason the user's name loses even though it is the one the tool already has. It is the only identifier in the list that changes without anyone touching the device.

A Naming Convention That Does the Work

A naming convention is the rule for making up tags. A good one makes the tag do two jobs: identify the device uniquely, and tell a technician at a glance what sort of thing it is. The simplest that works is a type code, a dash and a sequence number. Examples are LT-0147 for a laptop, DT-0033 for a desktop, PR-0012 for a printer. Further examples are MN-0210 for a monitor and SC-0005 for a scanner. Two letters, four digits, never reused. The type code is the only meaning the tag carries, and it is safe to carry because a laptop does not become a printer. Multi-site organisations sometimes add a site prefix, HV-LT-0147. That is fine so long as everyone accepts that the laptop will one day be at the other site with the wrong prefix on it. It will still be uniquely named, which is what matters.

Encode nothing that changes. The temptation is to put the department, the user's initials or the room into the tag. That way, FIN-LT-JS-3 tells you everything. And it does, until Jo Smith moves to sales and the laptop goes to a new starter in finance. At that point the tag tells you three wrong things with great confidence. Department, user and room belong in the sheet, where they can be edited. The tag is a name, not a description. (A tag that describes the device is a tag that will eventually describe a different device.)

Make the hostname equal the tag, as part of building every machine. This is the single highest-value step in the article. It costs nothing beyond typing LT-0147 into the name field during setup instead of whatever the build process would otherwise have invented. From then on, a technician connecting remotely sees the tag in the window title. A monitoring alert names the tag. The login record names the tag. A requester reading the sticker and a technician reading the screen are reading the same string. Where devices have no screen, printers, switches, scanners, the hostname still exists on the network and still equals the tag. The sticker does the rest.

Print the sticker on a label that will survive the device's life, and put it where it will be read. On a laptop, that is the lid or the palm rest, not the underside, where the serial already lives unread. On a desktop, the front. On a monitor, the lower bezel, facing the user. On a shared workstation in a clinic bay, put it at eye level on the monitor in letters a nurse can read from the door. That workstation's tag is the only name it will ever have. Add the desk's contact line under the tag, "IT: ext 4000 or helpdesk@example.com". That way, the sticker is also the one piece of desk marketing that is genuinely useful. A tag nobody can see is a tag nobody will type.

The Asset Tag Field on the Form

Add one field to the request form, named plainly, asked but never required. The label does three jobs in about twenty words: it says what the field wants, where to find it, and that not knowing is fine. "Which device is this about? Look for the IT sticker, a code like LT-0147, on the lid or the front. Not sure is a fine answer." Make it a short text field, not a drop-down of two hundred tags, which nobody will scroll. It must not be a required field, for reasons the library has already learned the hard way in Required Fields Without the Revolt. A required tag field collects serials, extension numbers and the word "laptop". It sends the people who cannot find the sticker to e-mail instead.

Put the field on the form of the department that needs it, not on every form. Tools that give each department its own form, QuerySolv among them, let the clinical workstation form ask for the tag while the general request form asks nothing of the kind. That is the right split. A password reset does not need a device. A form that asks for one anyway teaches requesters that the field is noise. The same field can carry a few agreed words besides a tag, "shared", "personal" or "not sure". That way, a requester who cannot give a tag can still say something true. The desk can tell "did not know" from "did not look".

Expect the field to be filled on perhaps a third of hardware tickets at first and most of them within a few months. Treat the gap as the desk's to close, not the requester's. The field is the cheap way to get the tag when the requester has it in front of them. The lookup at first touch, next, is how the desk gets it when they do not. Between the two, every hardware ticket ends up with a tag on it. The matched rate is the share of hardware tickets with a tag the sheet recognises. That is the number to report monthly. It climbs. Watching it climb is one of the small pleasures of the job, and there are not so many that you can afford to skip one.

The Inventory Sheet

The inventory sheet is a spreadsheet with one row per device and one column per fact. It is the whole asset system for a desk this size. Its columns are the device facts a ticket needs and nothing more. They are tag, type, model and specification, serial number, purchase date, and warranty end date. Then come assigned to, location, status, last verified, and notes. Eleven columns. A desk that adds a twelfth should be able to name the decision it changes. A desk that adds a twentieth has started building a CMDB in a spreadsheet, which ends the way it sounds.

Each column has a rule, and the rules are what keep the sheet honest. Tag is the key, unique, never blank, never reused. Type is one of a short fixed list. Model is written the same way every time. The per-model counts later in this series depend on "14-inch business laptop, model A" not also appearing as "A laptop 14in". Serial is copied, not typed, where possible. Purchase date is the invoice date. Warranty end is a date, not "3 years", so that a sort finds everything expiring this quarter. Assigned to is a person's name or, for a shared device, the word "shared" and the location. Status is one of in use, spare, on loan, in repair, or retired. A retired row is never deleted, because its tag is never reused and its history is still in the tickets. Last verified is the date someone last confirmed the row against the real device. That is the subject of Keeping Asset Data Honest.

Keep the sheet in a shared place the whole desk can read and only the desk can edit, with one named owner who answers for it. Not the finance fixed-asset register, which counts money rather than machines and is updated at year end; not a personal file on one technician's laptop, which goes on leave with them. A shared folder, a sheet with a plain name, a note in the desk's own documentation saying where it is. Most of the sheet's upkeep happens on tickets, a row changed as the ticket that changed the device is closed. The owner's job is the quarterly check that it still matches the building.

One formula makes the sheet useful from inside a ticket. On a second tab, there is a cell where the technician types a tag, and beside it a lookup. The lookup is written in whatever spreadsheet you have as something like VLOOKUP or XLOOKUP against the tag column. It returns the model, the assigned user, the purchase date and the warranty end on one line. Type LT-0147. Read the row. The formula is not the point. The point is that the device facts for any tag are one paste away, which is the speed a first touch needs. The same tab can hold a lookup the other way, from a person's name to their tag. That is for the far commoner case where the ticket has a requester and no tag.

The Lookup at First Touch

The first touch is the moment a technician first reads a ticket and decides what it is. For a hardware ticket it now has one more step: get the tag onto the ticket before doing anything else. If the requester filled the field, check it against the sheet, because a mistyped tag is worse than a blank one. If they did not, look it up. The requester's name in the sheet's assigned-to column gives the tag in a few seconds for anyone with one device. The login record, where the desk keeps one, gives the hostname the person last signed in to, which is the tag. And where neither works, the remote-support tool or the device's own screen shows the hostname, which is the tag, to anyone who connects. The whole lookup is about twenty seconds. The walk to the wrong bay 4 was eleven minutes.

Then fill the field, from the desk's side, every time, even when the ticket has been resolved by the time anyone thinks of it. The field is what makes the ticket findable later. A tag in a note is findable by full-text search. But a tag in a field can be filtered, counted and exported. The per-device and per-model counts later in this series are built on the field. A desk that fills the field on the tickets where it was easy and skips the rest has a sheet that describes the easy tickets.

Last, search. Filter the ticket list by the tag, read the last three subjects, and decide what this ticket is in light of them. This is the twenty seconds that pays for all the others. It is the step that gets skipped when the queue is busy. So make it a line on the desk's first-touch checklist rather than a thing technicians remember. The checklist already exists at most desks. "Tag on the ticket, history searched" is one more line on it, and the line that turns a slow laptop into a fifth ticket on LT-0147.

Where the Simple Setup Breaks

Shared devices break the assigned-to column, and the fix is to let location stand in for a person. A clinic bay workstation, a meeting-room screen or a dispatch-bay label printer has no owner, so its row says "shared" and the location. Its sticker is large and at eye level because the location is exactly what requesters get wrong. Hot desks break it the other way: the desktop stays and the people rotate. In that case, the row names the desk, not the occupant. Tickets about it carry the desktop's tag regardless of who raised them. In both cases the tag, not the requester, is the thread through the history. That is why shared devices are where the link matters most.

Docks and peripherals break the "one device per ticket" idea, because a laptop fault is frequently a dock fault and the dock has no tag. The practical answer is to tag docks if the organisation has more than a handful and they move between desks. Leave them untagged but noted in the laptop's row if they do not. Monitors are tagged, because they are swapped between desks so often that "my screen flickers" from three different people is one flickering monitor. Keyboards, mice and cables are not, and the sheet does not know they exist. Draw the line at "would I ever claim a warranty on it or count its faults".

Loaners, personal devices and devices in transit break the status column, and each needs one agreed word. A loaner has status "on loan", a borrower in assigned-to and a return date in notes, because a loan with no return date is a gift. A personal device raising a ticket gets the word "personal" in the tag field and no row. The desk does not inventory what it does not own. What it will do for such devices is a scope question answered in the library's article on personal and bring-your-own devices. A device between owners, in the cupboard, is "spare". A device awaiting repair is "in repair" with the ticket number in notes. That way, the cupboard and the sheet agree about what is in it. The cupboard, left to itself, has opinions.

A Short War Story: The Two Bay Fours at Harbourview Clinic

At Harbourview Clinic, the desk of three had made the walk to the wrong bay 4 so often that Femi kept a tally on a sticky note. It stood at nine for the quarter when the minor injuries workstation finally failed outright during a Saturday clinic, with a locum doctor and a waiting room of fourteen. The on-call technician, Grace, was told "the computer in bay 4". She drove in, fixed nothing in outpatients, and found the real machine forty minutes later by following the queue of patients. The machine had raised four tickets in the previous year under four nurses, two of them for the same login fault. Nobody had connected them because no ticket named the machine. The clinic paid the locum for an afternoon that saw half the patients it should have. The practice manager asked the desk, not unkindly, why a two-hundred-device clinic could not tell its own computers apart. Over the following fortnight the desk printed a tag for every device. It put the workstation tags at eye level on the monitors in letters visible from the door. It set each hostname to its tag, and added one asked-not-required field to the clinical form with the words "look for the IT sticker on the screen". Femi's sticky note has not needed a tenth mark. A device without a name is a device the desk will keep meeting for the first time.

The Asset Field Specification

The specification below is the one page that defines the field, the convention and the sheet together. That way, a new technician, or a new tool, can be given it and get the same result. Fill the blanks for your own desk. Keep it with the desk's documentation. Treat changes to it the way you treat changes to the form: deliberately, and written down. The naming convention section is the part most desks never write and then argue about. Writing it once ends the argument.

ASSET FIELD SPECIFICATION — ONE PAGE
Owner of this specification: ______________   Reviewed: ________

1. THE IDENTIFIER
   Key identifier: asset tag         Format: two letters, dash, four digits
   Type codes:  LT laptop   DT desktop   MN monitor   PR printer
                SC scanner  NW network   PH phone     OT other
   Site prefix (if any): ______       Sequence numbers are never reused.
   Hostname is set equal to the tag at build:  [ ] yes
   Serial number recorded in the sheet beside the tag:  [ ] yes

2. THE LABEL
   Printed on: durable label, ____ mm high lettering
   Placed: laptop lid or palm rest / desktop front / monitor lower bezel /
           shared workstation at eye level on the monitor
   Second line on the label: "IT: ______________"

3. THE FORM FIELD
   Field name: Device tag              Type: short text        Required: no
   Appears on form(s): ______________________________
   Label text: "Which device is this about? Look for the IT sticker,
                a code like LT-0147, on the lid or the front.
                Not sure is a fine answer."
   Accepted besides a tag:  "not sure"   "shared"   "personal"
   Filled by the desk at first touch when blank or wrong:  [ ] yes

4. THE INVENTORY SHEET
   Location: ______________________________   Owner: ______________
   Columns: tag | type | model and spec | serial | purchase date |
            warranty end | assigned to | location | status |
            last verified | notes
   Status values: in use / spare / on loan / in repair / retired
   Rows are never deleted; retired rows keep their tag.
   Lookup tab: tag to facts, and person to tag.

5. THE HABIT
   At first touch on any hardware ticket:
     [ ] tag on the ticket (from field, sheet, login or screen)
     [ ] ticket list filtered by tag; last three subjects read
   At close of any ticket that changed a device:
     [ ] sheet row updated (assigned to, location, status, notes)
   Monthly: matched rate reported (hardware tickets with a tag the
            sheet recognises, as a share of all hardware tickets): ____%

Harbourview's specification fits on one side and has changed twice since it was written. The first change added the "PH" code when the clinic bought handsets. The other moved the laptop label from the underside to the lid after a month of nobody finding it. Both changes were made by the owner, dated, and announced to a desk of three in one sentence. That is the right amount of ceremony for a document this size. The field is one line on a form. The sheet is one file. The convention is one rule. Together they give a desk of any size the one thing a ticket cannot otherwise provide: the name of the thing that is broken.

Frequently Asked Questions