When an automation programme underdelivers, the review is almost always strategic. Someone reopens the segmentation. Someone questions the messaging. Someone proposes a new lifecycle model with more stages than the last one.

In our experience that is the wrong room to be in. The strategy in the deck is usually defensible. What went wrong happened between the deck and the platform — in the data model, the identity graph, the trigger logic and the ownership model. None of it is visible in a strategy review, and all of it is findable in an afternoon if you know where to look.

First: which kind of failure is it?

Run this test before any other conversation. Take one real contact who should have converted and did not. Trace them through the flow they were supposed to experience and check four things:

1. Eligibility. Did they actually meet the entry criteria, according to the field values as they existed at the time, not as they exist now?
2. Path. Did they take the branch the design intended? If not, which condition evaluated differently from expectations?
3. Timing. When did each message actually send, in the recipient's timezone?
4. Content. Did the personalisation resolve, or did it fall back to defaults?

If any of those four is wrong, you have an implementation failure and no amount of strategy work will fix it. A strategy failure looks like the opposite: everything executed exactly as designed, and the design did not work. That is much rarer than the industry's conference agenda implies.

The seven implementation failure modes

1. A data model that cannot express the strategy

The strategy says "nurture differently by industry and buying stage". The CRM stores industry as free text entered by whoever created the record, and buying stage does not exist as a field at all — it lives in the heads of three sales reps.

This is the most common failure and the earliest to occur. It happens because strategy is written in business language and the data model is never checked against it before build starts.

Symptom: segments that should contain thousands of contacts contain hundreds, and the rest fall into a catch-all path nobody designed.

Fix: before building anything, take every segment named in the strategy and write the exact query that produces it. If the query cannot be written against current fields, the data model is the project. Do that work first, in the open, with a cost attached — it is the same argument made in the data plumbing nobody budgets for.

2. Identity that does not resolve

The same human is a lead in the CRM, a subscriber in the email platform, an anonymous visitor in the analytics tool and a user in the product database. If nothing reliably joins those four, every behavioural trigger you designed is running on a fraction of the evidence.

Symptom: customers receive prospecting messages. People who visited the pricing page three times get a "getting started" email. Suppression lists do not suppress.

Fix: pick one join key and enforce it everywhere. Lower-cased email is the pragmatic default for most mid-market businesses; a stable user or account identifier is better if your product can emit one. Then measure your match rate explicitly and publish it. Teams that do not measure match rate almost always assume it is higher than it is.

3. Triggers built on states instead of events

A flow that starts when "lifecycle stage equals MQL" behaves very differently from one that starts when "lifecycle stage changed to MQL". The first will re-enrol anyone whose record is touched. The second fires once, at the moment that matters.

This distinction sounds pedantic until a bulk import re-enrols 4,000 contacts into a welcome sequence overnight.

Symptom: unexplained enrolment spikes, duplicate sends, and flows that behave correctly in testing and strangely in production.

Fix: prefer event-based entry. Where the platform only supports state-based triggers, add an explicit guard field — a timestamp of last enrolment — and check it in the entry condition.

4. No exit criteria

Everyone designs entry criteria carefully. Exit criteria get one line at the end of the workshop, if that.

The result is the failure everyone has experienced as a consumer: you buy the product, and the sequence persuading you to buy the product continues for another eleven days. Or you reply to a sales email and the automated follow-up arrives anyway, undermining the person who just replied to you.

Symptom: customer complaints that feel small individually and corrosive in aggregate; sales reps who stop trusting marketing sends.

Fix: every flow needs at least four exit conditions written before build — converted, replied to a human, entered a higher-priority flow, and unsubscribed or suppressed. Then add a global frequency cap that no individual flow can override.

5. No testing environment, and no test that resembles reality

"We tested it" usually means someone sent themselves an email and it arrived. That test verifies rendering. It verifies nothing about branching, timing, suppression, or what happens to a contact who satisfies two flows at once.

Symptom: defects that only appear at volume, or only for contacts with unusual field combinations.

Fix: build a seeded test population — twenty to fifty synthetic contacts engineered to hit every branch, including the ugly ones: missing first name, two accounts, existing customer, unsubscribed, in another flow already. Run the full flow against them in a sandbox at compressed intervals. This takes about a day and catches most of what production would otherwise find for you.

6. Timing designed in a spreadsheet, not against human behaviour

Delays specified in hours from enrolment produce sends at 3am local time. Business-day logic that ignores public holidays sends "just checking in" on Christmas morning. Flows designed in one timezone dispatch to a global list at the sender's convenience.

Symptom: open rates that vary sharply by region for no message-related reason.

Fix: specify send windows, not delays. "Next business day between 8am and 11am recipient local time" is an implementable specification. "24 hours later" is not, for any list that crosses a timezone.

7. No owner after go-live

The project team disbands. Permissions stay open. Over eighteen months, forty-one workflows accumulate, six of which contradict each other and two of which nobody dares switch off because it is unclear what depends on them.

Symptom: nobody can answer "what happens to a contact who fills in this form?" without opening the platform and reading.

Fix: one named owner with the authority to refuse new flows. A written register of every live flow with its purpose, owner and review date. A quarterly review that switches off anything nobody defends. This is unglamorous and it is the difference between an automation estate that compounds and one that decays.

Symptom-to-cause reference

The pre-launch checklist

We do not launch a flow until every line here is true. It costs about a day per programme and it removes most of the failure modes above.

• Every segment in the strategy has a working query against real fields, with a real count.
• Identity match rate is measured and documented, with a stated threshold.
• Every entry condition is event-based, or state-based with an explicit guard.
• Every flow has at least four exit conditions.
• A global frequency cap exists and cannot be bypassed by individual flows.
• A seeded test population covers every branch, including edge-case field combinations.
• Send windows are specified in recipient local time, with holiday handling.
• Suppression lists are verified by sending a test to a suppressed contact and confirming nothing arrives.
• One named owner, one flow register, one review date.
• A rollback plan: how to switch this off in under five minutes if it misbehaves.

How to structure the project so this cannot happen

Three structural decisions do most of the work.

Sequence data before flows. Treat the data model and identity layer as phase one with its own acceptance criteria. Do not let flow-building start until segment queries return sensible counts. This is unpopular because flows are visible and data work is not, which is exactly why it needs to be a named phase with a budget rather than an assumption.

Make one person accountable for the whole path. Not a marketing owner for the message and an ops owner for the platform. One person who can be asked "what happens to this contact?" and answer without a meeting. Split accountability is how the routing delay in our campaign post-mortem survived for a full quarter.

Ship three flows properly rather than twelve approximately. A lifecycle model with fourteen stages and nine branches is a design that cannot be tested, cannot be explained to sales, and cannot be maintained by one person. Start with the three flows that carry real volume, instrument them well, and expand only when the first three are boring.

The uncomfortable conclusion

Automation strategy is genuinely easier than automation implementation, which is why so much more of it gets produced. A lifecycle framework can be built in a workshop. A working identity graph cannot.

If your programme is not performing, resist the instinct to redesign it. Trace one contact through one flow first. In most cases you will find the answer within an hour, and it will be a field, a trigger type, or a missing exit condition — not the strategy.

If you want that trace done by someone who has seen the failure modes before, our business automation and process automation teams run automation audits as a fixed-scope engagement.