When an Automation Audit Calls Your CRM a Business-Continuity Crisis, Check the Math First

We ran a scripted health assessment against a client's Salesforce instance expecting the usual list: a few stale fields, some workflows nobody had touched since the last admin left, maybe a duplicate-rule gap. What came back instead read like an incident report. Several hundred confirmed failing automations. A lead-to-opportunity conversion rate close to zero. A projected annual revenue impact large enough that one of our own team members, reading it out loud on the internal call, paused and said something close to: this isn't technical debt, this is technical bankruptcy.

That phrase is memorable, and memorable is exactly the problem. A finding that dramatic will get one of two reactions from a client, and both are wrong for the same reason. Either they dismiss it as an AI tool being sensational, or they panic and greenlight a rebuild nobody has scoped yet. Neither reaction has anything to do with whether the number is true. So before that report went anywhere near a client meeting, we did something that should be standard practice and mostly isn't: we made the tool prove it.

Large severity figures are easy to generate and hard to verify, which is exactly why they spread. A dollar amount tied to "revenue leakage" sounds precise. It usually isn't, unless someone has traced it back to actual records: actual opportunities that should have converted and didn't, actual leads that sat untouched because a routing rule silently failed.

We built that requirement into how we use these assessment tools now: any number it produces has to come with the record-level evidence behind it, or it doesn't get repeated to a client. Not because the tool is untrustworthy in general. Because a specific number attached to a business outcome is a claim, and claims get checked before they get quoted, whether a person made them or a script did. When we pushed on this particular figure, most of it held up. Some of it didn't, and we cut it before the client ever saw a draft. That distinction matters more than the headline number either way, because the client's next question is always going to be "how did you get that," and "the tool said so" is not an answer that survives contact with a CFO.

Once the number was defensible, the actual work started. It looked nothing like the report suggested. A list of several hundred failing automations sounds like several hundred separate problems. It almost never is. In this instance, a meaningful share of the failures traced back to a single disconnected integration: one broken link that a whole chain of lifecycle-stage workflows depended on. Fix that one connection and a large cluster of "failures" stops being a failure at all.

This is the part of automation debt that a raw count obscures. Counting broken workflows tells you volume. It doesn't tell you architecture. The useful question is how many distinct root causes are producing that failure count, and which of those causes touch a revenue-relevant path versus which ones just look bad on a dashboard. A cosmetic failure in an unused form and a silent failure in lead routing should never be triaged with the same urgency, even if they show up as the same kind of red flag in the same report.

The second engagement this pattern showed up in was quieter but just as telling. An audit of a client's marketing-automation instance found a utility workflow, years old, that had been built to work around a platform limitation. The platform fixed that limitation a long time ago. Nobody removed the workaround. It was still firing tens of millions of enrollments, adding weight to every record's history and pushing the account closer to real API throttling as usage grew.

Nobody built that on purpose to cause harm. Someone solved a real problem years ago, and the fix simply outlived the problem it was built for. That's the actual shape most automation debt takes: not one dramatic mistake, but a series of reasonable decisions that never got revisited once their original justification expired. An audit that only asks "is this broken" will miss it, because the workflow isn't broken. It's just no longer necessary, and running it costs something real every single day it keeps firing.

Fixing any of this carries its own risk, especially once leadership is watching. If the diagnosis is wrong, or the fix introduces a new problem, you don't want to find out because a rep is now looking at a dashboard with the wrong number on it. So corrected logic goes live in shadow mode first: it runs and produces output, but nobody downstream is told to trust it yet. We check whether the corrected numbers agree with what we already know to be true from other sources before letting anyone build a decision on top of them.

It is a slower way to ship a fix. It is also the only way we've found to be confident enough to hand a client a number and stand behind it a month later when someone in finance asks where it came from.

The last piece is the one that decides whether any of this gets funded. "Your automation is a mess" is not a business case. It's a mood. What moved this particular client was reframing the fix as a bounded decision against an unbounded one: a defined cost for controlled remediation now, against a materially larger loss if the system kept degrading under load and failed at a worse moment, on its own schedule instead of theirs.

That framing only works if the bounded number is real, which loops back to the first step. You can't present a credible remediation cost to leadership if you haven't already forced the underlying severity claim to defend itself. The order matters: verify the diagnosis, find the real root causes behind the raw count, test the fix quietly, then translate all of that into a decision with two numbers on it instead of one scary paragraph.

If you haven't looked at your own automation portfolio in the last year, or you've just received a severity report you're not sure how much to trust, start here:

Trace every headline number in the report back to specific records before repeating it to anyone outside your team. Group failures by root cause, not by symptom: one broken dependency can present as a dozen unrelated alerts. Flag anything touching lead routing, opportunity creation, or comp-relevant fields as a different risk category from cosmetic failures, regardless of count. Check for legacy workaround workflows built for a platform limitation that no longer exists. Cross-reference active workflows and pending operations against deactivated user accounts. Run any fix in shadow mode and validate its output against a known-good source before anyone relies on it. Present the remediation decision as two bounded numbers, not one open-ended warning.

None of this requires a rebuild to start. It requires someone willing to open the report, question the parts that sound too clean, and only then decide what's actually worth fixing first.