Published September 22, 2026 · Altvina Insights · 5 min read

The Tool Works Fine. The Gap It Was Bought to Close Is Still Open.

Adoption is not integration. Three questions to run against your last significant purchase, a tool, a hire, or a new process, to find out whether the handoff it was bought to fix actually changed.

Pull up the last significant thing you bought for the business. Software, a hire, a process somebody wrote up and circulated. Now finish this sentence out loud: it was supposed to change the handoff where ___ sends ___ to ___ so that ___ can do ___. If that sentence does not come easily, the next twenty minutes are worth spending.

Adoption is real, which is what makes this hard to spot

The thing usually works. People log in. Every seat is paid for and used. Two or three people use it well enough to demo it to a skeptical colleague. By every measure a vendor tracks, the purchase was a success.

And the work either side of it sits exactly where it sat before.

The numbers on the largest version of this problem are blunt. Writing up MIT's 2025 survey of 300 public enterprise generative AI deployments, Boston University's Questrom School notes that 95% of enterprise generative AI pilots show no measurable impact on profit or loss. Those are funded, staffed, sponsored programs at companies with change managers on payroll. Not shelfware. Working tools, with nothing showing up downstream.

Small firms are buying at pace too. The U.S. Chamber's Empowering Small Business survey found 58% of small businesses say they use generative AI, up from 40% in 2024. But the Federal Reserve's 2025 Small Business Credit Survey supplement draws the harder line: about 60% of small firms are either using AI currently or planning to use it, but far fewer describe it as fully integrated into their operations.

Buying is a decision you can finish in an afternoon. Integrating is not a decision at all, it is a redesign, and nobody sells you that part.

The shape predates AI by decades. The same thing happens when a firm hires a coordinator to take scheduling off the owner, buys a project tool to end the status meeting, or writes an intake process nobody routes through. Across the small service firms we see, this shows up often enough that we now ask about the last purchase before we ask about the current problem.

Three questions to ask about your last significant purchase

Do this on paper, for one purchase, and stay out of the tool's dashboard. Usage stats will tell you the thing is being used. That was never the question.

1. Which handoff was this supposed to change?

Name it as a transfer between two people, not as an outcome. "Better visibility" is not a handoff. "The project lead stops asking each tech for a verbal update on Monday because the status is already written down" is a handoff.

Without that sentence, you did not buy a fix. You bought a capability and hoped a fix would form around it. Nothing shameful in that, and it is also the whole reason the gap stays open.

2. Did that handoff actually change?

Ask the two people on either end, separately, in plain words: what do you do now that you did not do a year ago, and what did you stop doing? Their opinion of the software is beside the point. What they stopped doing is the evidence.

When nobody can name something they stopped, nothing changed. Work got added, and a new place to look got added. The old path is still open, and open paths get used, because on a busy Thursday the known route is faster than the correct one.

3. What is still routing around it by hand?

The third question earns its keep. Something is carrying that handoff, and the answer is almost never nothing. Look for the shape of it: a spreadsheet that gets exported and re-keyed, a recurring check-in that exists to reconcile two systems, a chat thread where the real decisions happen, one person who gets asked because they know which record to trust.

A rough threshold we use: when the workaround has a nickname, it is load-bearing. People only name the things they rely on.

Why the answer is usually not a different tool

Offered as our judgment rather than fact: when capability gets bought and the work does not change, the purchase is rarely the mistake. The buy is a symptom, and what it points at is a process that only ever existed in somebody's head.

Software is sold into a documented process. It expects to know who does what, in what order, and what counts as finished. Plenty of small firms run beautifully without any of that written down, because judgment lives with the owner, or with the one senior person who has seen everything twice. That works, right up to the moment you try to hand a piece of it to a system, a new hire, or a template.

At that moment the tool has nothing to attach to. So it gets installed next to the process instead of into it, and the person whose head holds the real sequence quietly keeps holding it, now with an extra login.

Which is why a second purchase rarely fixes what the first one missed. Same gap, new interface.

What to do with your answers this week

Take the workaround you named in question three and write that handoff down the way it actually happens. Describe it as it runs on a bad week, not as the vendor diagrams it and not as you wish it ran. Who starts it, what they need in hand before they can start, what "done" means, who gets it next, and what that next person does when the input is wrong or late.

Our expectation, and hold us to it: one page, about half an hour, and a stretch in the middle that stings, because the exercise has a way of putting two contradictory assumptions in the same room for the first time.

Then decide one thing and one thing only: does the tool you already own support that written sequence, or not? Should it support the sequence, the fix is a rule and a default rather than a purchase. And where it genuinely does not, you are holding a specification instead of a hope, which is a far better thing to take shopping.

The uncomfortable version, and the one worth sitting with: a page you cannot write at all means the gap was never in your software. An undocumented process wearing a tool's clothes, and no second purchase will dress it any better.

Content and Accuracy Disclaimer

This article was drafted with AI assistance and reviewed by the Altvina team. We rigorously fact-check all content to ensure reliability.

Should you notice any inaccuracies or outdated information, please contact us so we can correct it. Your feedback helps us maintain high standards of accuracy and transparency.