IT Asset Management Services: A Practical Guide for Teams Deciding What to Outsource

TL;DR

• IT asset management services means paying somebody else to run some part of knowing what technology you own, where it is, and what it costs.
• Four categories are sold under this name and only two of them overlap. Buying the wrong one is the common and expensive mistake.
• Discovery finds what exists. A record tracks what you know about. Logistics moves the physical things. Advisory tells you what to do about it.
• Most teams need discovery and a record. Many buy logistics and wonder why unknown machines never appeared.
• Almost nobody in this category publishes a rate, and one vendor that does publishes a figure that is a floor rather than a price.
• The thing that fails afterwards is reconciliation. A service that produces a list nobody checks against reality produces an authoritative-looking fiction.

The Audit That Found Forty Extra Laptops

A company of about two hundred and forty people goes through a security certification. The auditor asks for an asset register, which exists, maintained by the IT team in a spreadsheet and reasonably current.

It lists 212 laptops. Finance's depreciation schedule lists 249. Nobody can explain the difference, and both numbers are defended confidently by the people who produced them.

The investigation takes three weeks. The spreadsheet is a record of machines IT bought and issued. The finance schedule includes 23 machines acquired with a small company eighteen months earlier, which were never added to the IT register because nobody from IT was in that integration. It also includes 14 machines bought on team cards below the approval threshold, which never passed through IT at all.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

So 37 of the difference is real hardware that exists, is being used, has never been enrolled in anything, and is not patched or encrypted to any known standard. The auditor's finding is not about the count. It is that the company cannot demonstrate control over devices it did not know it had.

Nobody was negligent and nobody kept a bad record. The IT register was entirely accurate about what IT had done, and the finance schedule was entirely accurate about what the company had paid for. Both were correct and neither was complete.

The real issue is not a bad spreadsheet. It is that a record of what you issued is not a record of what you own, and no amount of maintaining the first produces the second.

What That Investigation Cost

Worth putting shape to the three weeks in the opening story, because the cost of not having a register is almost never counted and the cost of having one always is.

Three weeks of elapsed time, with real effort from an IT lead, somebody in finance, and an operations person pulling records. Call it a fortnight of combined working days spread across three people whose actual jobs stopped being done. None of it was recorded against anything.

Then the remediation: 37 machines to locate, enrol, patch and encrypt, each requiring contact with whoever held it. That is a project of its own, running after the audit rather than before it, under a deadline set by somebody external.

And the audit finding itself, which does not disappear once remediated. It appears in the report, it gets asked about at the next review, and it becomes a thing the company has to explain during any subsequent diligence process.

Against that, a quarterly reconciliation is a couple of hours four times a year, and a discovery tool is a subscription. The reason companies do not buy them is not that the arithmetic is unfavourable. It is that the cost of the current arrangement is invisible until something forces a count, and by then the expensive version is already underway.

That is the honest argument for doing this work before anybody asks for it, and it is the argument that tends to move a finance conversation faster than any efficiency case.

When You Do Not Need This

While one person can see the whole estate. Under about sixty people with everything bought through one route, a maintained spreadsheet is genuinely sufficient and buying a service adds cost without adding knowledge.

When the friction is visible but contained. Somewhere around a hundred people the register starts drifting: reassignments unrecorded, the odd machine unaccounted for. Fixable with a quarterly reconciliation and somebody who owns it.

When it becomes a control problem. Past roughly two hundred people, or after any acquisition, or the first time somebody asks for evidence rather than a number, the gap between the register and reality stops being checkable by memory.

The edge case that overrides everything is an acquisition. Integrating another company's estate is the single most reliable way to acquire machines nobody has a record of, and it is the situation in the story above.

Why Issuing Records Are Not Ownership Records

The distinction underneath the opening story is worth stating directly, because almost every company that believes it has an asset register actually has an issuing log.

An issuing record answers: what did we give out, and to whom. It is created as a by-product of a process, which is why it is usually accurate about everything that passed through that process and silent about everything else.

An ownership record answers: what does this company own. That is a superset, and the gap contains four recognisable categories.

Machines acquired with a company. Hardware that arrived in a transaction rather than through purchasing.

Machines expensed below a threshold. Bought on a card by somebody who needed one quickly, legitimately approved, never routed through IT.

Machines bought in a market you do not serve centrally. A new hire somewhere remote needed a laptop on Monday, somebody local sorted it, and the central process never saw it.

Machines that changed hands informally. Reassigned between people during a reorganisation, with the record showing the original holder indefinitely.

