How Do You Get Your Team to Actually Use AI?

Why does your team stop using AI after the first month?

Teams stop because the tool never attached to a job they needed doing. Enthusiasm carries the first two weeks, then the work reasserts itself and anything optional falls out.

Gallup's research on adopters and holdouts puts numbers on the reasons. Among employees who do not use AI in their role, 44% say the main reason is that they do not believe AI can assist with the work they do. The reasons given after that are resistance to changing how they do the job at 11%, not knowing how to use the tools at 10%, and not feeling safe using them at 8%. Training is the smallest of those. Most organisations treat it as the largest.

Read that ordering again, because it changes what you should do. The biggest reason by a distance is a judgement about the work rather than a gap in skill. The employee has looked at the tool, looked at their day, and not seen the connection. They are often right. A general purpose assistant is genuinely unhelpful for someone whose day is booking jobs inside a scheduling system, and telling them to use it more does not change that.

The second failure is that the tool sits beside the work instead of inside it. If using AI means opening another tab, copying text out of one system, pasting a result into another, and re-keying it into a third, it costs time on a busy day. People do the arithmetic quickly and quietly.

Where usage sticks, the pattern is consistent: the AI runs inside the system the person already works in, on a task they were already doing, and the output arrives where they expect it. That is a design decision made before anybody is trained, which is why adoption problems are usually traceable to the week the work was scoped rather than the week the licences arrived.

How do you introduce AI to a team without everyone assuming job cuts?

Introduce it by saying what it is for, what happens to the time it frees, and what stays with people, and say all three before anybody sees a tool. Silence gets filled with the worst available explanation.

Gallup found that as of May 2026, 25% of US employees strongly agreed their organisation had communicated a clear plan or strategy for integrating AI, which leaves three in four who did not. The effect of doing it is large: Gallup reports that employees who strongly agree leadership has communicated a clear plan are three times as likely to feel very prepared to work with AI and 2.6 times as likely to feel comfortable using it in their role.

What to actually say comes down to three answers. What work is this for, named specifically rather than as a category. What happens to the hours it frees, which for most businesses is taking on more work rather than reducing headcount, and if that is your answer then say it plainly. And what stays with people, which is the question everybody in the room is asking and nobody asks out loud.

Being specific protects you. "We are looking at AI across the business" invites everyone to guess which part of their job is on the list. "The after hours calls that currently go to voicemail get answered and booked, and the front desk keeps anything involving a complaint" tells the front desk exactly where they stand. The second sentence takes no longer to say.

The one thing not to do is mandate usage without changing the work. Forcing use produces compliance theatre: people open the tool, run something trivial through it, close it, and report that they used it. The honest question people have about their own security is answered separately in will AI automation replace my employees, which is worth reading before the conversation rather than after it.

What actually makes the difference in whether people use it?

Managers make the difference. The strongest association in the published research is whether somebody's direct manager visibly supports and uses it.

Gallup's work on manager support reports that employees who strongly agree their manager actively supports their team's use of AI are 2.1 times as likely to use AI a few times a week or more, and 6.5 times as likely to strongly agree that the AI tools their organisation provides are useful for their work. Its adopters and holdouts research puts the same relationship in frequency terms: 78% of employees who strongly agree their manager supports AI use are frequent users, against 44% of those who do not.

There is a gap up the hierarchy that makes this harder than it sounds. Within organisations that make AI available, Gallup found 67% of leaders using AI frequently, against 52% of managers, 50% of project managers and 46% of individual contributors. The people whose support matters most are using it least among the senior group, which means an adoption push that starts with an all staff announcement and skips the middle has skipped the mechanism.

Three things a manager does that actually move it. Use it in front of the team, including the attempts that fail, because a manager who only shows polished results teaches people that mistakes are punished. Point at the specific task: not "try AI on your reports" but "run this month's exception list through it first and check the three you would have checked anyway". And remove the friction they cannot remove themselves, which usually means an access request, an approval, or a rule nobody has updated.

None of that requires the manager to be technical. It requires them to have an opinion about which part of their team's work is worth changing, which is a management judgement rather than a technical one.

Should you train your team on AI tools, or build AI into the work?

Build it into the work. Training is the right answer for tools people choose to use, and the wrong answer for work that should not depend on anybody choosing.

The two approaches solve different problems. Training gets a team better at prompting an assistant, which pays off for open ended work: drafting, research, summarising, thinking through a problem. It does not produce reliability, because the output depends on who is at the keyboard and how busy they are. Built systems do the opposite. They handle the same task the same way every time, in the system where the work lives, whether anybody is enthusiastic that week or not.

Most businesses need both and buy only the first, because training is easier to purchase. The result is a team that has learned to use a chat window for work that should not involve a chat window at all. Copying customer details into an assistant and pasting the answer back into the CRM is not automation, it is a person doing integration by hand.

	Training people on a tool	Building AI into the work
Suits	Open ended work: drafting, research, summarising, thinking a problem through	Repeatable work with a defined input and a defined output
Result depends on	Who is at the keyboard, and how busy they are that week	The design, which does not change when somebody is on holiday
Where it happens	A separate tool the person chooses to open	The system the person already works in
What it costs	Mostly time, plus a course	A build, plus somebody operating it afterwards
How it fails	Quietly, when people stop opening it	Loudly, when an input changes and the exception queue grows
What you can measure	Usage, which is not the same as benefit	Volume, cycle time and exception rate against a baseline

