Your first automation project: picking a winner

Your first automation project should be frequent, rule-based, boring, and already written down — and its failure should be annoying rather than catastrophic. For most B2B service firms that means lead routing, data entry between systems, or meeting admin, not proposals or client-facing judgement calls. The point of project one is not the savings; it is proving to yourself and your team that automation ships and holds.

Why does the first project matter more than the tenth?

Because it sets the pattern. If the first project ships in a couple of weeks and quietly removes a chore, the team starts volunteering candidates, and the honest view of what AI automation actually does for B2B firms becomes internal culture rather than one person's opinion. If the first project is a six-month attempt to automate proposal writing, it dies half-built, and every future suggestion is met with "we tried automation".

I see the failure version regularly. A firm picks its most painful process — usually also its most complex — stalls, and concludes automation does not work for them. But the pain of a process and its suitability for automation sit on different axes. Project one should optimise for probability of shipping, not size of prize.

What makes a task a good automation candidate?

Four tests, applied in order:

• Frequency. Daily, or several times a week. A quarterly task can be miserable and still not be worth automating.
• Rules. Someone can write the decision logic as if/then statements without saying "it depends" more than once or twice. Judgement-heavy steps disqualify a first project — not automation forever, just first.
• Documentation. The task already exists as a written procedure another person could follow. If it lives in one head, write the SOP first; the automation is a translation of the SOP, not a substitute for writing it.
• Blast radius. When it breaks — and at some point it will — the cost is internal delay, not a client-visible error. Automating invoice generation before automating internal notifications gets this backwards.

Score your candidate list against those four and the winner usually picks itself. In the B2B service firms we work with, it is commonly one of: routing inbound enquiries to the right person, syncing form fills into the CRM, chasing internal handoffs, or assembling the weekly numbers email.

Which tasks should you rule out first time round?

Anything client-facing with your name on it, anything requiring taste, and anything where the process itself is still contested internally — automating a process the team disagrees about freezes the disagreement into software. Also rule out tasks that only look automatable because a vendor demo made them look easy. AI agents in 2026 do certain jobs genuinely well, but "the demo worked" is not one of the four tests.

The same discipline applies upstream of any tooling decision. If you cannot name your buyer, no workflow will fix your pipeline, because the defect is in the definition, not the plumbing.

How do you run the project so it actually ships?

The mechanism I use is deliberately dull. When you have picked the task, then write the current manual process as numbered steps, including the exceptions people quietly handle. When the steps are written, then mark each one as rule-based or judgement, and automate only the rule-based spine, leaving judgement steps as human checkpoints. When the build is drafted — most first projects fit comfortably in a no-code tool, though it pays to know where no-code ends and real builds begin before you start — then run it in parallel with the manual process for one or two weeks and compare outputs. When the parallel run shows no gaps, then switch over, keep the manual SOP as the documented fallback, and set a review for thirty days out.

The parallel run is the step people skip and the step that saves you. It converts "we hope it works" into observed behaviour before anything depends on it.

How do you know if it worked?

Pick the measure before you build: hours per week returned, lag removed (an enquiry answered in five minutes rather than five hours), or error rate on data entry. Measure the baseline for a week before switching anything on, or you will have nothing to compare against.

Most first projects return a small, dull, real number — two or three hours a week, a handoff that stops being forgotten. That is the correct outcome. The compounding arrives with projects two through ten, which now have a template, a sceptic-proof example, and a team that trusts the process. The firms that get automation wrong chase a transformation in month one; the firms that get it right install a habit.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.