IT Hardware Asset Management Platform: Why Leavers Keep the Laptop and You Keep Paying the Warranty

Why the asset register is wrong in every organisation that has one

A developer resigns on a Friday. HR records the leaving date in the human resources system. On the last day IT disables the account, which is the part everybody remembers. The laptop is at her flat two hundred miles from the nearest office, along with a docking station and a monitor that were shipped to her during a hardware refresh she never came into an office for. There is a ticket somewhere about arranging a courier. It is assigned to a queue rather than a person.

Ten weeks later, three systems disagree about that laptop. The asset register still shows it assigned to her, because nothing ever changed the record. The endpoint management console shows it checking in weekly, unpatched since the account was disabled, still holding whatever was in the local profile. Finance is paying an extended warranty on it that renewed automatically in the meantime. Nobody is lying. Each system is faithfully reporting what it was told, and no system was told the truth.

Multiply that by normal staff turnover across a few thousand employees and the numbers stop being administrative. Devices that never come back are a capital write off and, more seriously, an unmanaged endpoint with company data on it that your security team cannot see in any inventory. Warranty and support contracts renew on hardware that was scrapped two years ago. Lease returns miss their date and incur penalties. Refresh budgets are built from a register nobody trusts, so the estimate is padded, and the padding becomes the budget.

Problem one: you do not have an asset register, you have three

Every organisation of any size has at least three overlapping sources of truth about hardware and none of them agree. Procurement knows what was bought, with a purchase order, a cost, a serial and often a lease agreement, and then stops caring the day the invoice is paid. Discovery and endpoint management, whether that is Intune, Jamf, a Lansweeper scan or your EDR console, knows what is currently talking to the network, which is a completely different set. The asset register knows what somebody typed in, usually at receiving, occasionally updated afterwards.

The interesting information is in the differences, and almost nobody computes them. Devices present in the endpoint console with no purchase record are typically either acquisitions nobody imported or personal devices that found their way onto the estate. Devices in the register that have not checked in for ninety days are the recovery backlog. Purchase records with no matching device were either never deployed or were deployed and lost between the loading dock and a desk. Producing those three lists on a schedule and routing each to an owner is most of the value of this entire category, and it is a reconciliation problem rather than a database problem.

Lansweeper is strong at the discovery half and weak on lifecycle and finance. Snipe-IT is a clean, free register with no reconciliation engine behind it. Asset Panda is flexible and mobile friendly but generic, since it was designed to track any asset rather than a fleet of managed endpoints with identity and security systems attached. Oomnitza is the closest fit in the market because reconciliation across systems is precisely its premise, and it is a reasonable buy: the caveat is that its usefulness depends entirely on how well your specific integrations are modelled, which is where evaluations should focus. ServiceNow's asset management module is the right choice when you already run ServiceNow well and your configuration data is maintained, since it inherits the quality of what is underneath it.

Problem two: the lifecycle has states nobody models

Asset systems usually model in stock, assigned and retired. Real fleets spend a great deal of time in states between those. In transit to a new starter. At a repair vendor for three weeks. Issued as a loaner while the primary machine is being fixed. Sitting in a cupboard at a branch office that has no IT staff. Awaiting collection from a leaver. Staged for disposal but not yet collected. Each of those is a place where devices go missing, and a register with three states records them all as assigned, which is why the register is wrong.

Modelling the real states matters because it makes ageing visible. A device that has been in transit for six weeks is not in transit, it is lost, and the only way anyone notices is if the state has a clock on it. The same applies to repair returns and loaners that quietly became permanent. Every intermediate state needs an expected duration and an owner, and anything that exceeds it should generate work for a named person rather than appearing in a report nobody opens.

Problem three: offboarding is a logistics problem being run as a checklist

Recovering hardware from a leaver, particularly a remote one, involves a shipping label, a box, a courier, a chase sequence and an escalation path that ends with HR or payroll. Treating it as a line on an IT checklist guarantees a low return rate, because the checklist closes when the account is disabled and the physical object is somebody else's problem.

What works is treating each recovery as a tracked case with a deadline, opened automatically when the leaver record appears, carrying the specific assets that person holds. Generate the return label, send it with the box, chase on a schedule through channels the person will actually see given their work account is disabled, and escalate to their manager and then to HR when the deadline passes. Close the case only when the serial number physically arrives and is scanned at receiving, not when the courier says delivered. Organisations that put an owner and a clock on this see recovery rates change materially, and the reason is unremarkable: someone is now accountable for an outcome instead of a task.

