One thing I have learned working with ITAM customers is that software implementation rarely creates a new process problem. More often, it reveals the one that was already there.
When I first speak with customers during implementation, the conversation usually starts with visibility. They want to know what assets they have, who owns them, where devices are located, what software is assigned, and which records need cleanup.
That is normal. Every ITAM program begins with discovery, validation, and cleanup.
But once the platform is live and real teams start using it, a different pattern becomes visible. The biggest compliance risks are not always inside the asset list. They sit between teams.
The takeaway is simple: ITAM maturity is not proven by a clean import. It is proven when teams agree on what “done” means across offboarding, returns, renewals, software reclamation, and ownership changes.
I have seen this across very different customer environments.
At one public health nonprofit, the offboarding process looked disciplined on paper. HR closed employee exits on time. IT recovered most of the assigned equipment. Security handled access reviews separately. But when the team started reviewing user-linked assets and software, former employees were still tied to devices and licenses. No one had ignored the process. Each team had done its part. What was missing was a clear handoff showing that the full workflow had been completed.
A global events company had a different version of the same issue. The gap appeared during software renewal planning. Finance had the spending data. Procurement had the contract timeline. IT had a current assignment and usage context. But those inputs were not coming together early enough. By the time IT reviewed usage, the renewal conversation was already moving. The company did not lack information. The right information reached the right team too late.
A distributed services organization identified an issue with asset ownership. Devices were being returned, loaned, shipped, repaired, and reassigned across locations. The physical work was happening. The records were not always kept up. A laptop could be sitting in storage while still appearing assigned to a former employee. A loaner device could quietly become a long-term assignment without a formal ownership update. When someone asked for evidence, the team had to rely on memory instead of the system.
That is where the compliance trail breaks.
Not because teams are careless. Not because IT does not understand the process. Not because the company lacks tools.
It breaks because everyone owns a piece of the workflow, but no one can always see whether the full workflow was completed.
What I look for after go-live
During implementation, most customers are focused on getting the foundation in place. They import asset data, validate owners, clean up categories, connect discovery sources, review software records, and agree on the basic operating model.
That work matters. But I do not judge ITAM maturity by the first data import.
I look at what happens a few weeks later.
Are teams using the platform when a device is assigned to them? Are returns recorded when the device actually comes back? Are software licenses reviewed when users leave? Are renewals checked against current usage before Procurement moves forward? Are exceptions documented where the related asset, user, software, or contract record can be reviewed later?
That is where operating discipline starts to show.
Some customers have imperfect starting data, but mature quickly because they make the system part of their everyday work. Others begin with cleaner inventory but still struggle because the real decisions happen in email, spreadsheets, Slack, or side conversations.
The difference is not just data quality. It is adoption.
The strongest customers are not the ones who start with a perfect asset list. They are the ones who make sure every important action has an owner, a record, and a next step.
The handoff is where ownership becomes visible
Most compliance gaps I see are really handoff gaps.
HR knows an employee has left. IT knows which devices were assigned. Security knows which access needs review. Finance knows which costs are tied to the user or department. Procurement knows which contracts are coming up for renewal. A department manager knows whether a tool or device is still needed.
The problem is that this context often lives in different places.
That is usually the moment a customer moves from saying, “We need better inventory,” to saying, “We need better operating discipline.”
Inventory answers the question: What do we have?
Compliance asks a harder set of questions: What happened to it? Who owned the action? Was the record updated? Where is the reviewable evidence?
A returned device is not fully resolved until the asset record reflects the return. A terminated user is not fully offboarded until assigned assets, licenses, access tasks, tickets, and approvals have been reviewed. A software renewal is not fully governed until the renewal count is checked against current usage and ownership.
I remember one customer describing their offboarding process as “mostly handled.” In Customer Success, that phrase always makes me pause.
Mostly handled often means the major steps are underway, but the evidence is spread across too many places. The laptop return is in one conversation. The ticket closure is in another system. The license decision is in a spreadsheet. The access review sits with Security. The manager’s approval is buried in an email.
Nothing is intentionally broken. But when someone asks for evidence, the team has to reconstruct the workflow from fragments.
That may work for a small team. It becomes fragile as the organization grows, teams become distributed, and audit expectations become more formal.
Inventory-only ITAM does not show the whole story
A static asset record can tell you that a laptop exists. It may show the last known owner, location, serial number, purchase date, and status.
That is useful, but it does not always answer the questions customers face during audits, renewals, offboarding, or internal reviews.
Who had this device before it was reassigned? Was the returned laptop placed in storage, sent for repair, or issued to someone else? Was the user’s software reclaimed after departure? Was access reviewed across the right systems? Was the renewal count based on current usage or historical purchase data? Who approved the exception?
Those questions require context, not just inventory.
I see this often with customers moving away from spreadsheets or older tracking methods. Their teams usually know more than the system does. Someone in IT “remembers” that a laptop moved into the spare pool. A manager knows a device was loaned to a new hire for two weeks. Procurement knows a renewal is coming. Finance knows the cost center. Security knows which access review was completed.
The knowledge exists. It just does not live in a place where the organization can reliably use it.
That creates risk when people change roles, teams grow, or audit questions require proof.
This is why I often tell customers not to think of ITAM as a list of assets. ITAM has to become the place where asset-related work is recorded.
That does not mean the platform replaces governance. It does not mean compliance becomes automatic. A tool alone cannot make teams accountable if the process is unclear.
But a connected ITAM platform like AssetSonar can make accountability easier to practice. When asset, user, software, ticket, contract, approval, and lifecycle context are easier to review together, teams can reduce the amount of manual reconstruction required after the fact.
Where I usually see the gaps appear
The first place I look is offboarding.
Offboarding looks simple on paper. An employee leaves; access is removed; devices are returned; licenses are reclaimed; and records are updated.
In practice, each of those steps may belong to a different team.
That is what happened with the public health nonprofit. HR was consistent about closing employee exits. IT was recovering devices. Security was reviewing access. But because the work was happening across separate systems and conversations, the final state was not always clear. Some assets still appeared assigned to former employees. Some software access needed a second review.
The customer did not have an intent problem. They had a visibility and ownership problem at the handoff.
The second place I look is asset ownership.
Loaner laptops, transferred devices, repaired equipment, spare inventory, and returned assets are easy to lose track of when updates happen outside the system of record. A manager may know where the device went. A technician may remember who picked it up. But if the system of record still lists the previous owner, the organization cannot fully trust that record during an audit, a support request, or an internal review.
The distributed services customer saw this with returned and loaner devices. Their IT team was doing the physical work. Devices were coming back. Replacements were being issued. Equipment was moving between locations. But the records lagged behind the real world.
Once the team moved return and reassignment reviews into the system of record, the conversation changed. Instead of asking, “Where is this device?” they could ask, “Why is this record still open?”
That is a better question because it gives the team something to act on.
The third place I look is software and license ownership.
This is where ITAM and SAM disciplines overlap. A license may still be assigned to a former employee. A user may have access to software they no longer use. A department may renew more seats than it needs because the renewal process is not tied to current usage or assignment context.
The global events company saw this during renewal planning. Finance and Procurement were not doing anything wrong. They were working from the information they had. But IT had a usage-and-assignment context that needed to enter the renewal conversation earlier.
Once that became clear, the customer began treating license review as part of the operating rhythm rather than a last-minute renewal task.
That is one of the maturity shifts I like to see. The customer stops treating software cleanup as an annual exercise and starts connecting license ownership to everyday lifecycle events.
The fourth place I look is evidence.
Many teams can complete the work. Fewer teams can easily show the trail.
That matters because compliance conversations often happen after the work is done. By then, the question is not only whether someone removed access, reclaimed a license, or updated a record. The question is whether the organization can see when it happened, who did it, and what related records changed.
Adoption is the control layer
This is the point I come back to often with customers: adoption is not just a usage metric. It is a control layer.
A customer can have strong discovery, clean imports, good categories, and detailed asset records. But if teams keep doing the real work outside the platform, compliance evidence will still be scattered.
The customers who mature fastest are the ones who decide what must happen inside the system.
Device assignment happens in the system. Returns are recorded in the system. Transfers update ownership in the system. License reclamation is reviewed in the system. Renewal decisions use current system data. Exceptions are documented in the system. Offboarding is not considered complete until the related records are closed.
That is when ITAM starts becoming operationally useful beyond inventory.
In adoption reviews, I try to move the conversation beyond, “Is the data accurate?”
That matters, but it is not enough.
A better question is: Are technicians updating records at the point of return? Are managers approving exceptions in a traceable way? Are licenses reviewed when users leave? Are renewal counts checked before purchase decisions are made? Are open ownership gaps reviewed before they become audit questions?
Those are not just data quality questions. They are accountability questions.
What I tell IT leaders to fix first
The first thing I tell customers is to define what “done” means.
This sounds basic, but it is often the missing piece. Teams know their individual tasks, but they do not always share the same definition of workflow completion.
For offboarding, “done” should not only mean the employee record is closed. It should mean assigned devices are recovered or accounted for, software is reviewed, access tasks are completed, approvals are recorded, and asset records reflect the final state.
For renewals, “done” should not only mean the contract was approved. It should mean the renewal count was checked against current usage, inactive assignments were reviewed, owners were confirmed, and exceptions were documented.
For asset transfers, “done” should not only mean the device moved from one person to another. It should mean the owner, location, custody record, and related tickets or approvals were updated.
The second thing I tell customers is to assign workflow owners, not just task owners.
A task owner completes an action. A workflow owner makes sure the outcome is complete across teams.
This is especially important in ITAM because assets touch so many functions. IT may own the platform, but the evidence trail depends on HR, Security, Finance, Procurement, and department managers doing their part too.
The third thing I tell customers is to make the system of record part of the work, not an afterthought.
If a technician recovers a laptop but updates the record later, there is room for drift. If a manager approves a software exception via email, but it is not tied to the user or license record, the evidence is harder to find. If Procurement renews a contract without current assignment data, spend decisions become disconnected from reality.
The fourth thing I tell customers is to review adoption with the same seriousness as data quality.
In our customer conversations, this is where the most useful coaching often happens. We look at whether teams are actually using the workflows they designed. We check where records are still being updated late. We identify which handoffs still depend on manual follow-up. We look for places where the platform has the right data, but the process has not changed.
That is usually where the next stage of value comes from.
The Customer Success lesson
The biggest lesson I have learned after working with ITAM customers is this: compliance is not something teams can rebuild at the end of the quarter when it’s time for a business review.
It is created in small operational moments.
When a laptop is assigned. When a device is returned. When a user is offboarded. When a license is reclaimed. When a contract is renewed. When an exception is approved. When a ticket is closed. When ownership changes hands.
Every one of those moments either strengthens the compliance trail or creates a gap someone will have to explain later.
AssetSonar can help by providing teams with a more connected operating context for assets, users, software, tickets, contracts, approvals, and lifecycle activities. But the real value comes when organizations use that context to build clearer ownership and better habits.
That is what separates ITAM, as an inventory project, from ITAM, as an operating discipline.
And from what I have seen in Customer Success, that is where compliance maturity really starts.
