When You Need a Real Asset System, and What It Adds

Monday, 09:30, at Tollgate Foods, a food manufacturer with three sites and about six hundred devices. Sinead, who runs the desk of five, has an e-mail from a software vendor's compliance team asking how many installations of their product the company has. It asks politely, and with a deadline. She opens the inventory sheet, which has a row for every device and eleven honest columns. She finds that none of the columns is "software installed". The sheet was never meant to know that. The answer is somewhere in six hundred machines across three sites, and the deadline is three weeks. Bram, the technician who owns the sheet, says what everyone is thinking: "We can walk it." Sinead does the arithmetic on walking six hundred machines in three weeks and does not say anything for a moment.

A real asset system is software whose job is to know about devices. It knows what exists, what is installed on it, who has it, what it cost, when its cover ends and when it should be replaced. This is kept current largely by discovery, a small program on each device or a scan of the network. Discovery reports what it finds without a person typing anything. This article is part of our Asset Data Inside Tickets series. It is about the moment when the field, the sticker and the sheet that the rest of the series built stop being enough. It covers how to recognise that moment before an auditor does, and what the system adds and does not add. It also covers how the system should sit beside the help desk rather than swallow it.

It covers why the sheet has a ceiling and why it is not a number. Then come the four signals, count, churn, compliance and licences, one at a time. Next are what an asset system adds, what it does not fix, and how it should feed the help desk rather than replace it. A short war story and the readiness check to copy come last.

The Sheet Has a Ceiling

The inventory sheet is a good design for most small desks. I will keep saying so, because the commonest mistake in this area is buying an asset system to fix a habit. One row per device, a tag on every hardware ticket, an update at close and a reconcile each quarter will keep the fleet honest. That works for a fleet of a couple of hundred devices, for years, with a quarter-day of effort a quarter. It answers the three questions the first article in this series set out, it feeds the lemon list, and it costs nothing but discipline. A desk that has not yet built the habits will get no further with a system than with a sheet, and will pay for the privilege.

The ceiling is not a device count. It is the point at which the organisation starts asking the sheet questions it cannot answer in a week. Or it starts asking for proof where the sheet can only offer assertion. Or it starts changing faster than a quarter-day a quarter can follow. Those arrive as four signals, and they rarely arrive together. One organisation hits the ceiling at a hundred and fifty devices because it is regulated. Another runs eight hundred on a sheet quite happily because nothing moves and nobody audits. The question is never "how many devices", but "which of the four signals is already showing". The honest answer is usually one or two. That is the point at which to start planning rather than buying.

Recognising the ceiling early matters because the alternative is recognising it during an audit, a true-up or a merger. Those are the three moments when an organisation discovers what it does not know about its own equipment in front of someone taking notes. The sheet's great virtue is that it was cheap. Its great weakness is that it cannot prove anything, and a day comes when proof is what is asked for.

Signal One: Count

The count signal shows when the sheet stops being a thing one person can hold in their head and the quarterly walk stops finishing. For a single site with a couple of hundred devices, the sheet's owner knows most of the rows by sight and a quarter's sample is a morning. Somewhere between a few hundred and a thousand devices, and sooner across several sites, the walk becomes a project. The sheet grows tabs that different people maintain. Two copies appear with different numbers. The question "how many laptops do we have" produces three answers and a meeting. The sheet has not failed. It has been asked to be a database, and it is a spreadsheet.

The sign to watch is not the row count but the fork. That is the moment a second site or a second person keeps their own version because the shared one is "too big" or "always being edited". Forked asset data is worse than no asset data, because each copy is confidently wrong in different places. The second sign is the reconcile that no longer gets round the fleet in a year. Then the verified share, the measure from Keeping Asset Data Honest, stops climbing and the last-verified dates age. When a fifth of the rows have not been seen in two years, the sheet describes a building that used to exist.

Signal Two: Churn

