How to scope an automation project before you buy

The classic failure loop in small-business automation goes: vague idea → tool purchased → half-configured system → workarounds → quiet abandonment → “we tried automation, it didn’t work.” The tool usually takes the blame. The scoping — done in the first meeting, or not at all — is almost always the culprit. Here’s the method we use, which you can run yourself before talking to any vendor.

Step 1: State the problem without naming software

Write one sentence in this shape: “[Who] struggles to [do what] because [root cause], and it costs us [what].” For example: “Our office manager struggles to respond to inquiries the day they arrive because they come through four channels, and it costs us jobs we never knew we lost.” If you can’t fill in the cost, you don’t have a project yet — you have an annoyance. Annoyances make bad projects because nobody defends them at invoice time.

Step 2: Map the workflow as it actually happens

Not the official version — the real one, with names: who touches the task, where information lives, where it waits, where it gets retyped. Walk through the last three real instances, not the hypothetical average. The waits and the retyping are where the money is; the map is usually more revealing than any vendor demo. (You’ll also discover whether you have a definable process at all — the test from Automate, delegate, or hire? A decision guide.)

Step 3: Cut scope until it’s boring

Take everything you’d love the system to do and sort it: must have (the first version is pointless without it), should have (soon, not now), and not yet (everything that makes the project bigger without proving anything). The first version should prove one workflow end to end — intake to outcome — and nothing else. Boring first versions get finished, and finished systems earn the right to grow. Demos that do everything get abandoned.

Step 4: Define “done” before you start

Write down, in advance, exactly what you’ll check to know it’s working — call these your acceptance criteria. Good ones are embarrassingly concrete: “every form submission appears in the CRM within one minute, with a reply sent and a human notified — verified across twenty real submissions.” If a vendor can’t restate your criteria back to you, or waves at “it’ll save you tons of time,” the project is drifting before it starts.

Step 5: Only now, talk tools

With a problem statement, a workflow map, a must-have list, and acceptance criteria, tool selection becomes almost mechanical — and every conversation gets sharper, because you’re asking “can you meet these criteria for this workflow?” instead of watching demos. The difference in quotes you’ll receive is not subtle.

The pattern behind all five steps: clarity is cheap before you build and expensive after. An afternoon of honest scoping routinely saves a five-figure misfire. And if the scoping conversation is the part you’d rather not run alone — that’s a thing we do; the glossary’s plain-English definitions (AI & automation glossary) make a good pre-read.