Get your team to actually use AI by making the new route shorter than the old one, not by convincing anyone. Sort the work first. Tasks where a person adds judgement need practice and a review step. Tasks that are identical every time need a workflow that removes them.
This is for a company of 5 to 50 people where the licences are already handed out and usage quietly faded. Not for the question of where to start with AI, but for the question of why the start did not stick.
Why does usage drop off after the first weeks?
Because the old route is still there and it is still shorter. Every task has a path people can walk without thinking: the document they always copy from, the colleague who knows, last year’s template. A new tool only wins when it costs less effort than that path, checking the output included.
This is also why a session in the calendar changes so little. People meet a tool, go back to their desk, and run into their own habits again. What does change things: pick one task that comes back often, put the tool where that task already happens, and agree how the output gets checked.
So the order is task, then tool, then training. The other way around produces enthusiasm that evaporates in a fortnight. If you are still before that first task, where to start with AI covers the starting point. This article is about what happens to the people afterwards.
Train the person or remove the task?
Two different interventions, and the task type decides which one. Training fits work where a person makes a judgement call and the output is better for a human hand on it. Removal fits work that is the same every time and that nobody will miss.
| Task type | Example | Route | Why |
|---|---|---|---|
| Frequent, identical, no judgement | moving data between two systems | automate | training burns the time you were trying to save |
| Frequent, variable, judgement | first draft of a client email | train | the person decides, AI supplies the draft |
| Rare, complex | annual plan, pricing strategy | leave alone | the learning curve never pays back |
| Frequent, judgement, high risk | quotes, complaints, contracts | train plus a review step | mistakes are expensive here |
| Frequent, lookups in your own systems | customer status questions | automate | the answer already exists somewhere |
| Rare, simple, tedious | assembling the monthly report | automate | exactly the work nobody wants back |
Most programmes push everything into row two. Everyone learns to prompt, including for work that needs no human at all. The task survives with an extra step bolted on, and adoption stalls for reasons that have nothing to do with attitude.
The opposite error is just as common. Automate work where the judgement was the value, and the team gets output it has to redo. That is the fastest way to lose trust in the whole idea.
What do you do about resistance?
Treat it as information. Resistance is often an accurate reading of a bad tool: someone tried it, got an answer that looked right and was not, and concluded that checking costs more than doing. That is a measurement, not an attitude.
Three objections come up, and each needs something different. “It gets things wrong” needs better access to your own data plus a review step. “I do not have time” needs a smaller first task. “Will I still be needed” needs an honest answer about which work disappears and what remains, not reassurance.
What does not work is mandating usage and counting logins. That produces accounts, not use. The underlying pattern is in why SMEs fail at AI more often than large corporates: a project without an owner and without a sharp task belongs to everyone and therefore to no one.
How do you measure whether the team really uses it?
Count the old route, not the new one. The question is not how many people logged in, but how often the work still went the long way round. Three criteria you can track yourself, each over two weeks:
- How often did the task still happen by hand? Ask the people doing it, or count the exceptions in the system. Zero is suspicious, and usually means nobody is counting.
- How much of the output gets rewritten? If every piece is reworked from scratch, either the tool is not good enough or it is pointed at the wrong task.
- How many people use it without being asked? One person is an experiment. Three is a habit.
Put those three on one page and repeat after a month. That is enough. Larger dashboards distract from the only thing that matters: did the old route get shorter.
What if one enthusiast ends up doing everything?
This is the most common resting state after three months, and almost nobody writes about it. One person builds everything, the rest watch, and the moment that person takes a holiday the work stops. It looks like success and it is a risk.
Two moves help. First, stop asking that person to build more and ask them to hand one thing over, including what goes wrong when it goes wrong. Second, take the work nobody enjoys out of human hands entirely and put it in a workflow, so it no longer depends on who feels like it this week. Which marketing tasks qualify is covered in marketing tasks you can automate today.
Does training help?
Yes, on the right tasks. WeAdapt runs training and workshops around Claude, n8n and prompt engineering, and hands over every system with documentation so the team can adjust and build workflows itself. The goal is not tool familiarity. The goal is that people redesign their own task and keep it that way. The FAQ explains how that runs.
Frequently asked questions
How long before a team really uses AI? Count in tasks, not weeks. One task that recurs often and where the result is visibly better or faster changes behaviour within a few weeks. A general introduction without a task changes nothing, however many weeks you give it.
Does everyone need to join in? No. Start with the people who do the task most often and suffer from it. They produce the evidence the rest needs. Mandating usage for people without a fitting task produces logged in accounts and nothing else.
What if the team is afraid work will disappear? Say which work disappears. It is usually the part nobody wants back: retyping, looking up, summarising. What stays is the work with judgement in it. A vague answer to this question costs more trust than an uncomfortable honest one.
Is training enough, or do we need to build something? Usually both, on different tasks. Work with judgement needs training. Work that is identical every time needs a workflow. Training alone keeps the repetitive work alive; building alone leaves the judgement work untouched.
Adoption is a design question: which task do you put where, and with whom. Making that split and teaching it is what training and workshops covers, with consultancy in front of it when the question is which process goes first.
Want that split written down for your own processes? Book a call. At WeAdapt the route from discovery call to live takes four weeks, training included, which is what keeps the usage with your team.