Churn is the rate at which devices change hands, place or state. The churn signal shows when the update-on-ticket habit cannot keep up even when everyone follows it. A stable office where ten devices move a quarter is absorbed by the habit without anyone noticing. A business with seasonal staff, a contractor pool, a field force swapping tablets weekly or a hot-desking policy can see fifty moves a month. At that rate the drift rate stops falling no matter how disciplined the desk is. Most of those moves never had a ticket and never will. The reconcile finds them, three months late, in bulk.

The sign is a drift rate that plateaus. If the first three reconciles brought the wrong-row share down and the fourth and fifth did not, and the habits are being followed, the building is moving faster than a quarterly check can see. Discovery is the answer to churn specifically. Consider a device that reports where it is and who signed in to it every day. Its row then updates itself for the two columns that drift most, person and place. Nothing else in an asset system does as much for a high-churn fleet as that one daily report. It is worth asking any vendor what their discovery agent does when the device is off the network for a month. A field force is off the network for a month.

Signal Three: Compliance

The compliance signal shows the first time someone asks the desk to prove something about devices rather than to state it. An auditor asks for evidence that every laptop holding customer data is encrypted. A customer's security questionnaire asks how the organisation knows which devices hold their data. A regulator asks for the disposal record of a device that left the building two years ago, with proof of wiping. The sheet can say "encrypted: yes" in a column. An auditor will ask, correctly, how the desk knows. The answer "Bram checked it when he set it up" is a statement about a Tuesday eighteen months ago. Proof means a record collected from the device, recently, by something that was not a person remembering.

Regulated organisations hit this signal early and small ones hit it at unexpected moments, usually when a large customer sends a questionnaire. The sign is not the question itself, which every desk can answer once by walking, but the second question, and the third. Each needs another walk, until the desk is spending a week a quarter producing evidence by hand. At that point an asset system is not a convenience. It is the cheapest way to answer a recurring question, and its reports become the evidence. The sheet asserts. The system, because discovery collected the state from the device on a known date, can show its working.

Signal Four: Licences

The licence signal is the one Sinead met: the organisation needs to know what software is installed on which device. The sheet has no software column because a sheet with a software column is a sheet with six hundred rows of free text that is wrong by Friday. A licence true-up is the moment a software vendor asks the organisation to count its installations and pay for any above the number it has bought. It is the moment at which not knowing becomes expensive in a way nobody can argue with. The desk can count by walking, once. The vendor will ask again next year.

Software inventory is the one job that a spreadsheet genuinely cannot do, as opposed to the jobs it does badly at scale. The data changes every time anyone installs anything and only the device knows. It is also the job that most often pays for the asset system on its own. An organisation may discover it is paying for installations on retired machines, or holding licences for software nobody has opened in a year. It has then found the budget line the system comes out of. The sign is simple. If the organisation has had one true-up conversation and expects another, the licence signal is showing.

What an Asset System Adds

Named plainly and without a vendor, an asset system adds five things the sheet cannot have. Discovery fills and refreshes the rows without typing. An agent on each device, a scan of the network, or both report the model, the serial, the installed software, the signed-in user and the last time it was seen. Software inventory is the list per device of what is installed, matched against what the organisation has bought. Lifecycle and contracts cover the purchase, the warranty, the lease or support contract and the planned refresh. They provide reminders before each date rather than a sort on a column someone has to remember to run. Relationships show which device connects to which dock, which monitor, which user, which network. That way, a fault can be traced through the chain. And reports as evidence are the compliance answer. They provide a list of encrypted devices as of this morning, produced by the system from what it collected. A person does not produce it from what they recall.

Each of these is worth having when its signal is showing and a cost when it is not. Consider discovery on a stable fleet of a hundred and fifty desktops that never move. It is an agent to install, update and troubleshoot in exchange for information the sheet already had right. Relationships are indispensable in a data centre and decorative in an office. The honest buying question is which of the five the organisation has felt the absence of in the last year. A desk that answers "none, but it would be nice" should keep its sheet and spend the money on spares.