Three of those four are not process failures. They are reasonable responses to real constraints, and trying to eliminate them by tightening approval usually just pushes the behaviour further out of sight.

The more productive framing is that any ownership record needs an input that does not depend on your process being followed. That is what discovery provides, and it is the structural reason the sequence in this article puts discovery first rather than treating it as an optional extra for large estates.

What Teams Actually Need

"What do we actually own?"

Not what you issued. What exists. These differ, and the difference is where the risk concentrates.

It matters because every compliance question, insurance renewal and disposal decision depends on the second number, and most companies only have the first.

"Where is each thing and who has it?"

Current holder, not original assignee. Machines move between people without anybody updating a record.

It matters because recovery, security response and valuation all require knowing who actually has a device today.

"What are we paying for, including software?"

Hardware is visible and bounded. Software seats are invisible and recurring, and they grow without the scrutiny hardware gets.

It matters because for most companies past a hundred people the software number is larger and less examined than the hardware one.

"Is any of this out of support or unpatched?"

Age, warranty state, patch currency and encryption status. These are the questions security reviews ask.

It matters because these cannot be retrofitted in the fortnight before a deadline, which is usually when they are asked.

"Who checks the record against reality?"

Somebody, on a schedule, against an independent source. Almost nobody has this.

It matters because an unreconciled register degrades silently and looks authoritative the whole time.

Find Your Own Gap Before You Shop

The opening story is a gap between two numbers. Finding yours takes an afternoon and it determines which of the four categories below you actually need.

Pull three counts from three places that do not derive from each other, which is the part that matters.

Compare them against each other rather than looking at any one in isolation. The differences are informative, and they point in different directions depending on which pair disagrees.

If finance counts more than IT, you have machines that entered outside your process, which is the acquisition and expensed-purchase problem. If IT counts more than your device management console, you have issued machines that were never enrolled, which is a security gap rather than an inventory one. If the people count substantially exceeds every device count, either people are sharing or something is missing from all your records.

A rough fourth check is worth doing because it is quick: divide total devices by headcount. Most office-based companies land somewhere between 1.1 and 1.4 machines per person once you include spares and specialist hardware. A ratio materially below 1 means your records are incomplete rather than that people lack machines.

What this produces is not a register. It is a sized problem, and a sized problem is what tells you whether you need discovery, a record platform, or simply a quarterly habit.

The Four Categories Sold Under This Name

Discovery

Tools and services that scan networks and endpoints and report what is actually present.

When it is right: when you suspect an unknown estate, which you should after any acquisition, any period of expensed purchasing, or any gap in ownership.

When it fails: discovery sees what is connected. Machines that are off, offline, or never on your network remain invisible, so it narrows the unknown rather than eliminating it. It also tells you nothing about cost.

Record and spend platforms

Software maintaining the register, joining hardware, software seats and people, with spend attached.

When it is right: when you know roughly what you have and need to keep it current, control software spend, and answer questions with evidence.

When it fails: these are fed by integrations and by you. They do not find anything you did not tell them about, which is why pairing them with discovery is so common.

Logistics and lifecycle services

Vendors who physically handle machines: buying, shipping, storing, retrieving, wiping, reselling.

When it is right: distributed teams whose actual difficulty is moving hardware and getting it back.

When it fails: on exactly the problem in the opening story. A logistics vendor knows about machines it handled. It performs no network discovery and no software licence management, so it will never surface the 37 machines nobody told it about.

Advisory and managed ITAM

Consultancies and managed providers who run the function: policy, process, reporting, sometimes staff.

When it is right: large or complex estates, or organisations with a regulatory requirement and no internal capability.

When it fails: when the underlying data is poor. Excellent process applied to an inaccurate register produces confident wrong answers faster.

What the Record Should Actually Hold

A register that lists machines is a start. A register that answers questions is a different thing, and the difference is about six fields.

Two of those are the ones that make a register trustworthy rather than merely populated.

Acquisition route sounds administrative and is diagnostic. If you can see that 14 machines arrived via expensed purchases and 23 via an acquisition, you know exactly where your process leaks and can close it. Without that field, the leak shows up only as an unexplained gap between two counts.

Status and resolution is what stops the register filling with fiction. A machine that did not come back is either recoverable or a loss, and leaving it in neither state is how asset lists end up containing hardware nobody has seen for two years. Deciding to write something off is not an admission of failure; it is the thing that keeps the rest of the list believable.

The practical point for a buying decision is that these are configuration questions, not product questions. Most platforms in this category can hold all six. Whether they end up holding all six depends on what you decide to capture, which is why defining the fields before choosing a vendor produces a better result than the reverse.

