Why Automation Projects Fail Before They Launch

The Build That Died Three Weeks In

We got called in to fix a lead routing workflow that a client had paid another shop to build. On paper it looked fine. A form fill went into HubSpot, HubSpot pushed it to a call center dialer, and agents got a task. It ran clean in the demo.

Three weeks after launch it was quietly broken and nobody had noticed, because there was no crash to point to. Leads were sitting in a queue with blank phone numbers, because about 1 in 8 form submissions came in from an older lead form that used a different field name for phone number. The automation just didn't map it, so there was no error and no alert, just leads going nowhere.

That's the pattern we see over and over in audits. n8n and Make can handle the technical job fine in almost every case we've looked at. What actually breaks projects is nobody asking a handful of boring questions before the build started, and those questions are exactly the ones that come back to bite three weeks later once volume goes up and edge cases start showing up.

Below are the four questions we ask on every audit call now. These are the ones that kill projects before launch or right after it.

Question 1: Does the Software You're Connecting Actually Have an API

This sounds obvious until you're mid-build and discover the practice management system, the scheduling tool, or the internal database your client has been running on for eight years doesn't expose one. Or it has an API that's read-only, or it exists but the vendor charges extra for it and nobody budgeted for that.

This shows up constantly with legacy dental and legal practice software, older call center dialers, and homegrown internal tools that a developer built back in 2014 and then left behind. The system works fine for the humans using it day to day. It just wasn't built to talk to anything else.

When there's no API, there are a few common workarounds. Browser automation is one, though it's fragile and breaks on UI updates. A scheduled CSV export and import is another, which works but adds lag and manual steps. Sometimes it's a middleware layer that someone has to build and maintain on top of everything else. None of it is a dealbreaker by itself. What it does is change the cost and timeline more than people expect, and if that gets discovered after the quote's already signed, someone ends up eating the difference.

The audit question is simple. For every system this automation needs to touch, has anyone actually confirmed API access exists and tested a real call against it, or is everyone just assuming it does because the vendor's website mentions integrations?

Question 2: Whose Spreadsheet Is This, Really

Google Sheets shows up in almost every workflow we build, usually as a source of truth for pricing, inventory, staff schedules, or lead lists. Sheets are great for humans. They're also where automations quietly go to die.

The problem is rarely the tool itself. Spreadsheets accumulate years of manual habits nobody ever standardized, and that's usually what trips up the workflow later, things like phone numbers formatted three different ways in the same column, a dropdown that used to be enforced now just holding whatever people typed into it, or a tab that got renamed last year while three other sheets still reference the old name. None of this matters to a human reading the sheet, since people pattern match around messy data without even noticing. Automations don't work that way. They read exactly what's on the page.

We audited a sales team's pipeline sheet recently where "Closed Won" showed up as "Closed Won," "closed-won," "Won," and once just "w," typed by someone in a hurry. A workflow built to trigger on status changes would've missed three of those four variants completely, and the client would never have known why some deals weren't triggering the onboarding sequence.

The audit question here is to pull the actual data instead of the template. Look at 50 real rows instead of the five clean example rows someone shows you on the sales call. If the data's messy, decide upfront whether you're cleaning it before automating or building normalization logic into the workflow itself. Both approaches are fine, and either can work well once it's actually decided. What we push clients away from is skipping that decision entirely and just hoping the data behaves once it hits the workflow, since that's usually when things quietly break in week two instead of week one.

Question 3: What Happens When the Automation Doesn't Know What to Do

Every workflow handles the happy path fine in testing, where the lead fills out the form correctly, the data comes in clean, and the API responds fast. What almost nobody tests for is the other 10 to 20 percent of cases, the ones that don't fit the pattern.

What happens when a WhatsApp message comes in with no text, just an image? Or when the call summary from Twilio comes back garbled because of a bad connection? There's also the case where a HubSpot contact already exists under a slightly different email and the automation tries to create a duplicate anyway. If the answer is "I don't know, we haven't tested that," that's the gap that turns into a support ticket, or worse, a customer getting three duplicate emails and a business owner who can't say why.

