How to scope a client automation

Most automation failures happen before the first step is created. Clients describe their problem in outcome terms ("I want leads to go into my CRM automatically") while you need to think in trigger-action-condition terms. That gap — between what someone wants and what you need to build — is where most breakdowns originate.

Good scoping turns a vague request into a precise spec: one trigger, one or more conditions, one or more actions, one expected output. Everything else is out of scope until agreed otherwise.

The goal of this guide is to give you a repeatable process for arriving at that spec before you open Zapier, Make, or any other tool.

Before proposing any automation, document what actually happens today. Ask:

• What triggers this process? A form submission, an email, a calendar event, a new database row, a time schedule?
• Who does it manually right now? And how long does it take?
• What tools are already involved? Where does data enter, where does it need to end up?
• How often does it run? Daily, per transaction, on demand?
• What goes wrong in the current process? This is often your best signal for what to automate first.

Document this as a simple flow before you design anything. A whiteboard, a numbered list in a doc, or a Miro board all work. The format doesn't matter — the act of writing it down exposes assumptions.

The trigger is the most important part of any automation. Get it wrong and every step that follows is wrong too.

A trigger must be:

• Specific: "New row in Google Sheet 'Lead Intake', column A is not empty" — not "when I get a new lead"
• Reliable: Does it fire every time, or only sometimes? What edge cases exist?
• Controllable: Can you test it without affecting live data? Does the platform support test events?

Common trigger mistakes to avoid:

• Using email "received" as a trigger without filtering by sender, subject, or label — you'll catch everything
• Polling triggers with too-short intervals on free plans (hitting rate limits)
• Using form submission triggers on forms that occasionally get spam entries

Write the trigger down as a one-sentence spec: "This automation runs when [exact event] in [exact tool]."

Most automations need at least one filter or condition. Without them, you'll process records that should be skipped, duplicate records that already exist, or trigger actions on test data.

For each automation, ask:

• What should this NOT do? (Reverse scoping is often more valuable than forward scoping)
• What happens if the trigger fires but the data is incomplete? Missing email, empty name field, invalid format?
• Is there a deduplication concern? Could this trigger twice for the same record?
• Who should be notified when something fails?

Document each condition as a simple if/else rule:

IF status = "qualified"
AND email is not empty
THEN → continue to action
ELSE → stop (no action)

The more conditions you write out upfront, the fewer edge cases you'll debug in production.

Once you understand the trigger, conditions, and actions, write a one-paragraph scope statement. This becomes the first section of your SOW.

Template:

This automation runs when [trigger event] in [source tool]. It filters for [conditions]. When conditions are met, it [action 1] in [destination tool] and optionally [action 2]. It does not handle [explicit exclusion 1] or [explicit exclusion 2]. Edge cases such as [example] will be handled by [manual process / separate automation / out of scope].

Send this paragraph to the client before building. If they correct it, you've caught a misalignment before it costs you time. If they confirm it, you have written agreement on what you're building.

Before you can deliver an accurate timeline or price, you need to know:

• Do you have API access to all the tools involved? Some tools require paid plans for API/webhook access.
• Are credentials available, or does the client need to create accounts or upgrade plans?
• Are there data privacy constraints? (GDPR, HIPAA, internal IT policy)
• Who owns the automation account — you or the client? This affects maintenance responsibility.

A project that looks like a 3-hour job can become a 2-day project if the client needs to provision access, upgrade a plan, or involve IT. Catch this before you quote.

Checklist:

• Source tool access confirmed (API or webhook available?)
• Destination tool access confirmed
• Test environment available
• Client will provide credentials in a secure method (1Password, Bitwarden share, etc.)
• Agreed on who owns the platform account post-delivery