In short: Many AI projects start too big. One platform, every department, ten use cases at once. Three months later, nobody knows whether it paid off. My counterproposal is the smallest start that still proves something: one process, one person, two weeks. Measure before, measure after, then decide.
Why starting small is not a sign of hesitation
A small pilot sounds cautious. But above all it is one thing: a faster path to a decision.
A large project with many people involved delivers, after weeks, a picture made of many opinions. Some think it is great, others do not use it, and the truth lies somewhere in between. A small pilot delivers a number after two weeks. Time before, time after, for one clearly defined workflow.
With that number you can decide whether to continue. With a picture made of opinions, you cannot.
The math has to fit on one line
Before I plan a pilot with a company, we work through this formula together:
(Time before minus time after) times frequency times fully loaded cost per hour, minus AI and maintenance costs.
A worked example, made up to show the principle: An employee needs 45 minutes for a standard quote. With AI support it might be 15. She writes 10 such quotes per week. That adds up to around five hours per week, multiplied by her fully loaded cost. The ongoing costs for AI and upkeep are deducted from that.
If this calculation does not fit on one line, the use case is the wrong one. Either the workflow is too rare, too unclear or too different from one time to the next. Then we look for another one.
The first part is what matters: time before. Most companies do not know it. They estimate. That is why we measure it before anything gets built. A few days of writing it down is enough. Without this baseline, every later success story is just a claim.
Good starting processes
Not every workflow is suited for the first pilot. Good candidates are processes that occur often, follow a pattern, and where a person can judge the result quickly. From my experience, these work well, for example:
- Preparing quotes: Generate a first draft from the inquiry and the price list
- Customer service replies: Drafts for recurring questions that a person approves
- Meeting notes: Turn a recording or transcript into a clean entry in the CRM
- Screening tenders: Read new tenders and pre-sort which ones fit at all
What they all have in common: The result is a draft, not a finished product. A person decides. That keeps the pilot safe and the measurement honest.
Day one: no workflow tool
One point that surprises many people: In the first days I do not build any automated workflow. No n8n, no integrations, no automation.
Instead, the person works with a normal AI chat and a carefully assembled folder. It contains exactly the documents this workflow needs: the current price list, three good sample quotes, the rules that otherwise exist only in a colleague’s head.
The reason: The fastest gains often do not come from automation, but from having the right knowledge quickly at hand. Anyone who no longer has to spend 20 minutes searching for the right sample quote is already saving time before anything runs automatically.
Only once it is clear that the workflow works on this foundation is it worth automating.
The three-times rule
From this follows a rule I apply consistently: Only once a prompt has been repeated three times by hand does it become an agent.
Before that, you do not know whether the workflow really recurs. And you do not know which instructions are actually needed. The first time, you are still finding the words. The second time, you notice what was missing. The third time, it is clear how it works. Then it is worth writing it down for good.
And an agent does not go into production right away. It gets a probation period. At a conference talk I heard about this approach from a company that has had good experiences with it: Every employee first builds their own agent, in a simple tool without programming. It has to prove its worth on the business side. Only then is it properly integrated technically.
Before that, things had run the other way around there. The technology started first, requests from the team piled up, people tested for two to three weeks, said “it does not do what I had in mind at all”, and left it alone. Business quality before technology is the better order.
When it does not work: the cheapest levers first
Not everything in the pilot will work right away. That is normal. What matters is where you start fixing it. I always go in this order, from the cheapest to the most expensive lever:
- Context: Does the AI have the right documents? Is a rule missing that only exists in someone’s head?
- Instructions: Is it clearly described what the result should be?
- Tools and access: Can the AI reach the data it needs?
- Breaking it down: Is the task too big for a single step?
- Model: Only at the very end, the question of whether a different language model would be better.
Most cases where people say “the model is too dumb” are context problems. A better model with the same missing documents produces the same errors, just more eloquently.
The step toward several agents working together also comes late. Anthropic showed in an internal test that a system with several agents can perform significantly better than a single one on broad research tasks. The price was roughly fifteen times the computing power. For simple workflows, that is waste. For your first pilot, certainly.
After two weeks
At the end of the pilot, you have three things:
- A measured time before and after for a real workflow
- A collection of documents and instructions that belongs to you and that you can keep using
- One person on the team who knows what it feels like and can tell the others about it
The last point is often underestimated. One convinced colleague moves more than any presentation from the managing director.
And if the pilot shows that it is not worth it? Then you have invested two weeks instead of six months. That is a good result too.
What this means for you
Before you start an AI project, clarify:
- Which single workflow costs you the most time and still follows a recognizable pattern?
- Who on the team does this workflow most often and would be open to taking part for two weeks?
- Do you know how long this workflow takes today, measured and not estimated?
- Does the calculation of time saved, frequency and cost fit on one line?
- Who decides after two weeks whether to continue, and based on which number?
Building agents is no longer a feat today. Writing down the knowledge that sits in your team’s heads and keeping it current in daily operations is.
If you would like to select your first workflow together, book a first call. We will work out the line together and see whether it holds up.
