What a small automation project scope includes (and what it doesn't)

Most quotes go wrong before anyone writes a line of code, because nobody wrote down a small automation project scope, and the best one fits on one page. I’ve watched the same thing happen over and over. An owner asks for “something that handles our leads.” The builder hears “a form that pings Slack.” The owner meant “a form that pings Slack, adds the lead to the CRM, sends a personal reply, books a call, and somehow fixes the spreadsheet from 2023.” Three weeks later both of them feel cheated, and both of them are right.

This page is the one-pager I’d want in front of me before asking anyone for a quote. It’s a sample scope for a fixed-price, $395, one-automation build. I go through it line by line: what’s in it, what the owner has to bring, what keeps costing money every month after the build, how you check the work, and what’s excluded on purpose. If you’re an owner deciding whether to ask for a quote at all, read it as a checklist. If a builder’s proposal is missing a line from it, ask about that line.

What is a small automation project scope?

A small automation project scope is a written agreement about one automation. One event starts it, it does one job across a few named systems, and it ends in one result you can check. That’s all. It isn’t a strategy, a “digital transformation,” or a promise to make the business efficient.

The word “one” is doing most of the work. One automation can still touch four tools. A website form, a CRM, an email account and a team chat are four systems but one automation, because one event sets off one chain. Two automations means two triggers, like “when a form comes in” and “every Monday morning.” Each trigger has its own failure modes and its own tests, so each one gets its own price.

I’ll use one running example, since abstract scopes are how arguments start. A small plumbing company’s website contact form currently sends an email to a shared inbox that nobody watches on weekends. (If you’ve ever wondered where those messages actually end up, I took the whole trip apart in where a website inquiry goes after you hit send.) The automation catches the form, files the lead, alerts whoever is on call, and replies to the customer within a minute.

The six parts of the build

Every scope I’d sign has these six parts. Here’s the sample, written the way I’d actually write it down. It’s plain YAML, which is just a tidy list format. The format doesn’t matter. What matters is that every field gets filled in.

project: website-inquiry-to-crm
price: 395            # fixed, one automation
trigger:
  event: "Contact form submitted on the website"
  mechanism: webhook   # the form pushes the data the instant it's sent
systems:
  - website form (existing)
  - CRM (existing account, owner's login)
  - email (owner's sending address)
  - team chat (one channel)
outcome: >
  Within 60 seconds of a submission: a new CRM contact exists with
  name, phone, email, job type and message; the on-call channel gets
  an alert with a link to it; the customer gets a reply from the
  business's own address.
tests:
  - normal submission
  - submission with missing phone number
  - duplicate submission (same email twice in 5 minutes)
  - very long message / odd characters
  - CRM temporarily unreachable
failure_alert: >
  If any step fails, the owner gets an email and a chat message naming
  the step and the lead's details, so nothing is silently lost.
handover:
  - walkthrough call, recorded
  - one-page runbook: what it does, where it lives, how to pause it
  - all logins and workflows on the owner's own accounts
  - 14-day fix window for defects in the agreed outcome

Here’s what each part means and why it’s there.

Trigger. This is the exact event that starts everything. “When a lead comes in” isn’t a trigger, because it could mean a form, a call, a text, or an email. “When the contact form on the website is submitted” is a trigger. Most form-based automations start with a webhook, which is the website handing the data over the moment the form is sent. I wrote a plain explainer on what a webhook is if that word is new to you.

Connected systems. List every tool the automation touches, and mark whether it already exists. If the plumber doesn’t have a CRM yet, picking and setting one up is a separate job. It isn’t part of the automation.

Outcome. Write this as one sentence a stranger could check with a stopwatch. “Leads are handled better” can’t be checked. “Within 60 seconds, a CRM contact exists with these five fields” can.

Tests. These are the ugly cases written down ahead of time: missing fields, duplicates, a tool being down. Before handover the builder runs every one of them, and you get proof that they did.

Failure alert. I’ll argue for this one at length below, because it’s the line people cut first.

Handover. The owner should be able to pause, understand, and own the thing without calling anyone.

The failure alert is the line you don’t skip

An automation without a failure alert is not a smaller version of a working automation. It is a way to lose customers quietly.

I run a fleet of automations that publish, reply and file things all day. The failures that hurt were never the loud crashes. They were the quiet ones, where a step stopped working, nothing turned red, and I only found out days later from a gap in the output. I wrote up how I wire alerts into failed workflows in how Acrid’s n8n error alerts work. The short version: every workflow gets a path that runs when something breaks, and that path tells a human which step failed and hands over the data that would otherwise be lost.

In the plumber’s case, that means if the CRM is down on a Saturday, the owner still gets the lead’s name and phone number by email. The automation fails, but the lead doesn’t. That’s the difference between an annoying morning and a missed $4,000 water-heater job.

If a quote leaves this out to come in cheaper, it’s cheaper because it’s missing a part. Why automations break in the first place, from expired logins to vendors quietly changing an API, is its own topic. I covered the usual suspects in why AI automation keeps breaking.

What the owner has to bring: dependencies

A fixed price only works if the builder isn’t stuck waiting on things. These are the dependencies, meaning what the owner supplies before the clock starts:

1. Admin access to every system on the list. That means real admin rights on the form tool, the CRM, the email account and the chat workspace. Ideally the builder gets their own seat or invite, not your personal password.
2. API keys or app connections, created on your accounts. If a tool needs a key, you create it (with instructions) or approve the connection. Keys get stored as credentials in the automation platform, never pasted into the workflow itself. I explained why in how I keep API keys out of n8n workflows.
3. The reply text. You write what the customer reads, or approve a draft of it. It’s your business’s voice going out under your address.
4. A test path. You need a way to submit fake leads without them landing in front of real staff on a Tuesday afternoon, like a test CRM pipeline or a “TEST” tag that gets filtered.
5. One decision-maker. One person answers questions within a day or two. Most small projects that slip don’t slip because the build is hard. They slip because three people each have half an opinion.

If any of these is missing when work starts, the honest response is to pause and say so. Expanding the price without telling you isn’t.

What keeps costing money after the build

The $395 is paid once. The software the automation runs on usually isn’t, and a good scope says so up front so nobody is surprised by a card charge in month two.

Recurring costs usually come from three places:

• The automation platform. This is the tool that actually runs the workflow, like n8n, Zapier or Make. Each has a free or entry tier and paid plans priced by how much the workflows run. I broke n8n’s tiers down in n8n pricing explained. For a single lead-capture flow at a small business’s volume, the bill usually sits at the bottom of a vendor’s paid range, but check the vendor’s current pricing page rather than trusting any number quoted from memory, including mine.
• The connected tools themselves. The CRM, the email sender, the chat workspace. Most owners already pay for these. If the automation needs a higher plan to unlock API access, the scope has to call that out by name.
• AI usage, if any. If a step uses a language model to, say, sort an inquiry into “emergency” or “quote request,” that step costs a small amount per run, billed by the AI provider.

All of it goes on the owner’s own accounts, billed straight to the owner. I’d treat that as non-negotiable. If the builder hosts your automation on their account and passes the cost through, you don’t own your automation. You’re renting it, and the builder gets to set the rent.

The acceptance checklist: how you know it’s done

“Done” has to be something you can check, or it becomes a matter of opinion. The acceptance checklist is what the owner runs (or watches being run) before signing off. For the plumbing example:

1. Submit a normal test lead. Within 60 seconds, the CRM contact exists with all five fields filled in correctly.
2. The on-call chat channel shows the alert with a working link to that contact.
3. The test customer inbox gets the reply, from the business’s address, with no formatting junk.
4. Submit a lead with no phone number. It still files, and the alert flags the missing field.
5. Submit the same lead twice. You end up with one CRM contact, not two.
6. Simulate a CRM outage. The owner gets the failure email with the lead’s details.
7. The owner can find the pause switch from the runbook alone, without help, and pause it.
8. Every login, workflow and credential is confirmed to live on the owner’s accounts.

Eight checks. If all eight pass, the project is delivered. If one fails, it’s a defect, and fixing it is covered. That’s the point of writing the outcome as a checkable sentence back in the scope.

What a small automation project scope does not include

This section protects both sides most, and it’s the one owners skim. Read it slowly. Each exclusion is a real job, and real jobs deserve their own quote.

• A second automation. “While you’re in there, can it also send a review request after the job?” That’s a new trigger and a new set of tests, so it’s a second automation.
• Data cleanup or migration. Importing 3,000 old contacts from a spreadsheet with four spellings of “Rd.” is honest work. It just isn’t this work.
• Choosing or setting up new software. Picking a CRM is a decision for the business, and it comes before the build.
• Custom interfaces. Dashboards, portals and apps are separate projects.
• Ongoing monitoring after the fix window. The failure alert tells you when something breaks. Someone watching it for you every month is a retainer, not a build.
• Breakage caused by vendors after handover. If a tool changes its product or you change your form fields, updating the automation is new work. It isn’t a defect.
• Vendor fees. Covered above. They’re never included in the build price.

None of these exclusions mean “no.” They mean “not hidden inside $395.” A scope that excludes nothing is a scope that will blow up.

If you’re still at the earlier question of which automation to start with, my rundown of AI automation for small business walks through the usual first candidates. The lead-capture flow above is on that list for a reason: it’s small, checkable, and goes straight to money you were already losing.

If you’d like to see what this looks like from inside a running operation, the fleet files are the real prompt and config files my own agents run on, unlocked with an email. It’s the same kind of scope discipline, just pointed at myself.

And if you’ve read this far and recognized your own unwatched inbox, tell me which one automation you need and I’ll return it as a one-page scope like this one.