AI training for teams: why the course rarely sticks

The course went well. Forty people in a room or on a call, a trainer who knew the tools, a demo where ChatGPT wrote a marketing email in four seconds. Everyone laughed at the right moments. The feedback forms came back with fours and fives.

Two weeks later, a manager asks around. A few people use ChatGPT to rephrase emails. One person built a prompt for meeting notes. The rest have gone back to working exactly as before. Nothing about how invoices get processed, how quotes get written or how customer questions get answered has changed.

This is the most common outcome of AI training for teams, and it isn’t the trainer’s fault.

Why a generic course doesn’t change the work

A general AI course teaches the tool. What a language model is, how to write a prompt, what it’s good at, where it makes things up. That’s useful knowledge. It’s also knowledge that sits one step away from anyone’s actual job.

The person in accounts payable doesn’t need to know how to write a poem with ChatGPT. She needs to know whether it can help with the 200 supplier invoices that come in each month, half of them as scanned PDFs, and what happens to the ones with a wrong VAT number. The course can’t answer that, because the course doesn’t know her invoices.

So the transfer is left to each participant. Go home and figure out where this fits in your work. Most people are busy, the next deadline is tomorrow, and the figuring out never happens. The ones who do try usually pick something small and personal, like rewriting an email, because that’s what the examples showed.

There’s a second problem. Individual use doesn’t add up to a team that works differently. If five people each find their own way to use AI, you get five private habits, five sets of instructions nobody else can see, and no shared idea of what the tool should and shouldn’t do. I wrote about what that does to answers in why your team gets different answers from the same AI.

What a workshop on your own processes does differently

The difference is where you start. A course starts with the tool and hopes the processes follow. A workshop starts with the work.

In practice that means the people who do a process sit in the room together. Not forty people from every department, but the six or eight who handle orders, or support, or month-end close. Before anyone talks about AI, they walk through what actually happens. Where does the request come from? What do you look up? Where do you copy things? Where do you wait for someone? Where do mistakes happen?

That walk-through alone is usually revealing. People who’ve worked side by side for years find out they do the same step differently. Someone mentions a spreadsheet nobody else knew existed. The manager learns that a task she thought took ten minutes takes an hour.

Then, step by step, you ask the question the course never could: could AI do this part, or help with it? Some answers are yes. Many are no, or not yet, because the rules aren’t written down or the data sits in a system nobody can reach. Both kinds of answer are worth having.

A typical session ends with a short list. Three or four use cases, each tied to a real step in a real process, each with a rough sense of how much time it takes today and what it would need to work. One of them gets picked as the first thing to try.

What changes afterwards

The output of a good workshop isn’t enthusiasm. It’s a document that someone can act on next week.

Concrete use cases. Not “use AI for customer service,” but “draft replies to delivery-time questions from the order system, checked by a person before sending.” Specific enough that you can tell whether it works.

An honest no-list. The things that came up and aren’t worth doing, with the reason. This saves you from coming back to the same idea in six months.

A plan for the first step. Who owns it, what data it needs, how you’ll test it on real cases, and what result would count as good enough.

Shared language. The team that sat in the room now has the same picture of what AI should do in their process. That matters more than any individual prompt trick, because it’s the team that has to live with the result.

People also tend to keep using what they helped design. When the accounts payable team chose the invoice use case themselves, they want to see it work. That’s a different starting point from a tool handed down after a course.

When a course still makes sense

A basic course has its place. If most people in the company have never used an AI tool, a short introduction removes some fear and gives everyone the same vocabulary. Do that first, keep it short, and don’t expect it to change any processes.

But if the question is “how do we actually get value out of AI in our daily work,” a course is the wrong format. You need time with your own processes and someone who can tell you which ideas are realistic.

That’s how I run my AI workshop: one team, one or two processes, and you leave with the use cases and the plan written down.