How Do I Decide What Goes in Phase One of an Automation Project?

How much should the first phase of an automation project include?

Phase one should include one workflow that matters every day, the alert that tells someone when it breaks, and the documentation needed to hand it over. Nothing more. Dashboards, edge cases, and extra integrations wait. A small phase one that runs reliably beats a large one that is half finished and nobody trusts.

I have delivered more than 100 projects for over 25 clients across six-plus years, and the scope conversation is the one I take most seriously. Clients usually arrive with a long list. Lead routing, enrichment, a CRM cleanup, a reporting dashboard, Slack alerts, and some AI step they read about last week.

Every item on that list is reasonable. The mistake is trying to build all of it at once. My job in the first conversation is to find the one piece that, if it worked perfectly by next month, would change how the business runs. That piece is phase one.

Why do I keep phase one deliberately small?

Because the first automation teaches everyone how the business actually works. Edge cases, messy data, and unwritten rules only show up once something real is running. A small first phase surfaces those lessons cheaply. A large one discovers them all at once, usually in the last week, when every fix is expensive.

There is also a trust reason. When the first workflow runs cleanly for a few weeks, the team starts relying on it. That reliance is what makes phase two possible. If phase one is sprawling and fragile, the team learns to work around the automation instead of with it, and that habit is hard to reverse.

And there is a pricing reason. I work on fixed fees, and most of my projects land between $1,000 and $10,000. A fixed fee only works when the scope is clear. Keeping phase one tight is how I can promise a price and a result at the same time without padding either.

What test do I use to pick the phase one workflow?

I ask one question: if this broke tomorrow, would someone notice by lunch? If yes, the workflow touches real work every day and belongs at the front of the line. If nobody would notice for a week, it is a nice-to-have. Phase one goes to the workflow people would miss fastest.

The lunch test cuts through a lot of debate. Reporting dashboards almost always fail it, because people check them weekly at best. Lead routing almost always passes it, because a sales rep notices within hours when new leads stop arriving. Enrichment sits in between, depending on whether reps depend on it before their first call.

The second filter is money. Between two workflows that both pass the lunch test, I pick the one closer to revenue. A lead that reaches the right rep faster is worth more than a tidier internal handoff, even if both are useful. Go-to-market systems earn their keep by moving pipeline, so that is where I start.

What do I always include in phase one, even when it is small?

Three things go into every phase one regardless of size: the failure alert, a short written handover, and a test record that proves the workflow end to end. Those are not extras. They are what make the automation safe to rely on, and leaving them for later is how quiet failures start.

The failure alert matters most. An automation that breaks loudly gets fixed the same day. One that breaks quietly can run broken for weeks. I write the alert before the happy path, so the first thing I know about any workflow is how I will hear when it stops working. I wrote about why in why I write the failure alert before the happy path.

The handover is short on purpose. One page that says what the automation does, what triggers it, where it writes, who owns it, and what to do when the alert fires. If a person new to the team cannot read it and understand the workflow, it is not done.

What do I push to phase two on purpose?

I push edge cases, reporting, secondary integrations, and any AI step that is not essential to the core workflow. These all add value, but they add more value once the core workflow has run long enough to show where the real gaps are. Building them first means guessing. Building them second means knowing.

Edge cases are the hardest to defer, because clients can always think of one more. My rule is that phase one handles the cases that cover most of the volume and routes everything else to a person. A simple "needs review" path is cheaper and safer than automating a case that happens twice a quarter.

Reporting is the one I defer most often, with one exception. I still decide early what the reporting should eventually show, because that shapes which fields the workflow writes. The dashboard waits. The data structure that feeds it does not. More on that in why I scope the reporting before the automation.

How does this play out on a real client build?

Take the Kismet Health work, where I built automations connecting HubSpot through Zapier. The sensible starting point in a setup like that is the flow the team relies on every day, made reliable first, before anything that would be nice to have. That principle is what I bring to every engagement.

The Ajust work is a good example of why the foundation matters. Those automations run on Airtable and WhaleSync and have delivered more than 25,000 cases, helped more than 400,000 people, and saved more than 50,000 hours. Results at that scale come from core workflows that keep running, not from a long list of features shipped at once.

I am not claiming every project goes smoothly. Some phase ones reveal that the process itself needs fixing before anything can be automated, and that is a useful result too. It is far better to find that out in a small first phase than after building six workflows on top of a broken process.

How do I handle a client who wants everything in phase one?

I show them the full list, sorted by the lunch test and by closeness to revenue, and propose phase one as the top item plus its alert and handover. Then I price phase two separately with a rough range. Seeing the whole roadmap usually makes it easier to agree on starting small, because nothing is being thrown away.

Most people who push for everything at once are worried that phase two will never happen. Writing it down, with a rough price and an order, takes that worry away. The conversation shifts from "will this ever get built?" to "what should come first?" That is a much better conversation to have.

When a client still insists, I say plainly what the risk is. A larger first phase means a longer wait before anything runs, more surprises at the end, and a higher chance that scope creeps past the fixed fee. I wrote about that last part in when a fixed-fee project goes over scope.

What is the most common mistake when scoping phase one?

The most common mistake is saying yes to too much because it feels like better value. It rarely is. A bigger first phase takes longer to ship, leaves less time for testing and handover, and makes the client wait longer before anything runs. Value comes from the first workflow working, not from the length of the list.

I understand the pull, because it cuts against my own instincts. Coming from an aeronautical engineering background, I like complete systems. But a complete system that arrives late is worth less than a small one that works next week and grows from there. The engineering habit that serves me best here is testing small before building big.

So I would rather under-promise phase one and over-deliver phase two. People remember the first automation that worked from day one far longer than they remember how many features a proposal listed.

What should you do next?

If you are planning an automation project, write your full wish list, then apply the lunch test and sort by closeness to revenue. Make the top item phase one, add its failure alert and a one-page handover, and push everything else to phase two with a rough order. Then build the small thing well.

You will learn more from one reliable workflow in production than from any amount of planning. And the second phase will be sharper because it is built on what the first one taught you.

If you want help deciding what your phase one should be, or want it built on a fixed fee, reach out at pravinkumar.co. I build websites and the automations behind them for lead generation, and scoping is where the good projects start.