Companies Solved the AI Usage Problem Before They Solved the AI Value Problem.

The easiest part of an AI transformation to prove is that somebody opened the AI.

There is a record of the login. There may be a training certificate. Someone can count the prompts, put the number on a slide and report that adoption is moving in the right direction. Whether the business is doing better requires a different meeting.

Bain’s September 30 research, AI in Marketing: How Leaders Achieve Double the Revenue Impact, finds that only 6% of marketing organizations report significant performance impact from AI. Its 2026 survey includes 1,397 respondents. Business Insider identifies them as senior marketing and finance executives and reports that 95% of marketers say their organizations have adopted AI tools.

Those are findings about marketing organizations, not a census of every company or employee. They are also reported assessments, not an experiment proving what caused a financial result. The gap nevertheless illustrates a useful management problem: access, activity and value are different things.

Adoption makes a very good dashboard

A rollout needs adoption measures. Buying software that nobody can access or knows how to use would be an expensive way to preserve the existing process. Training completion and active accounts can reveal that something basic is going wrong.

The trouble begins when those measures become the definition of success. Licenses activated, Copilot usage, prompts submitted and employees trained are convenient because they arrive as numbers. A better customer decision is harder to count. So is work that no longer needs doing.

That imbalance creates an incentive for managers to ask employees to demonstrate AI use, attach an AI component to a goal or find a task for the new tool. As a management exercise, each request is understandable. As evidence of value, each needs another question: what improved?

Imagine an employee who uses AI to produce a weekly summary that nobody reads. Their adoption metric rises. If they eliminate the unnecessary summary, tool usage may fall while the team gets time back. A system that rewards the first outcome more clearly than the second is measuring the wrong achievement.

This is how an experiment can become another reporting obligation. The employee has to do the work, use the tool and then document the tool’s involvement. The dashboard gets three activities. The customer may get exactly the same service.

Using AI, changing work, improving results

These are three separate stages, and a company can stop at any one of them.

Using AI might mean drafting a campaign brief more quickly. Redesigning work might mean changing how customer research enters that brief, who checks it and how quickly the team can test competing ideas. Producing a better outcome means the resulting campaign earns more useful responses, lowers an actual cost or improves another agreed business measure.

The first does not automatically deliver the second. Neither guarantees the third.

Consider a hypothetical team that now produces ten versions of an email in the time it once needed for two. If every version still waits a week for approval, faster drafting may increase the review queue. If the team changes the approval process, it can run more experiments. It must still learn whether those experiments improve the customer response.

Bain associates stronger performance with centralized AI strategy, redesigned workflows and customer-focused uses. That supports a practical direction for implementation. It does not establish that copying a successful company’s process will produce the same return elsewhere.

The useful lesson is to follow the work beyond the moment a model produces an answer. Someone has to verify it, make a decision, deliver the result and observe what happened. A bottleneck anywhere along that route can absorb the time saved at the beginning.

Give the pilot an outcome before giving it a victory

A more demanding pilot starts with a problem that exists without AI in the sentence. Perhaps campaign approval takes too long. Perhaps customers abandon a confusing application. Perhaps staff spend hours correcting inconsistent product information. Each problem suggests a measure that survives changes in the software used to solve it.

Establish the starting point, choose a limited workflow and name the person responsible for the result. Count the checking and rework alongside the drafting time. Compare quality as well as speed. If the work touches a customer, include the customer’s experience in the assessment.

Time saved also needs a destination. Twenty minutes recovered in several disconnected intervals may make a day less irritating without reducing costs or increasing revenue. That can still be worthwhile. It should be described honestly rather than converted automatically into a financial benefit.

The 6% finding does not mean everyone else received nothing. Smaller gains, early experiments and benefits that have not yet been measured can coexist with limited reports of significant impact. Equally, high adoption does not establish that a major payoff is merely waiting to appear.

Companies should make room for useful experimentation and for the conclusion that a particular application is not worth continuing. Otherwise the person closest to the work learns that reporting enthusiasm is safer than reporting evidence.

The next progress slide could put usage next to a business result, with enough detail to explain the relationship. It would be a less convenient slide to assemble. It might also be the first one that explains why the company bought the software.