The sorting rule is whether the task is repeatable. Repeatable work with a defined input and a defined output belongs in a system. Judgement work with unpredictable inputs belongs with a person, with AI as an assistant they have been trained to use well. Writing that division down for a specific business is the roadmap exercise, and what belongs in one is in what an AI roadmap should include.

MIT's Project NANDA report The GenAI Divide: State of AI in Business 2025 is blunt about where this ends up. More than 80% of the organisations it looked at had explored or piloted general purpose tools like ChatGPT or Copilot, while only 5% of task specific enterprise systems reached production. Handing out a general tool is easy and it is what most companies have done. Getting a specific system into the work is the part that produces a measurable result, and it is what our transformation work is for.

How do you tell whether AI is actually being used, and whether it is helping?

You tell by measuring the work, not the logins. Usage statistics tell you a tool was opened. They do not tell you whether anything got faster or better.

Three measures cover most cases. Volume through the process, which answers whether the team is handling more without more people. Cycle time from arrival to done, which is where customers notice. And exception rate, meaning the share of items a person had to touch, which tells you whether the system is actually carrying the work or just pre-chewing it. Track all three against a baseline you recorded before anything changed, because the argument about whether it helped is unwinnable afterwards without one.

Watch for a specific pattern in the exception rate. A system handling most items unattended in month one and half of them in month four has not degraded technically. Something in the inputs changed, or the team started routing anything unusual to the exception queue because it was easier than checking. Both are fixable and neither is visible in a usage dashboard.

Ask the people doing the work a better question than whether they like it. Ask what they stopped doing. If nobody can name a task that has gone away, nothing has been automated regardless of what the licence report says. This is also the fastest way to find the work being done twice, where a system produces an output and somebody carefully re-does it by hand because they do not trust it yet.

Publish what you find. A team that sees the numbers move engages differently from a team told the initiative is going well. When we run a system, we report what it produced, which is the same principle applied to us: you never have to take our word for whether it worked.

What do you do about someone who refuses to use it?

Find out which of three things it is, because someone who refuses is usually one of three cases and only one of them is actual refusal.

The first is that they are right. The task genuinely is not a fit, and the person closest to it knows something the plan did not. Gallup's finding that 44% of non users say AI cannot assist with the work they do deserves to be taken seriously rather than managed around, because in a meaningful share of cases it is an accurate assessment of a tool that was chosen badly. Ask them to describe the work and you will usually learn where it should have been applied instead.

The second is risk. Gallup found concerns about data privacy, security and compliance cited by 43% of non users and 38% of infrequent users, and in regulated work that concern is often correct and unanswered. Somebody handling patient data or client files needs to know what the system does with it and who approved that. Answer it properly, in writing, and the objection usually disappears. Leave it unanswered and you are asking them to take the risk personally.

The third is genuine resistance, and it is rarer than managers assume. Where it exists it usually reads as one of two things: fear about their position, which needs the honest conversation rather than a training session, or status, where using a tool feels like an admission that the expertise they are known for is being commoditised. That second one is worth naming directly, and the answer is generally to give the expert authority over the system rather than exposure to it. The person who has done the work for nine years knows the exceptions, and the exceptions are what the system needs to handle. Put them in charge of that.

What does not work is mandating usage and counting compliance. It produces a metric that goes up while nothing changes, which is the worst outcome available, because it also destroys your ability to tell whether the next thing worked. The broader pattern of how these projects fail is in why AI automation projects fail.

Frequently asked questions

How much should we spend on AI training for our team?

Decide what the AI is for before deciding what training costs, because the answer changes by an order of magnitude. Open ended work, drafting, research, analysis, benefits from real training and the spend is mostly time rather than fees. Repeatable process work should not depend on training at all: it belongs in a system that runs whether people are enthusiastic or not, and the cost there is a build rather than a course. BLACKSIG scopes work on a call against the processes in question rather than publishing a rate. What moves the number is how many systems the work touches and how much runs unattended.

How do you actually roll AI out to a team, step by step?

Pick one process where the benefit is obvious to the people doing it. Record a baseline: volume, cycle time, hours. Tell the team what it is for, what happens to the freed time, and what stays with them. Build it into the system they already work in. Have their manager use it visibly for two weeks, including the failures. Then check the three measures against the baseline and fix what the numbers show. Widen only after the first one holds, because a second rollout on top of an unstable first one gives you two unclear results instead of one clear one.

Is it better to train our own people or bring in a firm?

Train your people for the judgement work and bring in help for the systems, which is the split most businesses get backwards. Your team knows the exceptions, the customers and the undocumented rules, which no external firm can learn quickly. What an external firm brings is knowing which processes are worth automating, what breaks in production, and who operates the result at three in the morning.

Can we get adoption up if our team is not technical at all?

Yes, and non technical teams often do better, because nobody is tempted to build their own thing on the side. The requirement is not technical skill, it is that the work arrives in the system people already use. A dispatcher who sees a booked job appear in the scheduling software has adopted AI without ever using an AI tool. That is the version that holds.

What if leadership is the problem rather than the team?

Then start with one manager and one process rather than waiting for a mandate. Gallup's numbers show the manager relationship carrying most of the effect, and a single department running something that measurably works is a stronger argument for a leadership team than any business case. Record the baseline first, because the case you will need in six months is the comparison.

How long before people use it without being reminded?

For a system built into the work, the reminders stop when the output becomes the normal way the task arrives, which is usually a few weeks. For a tool people have to choose to open, reminders may never stop, and that is the clearest signal available that the work should have been built rather than trained. Watch which one you have before adding another training session.