Three Ways Teams Buy the Wrong Category

The TL;DR claims that buying the wrong category is the common and expensive mistake. Here are the three shapes it takes, all recoverable and all costing roughly a year.

Buying a record when the problem is discovery. The most common, and the one in the opening story. A team knows its register is unreliable, buys a platform to maintain it properly, imports what it has, and ends up with an impeccably maintained version of an incomplete list. The 37 unknown machines remain unknown, because nothing in a record platform goes looking. The test is simple: ask whether your problem is that the list is messy or that the list is missing things. Those need different products.

Buying logistics when the problem is knowledge. Specific to distributed companies and genuinely expensive. Equipment vendors are visible, their value is obvious, and they solve a painful problem. They also only ever know about machines they handled, so a company buying IT asset management services from a logistics provider in the hope of a complete estate picture will not get one. That is not a failing of those vendors; it is a category boundary.

Buying advisory when the data is poor. A consultancy or managed provider applying strong process to an inaccurate register produces confident wrong answers more efficiently. Advisory is valuable once the underlying data is reasonable and premature before that, and the sequencing is easy to get backwards because process feels like the mature choice.

There is a fourth pattern worth naming, which is buying for a scale you do not have. Enterprise platforms in this space carry real implementation effort, and a company of a hundred and fifty people can spend two quarters configuring something a maintained spreadsheet and a quarterly reconciliation would have covered. The tell is a vendor conversation opening with workflow design rather than with what is currently going wrong.

How to Choose: Five Questions

Do you suspect you have an unknown estate?

If you have acquired a company, allowed expensed purchasing, or had a gap in who owned this, the answer is almost certainly yes. That points at discovery before anything else.

Is your bigger exposure hardware or software?

Count both roughly. For many companies past a hundred people the software number is larger, and the tools that address it are different.

What triggered this?

An audit, an acquisition, a renewal or a general sense of untidiness all point at different purchases and different urgency.

Who will own the record internally?

Name a person. A service without an internal owner produces a report nobody acts on.

Can you reconcile against something independent?

If your only check is comparing two systems that both derive from purchase orders, you have no check at all.

What an Auditor Actually Asks

Compliance is named several times above as the trigger, so it is worth setting out the questions, because they are narrower and more answerable than the anxiety around them suggests.

The request is factual and usually short. Produce a list of devices. For a sample, show evidence that each is encrypted and patched. Show who holds each one. Explain any difference between this list and your finance records.

That last question is the one the opening story failed, and it is asked more often than people expect, because comparing two of your own numbers is the cheapest test an auditor has.

Three findings recur and all three are avoidable in advance.

Devices outside management. Machines that exist and were never enrolled, so no control applies to them and none can be evidenced. This is the serious one, because it generalises: an auditor who finds a category of unmanaged devices reasonably asks what else is uncounted.

Assets with no resolution. Hardware neither returned nor written off, sitting in a register as though in service. This reads as poor control rather than as loss, and it undermines confidence in every other figure you present.

Evidence that is assertion. A register maintained by hand, with completion recorded by the person responsible for the task and no independent confirmation. It may be entirely accurate and it cannot be relied upon, which is a different thing.

The useful consequence is that preparing for an audit and fixing the underlying problem are the same work. Discovery addresses the first finding, a status field addresses the second, and a quarterly reconciliation against an independent source addresses the third. None requires buying IT asset management services, though a platform makes the evidence easier to produce on demand.

The Options

Lansweeper. Network discovery and inventory, the established name for finding what is actually connected. Best for the problem in the opening story, which is machines nobody recorded. Publishes no rate; the single currency figure on its pricing page is a customer savings claim rather than a price. Where it struggles: it finds devices and does not manage spend or handle anything physical.

Setyl. Asset and spend records joining hardware, software and people, starting from $300 per month on its entry tier with Advanced and Advanced Managed quoted. Best when the question is what you pay for rather than what exists. Read the published figure as a floor, since actual cost is driven by asset count, user count and integrations. Where it struggles: it is a record rather than a scanner, so it reflects what feeds it.

Josys. Device and SaaS management together, joined by the person. Publishes no rate. Best for the joined view across hardware and applications. Where it struggles: no physical logistics, and the same dependence on integrations as any record tool.

Torii. SaaS management and spend. Publishes no rate. Best for the software half specifically, which is frequently the larger and less examined number. Where it struggles: hardware is largely out of scope.