Note what is not on the list: nothing about tickets. An asset system does not take requests and does not own a queue. It does not know that the laptop it has a record for is the one Hana is complaining about this morning. The help desk knows that. The two systems know different things about the same device, and the whole design question, below, is how they tell each other.

What It Does Not Fix

An asset system does not fix habits, and a desk that buys one to avoid building them will have an expensive sheet. Discovery fills the columns a device can report about itself, model, serial, software, last user, last seen. It cannot fill the ones only a person knows. Those include who the device is actually assigned to, as opposed to who last signed in, and which cupboard the spare is in. They also include whether the leaver's laptop is in a drawer. A laptop in a drawer is off and tells discovery nothing. The update-on-ticket habit and the leaver ticket from the previous article carry straight over, unchanged. The organisation that skipped them will find its asset system confidently reporting that a device last seen eight months ago is assigned to someone who left nine months ago. That is the drawer problem with a licence fee.

It does not fix the tag, either. Discovery identifies devices by serial and hostname. Suppose the hostname is not the tag and the serial is not in the sheet. The system's records and the desk's tickets then describe the same devices under different names and cannot be joined. The naming convention from Linking Devices Without an Asset System is hostname equal to tag, serial recorded against it. It makes the migration from sheet to system a column import rather than a year of matching. Desks that did it find the system useful on day one. Desks that did not spend the first quarter typing tags into it, which is the sheet-building week again, at scale, with a deadline.

And it does not fix ownership. The sheet had one named owner. The system needs one too. And "the vendor keeps it current" is not a name. Discovery keeps the device-reported fields current. Somebody still owns the reconcile, now against the system's exceptions report rather than a floor walk. The someone still spends a morning a quarter on it. The morning gets more productive. It does not disappear. (Nothing in this trade disappears. It changes shape and gets a dashboard.)

Feeding the Help Desk, Not Replacing It

The right relationship between the two systems is simple to state. The asset system is where device facts live and the help desk is where tickets live. The tag is the key that joins them. Each fact has exactly one home. Warranty end, model, serial, installed software and last-seen date live in the asset system and are read by the help desk. Ticket count, the subjects of the last three tickets and the technician's decision live in the help desk and are read by whoever builds the lemon list. Nobody types a warranty date into a ticket and nobody types a ticket count into the asset record. Each is looked up where it lives. The moment a fact has two homes, it has two values, and the desk is back to arguing about which spreadsheet is right.

Most small-team help desks have no asset module, and QuerySolv is among them. The tag lives in a custom field on the department's form. When an asset system arrives the field stays where it is. The asset system then becomes the place the tag is looked up. The join can be as plain as a technician pasting the tag into the asset system's search. In that case, the technician pastes the device card from Warranty and History at a Glance into the first internal note. That is exactly what the sheet's lookup tab did and is no slower. The desk may want the join automated. A help desk might offer webhooks and a REST API, the two usual ways one program tells or asks another. Such a help desk can have a small script fetch the device facts by tag when a hardware ticket is created. The script can write them into the note. In that setup, the asset system's own alerts, a warranty expiring or a device unseen for a month, can open tickets the same way alerts from monitoring do. That is described in Enriching the Alert Ticket. The automation is a convenience. The design, one home per fact and the tag as the key, is the requirement.

Resist the two tempting shortcuts. The first is to make the help desk the asset system by adding twenty custom fields to the ticket form for model, serial, warranty and software. That produces device data copied by hand onto every ticket and wrong on most of them, and a form nobody will finish. The second is to make the asset system the help desk, because some asset tools offer a ticket queue as a feature. A ticket queue bolted onto an asset database is usually a worse help desk than the one the desk already has. An ITSM suite is IT service management software sold as a single product that bundles a help desk, an asset system and more. It is a reasonable way for a larger organisation to buy both at once. It is also a bigger tool than most small desks need for the ticket work alone. If the only reason to consider one is assets, buy the asset piece and join it by the tag. The requirements for choosing any of this are set out in Requirements Before Demos. And "it must join to our asset data by tag" is one line on that list, not the whole list.

