AI training for a team: where do you start?
Short answer
The first step in buying AI training for a team is not picking a tool, it is picking a piece of work the team actually does. A general awareness session goes down well in the room, but the next morning nothing on anyone’s desk has changed. When the day is run on work the attendees were going to do that week anyway — writing a specification, comparing incoming quotes, reading a report — what is left behind is a working flow rather than a slide deck. Who attends also comes before the tool: a group that does the same job gets further than a mixed group pulled from different departments.
Pick the work first, not the tool
The first question companies ask is usually "which tools do you teach?" That question belongs at the end. A day that starts from a list of tools introduces the team to a new menu, and nobody orders anything from it — because "when would I actually use this?" is left unanswered.
Built the other way round, the picture changes: you pick a piece of work the team does several times a week, that everyone finds tedious, and where mistakes are expensive. On a procurement desk that is usually writing a specification or lining up quotes that arrive in different formats; on another team it is reading reports, reviewing contracts, or repetitive correspondence.
That has one practical consequence: before the training, someone has to sit down and write the answer to "what are our repetitive tasks?" Without that list, the day inevitably turns into a general presentation.
Who should attend: a mixed group or one desk?
A group made up of people doing the same job moves faster than a mixed one. The reason is simple: the example is one everybody recognises, when one person gets stuck the others understand what they are talking about, and the flow built by the end of the day lands on a single desk all at once.
A mixed group — someone from marketing, someone from finance, someone from operations — is good for awareness and weak for application. Because everyone’s work differs, no shared example can be chosen, and once the example is generalised it fits nobody exactly.
Having both technical and non-technical people on the team is not a problem, it only changes the mix of the day. There are three separate subjects on the corporate side anyway — putting AI to work, speaking the same language as a technical team, and a first contact with software — and in most companies a combination is built.
Why does an awareness session evaporate overnight?
A presentation gives information, not reflex. For someone to start using a tool, they need to have run it once on their own work, with their own material, with somebody beside them. Watching it in a room does not produce that.
The second reason is discussed less: the person leaving the session does not know what to do the first time they get a wrong answer. Because nobody showed them the "why did the tool get this wrong, and how would you tell?" part, the conclusion tends to be "this will not work here." The tool being wrong is not the surprise; the surprise is that nobody has a way to check it.
Without a data boundary, training creates risk
The thing that has to be discussed in the first half hour of the day is which data will not go into the tool. If that sentence is never said, two kinds of people appear: the cautious one never uses it, the incautious one uses it where they should not. Both count as the training failing, and both are really the result of a missing frame.
Practical limits beat a theoretical privacy lecture: which document can be copied, which cannot, how a text with a client name in it gets anonymised, and what the company’s own tool policy says if it has one. These are things you can settle in a day, and when they are not settled all that remains is unease.
The same rule applies on our side: in a corporate day we do not use real client or supplier data when recording a screen or building an example — we build a fictional set. Teaching a session whose first sentence is "do not paste your data into the tool" using real data would contradict itself.
What should be left behind?
At the end of a day that went well there are three things: a working flow, built end to end, chosen from the team’s own work; a method for checking what the tool produces; and a short internal guide written in the team’s own words.
The third is the most underrated and the most durable. A guide handed down from outside sits on a shelf; the two pages the team wrote themselves at the end of the day is the thing that spreads through the company.
There are also things that will not be there at the end, and we say them up front: we are not a certification programme, we do not turn anyone into an AI engineer, and if the team is already advanced we say so and tell you we are not the right fit.
Who runs the day?
I run all of the open workshops myself. On the corporate side we run the process together with Uğur İnal: I build the content, and the management and technology questions — what will this cost us, which process should be automated, what should we keep in-house — are his.
There is a reason I am writing this down. The thing that annoys a corporate buyer most is finding out at contract stage that the person who wrote the proposal is not the person who walks into the room. Said up front it is not a problem; found out later it becomes a question of trust.
Frequently asked
Our team has no technical background — does that work?
It does. The most requested corporate subject is the part that needs no coding at all: handing over repetitive tasks, checking the output, and recognising which work is not suited to the tool. There is a separate subject track for non-technical teams.
What group size makes sense?
A size where everyone can put an example from their own work on the table. The larger it gets the more the day becomes a presentation; the smaller it gets the closer it is to one-to-one work. Tell us how many people are on the team and we will suggest a format.
Will we be working with our own data?
We work with examples drawn from your work, but which data does and does not go into the tool is drawn at the start of the day. Where real client or supplier data is not needed, we build a fictional set.
Do you issue certificates?
No, we are not a certification programme. What the team has at the end of the day is not a document but a flow that works on their own job, plus a short internal guide they wrote themselves.
Half day or full day?
A half day is for awareness and first contact; the team picks the tools up and tries something on their own work. A full day moves from awareness to application: we build one repetitive task end to end together. Which one fits depends on where the team stands today.
