Last updated: October 9, 2026
Software adoption is the share of a decision that actually runs inside the system you bought, not the number of people who hold a license for it. Adoption stalls when the platform needs inputs the operation cannot produce. Training does not create an input.
The vendor’s customer success lead sent me the usage export about an hour after I asked. Fourteen months of it. I want to be fair to her. She did not have to send anything.
Nine named seats. Three had signed in during the previous quarter. Two of those three were consultants from the implementation partner, still working through a data mapping task that had been scheduled to finish in month four.
So one employee was using it. He used the platform to look things up. Every covenant test the fund reported to its investors that quarter came out of a spreadsheet on a shared drive, and the version that counted was the one a single analyst kept.
Nobody at that firm was lazy. Nobody skipped the training, which had happened twice. The software was not bad. I have seen the same screen work well somewhere else.
This piece is about month fifteen. I work on the data side of finance and accounting operations, mostly for private credit managers and specialty carriers, and the unused platform is the single most common reason a firm calls me.
What Software Adoption Actually Counts
Count decisions, not seats. A borrowing base review is adopted when the exceptions it raises are raised by the system, queued for a named person, cleared in the system, and reconstructable nine months later. Anything short of that is a screen somebody visits.
Most firms measure the visit instead, counting licenses issued, licenses active, sessions per week, and a utilization percentage that lands in a board pack where nobody asks what it would mean for the number to be wrong. Those figures describe access. They say nothing about whether the work moved.
There is a worse version. A platform can show logins climbing quarter on quarter while the real work migrates further into Excel, because people sign in to read a number and then re-key it somewhere they trust more than the system of record.
I watched that for two quarters at a fund whose usage chart pointed up and to the right. The chart was honest. It measured the wrong verb.
National figures suggest the shallow pattern is ordinary. Census Bureau data put United States business use of AI at 19.8% as of early May 2026, with finance and insurance running ahead at 33.9% and firms of at least 250 employees at 37%. Plenty of buying. The question is what happened after the invoice cleared.
The Platform Asked for Something That Did Not Exist
When I get access to an unused system I do not start with the users. I start with the screen’s required fields. Then I go looking. Each field, in the firm’s actual records, until I find it or establish that it is not there.
Below is a composite of what that exercise turns up, assembled from several engagements rather than one. The left column is what the software needed. The middle is what the firm could hand it on the day.
| What the screen required | What the firm could produce | What the user saw |
|---|---|---|
| One borrower identifier, used everywhere | Four identifiers across loan system, administrator file, CRM, and the credit team’s sheet | Duplicate borrowers, and a portfolio total that did not tie |
| EBITDA, defined once | Reported EBITDA, adjusted EBITDA, and a sponsor figure with add-backs nobody had reviewed | A leverage ratio the credit committee would not sign |
| Covenant terms as structured fields | Terms in the credit agreement PDF, amended three times, two amendments unscanned | Blank tests, or tests built on superseded terms |
| A reporting date per borrower | Certificates arriving between day 12 and day 70, some never | A dashboard that was fresh and stale at once, with no label saying which |
| An owner for each flagged exception | No queue, and no name | A growing list of alerts nobody was accountable for closing |
Read the fifth row again. That one kills a rollout quietly.
A platform that flags exceptions and has nowhere to send them teaches its users something within about a month, which is that signing in generates obligations for them personally while producing no answer they can act on. Work, not answers. People are rational. They stop.
Not one of those five rows is a training failure. You cannot train somebody into having a single borrower identifier. It does not exist yet.
Row one is entity resolution, which is a project with a start date and an owner. Row three means reading the amendments and turning them into fields. Nobody enjoys row three.
That is work. Somebody has to be paid for it. No seat count changes that.
The Part Nobody Scoped
The tool you already bought is usually fine. What was never built is the road under it.
By road I mean a data foundation, which has a specific shape and a build order I have set out separately. Vendors do not sell it. They cannot. It is made out of your records and your rules, which is why it never arrives in a box.
It also requires somebody to make decisions a vendor has no standing to make. Which of two loan tapes ties. Whether a late certificate carries last quarter’s figure forward or shows as missing. Who may overrule the system, and where that gets written down.
Governance decisions dressed as data chores. At most firms I see they take weeks rather than quarters, and they almost never appear anywhere in an implementation plan, because the plan was written by the party who does not have to live with the answers.
While they stay unmade, one person is the database. You already know whose name that is.
Adoption now depends on that person, because any question the screen cannot settle lands in their inbox and the firm has quietly agreed this is the fast path. It is the fast path. That is the problem.
Three Functions Is the Ceiling. Six Was the Job.
The Census Bureau’s April 2026 working paper on the microstructure of AI diffusion measured depth instead of presence, which makes it the most useful adoption statistic I know of. Among firms using AI at all, 57% use it in three or fewer business functions. At the task level it is thinner, with 65% of firms confining use to three or fewer tasks.
Shallow, then. Not absent.
I ran the other version of this at a specialty finance investor. Phased across six functions, governance written down before the rollout, training built per role instead of per tool. Claude, GPT, and Copilot, each in the functions where it actually fit. Six years on, that program had shipped 34 solutions into production and lifted engineering productivity by 15%, and the data and AI operation was used as a differentiator in a nine-figure institutional raise.
Sequencing mattered more than tool choice. Not the shortlist. What made it hold:
- Each function got a named owner before it got a license. No owner, no rollout. That function waited.
- Training was written for the job rather than the software. An underwriter and a fund accountant were taught different things about the same model.
- Governance first. Not a committee. A written set of rules about what the system decides alone, what it drafts for a human, and what it may not touch.
- Every function carried a financial owner, so a pilot that stopped producing could be killed by somebody with standing to kill it.
- One function went first and went properly. Nothing else started until that one survived a full cycle.
Six is not a magic number. Depth beats breadth. A firm sitting at one function with nine licenses has not failed at software adoption so much as it has not started.
What You Still Own After the Signature
Buying a platform moves work. It does not move responsibility. The supervisory language here is blunter than most vendor conversations acknowledge.
The Federal Reserve, FDIC, and OCC’s 2023 Interagency Guidance on Third-Party Relationships says an institution’s use of third parties “does not diminish its responsibility” to meet safety, soundness and compliance requirements to the same extent as if the activity were performed in-house, and that using third parties “does not abrogate these responsibilities.” That guidance binds banking organizations rather than funds. It still matters to the rest of us, because it is the standard your bank counterparties answer to, and because LP and reinsurer diligence questionnaires borrow its structure wholesale.
NIST’s AI Risk Management Framework 1.0, published January 2023, makes the point structurally. Of its four functions, govern, map, measure, and manage, the framework calls govern “a cross-cutting function that is infused throughout AI risk management,” and asks it to cover third-party software and data plus the competencies of the people acquiring, deploying, and monitoring the system. Governance is not a gate at the end. It runs underneath.
Which returns the question to people. Every row in that table and every item in that list resolves to a named human with hours in their week, and the hours are the constraint rather than the software license. Pipelines and canonical records get built by data engineers. Exception queues get cleared by analysts who know the asset class.
Neither one ran the procurement.
Neither is the employee currently acting as the database.
If those seats do not exist at your firm, that is a hiring question rather than a software question. KORE1 has been placing them since 2005 and holds 92% twelve-month retention, which matters here for a dull reason. An exception queue handed to somebody who leaves in five months is a queue that stops being cleared.
Scope it by how long the work lasts. Data engineering staff augmentation for the build. An analyst on a contract engagement for the queue. A fractional chief data officer if what is missing is the person who decides which loan tape ties.
After the Invoice, These Come Up Every Time
We already bought the platform. Can you make it work?
Usually the platform is fine and the inputs are not, so the work is rebuilding records rather than replacing software.
I start by listing the screen’s required fields and going to find each one in your systems. That takes about a week. It tells you whether you are looking at a four-week data job or something structural. Replacing the platform before running that exercise means buying a second system with the same inputs.
How do we tell a training problem from a data problem?
Sit with your best user and watch them complete one real case in the system, start to finish, with no help.
Where they stop tells you which it is. If they stop because they cannot find the right button, train them. If they stop to open a PDF, call a colleague, or decide which of two numbers is right, no amount of training fixes that and you have just watched a data problem happen in real time.
Watch three people. The pattern shows by the second. There is also a readiness scorecard that walks one decision through seven links if you would rather do it on paper first.
Our vendor says the platform handles this. Why would we need anything else?
The vendor is describing what the software does once it receives clean, structured inputs, which is true and not the thing you are stuck on.
Separate the two claims next time you have them on a call. Ask who produces each required field, by name. Then ask what the system does when a field arrives late, arrives twice, or arrives with a value that contradicts the one already sitting in the record from last quarter.
The answers are usually reasonable. They are also about your side of the line.
Do we need a data hire first, or can we start without one?
Start without one.
The permanent search fails for the same reason the platform did, which is that nobody at the firm can yet specify the work, so the job description becomes a list of tools instead of a list of decisions. A fractional head of data gets you moving. You learn what the role needs by watching somebody do it for a quarter, then hire against a real specification. I would rather see one process genuinely running in the system by spring than a staffed org chart next year.
How long before anyone actually uses it?
Four to six weeks to get one process running properly, assuming an owner with protected hours.
That holds while the scope is one process. It collapses the moment somebody widens it to the whole portfolio.
One of our pilots has to go. How do we choose?
Cut the one with no financial owner.
Not the ones with poor results. A pilot with bad numbers and an owner is a pilot you can fix or stop deliberately, which makes it the healthier of the two cases even though it reads worse on a status slide.
A pilot with promising numbers and nobody accountable for its budget will run another year and change nothing. Nobody volunteers to cancel that one. For a structured version of the call there is a checklist for taking a pilot to production, and its gates work just as well in reverse.
Pull the Usage Export
Ask your vendor for twelve months of sign-in data by named user. Most will send it. Ask anyway. The ones who hesitate are telling you something too.
Then take the most important recurring decision that platform was bought to support, and read the record of how it was actually made last month. Not how the process document says it is made. Who touched it, which file they opened, what they re-keyed, and who they asked when two numbers disagreed.
If the answer runs through one person and a spreadsheet, you have your adoption number. It is not the one on the dashboard. Readiness is an operations question, and this is what it looks like at close range.
I would like to know what the export says. Connect with me on LinkedIn, then send me the seat count and how many of them were consultants. Where the missing piece is a person rather than a product, KORE1 recruits for exactly these seats.
