Everyone Wants AI. Almost Nobody Can Say What They Want It To Do.
This morning I got a message from someone in Sales Enablement who is trying to bring AI into their enablement workflows, but they don’t know where to start. When I asked what was driving it, two answers came back: The board wants it and they want productivity gains.
Then the honest part: we do not know how to approach this.
I have some version of that conversation almost every week, and it shows up at three different altitudes in variations of:
An Enablement leader asking about their own workflows
A CRO asking how to make their Sales teams more efficient and drive productivity
The CEO who just walked out of a board meeting where someone asked about their AI strategy, and now they need an answer faster than they need a plan
Very different rooms, all with the same gap. Everybody has the mandate, but almost nobody has the method.
The two things nobody says out loud
This takes real time to get right. You are going to work with it for a quarter, adjust it, and work with it again.
It is not always cheaper. Eventually, it might be, but it also might never be and running AI at any real volume costs money, sometimes more than what it was intended to replace.
But cheaper was never the right test.
The questions we should be answering to test our strategy are tied to output and quality. If you spend roughly what you were already spending, in dollars or in hours, and you do the work to get it right, and what comes out the other side is meaningfully more or meaningfully better, then it was worth doing. That is a productivity gain even when the invoice is the same size. Sometimes the return shows up as output, sometimes as quality, sometimes as capacity you did not have before. All three count.
What you cannot do is skip the question entirely. If you cannot say what you are getting back, you are doing AI for the sake of AI, and that is the most expensive version there is.
So I am not telling you it is not worth it. I am telling you that if your business case only holds together when AI comes in cheaper on day one, you have a business case problem before you have an AI problem. If you inherited that business case from somebody else, it’s far better to say so now rather than in nine months.
What is actually blocking people
It is almost never the technology. When I get underneath it, there are four things.
They do not know where to start. Not which vendor. Which end of the problem to pick up.
They do not know which workflows to focus on. There are hundreds of candidates and no framework for choosing between them, so the choice gets made by whoever is loudest or whatever demo landed best.
They do not know how to enable people once they have chosen. This is the step that gets skipped almost universally, and it is the step that decides whether any of it becomes adopted and part of the workflow or not.
They do not give it long enough to know whether it worked. Something ships, adoption looks soft at six weeks, the sponsor gets quiet, and the initiative dies without anyone declaring it dead.
Under all four, an enormous pressure is lurking, pushing us to “do AI” without much clarity on what that means. As a result, teams skip the planning and dive in, because diving in looks like progress while planning looks like delay.
The research backs up the shape of this. Sales Enablement Collective's landscape work found that a large majority of Enablement and Sales teams now use AI at least occasionally, while only about a quarter use it regularly. The difference between occasionally and regularly is absolutely material. Occasionally means somebody has access to a tool, whereas regularly means the way they work has changed.
The rollout that had to be pulled back
Here is the pattern I have watched more than once.
A new AI tool gets bought and then goes out with an announcement and maybe a launch session. Nobody maps what the rep actually has to be able to do differently, so nobody builds the enablement for it. And nobody teaches them the thing that matters most: how to work with an agent in the mix at all. That is a new skill that does not arrive with the license.
Then somebody notices the content feeding the new tool is out of date, and the truth is that it was already out of date and nothing about buying the tool fixed that. To compound this, the underlying workflow was never properly thought through, leaving the new tool sitting at an awkward angle to how the work really moves.
Then it breaks somewhere, and now the rep is not just unsupported, they are worse off than before. They are getting output they cannot trust, in a workflow that got more complicated, for a job that did not get easier.
Reps tell me this constantly. Not that AI is bad. That this AI, rolled out this way, made their job harder. They are right, and the cause is almost never the actual model. It is the enablement that never happened and the quality control nobody ran.
Eventually the tool gets pulled back out.
Now, pulling something back is not automatically a failure and sometimes the right answer genuinely is to return that work to a human. The problem is not the rollback. The problem is how the thing was framed on the way in.
Here are your two options at launch:
Option 1 includes announcing this is the new way of working. Then three months later, revising the announcement to “actually, this is the new way of working.” That is whiplash, and it does not just cost you this project; it costs you the credibility and trust you need for the next one.
Option 2 takes a different tone and narrative: we have done the design work to roll this out properly, we are going to gather your feedback, run quality control on how it is actually performing, and we may adjust it or pull parts of it back. Here is when we will review it.
Option 2 is honest and it makes the change a shared approach, rather than something being done to people.
This kind of alignment cannot only run downward. Your reps need to know from day one that this can change, but so do your sponsor and your leadership team. They are usually the ones who close the option off, not because they are defending a decision, but because they have moved on. The launch happened, the problem got filed as handled, and their attention went to the next thing on the list. Nobody senior is looking closely enough to notice that it did not actually get fixed, so the assumption that it worked never gets tested.
The lesson here is clear. Get the provisional framing agreed to at the top before you put it in front of the team. Everyone signs up for the same deal: we designed this carefully, we are going to check it, and we may change it. That is what makes an adjustment three months in the thing everybody expected instead of a reversal nobody saw coming. And the review date on the calendar is what pulls leadership attention back to something they have already stopped thinking about.
Say it at launch. It costs you nothing and it buys you the ability to be wrong.
Why this landed on Enablement, and why that is right
Enablement exists so people can do their jobs effectively. Enablement leaders are change agents by trade. You already know how to design around what somebody actually has to be able to do, not just what they need to know. You work one-to-many, which means you are already in the business of finding patterns instead of solving one rep's problem at a time.
Of course this is the function that gets asked to lead AI adoption. There is nobody in the building better positioned for it. You just do not always know how to approach it. That is a completely different problem, and a much easier one to solve.
Here is the part that should be reassuring. This is not a new discipline. It is your discipline, pointed at a new problem.
Every best practice you already know still applies. Understand what the person has to be able to do and design for the moment of need rather than the moment of announcement. Enable the managers, not just the reps. Reinforce after launch instead of stopping at it. Agree on what you are measuring before you start, with everyone who will be judging it. None of that changes because there is an agent in the workflow.
What changes is what you are enabling people to do. So you have to know what that is.
The question that turns a mandate into a scope
Here is something I say constantly. When someone outside enablement comes to me asking for training, I ask what they want people to be able to do. They almost always answer with "well, they need to understand..."
So I ask again “What do you want them to be able to DO with that information?”
That is when we get somewhere. Because that is when we find out whether the answer is training, a job aid in the moment of need, a change to the process, or a conversation with three managers.
The same question dismantles an AI mandate.
"We need to do AI" is not a scope. "What do you want your team to be able to do that they cannot do today?" is a scope you can design against, enable for, and measure.
Two things follow once you take the scoping seriously.
Working alongside an agent is not a tool skill:
It is a working relationship that includes directing it, judging whether what came back is any good, correcting it, knowing when to escalate, and when to just do the thing yourself. Those are real, teachable skills and almost nobody has built a curriculum for them. Without it, we are handing people a new colleague and onboarding them like it is a software release.
And the manager layer decides whether it lands. If a frontline manager cannot coach the new way of working, cannot tell strong agent output from weak, and does not reinforce it in a one to one, it will not stick. That has always been true of every change we have ever run. It is more true here, because the behavior change is bigger.
If you are the one who was handed this
You do not just need a strategy document. You need to convert a mandate into something you can build against, and you need to do it in the next conversation rather than after the next tool purchase.
So go into that conversation with the right question. Not "what tool are we buying?" and not "what is our AI strategy?" Ask about what they want the team to be able to do that they cannot do today. Then ask about what you get back if they can do it. Push until both answers are specific enough to design against. If nobody can answer either one, that is not a stall, that is the most useful finding you will produce this quarter, and it is the thing you take back to them.
Then pick one workflow. Design the human-agent split honestly, enable the humans properly, and say the review date out loud. Then give it long enough to tell you something true.
That is the work we built Beyond the Threshold for, and we built it because we kept having this exact conversation from both ends: teams handed an AI mandate with no method, and teams who had already bought and could not understand why nothing changed.
In part two: how to choose which workflow to start with, and what it actually looks like to decide what an agent owns, what stays human, and where the handoff between them goes.
You are not behind. Most of the market is standing exactly where you are.
Roz Greenfield is co-founder of Level213 and co-author of Accelerating Revenue: Your Definitive Guide to the Theory and Practice of Go-to-Market Enablement