Oomnitza. Asset workflows and automation across an estate. Publishes no rate; its pricing page carries a customer case study figure rather than a price. Best for larger estates with real process requirements. Where it struggles: enterprise-shaped implementation effort that a mid-sized company may not want.

Scalefusion and Miradore. Device management rather than asset management, included because they are regularly confused with it. Both publish rates. They enforce policy on enrolled machines and tell you about encryption and patch state, which is a genuinely useful input to an asset picture, but neither is an asset register and neither finds unenrolled hardware.

RemoAsset. Equipment logistics covering buying, renting and leasing, with shipping, retrieval, storage and wiping, plus a register of the devices it handled. Disclosure: RemoAsset is our own product. We build it, which is why it appears low on this page rather than high, and why its limits are stated plainly. It is deliberately not the recommendation for the problem this article describes. It performs no network discovery, so it would not have found the 37 machines in the opening story, and it performs no software licence management, so it has nothing to say about seats or renewals. Its Subscription tier is the only tier that publishes a figure, from $1,499 per year. Where it genuinely helps is the physical half: getting machines to people, getting them back, and knowing the state of the ones it handled. If your difficulty is knowing what you own, start with discovery and a record platform and treat this as a separate purchase for a separate problem.

The Software Half, Which Is Usually Larger

Hardware dominates these conversations because it is physical and countable. For most companies past a hundred people, software is the bigger number and receives a fraction of the attention.

The asymmetry has a simple cause. A purchase of 40 laptops is a single visible event that triggers approval. An equivalent annual spend accumulating across dozens of per-seat subscriptions, bought a few seats at a time by different teams on different cards, triggers nothing until a renewal lands on somebody's desk.

Three patterns account for most of the waste and all three are findable.

Seats attached to nobody. People left, the account was disabled, the seat kept billing. This is the single most common finding and the easiest to quantify: match your seat counts against your current employee list and the difference is money leaving monthly.

Duplicate tools doing one job. Two teams independently bought different products for the same purpose, neither knowing about the other. Consolidation is a negotiation rather than a cancellation, and the renewal date is the moment of maximum influence.

Tiers bought for a feature nobody uses. Somebody upgraded for a specific capability two years ago, the project ended, the tier persisted. Nobody downgrades anything by default.

What makes this tractable is that it is a records problem rather than a discovery one. Unlike hardware, software spend leaves a complete trail in your finance system, so the data already exists and simply is not joined to people.

That is why the platforms covering both sides, joining a person to their machines and their seats, tend to pay for themselves on the software half even when hardware was the reason somebody started looking.

The Decision Table

The Reconciliation That Makes All of This Real

Every category above produces a list. Only one habit makes a list trustworthy, and it is the cheapest thing on this page.

A reconciliation is a check of the record against the world, not against another record. Most inventory reporting is the second thing, which is why it so reliably produces confident wrong answers.

Run it quarterly and sample rather than auditing everything, unless the estate is small enough to cover completely. Thirty rows checked properly takes a couple of hours and gives you an error rate, which is the number you actually need, because it tells you whether your register is a document or a decoration.

Four checks cover most of it. Confirm the machine exists, by asking the named holder to read back a serial number. Confirm the holder is current, by matching the register against payroll. Confirm the status is true, by comparing anything marked as spare against the actual store. And confirm the value is current, by checking age against your depreciation schedule.

The payroll match is the one that finds real money, it takes about five minutes, and it is the check almost nobody runs despite both lists already existing. It reliably surfaces machines assigned to people who left months ago, and the distinction between those being lost and those sitting in a drawer matters, because one is a write-off and the other is a device you can reissue.

The failure to avoid is reconciling against a system that shares your register's ancestry. If your platform and your register both derive from purchase orders, comparing them proves only that the import worked. The check has to touch the physical world or a genuinely independent list.

What makes this work is that it is small and scheduled. An annual full audit becomes a project, gets deferred, and is eventually done badly under time pressure. A quarterly sample of thirty is a Tuesday afternoon, and it catches drift while the drift is still correctable.

The First Ninety Days

If you decide to act, the sequence matters more than the vendor, and a good share of the value arrives before anything is bought.

Weeks one to two. Run the three-count comparison from earlier. Do not design anything and do not book demos. The output is a sized gap, and a sized gap makes every subsequent conversation shorter and more specific.

Weeks three to six. Close the discovery question. If the gap is small and explainable, you may not need a scanning tool at all and a quarterly habit will hold the line. If the gap is substantial, this is where discovery earns its cost, and it is worth doing before choosing a record platform so that the platform is sized against reality.

