An ITAM implementation rarely fails because the software was wrong. It fails because somebody tried to record everything, the register reached about 60 per cent coverage, and nobody could say which 60 per cent. Scope is the whole game.
TL;DR
- Decide what you are not tracking before you decide what you are. That single choice determines success.
- Month one is scope and one authoritative source. Month two is loading reality. Month three is the recurring process.
- Partial coverage is only dangerous when it is undeclared. Known gaps are fine.
- Name the owner before the tool. An unowned register degrades within two quarters regardless of product.
- Two tools in this market publish prices; the rest need a demo, which sets your timeline.
- If you cannot say what the register is for, you are not ready to start.
The decision that makes or breaks an ITAM implementation
Write down what is out of scope, explicitly, and get somebody senior to agree it. Monitors. Cables. Personal phones. Anything under a value threshold. Meeting room hardware.
This feels like an admission of defeat and it is the opposite. A register covering laptops completely is useful. A register covering laptops, monitors, docks, phones and peripherals at 60 per cent each is useless, because no number it produces can be defended to anybody who asks how it was derived. Narrow and complete beats broad and partial every time, and the teams who accept that early finish their ITAM implementation with something people actually rely on.
What to do: state the purpose in one sentence first. Usually it is one of three: we need to know who has what for offboarding, we need to answer an auditor, or we need to forecast refresh spend. Each implies a different scope, and trying to serve all three at once is how scope creep starts on day two.
Month one: scope and a single source of truth
Pick one authoritative source per fact. Who holds a device comes from one place. Its serial comes from one place. If two systems can answer the same question, somebody will eventually have to reconcile them and nobody will own that job.
Define the fields you will report on. Not record. Report on. For most teams that is serial, model, holder, location, status and purchase date. Six fields. Every additional field is a form somebody has to fill in and a column that will be half empty.
Name the owner, with hours. Roughly half a day a month in steady state. Without a name this project produces a register that was accurate once.
Month two: load reality, not the ideal
Import from procurement records rather than from a spreadsheet somebody maintained, because purchase records are the one source that was accurate at the moment it was created.
Then verify a sample rather than everything. Twenty records, checked against the named holder. The point is not to fix twenty records; it is to learn your error rate before you publish a number anybody relies on.
Checklist for the load:
- Import from purchase and shipping records first
- Mark every imported record as unverified until somebody confirms it
- Verify a twenty-record sample and record the error rate
- Resolve duplicates before anybody sees the register
- Leave out-of-scope categories out, even where data exists
That second item matters more than it sounds. A register where everything looks equally confirmed on day one teaches people to trust records that nobody has checked.
Month three: the process that keeps it true
A register is a snapshot unless something updates it, and the something has to be an event that would happen anyway.
Tie updates to actions, not to memory. Ordering, shipping, assigning, reassigning, retrieving and wiping all have to happen regardless. Each one should write to the register as a side effect. Anything that depends on somebody remembering afterwards will decay.
Reconcile against people monthly. Compare the holder list against your directory and chase every difference. This is the only mechanism that catches a leaver whose laptop never came back, because a device in a drawer looks exactly like one that is switched off.
Report two numbers forever. Devices known, and devices confirmed within your window. Quoting the first alone is how an overstated figure reaches an auditor, and it is a hard position to recover from because the correction always sounds like an excuse. Build both numbers into whatever report you publish from month three onwards, so nobody ever has to ask which one they are looking at.
What the tools publish
Read from each vendor’s own page on 16 October 2026, with script and style blocks stripped first.
| Option | Published pricing | Fits an implementation that |
|---|---|---|
| AssetTiger | $15 a month unlimited items, $20 a month to 500 assets, then $40, $75, $140 and $275 | Needs a cheap register fast |
| Snipe-IT | Free self-hosted; hosting from $399.99 a year | Has somebody to run it |
| Lansweeper | No figure published; free tier available | Starts from an office network |
| Device42 | No figure published | Needs infrastructure relationships |
| Asset Panda | No figure published | Tracks non-computer assets too |
| RemoAsset | No figure published, quote-based with a demo required | Wants records created by shipping and retrieval |
RemoAsset. Worth considering for month three specifically, because the recurring-process problem is the one it addresses: assignment and retrieval write to the record as a consequence of the action. Disclosure that should shape how you read this: RemoAsset is owned by the same people who publish this site. Where it struggles, stated plainly: pricing is quote-based and requires a demo, so it cannot be benchmarked against the published ladders without a call; and it is a newer platform with a smaller footprint than the legacy global resellers. It covers devices it handles, so anything already in the field or bought elsewhere still needs importing and verifying like any other record.
Check the figures against the source before committing: AssetTiger and Snipe-IT both publish openly.
Final thoughts
Every successful ITAM implementation we have seen was narrower than the one originally proposed. The teams who did well decided what to ignore, covered the rest completely, and declared the gap rather than hiding it.
The ones that struggled chose a tool first, tried to record everything, and ended up with a system nobody quite trusted and nobody wanted to decommission. Scope and ownership decide this long before the product does.
How long should an ITAM implementation take?
Ninety days is realistic for a defined scope, split into scope and source selection, loading and verifying, then building the recurring process. The temptation is to compress it by loading data in week one, which produces a register full of unverified records that people then treat as fact. The last month, where updates get tied to events, is the part that determines whether it still works in a year.
What should we decide first?
What you are not tracking, agreed by somebody senior and written down. Monitors, cables, personal phones and anything under a value threshold are the usual exclusions. A register covering laptops completely is useful, while one covering five categories at partial coverage is not, because no figure it produces can be defended.
How many fields do we need?
Around six for most teams: serial, model, holder, location, status and purchase date. The test is whether you would report on a field, not whether you might record it. Every extra field is a form somebody has to complete and a column that ends up half populated, and half-populated columns are what make a register untrustworthy a year later.
Where should the initial data come from?
Procurement and shipping records, because those were accurate at the moment they were created, unlike a spreadsheet that has been edited by several people over two years. Mark everything imported as unverified until a human confirms it, then verify a twenty-record sample to establish your error rate before publishing any number that somebody will rely on.
What keeps the register accurate afterwards?
Tying every update to an action that has to happen anyway: ordering, shipping, assigning, reassigning, retrieving or wiping. Anything depending on somebody remembering to update a record after the fact will decay, usually within two quarters. Add a monthly reconciliation against your directory, which is the only method that catches a leaver whose equipment never came back.
Is partial coverage acceptable?
Yes, provided it is declared. A register that covers laptops and says plainly that it excludes peripherals is trustworthy within its scope. The damaging version is undeclared partial coverage, where records of varying age and confidence appear in one list with no indication which is which, and somebody quotes the total to an auditor or an insurer.
