Guide · Delivery · 4 min read
Scoping Your First Automation
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.
LB Labs · Updated Jun 2026
At a glance
- The best first automation is boring: frequent, rule-driven and measurable.
- Scope is a fence, not a wishlist — decide what the system will not do.
- Define success before the build, in numbers you already track.
- Pilot on live work with a safety net, not on test data.
- Plan the handover from day one — an automation nobody can run is a liability.
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.
Choose a boring process
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.
- It happens at least daily — volume is what makes the return visible.
- A competent new hire could learn the rules in a week.
- The output is checkable: right or wrong is not a matter of opinion.
- It touches at most two or three systems.
- Nobody's job is defined by it — assistance, not politics.
Draw the fence
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.
Define success before the build
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.
Map the process as it actually runs
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.
- 01Walk through the last twenty real cases, not hypothetical ones.
- 02List every exception you find and decide: automate it, route it to a human, or exclude it from scope.
- 03Mark every handoff between people or systems — each one is an integration requirement or a failure point.
- 04Confirm the map with the people who run the process; they will correct it in minutes.
Pilot on live work, with a safety net
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.
Plan the handover from day one
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.
- A named internal owner, agreed before go-live.
- A runbook: what the system does, what to check daily, what to do when it misbehaves.
- Access held by the business — accounts, credentials and admin rights in your name, not the vendor's.
- A defined support path for the things the owner cannot fix.