51% of Software Operators Say Fewer Than 1 in 4 Customers Use the AI They Built

More than half of software operators say fewer than one in four of their customers actually use the AI features they built.

That's from Banyan Software's first State of AI for Vertical Market Operators report, published this July and based on more than 260 founders, CEOs and operators of vertical market software companies. Banyan's summary of the finding is short and a little brutal: "Deployment, not development, is the industry's biggest AI challenge."

It's worth being precise about who that is. Vertical market software is built for a single industry, and its customers tend to be busy operators who use the product to get a job done, not to explore it. So this isn't a finding about every software company. But it is a finding about exactly the kind of customer who won't go looking for a new AI button unless it obviously makes their day easier, and a lot of B2B software has customers like that.

What makes that number hard to wave away is what it rules out. These aren't stalled pilots or demos that never left the sales deck. They're features that made it through design, engineering, QA and release. They run in production. The customers have them. Most of the customers just don't use them.

Shipping isn't the finish line

I've said this for a long time about every kind of feature, not just AI: you don't measure value when you ship. You measure it when the user experiences it. A shipped feature nobody uses has produced output and no value, and it's still costing you, because now somebody has to maintain it, test around it and explain it in onboarding.

AI features make that gap easier to fall into, for a reason Banyan's president of M&A, Max Risen, put plainly to IT Brew: companies are "building for the sake of building and not necessarily building to solve specific problems." When a board is asking what your AI strategy is, shipping something with AI in it can feel like the answer, whether or not a customer was stuck on anything the feature fixes.

The cheap yes moved upstream

A few years ago, an idea for a new feature had to survive weeks of scoping, estimating and arguing before anyone wrote code. That process was slow and often frustrating, but it did one useful thing: it made bad ideas expensive enough that a lot of them died early.

AI has removed most of that friction from building. A team can now prototype a plausible AI feature in days, and a plausible feature is easy to say yes to. The model can summarize, so let's add a summary. The model can draft, so let's add a draft button. Nobody had to show that a specific user, in a specific workflow, was stuck and wanted this. That's a cheap yes, and a cheap yes leads to an expensive no. The no just arrives later now, in a usage dashboard that stays flat three weeks after launch.

Building got cheaper. Building the wrong thing didn't. It may have gotten more expensive, because you can now build the wrong thing faster and in larger quantities than before.

Trust is the barrier product leaders name

When product leaders explain why customers don't adopt AI features, trust comes up first. In Delightpath's 2026 State of Product Leadership report, which surveyed 107 senior product leaders, 44% said users' trust in the output was the number one barrier to AI feature adoption. The same report found that only 7% of teams can identify and act on adoption problems in real time.

Put those two numbers together and a likely pattern emerges. The feature ships, some customers try it, the output isn't reliable enough for their actual work, and they quietly go back to how they did it before. The team doesn't notice for a while, because the feature works fine in the demo and nobody's watching usage closely. By the time anyone asks why adoption is low, the customers have already formed their opinion.

Trust isn't something you add after launch with better onboarding. It comes from the feature being useful for a real task, often enough that people stop double-checking it. That's a product decision, and it gets made, or skipped, long before launch.

An unused feature isn't free

It's tempting to treat an AI feature nobody uses as harmless. It shipped, it didn't break anything, and maybe adoption will pick up. But an unused feature keeps costing you after launch. Someone has to keep it working as the model and the product around it change. It takes up space in the interface, so the features people do use get a little harder to find. And with AI features in particular, there's often a running inference bill attached to something nobody opens.

The harder cost is that unused features are surprisingly difficult to remove. Vijay Iyengar, head of product at Mixpanel, described this on Lenny's Podcast while explaining why Mixpanel eventually shut down products that were pulling engineers away from its core: "It's also 10x more painful than you think to cut mild successes." A feature with a little usage has a team, a roadmap and a few loud customers behind it, and every one of them will argue for keeping it.

That's the strongest argument for doing the checking up front. It's a lot easier to not build a feature than to take one away.

What to check before building the next AI feature

None of this means AI features are a bad idea. Some of the best product work happening right now uses AI to remove a task people genuinely hate. The difference is in where the idea started.

So before your team builds the next one, I'd want a few questions answered, and I'd want the answers written down. The first is which specific user, in which specific workflow, is stuck today, and how you know. If the honest answer is "the model can do this," you're starting from capability instead of a problem. The second is what that person does instead right now. The best AI features replace something people already do the slow way and resent, and if nobody does the task today, that's worth understanding before you automate it.

Then I'd ask how accurate the feature has to be before people will trust it with real work, because a feature that's right 80% of the time is useless for some jobs and wonderful for others. And last, I'd ask what usage should look like three weeks after launch if it works, and who's going to be watching. Setting that bar before you see the data is what lets a flat line read as a finding instead of a reason to wait another quarter.

That's not a heavy process. For most features it's an afternoon of looking at how people actually work and a short conversation with a few of them. It's a lot cheaper than maintaining a feature that a quarter of your customers ever open.

The number to watch

If you build software with AI in it, it's worth pulling your own version of Banyan's number. Pick your three most recent AI features and look at what share of active customers used each one in the last month. Not who has access to it. Who used it.

If that number is under a quarter, you're in good company, according to Banyan. But it's also a sign that the next AI feature shouldn't start with what the model can do. It should start with a person who's stuck.