Why Won't I Automate a Process That Is Already Broken?

Why won't I automate a process that is already broken?

Because automation does not fix a broken process. It runs the broken process faster, more often, and with less human judgment in the way. If leads are routed by guesswork today, an automation will route them by guesswork thousands of times. So before I build anything, I make sure the manual version works.

This is one of the firmest rules in how I work. I build websites and the automations behind them for lead generation, and over 6+ years I have delivered 100+ projects for 25+ clients. The requests that worry me most are not the complicated ones. They are the ones where someone wants to automate a mess so they never have to look at it again.

I understand the impulse. Manual work is tiring, and a broken process is painful. Automation feels like relief. But relief that hides the problem is not a fix. Here is how I think about it, and what I ask clients to do first.

What does a broken process actually look like?

A broken process is one where the people doing it cannot describe the same steps, the same rules, or the same outcome. Ask two team members how a lead gets qualified and you get two answers. Ask what happens when data is missing and you get "it depends." Those gaps are exactly what an automation cannot handle.

The symptoms are usually easy to spot once you look. There are spreadsheets nobody trusts. There are exceptions handled by one person who remembers them. There are steps that exist because "we have always done it this way," with no one sure why. And there are outcomes nobody measures, so nobody knows whether the process works.

None of this means the team is careless. Processes drift as a business grows. What worked for ten leads a week stops working at a hundred. The point is to notice the drift before encoding it into software that will repeat it without complaint.

Why does automating a broken process make it worse?

Because humans quietly patch broken processes every day, and automation removes the patch. A person notices a lead looks odd and checks it. A person sees a duplicate and merges it. An automation does neither unless you told it to. The hidden human fixes disappear, and the errors flow straight through.

Speed makes this worse. A manual mistake affects one record at a time, and someone usually notices. An automated mistake can touch hundreds of records before anyone looks. By then, the CRM is full of wrong owners, wrong stages, or wrong emails sent to the wrong people.

There is also a trust cost. When an automation produces bad results, the team stops trusting automation in general, not just that one workflow. It is common for a team to swear off automating anything after one bad experience. That is a shame, because the problem was never the tool. It was building on a process that was not ready.

How do I check if a process is ready to automate?

I ask the team to run it by hand, the same way, for a short stretch, and write down every step. If they can describe the inputs, the rules, the edge cases, and the expected output in plain words, the process is ready. If the write-up keeps saying "it depends," it is not ready yet.

I look for three things in that write-up. First, clear rules: every decision should have a condition someone could check. Second, known exceptions: the weird cases should be listed, not remembered. Third, a measurable outcome: the team should know what "done well" means, so we can tell if the automation does it.

This step often feels slow to clients. They hired someone to automate, and now they are being asked to do the work by hand. But it is usually the most valuable part of the project. Many processes get simpler just by being written down, and some turn out not to need automation at all.

What do I do when a client insists on automating anyway?

I explain the risk plainly and offer a smaller first step. Usually that means fixing the process together, then automating the stable part. Sometimes it means automating only the data collection and leaving the decision to a person. If a client still wants the full build on a broken base, I say no.

Saying no is not comfortable, but it protects both of us. My work is priced as fixed fees, with most projects between $1,000 and $10,000. A fixed fee only works when the scope is clear. Automating a process nobody can describe is not a clear scope. It is an open-ended debugging job wearing an automation project's clothes.

Most clients appreciate the honesty once they see the alternative. A short phase to fix and document the process, followed by an automation that actually works, costs less in the end than an automation that has to be rebuilt after it causes damage.

What does a good process look like before automation?

A good process is boring. The same inputs produce the same outputs. The rules fit on a page. The exceptions are listed and handled. Someone owns it, and someone checks the results. When a process is that boring by hand, automating it is mostly translation, and translation is low risk.

The automations I am proudest of were built on boring foundations. For Ajust, I built automations on Airtable and WhaleSync that have delivered 25,000+ cases, helped 400,000+ people, and saved 50,000+ hours. For Kismet Health, I connected HubSpot through Zapier. Neither of those was clever for its own sake. Work at that scale only holds up when the steps underneath are clear.

My aeronautical engineering background shapes this too. In that field, you do not automate a system you cannot describe, because failure is expensive and hard to undo. Revenue systems are not aircraft, but the habit carries over. Understand it, document it, then automate it.

Which parts of a messy process can you still automate safely?

The parts that do not make decisions. Collecting data, copying it between tools, sending a notification, or creating a task for a person to review are usually safe even when the surrounding process is still messy. They reduce busywork without letting software make a judgment call nobody has defined yet.

This is a useful middle path. If lead qualification is unclear, do not automate the qualification. Automate the enrichment that gathers company size and industry, then post the lead to a channel where a person decides. You save time on the boring part and keep a human on the part that needs judgment.

Over time, the human decisions become data. After a few weeks, you can look at what the person decided and why, write those patterns down as rules, and then automate the rules. The process gets fixed by watching it, not by guessing.

What have I learned from turning down this kind of work?

That the projects I decline teach me as much as the ones I build. Most requests to automate a broken process are really requests for help with the process itself. When I reframe the work that way, the client usually gets a better result, and the automation that follows is smaller, cheaper, and more reliable.

I have also learned to ask about the process in the very first call. If I wait until the build is underway, the pressure to just ship something is strong. Asking early, before anything is scoped, makes it a normal part of the conversation instead of a late surprise.

And I have learned that the best automations often replace less than people expect. A system that removes the busywork and leaves a person in charge of the hard calls tends to last longer than one that tries to remove the person entirely. One way I find the broken part is to ask clients for their worst lead first.

What should you do next?

Pick the process you most want to automate and run it by hand for a week. Write down every step, every rule, and every exception. If the write-up is clear, you are ready to automate. If it is full of "it depends," fix the process first, then automate the stable parts.

If you want more on this mindset, read what I tell clients who want to automate everything. For how I check an automation before it goes live, see why I run a pre-flight check before an automation goes live. And for a real example of automation done for people, read what Ajust taught me about automations that serve real people.

If you have a process you want to automate and you are not sure it is ready, reach out and let's chat. I will tell you honestly whether to build now or fix first.