Guide · Delivery
How to choose and scope a first automation project that pays for itself — picking the right process, defining success honestly, and avoiding the traps that stall most first builds.
At a glance
The first automation a business ships sets the tone for everything after it. A tight, boring, successful first project builds the confidence — and the internal skills — to take on bigger systems. An ambitious first project that stalls poisons the well for years.
This guide is the scoping conversation we have with every new client, written down. It will not tell you which platform to buy; it will tell you how to choose a project that succeeds.
The instinct is to automate the most painful process first. Resist it: the most painful process is usually painful because it is complex, political or exceptional — the three things automation handles worst.
The best first candidates are boring: high-frequency, rule-driven work where the correct outcome is checkable. Think enquiry handling, quote follow-ups, appointment reminders, document intake, invoice chasing — work your team does on autopilot and resents.
Scope on a first automation is a fence: the value comes from what you keep out. Every “while we're at it” addition raises the integration surface, the testing load and the number of things that can stall the launch.
Write down what the system will not do with the same care as what it will. The excluded items are not rejected — they are the roadmap for phase two, earned by shipping phase one.
If success is not defined before the build, the launch review becomes an argument about anecdotes. Pick a small number of measures you already track — response time, completion rate, hours spent, missed enquiries — and record their current values now. That baseline is the most valuable artefact of the scoping phase.
Be honest about the goal: cost, speed, quality or capacity. A system tuned to save hours looks different from one tuned to never miss a lead. Choose, and write the choice down.
The documented process and the real one are rarely the same thing. Sit with the person who does the work and map what actually happens — including the workarounds, the sticky notes and the exceptions.
Test data proves the system runs; only live work proves it works. Pilot on a bounded slice of real volume — one location, one enquiry type, one day a week — with the old process still standing behind it.
Review honestly, including the failures. A pilot that reports only good news has not been reviewed; it has been marketed. The failures found in a two-week pilot are the cheapest ones you will ever fix.
An automation only the builder understands is a dependency, not an asset. From the first week of the build, decide who in the business will own the system, monitor its output and make routine adjustments — and make sure the build produces the documentation and access they need.
Keep reading
Find out whether your business is ready for one connected operating layer — score fragmentation, handoffs, systems and ownership, read the two totals together and choose one focused next move.
Score your business across revenue leakage, operational burden, systems and team readiness — two totals, a diagnostic matrix and one clear next move.