Access Is the Start of the Problem
Most stalled AI rollouts look uneven, not empty.
One person has a Claude workflow they use every morning. Another uses Copilot to summarize meetings. Three people tried the approved tool, got a bland answer, and never opened it again. A manager is quietly pasting sensitive material into a personal account because the company tool feels worse. Leadership sees a license dashboard and calls the gap a training problem.
That diagnosis is too broad to be useful.
The question isn't whether the team understands AI. It's whether each person can connect an approved tool to a recurring piece of work, get a result worth keeping, and know what to do when the result misses.
Access matters. It removes the first barrier. It doesn't create a habit, improve the output, or give a manager a reason to protect time for practice.
Before booking another general workshop, find out where the chain breaks.
Start With One Recurring Task
Ask five people a concrete question: "What did you work on twice last week?"
The answers might be a client recap, a first-pass analysis, a status update, a spreadsheet cleanup, or a meeting brief. Pick one task per role. Then ask the person to show you how it happens today.
This is more useful than asking, "How comfortable are you with AI?" Comfort is vague. A repeated task has inputs, decisions, an expected result, and a real cost when it goes wrong.
The task also tells you whether the tool belongs in the workflow. Some work doesn't need a model. A two-minute template may beat a ten-minute chat. Good enablement includes permission to leave AI out when it adds friction.
For work that does fit, write down four things:
- What starts the task
- What information the person needs
- What a usable result looks like
- What must be reviewed by a human
That small map gives a workshop something real to improve. It also prevents the common mistake of teaching features without connecting them to work.
Find the First Broken Link
Uneven adoption usually comes from one of four breaks.
The workflow isn't clear. The person has seen a demo, but no one has shown where AI fits into their actual process. "Use AI for research" is an idea. "Turn these five interview notes into a tagged evidence table before Thursday's synthesis" is a workflow.
The tool is missing context. The model doesn't know the team's terminology, examples, constraints, or quality bar. The first answer sounds generic, so the person concludes the tool isn't useful. A short reference file or a reusable Skill can change the result more than another list of prompting tips. The deeper version of this diagnosis is in the Context Audit.
The manager signal is mixed. Leadership says experimentation matters, but delivery targets stay fixed and no practice time appears on the calendar. People read that correctly: experimentation is extra work. A manager doesn't need to become the team's AI expert. They do need to name the work worth testing and make room for the test.
The first failure becomes the verdict. New users often get one weak result and stop. Experienced users narrow the task, add missing context, compare the answer with a source, or switch tools. The gap isn't confidence. It's a small set of recovery moves.
Label the break before you design the fix. Each one needs a different intervention.
Look for the Quiet Signals
License activation and chat counts show activity. They don't show whether the activity helped.
Sit with the team for an hour and look for quieter signals:
- People rewrite most of the output before using it
- The same two enthusiasts answer every AI question
- Managers ask for use cases but can't name a priority workflow
- Approved tools are available, but personal accounts feel easier
- Nobody knows which inputs are safe to use
- Useful prompts live in private notes or old chat threads
- A good workflow depends on the person who invented it being in the room
These aren't edge cases. They're the operating system of adoption. They tell you whether the team has a shared method or a few isolated wins.
A useful diagnosis separates individual skill from team conditions. Someone can be curious and capable while working inside a system that gives them no approved data, no examples, no review standard, and no time to practice.
Build the Smallest Useful Intervention
Once you know the break, keep the response narrow.
If the workflow isn't clear, run a lab around one repeated task. Bring real, sanitized inputs. Show the current process. Let the group build a better version and test it against the same quality bar.
If context is missing, create one reusable artifact. That might be a Skill, a reference document, an AGENTS.md file, or a reviewed example. Put it where the team already works and name an owner.
If the manager signal is mixed, write a 30-day adoption brief. Name the workflow, the people testing it, the protected practice time, the review point, and the decision you'll make at the end.
If first failures are stopping people, teach recovery. Have people compare a weak result with a better one, identify the missing information, and make one change at a time. The lesson should end with a move they can use tomorrow, not a catalog of features.
The smallest intervention is often one room, one workflow, and one artifact. A broad rollout can come later, once that unit works.
Don't Average the Team
An average adoption score hides the people you need to understand.
Split the room into practical groups:
- People with a repeatable workflow already
- People experimenting without a stable result
- People who tried the tool and stopped
- People who haven't found a relevant task
- People blocked by policy, access, or data
Each group needs a different next step. Your active users can turn private techniques into shared artifacts. Experimenters need a quality bar. People who stopped need a better first workflow. People without a relevant task need permission not to force one. Blocked users need an operational answer, not inspiration.
This is also why mixed-role sessions need careful design. A legal reviewer, an account manager, and an operations analyst may use the same model, but they don't share the same risk, inputs, or definition of done.
End the Diagnosis With a Decision
A diagnosis shouldn't end with "people need more training." It should end with a choice.
For the next 30 days, choose one workflow and one cohort. Decide what will change: less time to first draft, fewer correction rounds, more consistent output, or a safer handoff. Name the artifact the team will keep. Pick a date to review what happened.
Then write down what would make you stop. If the workflow remains slower, the quality drops, or the safety review becomes harder, don't scale it. Adoption is not the goal by itself. Better work is the goal.
The next step is measurement. How to Measure AI Adoption Without Inventing ROI shows how to build a before-and-after card that a business team can actually use.
Access tells you who could use the tool. A workflow diagnosis tells you who can use it, for what, and what needs to change next. That's the difference between a rollout and an operating habit.