A Short War Story: The True-Up at Tollgate Foods

At Tollgate Foods, Sinead's desk answered the vendor's installation count by walking. It took Bram and two colleagues most of three weeks across three sites. They found that the company had forty-one more installations of the product than it had licences. Twenty-three were on machines the sheet showed as retired but whose software had never been removed from the vendor's registration record. Six were on laptops in drawers belonging to people who had left. The vendor's true-up was settled on the forty-one. The sheet could assert that twenty-three were retired but could not prove when or that the software was gone. Owen, the finance director, paid for software on machines that had been in a skip for a year. The same quarter, a large retail customer's security questionnaire asked how Tollgate knew which laptops holding its order data were encrypted. The honest answer, "we check at setup", did not satisfy the customer's auditor. Sinead's readiness check scored three of the four signals showing. The company bought an asset system with discovery and software inventory, keeping the tag as its key because the hostnames already matched. The second true-up, a year later, was answered from a report in an afternoon and came out under the licence count. Three weeks of walking, a payment for software in a skip and a customer's raised eyebrow were the price of answering a question the sheet was never built for. A sheet is a fine tool until someone asks it to testify.

The Readiness Check

The check below scores the four signals and three readiness conditions, so that the decision to buy, plan or wait is written down with its reasons. Score each signal 0 if it is absent, 1 if it is beginning to show and 2 if it is costing the desk time now. Then read the total against the bands at the bottom. The readiness conditions are not scored. They are prerequisites. A desk that cannot tick all three should fix them first. An asset system installed on top of an unmatched fleet and no close habit is the sheet's problems with a monthly bill. Fill it once a year, or whenever an audit, a true-up or a merger makes the question live.

ASSET SYSTEM READINESS CHECK — DATE: ________   COMPLETED BY: ______________

THE SIGNALS (score 0 absent / 1 beginning / 2 costing time now)
  Count     Devices: ____   Sites: ____
            Sheet has forked into copies  [ ]   Reconcile no longer completes
            the fleet in a year  [ ]   Verified share falling  [ ]        Score: __
  Churn     Device moves per month (estimate): ____
            Drift rate has stopped falling over two reconciles  [ ]
            Seasonal, contractor or field fleet  [ ]                        Score: __
  Compliance
            Evidence about devices requested in the last year: ____ times
            Produced by walking  [ ]   Regulated data on devices  [ ]
            Customer questionnaires asking about device state  [ ]        Score: __
  Licences  True-up or installation count requested  [ ]   Expected again  [ ]
            Software bought per device with no installation record  [ ]  Score: __
                                                              TOTAL: __ of 8

READINESS CONDITIONS (all three before buying)
  [ ] Tag on every device; hostname equals tag; serial recorded against it
  [ ] Update-on-ticket habit on the close checklist and being followed
  [ ] Matched rate above ____% for the last two quarters

WHAT WE WOULD NEED IT TO DO (tick only what a signal above justifies)
  [ ] Discovery (agent / network scan / both)   [ ] Software inventory
  [ ] Lifecycle and contract reminders           [ ] Relationships
  [ ] Evidence reports for: ______________________________
  [ ] Join to the help desk by tag (lookup / API)   Fact homes agreed  [ ]

DECISION
  0-2  Keep the sheet; review in a year                 [ ]
  3-4  Plan: write requirements, fix readiness gaps     [ ]
  5-8  Buy this year; the signals are already costing more than the system  [ ]
  Reason, one line: ______________________________________________

Tollgate's check the first time scored six. The readiness conditions were already met because Bram had made the hostnames match the tags two years earlier. His reasons had nothing to do with this, and were, he says, mostly tidiness. That tidiness turned a quarter of matching into an afternoon of import. A desk that scores two should feel pleased rather than deprived. Its sheet is doing the job and the money is better spent on spares and a label printer. A desk that scores six and is still walking the building has an answer, and the check is the page to take to Owen. The sheet got the desk this far, which is further than most. The system is for the questions the sheet was never asked to answer.

Frequently Asked Questions