SHEET 07 · BUYING · LESSON 2 OF 2 · SURVEY DATE: SEPTEMBER 2026
How to Run an Asset Inventory Proof of Concept
By Asset Inventory Ranked research team · 20 September 2026 · 3 min read
Bottom line
A useful proof of concept tests an asset inventory tool on your own estate against success criteria written before it starts: which sources it connects, how many known assets it gets right, which gaps it finds that you can confirm, and how its fixes reach your system of record. Keep the scope small and the timeline short.
Last updated 20 September 2026
Why run a proof of concept at all?
Vendor pages describe what a product can do. A proof of concept shows what it does with your data, your credentials and your network segments. It is also the fairest way to measure deployment effort: how long it takes to get API access to each source, or to place a scanner on each segment. Our scores come from public material only, so a proof of concept is where you check them against your own estate.
What should you decide before it starts?
- Scope: two or three network segments, one cloud account and the identity provider, rather than the whole estate.
- Sources: the five to eight tools the product must connect to, such as endpoint management, EDR, the directory, a cloud console and the CMDB.
- A known sample: 30 to 50 assets whose details you can confirm by hand, including a reimaged laptop, a renamed server, a retired device still in the CMDB and a cloud workload that was rebuilt.
- Owners and dates: who grants API access or network placement for each source, and by when.
- Success criteria, written down and shared with the vendor before day one.
Which success criteria work?
- Coverage: every in-scope source connected, and each asset class you care about present.
- Correlation: each sample asset appears once, with the right owner and status.
- Gaps: the tool finds devices missing an agent or a CMDB record, and a sample of them are confirmed by hand.
- Freshness: a change you make, such as starting a new cloud workload, appears within the time the vendor states.
- Write-back: one corrected record or ticket reaches your ITSM tool through its normal process.
- Effort: the hours your team spends, tracked from the first day.
How long should it run, and what does it cost to start?
Long enough to cover a full sync or discovery cycle for every source plus a few days of change, and short enough to keep attention: two to four weeks is usually enough for a scoped test.
Published trial terms make it easier to start. runZero offers a free, full-featured 21-day trial and a Community Edition for 100 or fewer assets. Lansweeper offers 14 days of full access and then a free tier up to 100 assets. Device42 offers a free trial download. JupiterOne's pricing page mentions no free tier or trial, and the other tools in our ranking do not publish trial terms on the pages we reviewed, so ask.
How do you compare two tools fairly?
Run them against the same scope and the same sample in the same weeks. Compare asset counts only after checking for duplicates: a higher total can mean more duplicates rather than more coverage. Score each tool against the criteria you wrote and weight them the way your team would. The calculator applies that method to our scores; you can apply it to your own results.
What should the final report contain?
- The sources connected, and the ones that failed with the reason.
- Sample accuracy: how many of the known assets were correct.
- Confirmed gaps by type, and who would own each fix.
- Team hours spent, and the setup still outstanding.
- A written price for your asset count and term.