AI Enablement Is a Loop, Not a Roadmap

You can give everyone in your company an AI tool, teach them how to use it, and still find that very little changed in the business.

And if that has happened in your firm, I would look at what happened after the training before deciding your people weren't interested. We have built tools that worked, did what we asked them to do, and still weren't something a person could use in their actual week.

That is the work I mean when I say AI enablement, getting the data into a usable form, changing the process, helping people work differently, and building or trying tools until the business gets a real result. You keep going around that loop because buying the tool doesn't tell you which part you got wrong.

Let me give you one of ours, because it explains this better than a definition does.

We built a tool that read sales meeting transcripts and scored the salesperson against a rubric, basically a written standard for what a good call should include. The supervisor could use that assessment to give feedback with something behind it, instead of relying on whichever calls he happened to hear.

The model read the transcripts, applied the standard and wrote the reports, so from the technical side it worked.

But the reports had far too much text, pages of assessment that the supervisor would have to read before deciding who needed help. We had given him more information without making it easier to do his job.

So we killed the reports and kept the scoring, with the low scores shown first. Now he could open the tool and see where to spend his attention, rather than read through everyone to find that out.

The first version wasn't completely wasted, the useful part survived. We had to put it in front of someone doing the work before we understood what to take away.

That is the loop, create something, people use it, adapt until it's useful.

And please don't hear one useful example and assume the rest came easily. We had over ten prototypes, roughly 100 hours of engineering and over 200 billion tokens spent on systems that never reached production adoption.

Those are our numbers, not a failure rate you should budget against. When we got things right, we had over 100 consultants using the tool daily and getting real improvements, but I don't have a measured performance percentage to attach to that.

The failed builds matter because they are part of what it cost to find something people would use. If your plan has money for software and training but nothing for those attempts, part of the job is missing from the plan.

When I looked at definitions of AI enablement, most of the emphasis was on getting the company ready. The Hackett Group says it “refers to preparing an organization to adopt and scale artificial intelligence as an integrated part of business operations.”

Upland Software calls it “the process of equipping organizations with the right technology, infrastructure, and connectivity to leverage AI effectively across their business processes.” And Straive calls it “the discipline of preparing every layer of an enterprise to deploy and sustain AI reliably.”

None of that is wrong, and the pages go beyond those opening definitions. Hackett discusses putting AI into workflows and performance management, Upland talks about tangible outcomes, and Straive says, “Adoption is signing the contract. Enablement is what makes the model useful.”

So my disagreement isn't that they forgot results existed. It is that an owner still needs to decide what result ends the work, otherwise getting ready can go on for as long as you're willing to pay for it.

A roadmap can name an assessment phase, a foundation phase and a pilot phase, and all three can finish without the work becoming better. My test is whether something useful changed in the business, and whether we can point to it.

That is harder to promise in advance. You don't know which version will work, so you need a plan that can change when the first one doesn't, not just a date when the program ends.

I'm talking about enabling AI across the company here, not sales enablement software, which is a different use of the word.

The confusion is real. In a Reddit discussion about AI enablement, someone asked how organizations define it and whether enablement leads help, and one reply was, “It seems like a complete waste of funds.”

I wouldn't use that comment to judge a job, but I understand the question behind it. If you can't say what the work changes, how does an owner know whether to keep paying for it?

The first explanation I hear when adoption stalls is often about the team, people aren't skilled enough, they aren't curious, they like the old way. What I have seen is that people have rarely been the main problem, most want the tools and are willing to learn.

Many are already trying. In Microsoft and LinkedIn's 2024 Work Trend Index, 78% of AI users were bringing their own tools to work, rising to 80% at small and medium-sized companies.

That is the shadow AI problem from another side, people didn't wait for the company to decide how this would work. The survey covered 31,000 people across 31 countries, it wasn't a study of firms exactly like yours.

Permission matters too. Slack's 2024 research found desk workers at companies with established permission to use AI were nearly six times as likely to have experimented, while a separate survey that year found 45% didn't have explicit permission.

Those are survey relationships, not proof that saying yes produces six times the adoption. But if your people are unsure whether they are allowed to use a tool on client work, that is something management needs to settle.

Now, wanting the tool and wanting your workflow changed are different things, and I see both sides of that. People can be happy to try AI and still dislike having to learn a different way of doing a job they already know.

Gallup's February 2026 survey gives that objection a number, 46% of non-users in organizations where AI was available said they preferred to keep doing the work the current way. The full survey covered 23,717 U.S. employees, not just service firms where someone was guiding a rollout.

So I am not saying resistance never happens. I am saying that giving people a tool and asking them to work differently creates a management job, and calling the team resistant doesn't do that job for you.

The four jobs inside AI enablement

The first is data design, which sounds more technical than it needs to. AI needs access to the information the work depends on, including the checks, exceptions and decisions that currently live in someone's head.

If a manager knows when a customer needs a different response but has never written it down, the tool doesn't inherit that knowledge because you connected it to the inbox. Documenting the process is part of making the information usable, not a separate exercise in tidiness.

Gallup found frequent AI use among 88% of employees who strongly agreed that AI fitted their systems and processes, compared with 55% of those who did not strongly agree, within organizations that made AI available. That doesn't prove integration caused the difference, but it is another reason to look beyond whether everyone has a login.

