Why I Audit a Client's Old Zaps Before Building New Ones

Why do I audit a client's existing automations before building anything new?

Because the new automation will live next to the old ones, and the old ones decide whether it works. Before I build a new Zap or scenario, I list what already runs, what each one touches, who owns it, and whether it still matters. That audit prevents duplicate leads, overwritten fields, and silent failures nobody can explain later.

When a client asks me for a new automation, the request is usually clear. Route demo requests to the right rep. Push form leads into HubSpot with the right source. Send a Slack alert when a high value account books a call. The temptation is to open Zapier and start building.

I resist that. The new build is rarely the hard part. The hard part is everything already running in the account that nobody has looked at in months.

What does an automation audit actually involve?

It is a short inventory, not a big consulting project. I list every active automation in the client's tools, note its trigger, the systems it reads and writes, the fields it changes, who created it, and when it last ran successfully. Then I flag anything that overlaps with the new build or looks abandoned.

For most small and mid-sized B2B teams, this means looking across Zapier, Make, any HubSpot workflows, native integrations between tools, and the occasional script someone set up on a server years ago. Each tool has its own list. The audit puts them in one place.

I keep the format simple: a sheet with one row per automation. Name, tool, trigger, what it writes, owner, last run, status, and a notes column. Nothing more. The goal is a map someone can read in five minutes, not a document nobody opens again.

This is also where you find out who actually understands the stack. It is often one person, and sometimes someone who has left. That alone changes how I plan the build and the handover.

Why not just build the new automation and fix problems later?

Because the problems an audit prevents are the kind that hide. A duplicate lead or an overwritten field does not throw an error. It just quietly makes the CRM less trustworthy, and by the time someone notices, nobody can tell which automation caused it. Fixing that later costs far more than looking first.

The classic case is two automations updating the same field. An old Zap sets lead source from a form, and the new one sets it from a UTM parameter. Both run. Whichever finishes last wins, and the field flips depending on timing. Reports built on that field become meaningless. I explained this failure in detail in my piece on what happens when two automations update the same CRM field.

The second case is duplicate creation. An old integration creates a contact in HubSpot on every form fill, and the new automation does the same. Now every lead exists twice, and routing rules fire twice.

The third case is the loop. The new automation updates a record, which triggers an old one, which updates the record again. These are the expensive ones, in task usage and in trust.

What do I look for first in the audit?

I look for anything that touches the same objects and fields as the new build. If I am building lead routing, I check every automation that creates or updates contacts, companies, or deals, and every one that changes owner, lifecycle stage, or lead source. Overlap is where the risk lives, so I start there.

After overlap, I look for abandoned automations. A Zap that has not run successfully in months, or one that errors on every run, is a signal. Either the process it supported is gone, or it broke and nobody noticed. Both deserve a conversation before I add anything new.

Then I look at ownership. Which automations are connected to a personal account of someone who left the company? Those are time bombs. When that account is deactivated, the automation stops, and the business process it supports stops with it.

Finally, I look for automations that exist only because a tool was missing a feature at the time. Sometimes the tool has since added it natively, and the automation can be retired.

How do I decide what to turn off?

I never turn anything off on my own. I bring a short list to the client with three categories: keep, merge into the new build, and retire. For each one I note what it does and what would break without it. The client decides, because they know which processes still matter and which ones are history.

This step is about trust as much as cleanup. Clients are often nervous about touching automations they did not build, especially ones that seem to work. A clear list with a reason for each recommendation makes the decision easy.

For anything marked retire, I pause it first rather than deleting it. A paused automation can be switched back on in seconds if someone discovers it mattered. After a few weeks with no complaints, it can go.

Merging is often the best outcome. If an old Zap already does half of what the new build needs, extending it with clear documentation is usually cleaner than running two automations that each do part of the job.

Does this audit slow projects down?

It adds a little time at the start and saves much more later. In my automation projects, the audit is a short, fixed part of the scope, done before the build begins. Because I price projects as a fixed fee, I include it in the scope rather than discovering problems halfway through and renegotiating.

I work on fixed-fee pricing, with most projects between $1,000 and $10,000. Fixed fees only work when scope is predictable. The audit is how I make it predictable. Without it, I would be guessing about what the new automation has to coexist with, and that guess is where fixed-fee projects go wrong.

It also changes the first conversation. Instead of starting with "here is what I will build," I start with "here is what you already have, and here is what I recommend." That framing is often more useful than the build itself, because few teams have ever seen their whole automation stack in one place.

Sometimes the audit reveals that the new automation is not needed at all. That is a good outcome too.

What happens to the audit after the build?

It becomes the first page of the handover document. The client gets a current map of every automation, including the new one, with owners, triggers, and fields. That map is what lets someone else maintain the stack later without starting from scratch, which matters for a solo practitioner whose clients should never depend on one person.

I think of the audit and the handover as the same document at two points in time. I wrote about why I start the handover early in my piece on writing the handover doc before the build. The audit is the "before" picture that makes the handover honest.

I also suggest a light review rhythm. Once a quarter, someone opens the sheet, checks that each automation still runs and still matters, and updates the owner column. It takes less than an hour and stops the stack from drifting back into the state I found it in.

If you have inherited automations from someone who left, my guide on dealing with an inherited automation covers what to do first.

What has this habit taught me about client automation stacks?

That most automation problems are not technical. They come from nobody owning the whole picture. Each automation made sense when it was built, by whoever needed it that week. The mess comes from the gaps between them. An audit is just the act of someone finally looking at the whole thing at once.

The automations I am proudest of are not the clever ones. They are the ones that still run cleanly a year later because they were built with a clear view of what else was running. My production automations for Ajust, built on Airtable and WhaleSync, and for Kismet Health, connecting HubSpot through Zapier, are the kind of systems where that discipline matters most, because real work depends on them every day.

The habit also keeps me honest about scope. When I can see the full stack, I can tell a client when the right answer is to fix something existing instead of building something new.

What should you do next?

Before your next automation build, spend an hour listing every active automation across Zapier, Make, HubSpot workflows, and native integrations. Note what each one triggers on, what it writes, who owns it, and when it last ran. Flag overlaps with the new build and anything that looks abandoned, then decide what to keep, merge, or pause.

If that list surprises you, you are not alone, and it is far better to be surprised now than after a new automation starts fighting an old one.

If you want someone to run that audit, clean up what is there, and build the next automation so it fits cleanly into your stack, reach out. This is how I like to start automation projects, because it is what keeps them stable. Let's chat.