Most asset registers record what a device is. Recovering one requires knowing where it went and who has it, which is a different set of fields entirely, and it is usually the set that is missing.
TL;DR
- Model, specification and purchase cost describe an asset. None of them helps you get it back.
- Four fields decide whether recovery is possible: serial, assigned person, delivery address and issue date.
- The delivery address is the one almost nobody holds, and for a remote employee it is often the only address you have.
- Add a verified date with its method, or you cannot tell a current record from a two-year-old assumption.
- Add a data obligation state, which is what a security review asks for and what most registers cannot produce.
- Every extra field reduces the chance any given row is wholly right, so keep the set small and maintained.
Why registers are built for the wrong question
Asset registers originate in finance and in inventory, where the question is what do we own and what is it worth. That produces fields about the object: model, specification, purchase price, depreciation, warranty.
Recovery asks a different question entirely: where is this specific thing and who do I contact about it. A register that answers the first question perfectly can be useless for the second, and most are, because nobody designed them for a fleet that lives in people’s homes.
The fix is four fields, none of which is technically difficult and one of which is almost always absent.
The four that make recovery possible
| Serial number | Which physical object | The only identifier that survives a reimage, a rename or a change of tagging scheme |
| Assigned person | Who to contact | An individual, not a team. A team cannot post a laptop |
| Delivery address | Where to collect from | Usually the only address you hold for a remote employee, and usually stale |
| Issue date | Whether chasing is worth it | Turns a judgement into arithmetic about residual value |
The third row is the one to act on. Most registers inherit an office address from a time when everybody was in one, and for somebody hired remotely three years ago it may never have been updated since the original delivery.
A worked example
A company tried to recover fourteen devices from people who had left over the preceding year. The register was reasonably well maintained and held model, specification, purchase cost, warranty expiry and assigned person for every row.
Nine of the fourteen had no address beyond a country. Four more had an address that turned out to be a previous home. Only one could be acted on immediately, and the rest required tracing people through personal email to ask where they lived.
The register was not inaccurate. It recorded everything it had been designed to record, and none of it answered the question being asked. Adding a delivery address field and confirming it at the start of each notice period changed the recovery rate more than any process change that year.
Two more worth adding
Verified date, with the method. When somebody last confirmed the row was true, and how. Without it every row looks equally authoritative, so the register is only as credible as its worst entry and nobody can identify which that is. Record whether it came from a physical sighting, a scan, a user confirmation or an automatic management check-in, because those prove quite different things.
Data obligation state. Open, closed or never issued. A device that was assigned and has no recorded wipe is open regardless of where it physically sits, which includes machines in your own storeroom. This is the field a security questionnaire asks about and the one most registers cannot produce.
Both are derivable from data you already hold, which makes them cheap to add and easy to backfill.
Keeping the address current
What to do:
- Capture the delivery address at despatch, from the order, rather than relying on an HR record.
- Ask the employee to confirm receipt, which both verifies the device arrived and validates the address.
- Re-confirm the address at the start of any notice period, as a single line in the equipment message.
- Ask again whenever a device is replaced, since a refresh is a free opportunity to refresh the data.
- Record a phone number alongside it, because couriers need one and failed deliveries cost days.
- Never overwrite the previous address silently. Keep it, since a device may still be at the old one.
The last point catches people out. Somebody who moved house eighteen months ago may well have left a monitor or a dock at the old address, and an overwritten field destroys the only record of where it went.
What to leave out
Every field added reduces the probability that any given row is wholly correct, because each one is something that can be stale. A six-field register at 95 per cent accuracy answers more questions usefully than a twenty-field register at 60 per cent.
Leave out anything your management console already holds and can be joined on demand: MAC addresses, detailed specifications, operating system version. Duplicating console data means maintaining it twice and watching the two disagree, which actively reduces trust in both.
The test for any field is whether somebody will act differently because of it. A field nobody acts on is a field nobody maintains, and an unmaintained field is worse than an absent one because it looks like information.
The address and the serial both originate at despatch, which is why registers maintained by whoever ships the device are consistently better than those maintained by somebody downstream.
Snipe-IT supports custom fields and holds purchase dates and assignment. Its self-hosted edition is free and open source, and hosted tiers are published at $39.99 monthly or $399.99 annually for Basic.
AssetTiger is the hosted alternative, priced 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. Because it despatches the device, the serial and the delivery address are captured from the order rather than entered afterwards, which is precisely the gap this article is about. 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 options are compared in our laptop retrieval comparison.
Final thoughts
A register full of accurate information about hardware can be entirely unable to answer the only question that matters when somebody leaves. The difference is four fields, and the one that decides most outcomes is a delivery address that nobody thought to record because everybody used to sit in the same building.
Capture the address and serial at despatch, confirm receipt, re-confirm at notice, and add a verified date and a data obligation state. Then resist adding anything else, because the register that gets used is the small one people believe rather than the comprehensive one they check against something else.
Frequently asked questions
Which asset register fields actually matter for recovery?
Four: the serial number, the individual it is assigned to, the delivery address it was sent to, and the issue date. Serial because it is the only identifier that survives a reimage or a change of tagging, the person because a team cannot post a laptop back, the address because it is usually the only location you hold for a remote employee, and the issue date because it turns the decision about whether to chase into arithmetic rather than a judgement.
Why is the delivery address so often missing?
Because registers were designed when everybody worked in one building and the address was obvious, so the field either does not exist or holds an office nobody attends. For an employee hired remotely several years ago, the address used for the original delivery may be the only one the company ever had, and it will not have been updated since. It is also the field most likely to have gone stale quietly, since people move house without telling IT.
When should the address be confirmed?
At despatch from the order, again when the employee confirms receipt, at the start of any notice period as a single line in the equipment message, and whenever a device is replaced. The notice-period confirmation is the highest value of the four, since it costs one sentence and prevents a failed collection that would otherwise cost a week. Keep the previous address rather than overwriting it, because a monitor or dock may still be at the old one.
What is a data obligation field?
A simple state showing whether a device that held company data has an evidenced wipe: open, closed or never issued. The rule that populates it is that any device which was assigned and has no recorded wipe is open, regardless of where it physically sits, which includes machines in your own storeroom that nobody cleared on arrival. It is the field a security questionnaire asks about and the one most registers cannot produce, and it is derivable from data you already hold.
How many fields should a register have?
Six or so, and fewer than most templates suggest. Every field added is another thing that can be stale, so completeness and accuracy pull against each other, and a six-field register that is 95 per cent accurate answers more questions usefully than a twenty-field one at 60 per cent. The test for adding anything is whether somebody will act differently because of it, since a field nobody acts on is a field nobody maintains.
Should we duplicate data from our management console?
No. Anything the console already holds and can be joined on demand, such as MAC addresses, detailed specifications or operating system version, should stay there rather than being copied into the register. Duplicating it means maintaining the same fact in two systems and then watching them disagree, which reduces trust in both and creates work that produces nothing. Connect the console as a reconciliation source instead, since it is the only input that maintains itself.