How Do I Write a Statement of Work for an Automation Build?

What goes into a statement of work for an automation build?

A good statement of work for an automation names the trigger, the systems involved, the exact outcome, what happens when something fails, what is out of scope, and how we will know it works. It reads like a test plan. If both sides cannot picture the finished automation from the document, it is not ready.

I have delivered 100+ projects for 25+ clients over 6+ years. The lesson I trust most from that work is simple: a statement of work that describes behavior prevents more scope arguments than one that describes tools, and more than any clause about change requests.

My projects are fixed-fee, and most land between $1,000 and $10,000. Fixed-fee pricing only works when the scope is precise. This is how I write the scope for automation work, from the first section to the sign-off, and why each part earns its place.

Why is scoping automation work harder than scoping a website?

Automation scope is harder because the hard part is invisible. A website has pages you can count and designs you can approve. An automation has edge cases, data quirks, and failure paths that nobody thinks about until they happen. A vague scope hides all of that, and the hidden part is where the extra weeks come from.

A client asks for "a Zap that sends new leads to HubSpot." That sentence could describe an afternoon of work or a month of work. Does it need to check for duplicates? Match to existing companies? Assign an owner? Handle leads with missing fields? Alert someone when it fails? Each answer changes the build.

So the statement of work has to surface those questions before the price is set. If I cannot answer them yet, the right move is a short paid discovery step first, not a guess dressed up as a fixed fee.

How do you describe the trigger and the outcome?

Describe the trigger as a specific event in a specific system, and describe the outcome as a specific change someone can check. "When a demo form is submitted on the website, a contact and a company exist in HubSpot within five minutes, with owner assigned by territory." Both halves should be testable by someone who did not build it.

I write one of these sentences for every automation in the project. If a project has four automations, the statement of work has four trigger and outcome pairs. This forces precision. Writing these sentences together is often the moment both sides discover they pictured different outcomes.

This format also makes acceptance easy. At the end of the project, we run each trigger and check each outcome. If the outcome matches the sentence, that part is done. Nobody has to argue about whether the work feels finished.

Which systems and accounts should the document list?

List every system the automation touches, who owns each account, what access I need, and which plan or tier the client is on. Automations depend on accounts I do not control. If a required feature sits on a plan the client does not have, the document should say so before work begins, not halfway through the build.

For example, my automations for Ajust run on Airtable and WhaleSync, and the work for Kismet Health connects HubSpot through Zapier. Each of those tools has its own limits and plan differences. I note the tools in the statement of work and point to the vendor's own pricing and documentation for current plan details rather than restating them.

The access section is equally practical. It lists the accounts I need, the permission level, and a target date for access. Delayed access is one of the most common reasons automation projects slip, and writing it down turns a vague dependency into a shared deadline.

How should a statement of work handle failure?

It should say what happens when the automation cannot complete, who gets told, and how fast. Every automation will fail at some point because an API changes, a field is missing, or a vendor has an outage. A scope that ignores failure is describing a demo, not a production system. Failure handling is part of the build, not an extra.

In practice, I write a short failure section for each automation. It names the alert channel, such as a Slack message or an email to a named person, and the expected behavior, such as retrying or holding the record for review. This is also where I note any logging the client will be able to see.

Clients do not always ask for this section, but it pays for itself. The first time an automation fails quietly and nobody notices for weeks, the cost is far higher than the hour it took to design an alert.

What belongs in the out-of-scope section?

Out of scope should list the reasonable things a client might assume are included but are not. Typical items are cleaning historical data, building reports, training the wider team, changes to the website, and support after the handover period. Writing them down is not about saying no. It is about making sure nobody is surprised.

I think of this section as the client's protection as much as mine. If something they care about is not in scope, they see it before they sign and can ask to add it. That conversation is easy at the start. The same conversation three weeks into the build is much harder for everyone.

Phasing helps here too. When a client wants more than fits the budget, I split the work into a first phase that delivers a working core and a later phase for the extras. I wrote about that decision in how I decide what goes in phase one of an automation project.

How do you define done for an automation?

Done means every trigger and outcome pair passes on real or realistic test data, failure alerts fire when they should, and the handover documentation is delivered. I list the test cases in the statement of work itself, so acceptance is a checklist we run together rather than an opinion either of us holds.

The test cases cover the normal path and the awkward ones. A lead with no company name. A duplicate submission. A record that already exists. A field in the wrong format. If the automation handles those the way the document says it should, it is ready.

Handover is part of done, not something after it. I write the handover document before the build, which sounds backward but keeps the build honest. I explained why in why I write the handover doc before the build.

What separates a strong statement of work from a weak one?

A weak statement of work lists the tools that will be used. A strong one describes what the client will see happen, in plain sentences. Describing behavior makes scope easier to agree on, easier to test, and much harder to misread, because everyone can picture the same finished system before the build starts.

Length matters in a specific way. A strong statement of work is short on legal language and long on examples. A single concrete example of a record moving through the system clears up more confusion than a paragraph of definitions.

The last difference is honesty about unknowns. If something cannot be scoped yet, the document says so and proposes how to find out. A fixed fee built on a guess is not fixed, it is just a future argument. My thoughts on pricing in that range are in why most of my projects land between $1,000 and $10,000.

What should you do next?

Take the scope for your next automation project and rewrite each item as a trigger and outcome sentence. Add a failure section, an out-of-scope list, and the test cases that define done. If any sentence is hard to write, that is the part of the project most likely to cause trouble, so resolve it before anyone signs.

This works whether you are hiring someone or doing the work yourself. A clear statement of work protects the budget, the timeline, and the relationship. It also produces a better automation, because the thinking happens before the building.

I build websites and the automations behind them for lead generation, and every project starts with a document like this. If you are planning an automation and want help scoping it properly, reach out and let's chat.