How I Decide Which Automation to Build First for a New Client

How do I decide which automation to build first for a new client?

I pick the automation that removes the most repeated manual work on a process the client already runs well, with the smallest blast radius if it fails. Not the most impressive idea. Not the one with AI in the name. The first build has one job: earn trust by working quietly, so the second build gets approved without a debate.

Over 6+ years I have delivered 100+ projects for 25+ clients, and that work includes automation: lead routing, CRM updates, content operations, and the systems that run a go-to-market motion. What to build first is the question I face at the start of every automation engagement.

New clients usually arrive with a list. Some items are urgent, some are exciting, and a few are both. My job in the first week is to turn that list into an order. This is how I do it.

Why does the first automation matter so much?

The first automation matters because it sets the client's expectations for everything after it. If it works and saves visible time, the client trusts the next proposal. If it breaks, or solves a problem nobody felt, every later idea has to fight that memory. The first build is a trust exercise disguised as a technical one.

There is also a practical reason. The first automation teaches me how the client's systems actually behave. Field names that do not match the documentation, permissions nobody remembers granting, integrations that were set up years ago. A small, contained first build surfaces those surprises cheaply.

My aeronautical engineering background shapes this. In aircraft systems, you do not test a new component by bolting it onto the most critical path first. You test it where a failure is contained and visible. I apply the same instinct to business systems.

What are the criteria I score each idea on?

I score each idea on four things: how often the manual work repeats, how stable the underlying process is, how bad a failure would be, and how visible the result will be to the people who approve the next phase. High repetition, high stability, low failure cost, and high visibility make the strongest first build.

Repetition is the easiest to measure. A task done fifty times a week beats a task done once a month, even if the monthly one is more painful. Automation pays back through volume.

Stability is the one people skip. If the process changes every few weeks, automating it locks in a version that will be wrong soon. I would rather automate a boring process that has run the same way for a year than an exciting one that is still being figured out.

Failure cost and visibility pull in opposite directions, which is why I score them separately. The ideal first build is one where success is obvious to the team but a failure would be caught before it reached a customer.

Why do I avoid the most exciting idea as the first build?

The most exciting idea is usually exciting because it is new, complex, or touches customers directly. Those are exactly the traits that make a first build risky. Exciting ideas also tend to sit on processes that are not settled yet. I would rather earn the right to build them by shipping something dependable first.

A common example is an AI step that drafts outreach or replies to inbound leads. It sounds like the biggest win. But it touches customers, depends on clean data, and needs careful review. As a first build, it carries too much risk for too little proof.

The alternative is often unglamorous: making sure every form submission lands in the CRM with the right owner and the right fields, every time. Nobody gets excited about that in a kickoff call. Everybody notices when it works.

What does a good first automation look like in practice?

A good first automation moves data between two systems the client already uses, on a process that runs the same way every time, with an easy way to check the result. Form to CRM, CRM to Slack alert, or a content table to the website are typical. Each one is small, visible, and easy to undo.

The automations I have in production show the range. For Kismet Health, I connected HubSpot through Zapier. For Ajust, my automations run on Airtable and WhaleSync, with 25,000+ cases delivered, 400,000+ people helped, and 50,000+ hours saved. Systems at that scale depend on a reliable core, not on the flashiest feature.

The common thread is that the core data flow has to be trustworthy before anything clever sits on top of it. If records arrive late, duplicated, or incomplete, every later layer inherits the problem.

How do I handle a client who wants the big idea first?

I explain the order and offer a path to the big idea, usually as the second or third build. Laying out the reasoning is the best argument I have. If a client still insists, I scope the big idea with extra safeguards: a review step, a limited pilot group, and a simple way to switch it off.

I do not pretend the big idea is bad. Often it is the right long-term goal. What I push back on is the order. A short conversation about what has to be true for the big idea to work, such as clean data and clear ownership, usually makes the case for doing the foundation first.

Fixed-fee pricing helps here. Most of my projects fall between $1,000 and $10,000, and each phase has a clear scope. A client can see that the first build is a contained piece of work with a defined outcome, and that the bigger idea has its own scope and price when we get there.

When is the right first build no automation at all?

Sometimes the right first move is fixing the process or the data, not automating anything. If lead stages mean different things to different people, or if the CRM is full of duplicates, automating on top makes it worse faster. In those cases the first deliverable is a cleanup and a written rule.

This is the advice I find hardest to sell and most valuable to give. Nobody hires an automation builder hoping to hear "not yet." But a cleanup that makes the next three automations reliable is worth more than one automation built on sand.

I wrote more about this boundary in when not to automate a workflow, and about how I make the same call in my own practice in what I automate versus do by hand.

How do I know the first automation worked?

I agree on the success check before building. Usually it is simple: the manual task stops, the records arrive correctly, and nobody has to fix anything by hand for a few weeks. If the client's team stops thinking about the process entirely, that is the strongest sign it worked.

I also watch for the quiet failures. An automation that runs without errors but writes the wrong value into a field is worse than one that crashes, because nobody notices. So part of every first build is a way to spot-check results, even if it is just a weekly look at a filtered view.

Once the first build has run cleanly for a few weeks, the conversation about the next one is easy. That is the whole point.

What should you do next?

If you are planning automation work, list every idea, then score each on repetition, process stability, failure cost, and visibility. Pick the one with high repetition, a stable process, low failure cost, and visible results. Build that first, prove it works, and only then move to the idea everyone is excited about.

If your list includes anything that depends on messy data, add a cleanup step before it. That one change will save you more time than any single automation.

I build websites and the automations behind them for lead generation. If you want help deciding what to automate first and building it properly, reach out. Let's chat.