What Do I Tell Clients Who Want to Automate Everything?

What do I say when a client asks me to automate everything?

I say yes to the goal and no to the scope. The goal, less manual work and fewer dropped leads, is right. Automating everything at once is how you end up with a fragile system nobody understands. So I ask which one process hurts most, and I start there, with the manual version written down first.

This request is common, and I understand why. Founders see demos of AI agents running whole sales teams. They have watched hours vanish into copy-pasting between HubSpot, spreadsheets, and inboxes. They want all of it gone, and they want it gone this quarter.

I would rather lose a bigger project than build something that collapses six weeks after handover. So the first conversation is less about tools and more about which work actually deserves a machine, which work deserves a better process, and which work should stay human.

Why is automating everything at once a bad idea?

Because every automation encodes a process, and most teams have not agreed on their processes yet. Automate an unclear process and you get unclear results, faster and at scale. When something breaks, nobody knows whether the automation failed or the process was wrong to begin with.

There is also a maintenance cost people underestimate. Each workflow is a small piece of software. It depends on field names, logins, plan limits, and the behavior of tools that change without asking you. Twenty automations built in one sprint means twenty things that can break quietly, all at the same time.

My aeronautical engineering background shapes how I think about this. In that world you never add a system you cannot inspect, test, and understand when it fails. I bring the same instinct to revenue systems. If a client cannot explain what a workflow does in one sentence, it is not ready to be automated.

Which four questions do I ask before automating anything?

I ask four questions about each candidate process. How often does it happen? What does a mistake cost? Is the process already consistent when a human does it? And who will own it after launch? Processes that are frequent, consistent, low-risk to get slightly wrong, and clearly owned go first.

Frequency matters because automation pays back through repetition. A task done twice a month rarely justifies a workflow, its testing, and its upkeep. A task done fifty times a day almost always does.

Consistency matters most. If three people on the team do the task three different ways, automation will lock in one of them, or worse, a blend nobody chose. When the answers differ, I suggest the team runs one agreed manual version for a couple of weeks first. That alone often removes much of the problem.

Ownership is the question clients skip. Someone has to read the alerts, approve changes, and notice when results drift. If nobody owns it, I would rather not build it. I wrote more about choosing the first build in how I decide which automation to build first for a client.

What usually belongs on the do-not-automate list?

Anything that depends on judgment about a specific person or deal, anything where a mistake damages a relationship, and anything the team has not done consistently by hand. Personal follow-ups to warm prospects, pricing exceptions, and sensitive customer conversations usually stay human, with automation preparing the context rather than sending the message.

That last distinction is where the real value often sits. An automation does not have to do the task to save time. It can gather the account history, pull recent activity, draft notes, and drop everything into the CRM so the human does the judgment part in a fraction of the time.

I am not against bold automation. I am against automating the parts of revenue work that buyers can feel. My longer argument is in which revenue tasks should stay manual, and it is the list I bring into these client conversations.

What does a good first automation look like?

A good first automation is boring, frequent, and easy to check. Routing new form leads to the right owner, syncing records between two tools, or flagging stale deals are classic examples. They save real time, they fail visibly, and they teach the team how to live with automation before anything riskier is built.

The work I did for Ajust is a useful illustration of scale built from steady foundations. The Airtable and WhaleSync automations behind it have supported more than 25,000 cases delivered, more than 400,000 people helped, and more than 50,000 hours saved. Those numbers come from systems that do a clear job reliably, not from trying to automate everything on day one.

For Kismet Health, the work runs through HubSpot via Zapier. Different stack, same principle: pick processes that are clear enough to encode, connect the tools the team already uses, and make the system understandable to the people who depend on it.

How do I scope a project when the client wants it all?

I scope in phases with a fixed fee for each phase. Phase one covers the highest-value, lowest-risk processes plus monitoring. Later phases are written up but not committed until phase one has run in production. Clients get a roadmap for everything, and a budget only for what has earned its place.

Most of my projects land between $1,000 and $10,000 on a fixed fee, and phasing is how bigger ambitions fit inside that model honestly. The client is not paying upfront for a vision. They pay for working systems, one stage at a time, and can stop whenever the returns flatten.

Phasing also protects the relationship. If phase one shows that a process was messier than anyone thought, the plan changes instead of being forced into a contract written before anyone knew.

What do clients usually discover after the first phase?

Often, that the process design mattered more than the automation. Writing down how leads should be routed, what a qualified lead means, or when a deal is stale forces decisions that were never made. Once those decisions exist, the automation is often the easy part.

Some items on the original list often stop needing automation at all. Sometimes a clean process removes the friction. Sometimes a single report replaces several manual exports. Sometimes a data model fixed at the source makes a whole category of cleanup work disappear. I explain that last point in when not to automate a workflow.

That is the outcome I aim for. Not the most automations, but the fewest needed to make the work fast, accurate, and owned.

What should you do next?

If you want to automate everything, start by listing every manual task your team repeats, then score each one on frequency, cost of mistakes, consistency, and ownership. Pick the top one. Write its manual process down. Run that version for two weeks. Then automate it with monitoring from day one.

You will move slower in the first month than you hoped, and faster for every month after that. The systems that last are built one owned process at a time.

If you want help deciding what to automate first, or a phased plan for the rest, reach out. I build websites and the automations behind them for lead generation, and scoping the first phase honestly is where every good project starts. Let's chat.