Three weeks after the AI workshop, the flipchart photos are still sitting in the Teams chat. The list underneath is sorted by effort and benefit, two items are marked green. Nobody has opened it since. The day was good, the feedback was good, and every workflow in the company still runs exactly as before.
This is not a complaint about the workshop. An AI workshop solves one part of the job remarkably reliably. The other part it cannot solve, by its very design, and which part that is stands fixed before the first participant walks into the room.
What does an AI workshop actually deliver?
An AI workshop delivers three things reliably: a shared language in the leadership team, proof on real work that the tools can do more than fill in text blocks, and an honest list of the places where work hurts. All three are preconditions for change in daily operations. They are not the change itself.
The second point is usually underrated. What moves a room most is an unspectacular exercise: solve the same task twice, once without any context about the company and once with it. First the generic suggestion that fits any industry, then the same brief after the tool knows the role, the customer structure, the tone and the last three reports. The difference between those two answers convinces a management team in ten minutes more than any slide about possibilities.
You can try this without booking anything. The tools for it sit in our toolbox, eleven of them, copy and paste, no sign-up: an interviewer that writes the company profile together with you, a traffic-light template, a baseline sheet. Everything one person can do alone in their own tool costs nothing and needs no room with a flipchart.
What a workshop cannot deliver has nothing to do with the quality of the facilitation. A day is a format with people in a room and an end at five. Operations is a format with access rights, approvals and a recurring monthly date. You cannot rebook one into the other, not even with a second workshop.
The split that explains the day after
When recurring work refuses to stop, we work with seven questions. What does the system know about us, where can it reach, what can it do, what is it allowed to do, who works with it and who carries it, how does it stay alive, what does it deliver. The model behind this underpins our AI consulting.
What matters is not the list but where it breaks. Four of these questions one person can largely answer alone, in their own tool, in a single morning: what the system knows about the company, what it can do, who can judge the output, and how you would recognise an improvement. A workshop works precisely in that group, which is why the day feels productive. It is productive.
Three questions fall out of the room:
- Where can it reach? Access to mail, file storage, the ERP or time tracking cannot be worked out in a session, it is granted. And granted by someone who is rarely in the room that day.
- What is it allowed to do? Which step may run without asking and which waits for an approval depends on a single question: what does it cost to undo this mistake? A badly formatted table gets fixed during the coffee break. An email to the customer with the wrong number does not. That is a management decision, not a group result.
- How does it stay alive? A workflow nobody maintains quietly stops working after the second model change. You notice it through a sentence like "that used to work better", and you notice it weeks later. Maintenance needs a person with hours, not a resolution.
These three are not insights you can work out. They are decisions. And decisions rarely happen in a room where everyone is currently enthusiastic. The decision comes later, when the calendar is full again. Which is why it pays to pull them forward.
So you can leave the first four questions to the workshop. The other three you answer beforehand, and three lines are enough for that.
On the first of those three it helps that we come from information security: before the first access, we clarify which data a system may read and what of it leaves Switzerland. That is the reason companies let us near their file storage, and it is no reason to postpone the rebuild.
The date that comes before the invitation
Enthusiasm has a short half-life. In our experience the week after such a day is the best opportunity a company gets to rebuild something under its own steam. After that, daily business wins, and not out of inertia, but because daily business has customers and the workshop list does not.
That is why, for days on which a team builds on its own work, we have written down one condition: management commits to the decision date before the day takes place. A date on which someone decides which of the built approaches continues, usually within thirty days. Without that date we do not take the day on.
It sounds bureaucratic and works the opposite way. A date in the calendar answers three questions at once that otherwise stay open: who decides, by when, and on what basis. It also prevents the most common form of failure, the friendly one: nobody says no, everyone nods, and four months later the topic is closed without a decision.
The date costs nothing and fits into the invitation. Two sentences are enough: on this date, management sits down for thirty minutes and decides which workflow gets rebuilt. Everyone attending the workshop then knows from the first coffee what the day is heading towards, and works differently because of it.
If the decision ends up being to rebuild a single workflow, that is the better news. A time-boxed undertaking with a date is easier to approve than an open-ended retainer, and that is exactly what One Less Process is for: four weeks, one workflow, measured against the number from before.
The person who has the hours
The second piece of preparation is less comfortable, because it costs time before anything runs. You need a named person in the company who carries the rebuild. Our guide value for an ongoing mandate is four hours a week, and without that person we do not start. Honestly, this is the condition a conversation with us most often hinges on.
This is not a new position and not a title. We mean the person who answers access questions, collects approvals, corrects the work instructions when a result is almost right, and notices that the summaries have got worse since the model change. Technically they need to know nothing. What is needed is an overview of the operation and being reachable.
The most common answer to this question is that the team will handle it. Translated, that means nobody will. A task that sits with everyone loses every week against a task that sits with one person. Whoever cannot name someone on the workshop day will not get a name after the workshop either.
The second most common answer is the head of IT, and that is usually the wrong choice. Not for lack of ability, but because that role already wears three other hats and does not run the day-to-day workflows itself. What works best in our experience is someone from the area where the work actually comes up, close enough to management to get an approval in two days instead of two weeks.
The number you cannot collect afterwards
The third piece of preparation is the one most often forgotten and the least recoverable. For the workflows that come up in the workshop, you need today's costs beforehand.
Afterwards it no longer works honestly. Once someone in the room has described how painful the monthly report is, everybody remembers the worst version. Once a first draft is running, nobody remembers the rework from before. The measurement before the start is the only one you cannot repeat.
A workflow is rarely expensive through working time alone. On top come handovers between people, external costs, errors and rework, and waiting time, during which a case sits and someone else is blocked. Waiting time is the item that usually goes missing in such calculations, even though a case between two departments spends most of its life sitting still. How to add up the five items without turning it into an undertaking with its own project manager, we wrote down in calculating what a workflow costs. One hour per workflow is enough, and the estimate may be rough. What matters is that the number is on paper before the workshop and confirmed by the person who does the work today.
That number also changes the day itself. An idea without a price tag wins the room on enthusiasm. An idea with the line "this costs us this much today" wins on value, including when it sounds boring.
When the list ends up too long
A long list is not a result, it is raw material. Once the workshop is over and the list runs longer than three lines, a separate question follows: which idea first. That needs no further meeting, two axes are enough. We described it in prioritising AI use cases, including the cases where the most popular idea is the worst one to start with.
What belongs in the invitation
Before you book an AI workshop, with us or with anyone else, write three lines into the invitation. First, the date on which the result gets decided, and who decides. Second, the name of the person who will have the hours afterwards. Third, the three to five workflows that will be discussed, each with a rough number for what they cost today.
With those three lines, a good day becomes a beginning. Without them, a good day stays a good day that people still mention in December, and a workflow that runs unchanged in January. This preparation decides more about the outcome than the choice of facilitator.
If you are unsure about the third line, bring the workflows to the free first conversation. We work through them together, and afterwards you can see which one is worth doing first.
In rooms like these we rarely ask which idea is best. We ask: who has four hours free on the Monday after the workshop, and do they know about it yet?
Frequently asked questions
What needs to be settled before an AI workshop?
Three things the workshop itself cannot settle: the date on which the result gets decided, and who decides. The name of the person who will have the hours afterwards. And for the three to five workflows you plan to discuss, a rough number for what they cost today.
How soon after an AI workshop should the decision be made?
We usually set the decision date within thirty days and have it committed before the workshop happens. Enthusiasm has a short half-life, and after that daily business wins. A date in the calendar settles up front who decides, by when, and on what basis.
Does AI in daily operations need its own position in the company?
Not a new position, but a named person with a time budget. Our guide value for an ongoing mandate is four hours a week. They answer access questions, collect approvals and correct the work instructions. Technically they need to know nothing; they need an overview of the operation and to be reachable.
