Skip to main content
By Jonas AnderssonCo-founder
6 min read

Breakdown

Why follow-up automation fails before it goes live

A team can spend a week building a follow-up automation, test it against a handful of records, watch it work, and still switch it off once the real queue exposes missing data and unhandled exceptions.

The workflow tool is rarely the first thing to inspect. Start with the data it depends on, the exceptions it must survive, and the person who will own it after launch.

Where it breaks before anyone notices

Follow-up automation does not usually fail in one dramatic way. It fails in four quiet ones.

Each failure mode looks slightly different in practice, but they share the same root cause: the automation was built before the conditions for it to work were actually in place.

Failure mode 1

The trigger field is not filled in consistently

The automation fires when a CRM field reaches a certain value, deal stage, contact status, last activity date. The workflow tool works. But that field is only filled in 60 percent of the time because nobody enforced it at intake.

The 40 percent with missing data either receives no follow-up or the automation fires on stale values from the last time anyone touched the record. Neither is acceptable. The team loses confidence, starts overriding manually, and eventually disables the automation because the manual version feels more reliable.

The fix is almost never in the automation. It is in making the trigger field required at the point where the record is created or transitioned. Data hygiene first, automation second.

Failure mode 2

The message template does not match real situations

The template was written against a typical case. But every tenth record has something unusual: a different stakeholder, a longer sales cycle, a previous conversation that changes the appropriate tone. The automation sends the standard message regardless.

Recipients notice. Response rates drop below what the manual version produced. The team concludes that automated follow-up does not work, when what actually failed was the assumption that one template covers all cases.

Templates work when the situation is consistent. If the situation varies enough to need a different message, the automation needs an exception path, a way to pause the sequence and flag the record for human review before it sends.

Failure mode 3

There is no exception path

A prospect says they are traveling for two weeks and asks to reconnect after. The automation does not know. It sends three messages during those two weeks. The prospect never replies. The lead is marked cold and closed.

This failure mode is not a data problem. It is a design problem. Every follow-up automation needs a mechanism for pausing or redirecting the sequence for a specific record. Usually a checkbox field, a status value, or a date override. Without it, the automation handles every record as if all situations are the same.

Building the exception path before launch is not optional. It is the difference between an automation that the team trusts and one that they work around.

Failure mode 4

Nobody owns it after launch

The automation is built, tested, and launched. The person who built it moves on to the next project. Three months later, the sales process changes. The stage names are different. The trigger condition no longer fires correctly. Nobody updates the automation because nobody feels responsible for it.

Automations that survive are owned, in the sense of someone noticing when it stops working and caring enough to fix it. Usually this is the person whose daily workflow the automation supports. The handover conversation should happen at launch, not six months later when something is broken.

The diagnostic question

If you turned the automation off tomorrow, how long before someone noticed?

If the answer is "immediately, because people depend on it," the automation is working. If the answer is "probably never, because people already work around it," it has already failed, the team just has not turned it off yet.

The pre-launch checklist

Five things to verify before you launch a follow-up automation.

Most automation failures are visible in the data before the first message ever sends. Running this checklist on the records the automation will touch is faster than diagnosing the failure three months after launch.

Check before launch

Verify these five conditions

The trigger field is filled in on at least 90 percent of the records the automation will act on. Below 90 percent means the data problem comes first.

There is a field or status value that pauses the automation for a specific record. Test it before launch.

The message template has been reviewed against at least ten recent real cases, including the unusual ones.

Someone is named as the owner of the automation after launch, not the builder, but the person whose workflow it supports.

There is a way to monitor whether the automation is firing. Even a simple sent-message log reviewed weekly for the first month.

Common questions

Questions about why automation fails

No named owner after handover. The automation gets built, tested, and launched. Three months later a process change makes the trigger condition wrong. Six months later the template language is out of date. Nobody updates it because nobody feels ownership for it. Naming an owner at launch, not the builder, but the person whose workflow it supports, is the single most reliable prevention.

Run a field completion report on every field the automation depends on. If any required field is below 90 percent completion, the data work comes first. Automation built on 60 percent field completion fails on 40 percent of records, silently, in ways that erode trust in the system before anyone can diagnose the root cause.

Build the exception path before launch, not after. Define the field or status value that pauses the automation for a specific record and test it before going live. The exception path is not an edge case. It is a core feature. Every workflow has cases that do not fit the standard path, and the system needs a designed response for each one.

Key takeaways

  • Most automation fails before the first message sends, because the data was not ready.
  • The trigger field needs a fill rate that matches the cost of a missed or mistaken message.
  • Build the exception path before launch. It is not optional.

If you only remember one thing

An automation that nobody will miss was not solving a real problem.

Continue the thinking

Sources

References behind this piece

  1. Predicts 2020: RPA Renaissance Driven by Morphing Offerings and Zeal for Operational Excellence

    Gartner / 2019-12-16

    Cited for analysis of RPA implementation failure patterns and the conditions under which automation projects underperform.

  2. State of Sales, 6th Edition

    Salesforce / 2024-01-01

    Used for context on commercial team time allocation and the cost of manual administrative work that automation targets.

  3. The Cost of Poor Quality Data

    Gartner / 2021-10-01

    Used for the finding that poor data quality is the primary upstream cause of automation failure in commercial operations contexts.

Jonas Andersson, co-founder of Mannvit Labs

Written by

Jonas Andersson

Co-founder, Mannvit Labs

Co-founder of Mannvit Labs, leading systems, data, automation, and technical delivery. He spent four years before this running e-commerce for a Swedish retailer, from SEO to campaigns.

He builds the internal tools and data workflows these guides come out of. See the builds.

  • Automation & workflow design
  • Process optimization
  • Operational systems