Weeks seven to ten. Fix the inputs rather than the outputs. Decide how an expensed machine gets recorded, who adds acquired hardware, and what happens when a device is reassigned. These are small process changes and they determine whether your register stays accurate after the initial effort fades.

Weeks eleven to twelve. Establish the reconciliation. Thirty rows, quarterly, against payroll and a physical sample, with a named owner. Put the first one in a calendar before the project loses momentum, because this is the step that is always intended and rarely scheduled.

Then compare the counts again. If they have converged, the remaining question is whether a platform saves enough manual effort to justify itself, which is a much easier decision to make with accurate data than with a suspicion.

One caution about ordering. The instinct after a gap is discovered is to buy a record platform immediately, because it feels like the thing that fixes registers. A platform populated from an incomplete picture produces a tidy, confident, incomplete picture, which is harder to challenge later than an acknowledged gap.

The Cost of Getting This Wrong

Three layers, and only the first gets a budget line.

The visible cost is the subscription or service fee, and it is the smallest number here by a wide margin, as the previous section sets out. It is also the only one that appears in a proposal, which is why proposals are a weak basis for this decision on their own.

The second layer is the time spent reconstructing. Three weeks of investigation in the opening story, performed by people whose actual jobs were something else, triggered by a question that would have taken an afternoon to answer with a current register. That work recurs at every audit, every insurance renewal and every diligence process.

The third layer is the one that actually matters, and it is a control problem rather than a cost. An organisation that cannot demonstrate what it owns cannot demonstrate that its security controls apply to everything, because some of the estate is outside the controls by definition. That is a finding, and it is the kind that generalises: if you did not know about 37 laptops, what else do you not know about?

So the question is not what IT asset management services cost. It is this: if somebody asked you today to prove that every device your company owns is accounted for, patched and encrypted, how much of the answer would be evidence and how much would be the assumption that your issuing records are complete?

Acquisitions Are Where Estates Go Wrong

The opening story turns on an acquisition, and that is not a coincidence. Integrating another company's technology is the single most reliable way to acquire hardware nobody has a record of.

Four things happen at once and each one breaks a different assumption.

The acquired estate arrives with its own record, of its own quality. Sometimes good, frequently a spreadsheet maintained by somebody who has since left. Whatever its state, it was built to answer that company's questions rather than yours, and merging it is a data exercise nobody budgets for.

Nobody owns the merge. Integration plans cover systems, contracts and people. Device registers sit below the threshold of attention, so they are handled by whoever has capacity, which is usually nobody for several months.

The acquired machines are enrolled in something else, or nothing. They were managed by a different platform under different policies, and bringing them into yours requires touching every device. Until that happens they are outside your controls while appearing, to an auditor, to be your responsibility.

The purchasing routes differ. The acquired company may have expensed hardware, used a different supplier, or let people buy their own. Those habits persist after the acquisition unless somebody actively changes them, which means the leak continues.

The practical response is to treat the device estate as an explicit integration workstream with a named owner, even when it feels too small to warrant one. Discovery first, because the acquired record cannot be trusted and should be verified rather than imported. Then enrolment, because unmanaged machines are the actual exposure. Then the register merge, which is clerical once the first two are done.

Doing this in the first ninety days is substantially cheaper than doing it during a certification two years later, which is what the opening story describes.

When You Are Ready to Move Beyond the Spreadsheet

The spreadsheet is rarely the problem and replacing it with software fixes nothing by itself. Plenty of companies run three hundred machines on a well-maintained sheet because one person takes it seriously and reconciles it quarterly. Plenty of others own a platform and a register that is substantially fiction.

What changes the answer is unknowability rather than volume. When machines enter the company through routes nobody controls, when acquisitions bring estates nobody documented, and when the people who would notice are no longer close enough to notice, the limiting factor stops being effort and becomes visibility.

At that point the sequence that works is discovery first, record second, process third. Find out what exists, put it somewhere that stays current, then build the habit of checking. Teams who buy the record platform first spend six months carefully maintaining an incomplete picture, which is a worse position than an acknowledged gap because it feels finished.

There is one more thing worth saying about timing. The companies that do this well almost never started because somebody decided asset management was important. They started because an audit, an acquisition or an insurance renewal forced a count, and then kept the habit afterwards because the count had been painful. If none of those has happened to you yet, you have the rare advantage of being able to do it calmly, which is both cheaper and considerably more accurate than doing it under a deadline.

And reconcile against something independent. Comparing your platform against your purchase history proves nothing, since both come from the same orders. The checks that work touch the physical world or a genuinely separate list, and the cheapest useful one is matching holders against the current payroll.

Frequently Asked Questions