Good automations have explicit fallback rules built in. If the data doesn't match the expected format, it goes to a human review queue instead of getting guessed at. If an API call fails, the system retries once and then alerts someone rather than silently dropping the task. Low-confidence AI summaries get the same treatment, flagged for a human instead of getting published straight to the CRM. This kind of logic has to be designed in from the start, since the fallback path is usually a third of the actual build effort even though it only handles a small slice of the volume.

The audit question is this: for the top five ways this workflow could receive weird or incomplete data, what does it actually do about each one. "It'll probably be fine" isn't something we sign off on, we want a real answer before the build starts.

Question 4: What's the Real Cost of Running This

This one kills budgets more than it kills builds, and it kills trust just as fast. A workflow that uses an AI model to summarize calls or draft responses has a per-call cost. So does a workflow that sends outbound WhatsApp messages through a business API, or one that pulls enrichment data from a third-party lookup service.

At low volume this is invisible, since ten calls a day at a few cents each is nothing anyone notices. Then the business grows, or a marketing push doubles lead volume for a month, and suddenly the automation that was "free to run" has a monthly bill that surprises everyone. Nobody modeled it against the volume the business would actually hit at scale. The number they used was whatever showed up in the demo.

We've seen this hit hardest with call summarization workflows, where a client wanted every single call transcribed and summarized by an AI model regardless of length or importance, and the API cost scaled with call minutes. At 40 calls a day averaging 12 minutes each, that adds up fast, and it's a very different number than the client expected when they signed off on AI call summaries as a feature.

The audit question: what's the per-unit cost of this automation, whether that's per lead, per call, or per message, and what does that number look like at 2x and 5x current volume. If nobody's run that math yet, whatever's in the proposal right now hasn't actually been tested against real volume, which is exactly the gap we walk through in our guide to running these numbers before you commit to a build.

What an Actual Audit Looks Like

When we run a free automation audit, the workflow diagram is the last thing we look at. First we look at the systems it needs to connect to, the actual data it will read, and the volume it needs to handle at scale.

A typical pass for a lead handling and follow-up build goes like this. First we confirm API access on every system involved, HubSpot, the ad platform, whatever CRM or phone system is in play, and we test a live call against each one instead of trusting the documentation. Then we pull a real sample of the data, usually a Google Sheet or CRM export, and check for the formatting inconsistencies that'll break field mapping down the line. Next we map the edge cases, things like a duplicate lead or a phone number in the wrong format, and write explicit fallback rules for each one in n8n or Make instead of leaving them to fail silently. Only after that do we model cost per unit against expected monthly volume, factoring in the AI model calls and messaging costs plus any paid enrichment lookups, so there's a real number before a single node gets built.

By the time we quote a build, all four of these have been checked already, and the client's seen exactly what we found for each one before they pay for anything.

"Isn't This Just Slower and More Expensive Upfront"

Fair objection, and we hear it a lot. Yes, an audit adds a few days before the build starts, and it can feel like paying for something that isn't visible progress.

The alternative is finding these four problems after launch, when a client's business is already depending on the workflow and every fix turns into an emergency instead of a planning conversation. Fixing a missing fallback rule after a customer's gotten a wrong automated reply costs more in trust than it ever would have cost in audit time. And the audit itself doesn't have to be a drawn-out process. Most of what we've described above takes a focused hour or two once you know what to look for.

Skipping this step just pushes these four problems to right after launch, when they're harder to fix and a lot more visible to the client.

Get the Audit Before You Sign Off on Anything

If you're about to greenlight an automation project, whether it's for lead follow-up, customer support replies, call summaries, or reporting, run these four questions against it first, the same reason we push clients to automate one workflow before buying a whole platform instead of scoping something bigger than the problem calls for. That's API access, real data quality, fallback rules, and actual cost at scale. If your current vendor hasn't walked you through all four, that's worth asking about before you sign anything.

We run this audit for free, no pitch deck or pressure involved, just an honest look at whether the automation you're about to pay for will actually hold up once real data and real volume hit it. Book a free 60-minute call and we'll go through it with you.