How to scope an AI automation project without wasting money

Most AI automation money is wasted before anyone writes a line of code. It happens in the first conversation, when “automate our customer service” is accepted as a project. It isn’t a project. It’s a wish with no edges, so the work never finishes and nobody can say whether it paid off.

Scoping is how you give it edges. Here is the method I use for every build, including my own. At the end there’s a one-page template you can copy and fill in before talking to anyone, me included.

Step 1: Pick one workflow, not a department

A workflow has a start event, a few steps and an end state you can point at. “A lead fills in the website form, someone qualifies it, someone books a call” is a workflow. “Sales” isn’t.

Pick the one that is:

• Frequent. It happens at least several times a week. A task you do twice a year is almost never worth automating.
• Boring and repeatable. The same steps each time, with a small number of known exceptions.
• Visible when it fails. Slow replies, lost leads, double entry, things that slip through.
• Owned by one person. Someone who does it today and can tell you where it really goes wrong.

If three workflows look equally good, choose the one where a mistake is cheapest. Your first build is where you learn how automation behaves in your business. Learn that somewhere a failure costs an apology, not a refund.

If you can’t tell which of your workflows qualifies, the free 2-minute automation audit gives you a quick first read. It takes no email.

Step 2: Measure the baseline before anything is built

Write down how the workflow performs today. Four numbers are enough:

1. Volume: how many times a week it happens.
2. Time: how many minutes each one takes a person, start to finish.
3. Delay: how long the customer or colleague waits for the outcome.
4. Error rate: how often something goes wrong, such as a missed lead, a typo in an invoice or a duplicate entry.

Count for one or two normal weeks. Don’t estimate from memory. People are reliably wrong about their own work in both directions: they overcount the annoying tasks and undercount the invisible ones.

This is the step people skip, and it’s the one that protects your money. Without a baseline, every automation looks like a success in the demo. With one, you can ask a plain question after a month: is the number better, and by more than the system costs to run and maintain?

Step 3: Write the “must never happen” list

This is the most valuable page in any scope. Before talking about features, list what the system must never do. For a lead-handling workflow it might be:

• Never book the same customer twice for one request.
• Never lose a lead because another system was down.
• Never text someone who has opted out.
• Never promise a price or a time slot the business hasn’t approved.
• Never handle a safety emergency without a person.

Each line becomes a design decision and a test. When I built the Lead Responder engine, most of its tests check what happens when a webhook repeats, a vendor is down or a lead shouldn’t be booked at all. The happy path is one test. Getting through a bad day is the rest.

The list also has to cover the people building the system, not just the system. I learned this the hard way. While working on that engine, I ran its test suite in the wrong place. The setup step of the suite empties its database tables before the tests run, which is normal for a test database. It wiped the data behind the live public demo. It was demo data only, nothing a customer owned, but the lesson stuck, and two rules went onto my own list:

• Never run tests against a live database. The suite now refuses to run unless the database name says it’s a test database.
• Read what a setup or migration script does before running it anywhere near real data.

Your list will be different. What matters is writing it down before the build, because these are the rules that decide whether you need a five-step no-code workflow or real engineering. I go into that choice in n8n vs Make.com vs Zapier.

Step 4: Decide where a person stays in the loop

Mark each step with who decides: a fixed rule, the AI, or a person. The AI should mostly be reading and suggesting: classifying an email, pulling fields from an invoice, drafting a reply. Rules and people should decide anything that:

• costs money or commits the business to something,
• can’t be undone,
• touches someone’s safety, health or legal position, or
• involves consent, such as who can be contacted and how.

That’s the pattern behind Inbox Triage, which runs on this site: the AI labels each message, fixed rules decide the outcome, and a person reviews anything sensitive. It’s less impressive in a demo than “the AI handles everything”, and far more pleasant to live with.

If you want the longer explanation of why an agent that plans and calls tools needs these checkpoints more than a simple chatbot does, read Agentic AI vs chatbots.

Step 5: Set a stop rule

Decide, before you start, under what condition you’ll stop. For example:

If after four weeks live the first slice hasn’t reduced the weekly time on this workflow by more than it costs to run and maintain, we switch it off and keep the manual process.

A stop rule feels pessimistic. It’s actually what lets you start. It caps your downside at the cost of the first slice, turns “is it working?” into a measurement instead of a debate, and stops a half-working system from hanging around for a year because nobody wants to admit it didn’t help.

Put the running costs in the same sentence. An automation isn’t a one-off purchase. Model calls, tool subscriptions, hosting and the time to fix it when a connected app changes all keep going. That’s why SlickLab’s automation service is priced as a monthly subscription: so maintenance is planned, not a surprise.

Step 6: Fix the first slice

The first build should be the smallest version that runs on real work, end to end, with the “must never happen” list enforced. Not a prototype on sample data. Not every exception. One path, live, measured against the baseline.

A good first slice usually:

• handles the most common case, and sends everything else to a person,
• runs alongside the manual process for a week or two, so you can compare,
• logs every decision, so you can see why it did what it did, and
• has a fixed price and a fixed finish line.

Extensions come after the stop rule says the slice earned its place. Use the cost calculator for a rough idea of what a build like this costs, but the real number comes from the scope.

The one-page scoping template

Copy this into a document and fill it in. If you can’t complete a section, that’s useful too: it’s the question to answer before spending money.

AI AUTOMATION SCOPE — one workflow, one page

1. WORKFLOW
   Name:
   Starts when:                 (the trigger event)
   Ends when:                   (the end state you can point at)
   Owner today:                 (one person)

2. BASELINE  (counted over 1–2 normal weeks, not estimated)
   Volume per week:
   Minutes per item:
   Customer wait time:
   Errors per week, and what kind:

3. MUST NEVER HAPPEN
   -
   -
   -
   (each line becomes a design rule and a test)

4. WHO DECIDES EACH STEP
   Step                         Rule / AI suggests / Person
   1.
   2.
   3.
   Anything about money, consent, safety or that cannot
   be undone: Rule or Person.

5. FIRST SLICE
   The one path it handles:
   What goes to a person instead:
   Runs alongside the manual process until:
   Fixed price:                 Finish line:

6. RUNNING COSTS  (per month)
   Model / API calls:
   Tool subscriptions:
   Hosting:
   Maintenance:

7. STOP RULE
   After ___ weeks live, if ______________________,
   we switch it off and keep the manual process.

8. DATA
   What data it touches:
   Where that data is allowed to live:
   Who can see the logs:

Where to go from here

If you filled in the template and you’re confident in it, you’re ready to talk to a builder, and you’ll get a much better quote, because you’ve done the part that usually takes the first two meetings.

If some sections are blank, that’s exactly what the paid AI Readiness Audit is for. For USD $180 to $600, one-time, I map your workflows with you and deliver a prioritised opportunity map: what is worth automating, what isn’t, and a clear next step, scoped like this page, before you commit to any build.

For the wider view of where AI agents fit in a small business, start with the guide Agentic AI for small business. If your workflow lives inside ServiceNow, the same method applies, and ServiceNow AI integration: what actually works covers the platform-specific parts. If you need an AI assistant to reach internal tools safely, read What is an MCP server. And when you’re ready, see the products I already run, or send me your workflow.

Questions people ask