Problem four: leases, warranties and disposal evidence are financial obligations, not metadata

Leased hardware carries a return date and penalties for units returned late, damaged or missing. Warranty and support contracts renew unless cancelled. Depreciation schedules feed the fixed asset register your auditors look at. All of these are obligations with dates attached, and they are typically held as a spreadsheet maintained by whoever last cared.

The build should treat the agreement as a first class object with its term, return window, penalty terms and the specific assets covered, then generate work before the date rather than reporting the miss afterwards. Lease returns in particular need a physical process starting weeks ahead: identify covered units, locate them, retrieve them from wherever they actually are, wipe them, and package them for return with a reconciled list. Discovering a lease return is due next week is how organisations end up buying out equipment they intended to give back.

Disposal deserves the same rigour. When data bearing devices leave, your asset disposition vendor issues a certificate listing the serials they received and destroyed. Almost nobody reconciles that certificate against the list of serials they sent, which means a device that fell out of the process is invisible. Make the reconciliation automatic, hold the certificate against each asset record, and record whether the vendor holds R2 or e-Stewards certification, because when a data protection question arrives years later the evidence chain from decommission to destruction is what answers it.

What this costs and how long it takes

A first release covering the unified asset record, reconciliation across procurement, discovery, identity and HR, the real lifecycle states with ageing, and the offboarding recovery workflow runs $55,000 to $120,000 and ships in 10 to 14 weeks. A full platform adding lease and warranty obligations with proactive workflow, repair and loaner tracking, stock levels and reorder points across sites, refresh planning against depreciation and support end dates, disposal evidence and reconciliation, and finance system integration runs $140,000 to $350,000 over 5 to 10 months.

The cost drivers here: how many source systems need integrating and whether any of them are legacy procurement platforms without usable APIs. How many sites and whether receiving happens locally, because asset tagging at the point of receipt is a process design question with a physical component. Whether you want the reseller to tag and pre enrol devices before shipping, which is worth doing and requires them to send you structured data. Acquisitions, which arrive with their own estates, their own tagging schemes and no shared identifiers. And mobile phones, which drag in carrier contracts and a different set of obligations than laptops.

Build versus buy, and when buying is right

Buy if you are under roughly 500 devices on one or two sites with low turnover. Snipe-IT costs nothing and will hold a clean register, and Asset Panda adds a decent mobile experience for receiving and audits. At that size the reconciliation can be done by a person once a quarter and there is no case for engineering.

Buy Oomnitza or ServiceNow if your integration surface is mainstream, your processes are close to standard, and you are willing to adapt your workflow to the product. That is a real path and it is faster than building. It stops being the right path when your obligations are unusual, when you are reconciling across systems that no product ships a connector for, or when your fleet includes categories beyond laptops and phones, for example clinical devices in a hospital group or trading floor hardware in a bank, where the asset model itself needs to differ.

Build when recovery from leavers is a known and unmeasured loss, when you have paid a lease penalty or a warranty on scrapped equipment in the last year, when your security team's endpoint list and your asset register differ by a number nobody wants to say out loud, or when acquisitions have left you with several estates that have never been reconciled to one another.

How to choose a developer for asset management

Ask what they would do with a device that appears in the endpoint console but has no purchase record. If they treat it as a data quality error, they have missed the point. It is a finding, and the system's job is to route it to someone who can explain it.

Ask how they intend to match records across systems when the identifiers do not agree, because serial numbers are formatted differently by different vendors and consoles, asset tags are frequently absent, and the join has to be tolerant with a human review path for ambiguous matches. Ask how the offboarding case closes, and listen for whether the answer involves a scan at receiving or a courier status. Ask what happens when an acquisition arrives with 800 untagged devices, since that is a real scenario in any organisation that grows by buying companies.

Agree ownership before kickoff: repository, cloud accounts and the freedom to bring in another firm, in writing. At Digital Heroes the client owns the code from the first commit. A first step you can run this week without buying anything: export your asset register, export the last ninety days of endpoint check ins, and count the records that appear in one and not the other. That number is the business case, and in most organisations of this size it is uncomfortable enough to end the debate.