The second job is process redesign, deciding how the work should run now that AI can do part of it. Putting a faster tool into every old step can leave you with the same old process and one faster step.

In Microsoft's 2026 Work Trend Index, 45% of AI users said it felt safer to focus on current goals than to redesign work with AI. I understand that choice, because people still have work due while you're asking them to try a new way.

The third job is helping people through that change. They need time to learn, clear permission and boundaries, and a plan for what they should do with any time the tool frees.

That last part gets missed. If the report takes less time, should they take on more client work, fix a recurring problem, spend more time with existing clients? Somebody has to name the work, or the work around it takes the time back.

The fourth job is prototyping and testing tools, built or bought, on the work people actually have. You learn something from the attempt that you couldn't learn from a demonstration.

An interview study of ten experienced U.S. professionals using M365 Copilot found none named formal training as their main way of learning, eight learned through trial and error and six through tips from colleagues. It is a small exploratory study, not evidence that training is useless, but it describes why a course cannot do all the learning for you.

Across our unsuccessful builds, the problems were missing foundational data, solving the wrong problem, output people wouldn't use, and unreliable results. Those are different failures, and buying a stronger model doesn't answer all of them.

Missing data deserves particular care, because it can sound like a reason to spend months preparing everything before you try anything. The question is which data this particular job needs, and building a small version helps you find that out.

You still need to protect client information and understand the process before testing. But you don't need to make the whole company ready in the abstract before learning whether one supervisor can use the report you're proposing.

All four jobs need leadership behind them. That doesn't mean you personally write every instruction or fix every bug, it means somebody has the hours, the authority and the budget to keep working when the first version disappoints.

In the Production Gap, that missing authority is the Owner Ceiling. An employee can be very good with the tools and still be unable to change what the team is expected to deliver this week.

Who owns the loop

This is why AI enablement is bigger than training. Training can finish when the course finishes, the work of getting a business result cannot.

And I wouldn't take that as permission to buy less training. The 2024 Microsoft and LinkedIn survey found only 39% of people globally who used AI at work had received AI training from their company, so there was a real training gap too.

Gallup's May 2026 figures showed nearly half of U.S. employees saying their organization had integrated AI, while only 30% reported using it regularly. The page didn't state the sample size, and these weren't counts of purchased seats versus active seats.

The practical distinction is simpler than the surveys, someone finishing a course tells you they attended, not whether your delivery process improved.

Darlene Newman makes a useful argument that stopping at tool training leaves out the work of defining workflows, decisions and handoffs. Her line is, “Traditional enablement helps humans learn software. AI enablement helps software learn the business.”

I agree with the work she names. Where I would be careful in a small firm is turning each part into a separate role before you've worked out what needs doing.

In a 25-person firm, those jobs may fall to the same couple of people, including you. Hiring someone to run approvals won't replace having someone who can actually help the team when a tool breaks.

In the firms I've watched get this right, an existing employee often starts helping colleagues, sharing instructions and building small tools. I call them AI enablers, and I would look for that person before assuming you need a new title.

But they have to be ahead of the users and reachable. My team tells me what they tried and what went wrong because they know I can help fix it, and that gives me both a problem to solve and an idea of what they wanted the tool to do.

Without that response, reporting a problem becomes more work with no clear benefit. People go back to the old tool, and you may never hear why.

If nobody in your company can provide that help, close the gap, whether through learning, outside help or a hire. Don't pretend an enthusiast can carry a job they don't have the knowledge or authority to do.

Start with one piece of work

Pick a workflow where you can name the result you want, the hours a recurring task takes, the cost of delivering a service, the turnaround time a client keeps asking about. If you cannot name the result yet, deciding that is the first part of the work.

Then write down what the people doing that workflow know, the checks they make, the exceptions they handle, what tells them something is finished. Keep this about that workflow, not a project to document the entire company.

Build or buy the smallest version that could help and put it in front of someone on real work, with the checks that work needs. Give them a way to tell you what they tried and what broke, and make sure someone is responsible for answering.

When the feedback arrives, use it. Maybe you need better data, maybe the output is too long, maybe you aimed at the wrong problem, like we did when we gave the supervisor more reading instead of a way to find who needed him.

Adapt it and hand it back, then check whether the result you named is improving. A version people use is progress, but it isn't the whole result if the rest of the process takes back the saving.

On the Delivery Model Ladder, this is the work between adding AI to someone's existing job and rebuilding the workflow around it, Stage 1, Enhanced, toward Stage 2, Augmented. One of the Four Numbers asks what share of the hours AI freed has a named use, because the business needs that decision too.

This is hard and it can be expensive, you're changing tools, information, people's jobs and your own view of the business together. I don't have a formula that tells you which attempt will work, and my experience isn't a controlled comparison against firms that did it another way.

The loop needs enough repeated work to improve, somebody with authority to change it, and a result you can check. If the company is you and two other people, you're dealing with a different problem, how to divide your own work with AI.

And even in a larger firm, the person who carries the tools cannot carry the authority for you. Before you approve the next rollout, decide who can change the work when the first version teaches you something you didn't expect.