Devices are almost never lost while somebody is using one. They are lost in the moment responsibility moves between teams, when the machine briefly belongs to a handoff rather than to a person, and nothing enforces the transfer.
TL;DR
- Endpoint lifecycle management is usually described as five stages. The useful subject is the four transitions between them.
- Each stage has an owner at most companies. The transitions generally have none, which is where the register stops matching reality.
- The fix is the same at every handoff: the record changes at the moment the device moves, performed by whoever moved it.
- Batch updates written later from memory look authoritative and are the main source of drift.
- Sample twenty rows a quarter and record which handoff each failure came from. That tells you which one is leaking.
- A tool imposed on undefined ownership produces a well-structured record of a process nobody follows.
The five stages, briefly
Procurement, deployment, maintenance, retirement from the user, and disposal or resale. Four of the five are owned by IT at most companies and run reasonably well, because each has somebody waiting on it and therefore somebody chasing it.
The exception is retirement, which is owned by a mixture of HR, IT and a departing person’s manager, which in practice means owned by nobody for a period of days or weeks.
Listing the stages is the easy part and it is not where the value is. Everything useful happens at the joins.
The four handoffs
| Supplier to register | Device reaches a person before it reaches the record | Record on despatch from the serial on the order, not on receipt |
| Register to user | Assigned to a name with no confirmation it arrived | Require the user to confirm receipt, which also captures the address |
| User to custody | Device in a cupboard, record still says assigned | Change the record on arrival, by whoever opens the box |
| Custody to outcome | Disposed of with no certificate linked to the asset | Close the record only on evidenced wipe or certificate |
Each is a two-line process change rather than a project, and the pattern is identical in all four. Any design where somebody updates the register afterwards, in a batch, from memory, will drift.
A worked example
A company with 611 devices in its register was asked by an auditor to pick twenty rows at random and show the device. Fourteen checked out.
Of the six that did not, three were with people who had left between four and eleven months earlier, two were in a cupboard while the register showed them assigned to employees who had since been issued replacements, and one had been returned, assessed as broken and sent for disposal eighteen months previously by somebody who no longer worked there.
Every one of the six failed at a boundary. Not one was lost while in use, in procurement, or during disposal. Five stages had owners and four transitions did not.
Finding which handoff is leaking
What to do:
- Pick twenty register rows at random, using a random number rather than judgement.
- Verify each by evidence: a physical sighting, or a management check-in within the last fortnight with the assigned name matching.
- Record the failure type for each miss: wrong state, wrong person, serial mismatch, or does not exist.
- Map each failure type to the handoff it came from, since the four correspond directly.
- Fix the handoff rather than the twenty rows, because the other 591 have the same error rate.
- Repeat quarterly and write the percentage down with the date.
A good quarter produces one number and one sentence: accuracy was 88 per cent, and six of seven failures were devices in custody still showing as assigned. That sentence names the handoff and its owner, which is the entire point.
The field that is usually missing
Most registers record what a device is. The ones that get trusted record when somebody last confirmed it, and how.
Without it every row looks equally authoritative, so the register is only as credible as its worst entry and nobody can tell which that is. With it, a row verified last month is treated as fact and a row last touched two years ago is treated as a lead.
Record the method too, because the four are not equivalent. A physical sighting proves most and scales worst. A management check-in is automatic and proves only that a device with that identifier was online, which is a weaker claim than it appears. For a distributed fleet the workable combination is check-in as the continuous signal plus an annual user confirmation asking people to read the serial from the underside of their machine.
Where tooling helps and where it does not
Define the owners first. A tool imposed on undefined ownership produces a tidy record of a process nobody follows, which is the common and expensive outcome.
Snipe-IT is a genuine register and its self-hosted edition is free and open source, with hosted tiers published at $39.99 monthly or $399.99 annually for Basic.
AssetTiger is the hosted alternative, priced by asset count at $20 a month for 500 assets and $40 for 2,500, reducing to $18 and $37 on annual billing, with unlimited users. Its 250-asset tier is a 30-day trial rather than a permanent free plan.
Disclosure: RemoAsset is owned by the same people who publish PeopleOpsHQ. It addresses the two physical handoffs directly, since it creates the record at despatch and changes it on receipt rather than relying on anybody remembering. It publishes no price and requires a demo, it is much weaker for hardware it did not supply, and it is not a certified disposal vendor. The lifecycle options are compared in our device as a service comparison.
Final thoughts
Endpoint lifecycle management is sold as a five-stage model and lived as four unowned transitions. The register does not become inaccurate because anybody is careless; it becomes inaccurate because the moment a device changes hands is the moment nobody is accountable for it.
Name an owner for each handoff, change the record when the thing moves rather than afterwards, add a verified date with its method, and sample twenty rows a quarter. That is a page of process and it addresses most of what makes a register untrustworthy, long before any tool is involved.
Frequently asked questions
What is endpoint lifecycle management?
It covers a device from purchase through deployment, maintenance and retirement to disposal, usually described as five stages. The more useful framing is the four transitions between those stages, because devices are rarely lost inside a stage where somebody owns them and are routinely lost at the boundaries where responsibility moves between teams. A tool that talks only about the stages and not the handoffs is describing the easy half.
Why do asset registers become inaccurate?
Because the record is updated after the fact rather than at the moment the device physically moves, usually by somebody who did not handle it and is working from a message. Batch updates written later from memory look exactly as authoritative as records created at the point of movement, which is why the drift is invisible until somebody samples. The single most effective change is to require whoever moved the device to change the record then.
Which handoff causes the most problems?
The one from a user back into your custody, meaning a device returned after somebody leaves or is upgraded. It is the only transition with nobody waiting on the outcome, since every other stage has a person who wants something, and a returned device in a cupboard has no customer. That absence of pressure is why it drifts, and it is why devices sit marked as assigned to people who left months earlier.
How do we measure register accuracy?
Sample rather than count. Take twenty rows chosen at random rather than by judgement, verify each by physical sighting or a recent management check-in with the assigned name matching, and express the result as a percentage recorded with the date. Correcting the sampled rows is worth little on its own, because the rest of the register has the same error rate, so the value lies in recording which handoff each failure came from and fixing that process.
What should we record beyond the basics?
The date somebody last confirmed the record was true, and how they confirmed it. Without that field every row appears equally reliable, so the whole register is only as credible as its worst entry and nobody can identify which that is. Recording the method matters because a physical sighting, a scan, a user confirmation and an automatic management check-in prove quite different things, and a register whose rows are all check-ins knows only that its devices were powered on somewhere.
Should we buy a tool or fix the process first?
Process first, by a clear margin. A tool applied to undefined ownership produces a well-structured record of a process nobody follows, which is worse than a spreadsheet because it also cost money and created an expectation. Write the five stage owners and the four handoff owners on one page, run it for a quarter, sample at the end of it, and the tooling requirement becomes both obvious and considerably narrower than any vendor will propose.