Almost every company I talk to has already tried this. Someone ran a pilot. It went fine. And then nothing happened.
That's the part worth understanding, because "it didn't work" is almost never true. The demo worked. Everyone in the room said it was impressive. Somebody said "we should really do something with this." And then the quarter ended.
Pilots don't fail. They stop.
Failure would be useful — you'd learn something. What actually happens is quieter, and it's nearly always one of these four.
Nobody owned it after the demo. The person who ran the pilot had a day job. The pilot was the interesting thing they did that month, not the thing they were measured on. When the quarter got busy, it was the first thing to go, and nothing broke when it did. That's the tell: if a project can be dropped without anything breaking, it was never in anyone's workflow.
It ran on generic knowledge. The tool was impressive at things anyone could do. It couldn't quote your prices, use your terms, follow your process, or write in the way your customers expect from you. So every output needed a rewrite, and rewriting is the whole job. A tool that gets you 80% of the way there is worth nothing if checking the 80% takes as long as writing 100%.
It was one clever person's tool. One colleague got very good at it and became the bottleneck. Everyone else asked them to "just run it quickly." When that person went on holiday, the tool went on holiday.
Nobody defined what good looked like. So there was no way to tell whether it was working, which means there was no way to argue for keeping it, which means it lost every budget conversation it entered.
Notice that none of those are technology problems. The models got better every month of your pilot. That was never the constraint.
What a working setup actually looks like
The companies where this sticks have four things in place, and they're all unglamorous.
Workers that know your business specifically. Not a general assistant with a clever prompt — a role that has read your actual documents. Your price list. Your standard terms. The last two years of quotes you've sent. The email you send when a delivery is late. When a worker has those, its first draft is something you edit rather than something you rewrite, and that difference is the entire business case.
A job that happens on a schedule, not on demand. "Use it when you think of it" means never. The setups that survive are the ones where something arrives whether anyone remembered or not: the Monday pipeline report, the overnight inbox triage, the weekly summary of what shipped. Once people start expecting that email, the tool has entered the workflow, and it's very hard to remove.
A named owner who isn't the smartest person in the room. Ideally the person who does the work, not the person who likes the technology. If your most technical colleague owns it, it becomes their side project. If the office manager owns the office-manager workers, it becomes the way the office runs.
Two hours of training for everyone else. Not a manual. A session where each person builds one worker for their own job, badly, with help. People don't adopt tools they've been shown; they adopt tools they've touched. Somebody who has built one worker will build a second one without being asked. Somebody who watched a demo will not.
Why the first four are the ones that matter
Four is a small enough number to actually finish, and large enough that the approach proves itself. Pick them like this:
- The job someone complains about weekly. Not the biggest job — the most irritating one. Irritation drives adoption far better than efficiency does.
- The job with a clear right answer. Something where it's obvious whether the output is good. Save the judgement-heavy work for later, when trust exists.
- The job that's currently a bottleneck on one person. Quotes that only Petra can write. Reports only the boss produces.
- The job nobody has time to do at all. The competitor research, the follow-up with old customers, the documentation. This one is pure upside — nothing is lost if it's imperfect, because the alternative is nothing.
That list is deliberately not "the most valuable four jobs in your company." Starting with the highest-stakes work is how you get one bad output in week one and a company-wide conclusion that AI doesn't work.
The honest part
You can do all of this yourself. Nothing above needs a consultant. askTheodor costs 12€ a month, the academy walks through exactly this sequence, and plenty of people set it up over a couple of weekends. That's genuinely the cheapest path and I'd rather tell you than have you find out after paying me.
What it costs instead is your attention across those weekends — and attention is the thing most owner-managers have least of. That's the actual trade.
If you'd rather not spend it, that's what our setup and training service is: we install it on your machines, build those first four workers around your own documents, and run the two-hour workshop that hands it to your team. In German or English. Scoped per case, fixed price in writing before anything starts, and no price on the website because a four-person office and a sixty-person Mittelständler need genuinely different amounts of work.
Either way, the sequence is the same one. The only question is who spends the weekends.
One thing to take away
If your last pilot stopped, don't restart it with a better model. Restart it with a named owner, four specific jobs, your own documents loaded, and one thing that arrives on a schedule whether anyone remembers or not.
The model was never the problem.