Written by Nick Baudoin

We have never run an AI training course, and we use AI in almost every recurring part of the business. Those two facts are connected, and the connection is the opposite of what most rollout advice assumes.

The standard approach starts with the tool. Pick a platform, buy seats, run a session, measure adoption, worry about the people who never log in. What we do starts with a complaint. Somebody says a recurring task is eating their week, and that complaint is the trigger for everything that follows.

Why the tool-first version stalls

A training program teaches capability to people who don’t yet have a problem in front of them. They learn it, they go back to their week, and their week is already full. The knowledge decays before it meets a use case.

The other failure is subtler and harder to reverse. Rolling out a tool with a mandate makes adoption a loyalty test. People who are already stretched hear “learn this on top of everything else”, and the quiet resistance you get isn’t about technology at all. It’s about being handed a second job by someone who never asked what the first one was costing.

Starting from a complaint inverts both problems. The person already has the use case, because they raised it. There’s no case to make that the problem is real, because the person who lives with it named it. And the outcome belongs to them rather than to whoever bought the seats.

The three outcomes a complaint can have

Once someone raises a recurring problem, it turns into one of three things, and which one depends on the shape of the work rather than on anyone’s job title.

An automatic routine. The task is repetitive and the output is predictable. It becomes something that runs without a person. Not one person has to learn a thing, which is the best possible result and the one that rarely gets counted as adoption.

A recorded walkthrough. The task is occasional, or it’s conceptual enough that watching someone reason through it once is worth more than a document. We record it and attach it to the work it belongs to. It’s five minutes of someone’s screen, not a course.

A skill with an evaluation process. This is the interesting case: the task recurs, but the output varies enough that you can’t just automate it and walk away. Copy, analysis, review work. Here we write down how the task should be done, and separately how you check whether it was done well. The second half is the part most teams skip, and skipping it is what produces the quality drift that makes teams give up on AI six months in.

Those get grouped by purpose and stay visible across the team, so the useful one surfaces from a description of the problem rather than from remembering it exists. Knowing the catalogue isn’t the point.

Why the evaluation half matters more than the automation half

If you take one thing from this, take this one.

Automating a task is the easy half, and the half almost everyone does. The hard half is knowing, three months later, whether the output is still good, because degradation is gradual and invisible. Nothing breaks. The work just gets slightly worse in a way that no single person notices, and by the time it’s obvious the team has lost confidence in the whole idea.

So for anything with variable output, we write the check at the same time as the process. What does a good result look like, what are the failure modes, and what’s the recurring test? Then that check runs on a schedule rather than when someone remembers to worry about it.

This is also what makes the work safe to hand to a new person. A documented process with a documented standard can be delegated. A process that only works because the person running it knows when it looks wrong cannot.

Where a person stays in the loop, deliberately

The rule we operate is that anything irreversible or outward-facing waits for a human.

Software drafts, prepares and flags. It can watch metrics, prepare what should happen next, and tell somebody it’s ready. It doesn’t send on anyone’s behalf and it doesn’t make decisions at the level where being wrong is expensive to undo. Email drafts sit as drafts.

That boundary does two jobs. The obvious one is risk. The less obvious one is trust: people adopt automation faster when they know exactly where its authority stops, because they’re not being asked to take it on faith. Ambiguity about what the system is allowed to do on its own produces more hesitancy than any amount of capability does.

What this means for hiring

Two knock-on effects, and the first one surprised me.

The skill that’s become most valuable isn’t prompting. It’s the ability to describe your own work precisely enough that someone, or something, else could do it. That’s a writing and thinking skill, it’s visible in an interview if you ask for it, and it transfers across every tool that will exist in five years.

The second is that written process makes trial work meaningful. We run a paid trial for most roles, and it only tells you something if the candidate has a real standard to work against. Without documentation, a trial measures how quickly someone guesses your preferences. With it, it measures whether they can hit a stated bar and notice when they’ve missed it.

Our hiring runs largely on referrals from people already on the team, which is a good source and a narrow one. The trial is what keeps that from turning into hiring by familiarity.

What it costs when it goes wrong

Two failure modes, both of which we’ve hit.

The first is building something for a complaint that turned out to be seasonal. Somebody has a terrible fortnight, the problem feels permanent, and three weeks of work goes into a routine that runs twice more and then never again. The cheap guard is to wait for the complaint to arrive twice from two different weeks before building anything durable for it.

The second is the process that outlives its reason. The task changes, the automation keeps running on the old shape, and the output is quietly wrong in a way that looks fine at a glance. That’s the same drift problem as quality degradation, and it has the same fix: the scheduled check has to include whether the thing is still solving the problem it was built for, not only whether it’s still producing output.

The honest caveats

This works at our size. A complaint-driven approach needs people who feel safe raising the complaint and a short path from raising it to something changing. Both get harder as headcount grows, and I don’t have evidence about what breaks first.

It’s also slower at the start than a mandate. You wait for real problems instead of scheduling adoption, and for the first stretch it looks like nothing is happening. The trade is that what does get built stays used, because every piece of it started with somebody who wanted it.

And it produces uneven coverage on purpose. Some parts of the business have a lot of this and some have almost none, determined by where the recurring pain actually is rather than by a plan. That’s a feature if you believe the complaint is a better signal than the roadmap, and a problem if you need to report uniform adoption to somebody.

Common questions

What if nobody raises a complaint? Then either there isn’t a recurring problem worth solving, or people don’t believe raising it will change anything. The second is the real issue, and no tooling decision fixes it.

How do you stop quality drifting once something is automated? Write the check at the same time as the process, and put it on a schedule. If the only quality control is someone noticing that the output looks off, you don’t have quality control; you have luck.

Doesn’t this need technical people? Less than it used to. The binding constraint is being able to describe the work and say what a good result looks like. That’s much closer to writing a standard operating procedure than to writing software.

Author Bio:
Nick Baudoin is Founder and President of Alkali, which builds websites and marketing programs for established B2B companies.