Workshop or implementation: which one you actually need
Workshop or implementation: two different purchases
“We have to do something with AI” often mixes two jobs. A workshop gives the team a shared language, shared rules, and one to three experiments they run themselves afterwards. Implementation, for us, starts with the Process Check: one recurring workflow, a written case, and a package size if you then want it built. Both are real offers. They answer different jobs.
This is for leadership and office leads in a Swiss SME, often 5 to 80 people, with little or no internal IT. You are choosing between an AI workshop for the company and AI consulting that ends in a built workflow. You are not choosing a prompt course, and you are not choosing a startup product.
Choose the workshop
- The team needs shared rules and an allow-list before anyone pastes client work into a chat
- People already use tools, and nobody agrees which data class may go where
Choose the Process Check
- One workflow repeats: same input, same output, a person you can name
- You want a case and a package size in 30 minutes, then you decide whether to build
When a workshop fits
The AI in Business workshop is for leadership and specialist teams who already touch tools, or should, and do not share guardrails. The job sounds like this: everyone should be allowed to use a company chat or Copilot without dropping customer data into a private account.
You should leave with three concrete things, not a slide titled “AI strategy”:
- Which tools are on the allow-list, and which stay off it for work data.
- Which data class may go where: public copy, internal notes with no people in them, personal data.
- One to three experiments the team will run itself in the following weeks, small enough to finish, with a person named for each.
Bring the tools that were already open this week, and two or three places where client text went into a prompt. You may redact names. No system gets connected on the day.
That day fits when the visible problem is inconsistency. One person has a private ChatGPT account. Another was told not to. A third pastes client mail “just to draft the reply” because there is no agreed place to do it. Banning the tools moves that draft onto a phone. Buying seats for everyone without the page of rules leaves the same hole, now with an invoice attached.
The workshop is a poor fit when you already know the workflow and the only question is whether to build it. A room full of people will not assemble Monday’s report by the end of the day. Training is not a connector between your inbox and the accounting tool.
An engineering team that wants agents inside a code repository is a different format: Agentic Coding. This article is about the office.
When the Process Check fits
The Process Check is one recurring workflow. Thirty minutes online, a case (what, who, how often), and a package size if a fixed-price build is the sensible next step. You do not have to buy the build. Detail of what the half hour includes and what it refuses is in what the Process Check is.
Bring work that already has a shape: invoices that should land in the books, quote follow-ups that die in one inbox, a report glued from several sources, a spreadsheet that only exists because two systems do not talk. Copilot can still be the right answer in the middle of that. When a licence is enough, and when you need the transfer built, is covered in which process you should automate first.
Bring a file from the last run, the name of the person who does it today, and how often it happens. You get a case, or the statement that this workflow is not ready yet. Getting the whole team onto shared vocabulary is not the job of those 30 minutes.
The Check is a poor fit for “we need a shared vocabulary”, “we need an allow-list”, or “we want the board to see that we take AI seriously”. Those are workshop jobs. It is also the wrong hour for a product idea or an MVP. Validating a product is a different offer. This cluster does not scope startups.
A made-up example, not a client story: twelve people, a bookkeeper, and a shared inbox. On Monday someone rebuilds a report from the CRM, two sheets, and a PDF. On Tuesday a colleague pastes a customer complaint, name included, into a private chat to “make it nicer”. The report is a Process Check topic: it repeats, it has inputs, it has an output. The complaint is a workshop topic: the team has no rule for personal data, so the draft went to the wrong place. Buying a workflow for the complaint does not write the rule. Running a workshop for the report does not move the figures next Monday.
AI training versus implementation
People search this as AI training versus implementation, or as AI consulting for an SME. Training, in the useful sense, is the workshop: the same terms, the same allow-list, a few experiments, then the team works. Implementation is a bounded change to one workflow, after that workflow is named.
A catalogue of tools is neither. So is a prompt library that never touches the Monday file. If a proposal does not say which of the two jobs it finishes, you cannot compare it with the other quotes in the pile. Ask the vendor to point at the outcome: a one-page rule the office will actually use, or a workflow that runs with a person checking the result. If they answer with both, ask which one the engagement is for. Combining them into one invoice is how offices buy a day of slides and still copy the report by hand.
If you think you need both
Sometimes both jobs exist, as in the sketch above. Do them as two decisions, in an order, not as one blurred project.
Start with the workshop if personal data is already leaving the company in private chats, or if nobody can say which tool is allowed. Building on top of that habit locks the habit in. A page of rules is cheaper to get wrong and fix than a package built on the wrong data path.
Start with the Process Check if one workflow is already clear, the data in it is allowed to sit in your existing tools, and the pain is hours, errors, or a single person who cannot be on holiday. You can write a short allow-list afterwards without waiting for a full day, if the only people involved are the ones who touch that workflow.
Do not buy a build “so the workshop has something to show”, and do not book a workshop “so the build has change management”. If you cannot say which sentence is yours, you are not ready for either invoice. Spend an hour internally: list the repeating work on one side, and the places client data currently gets pasted on the other. The longer column is the first purchase.
What you are not buying
A product idea, a venture, or an MVP. That is outside this choice.
A legal opinion on the Swiss Data Protection Act. The workshop can set a practical traffic light with the team. It does not replace advice from someone who carries that duty for you.
A promise that every seat will “use AI” by Friday. A workshop can change what people are allowed to do. A build can change one workflow. A usage percentage is a different measurement from either result.
Two next steps, not one button
Need rules for the whole team, an allow-list, and a few experiments people run themselves: the workshop.
Need one bounded workflow that already has input and output: the Process Check.
Is an AI workshop the same as implementing a workflow?
No. A workshop sets shared rules and a short list of experiments the team runs afterwards. Implementation here means the Process Check on one recurring workflow, then a fixed-price build only if the case is worth it. Pick the one that matches the job. If client data is going into private chats, start with the workshop. If the same file is rebuilt every week, start with the Check.
Written by
Aurum Avis Labs
Builds and ships at Aurum Avis Labs. Writes here about what we learn working with founders and SMEs in the DACH region.
Related Articles
You might also be interested in these articles
