Most funnels are not underperforming. They are disconnected.

Three products, three signup flows, three sets of lifecycle messaging — and one contact record. Each product emits tag events into a shared workspace rather than keeping its own customer database, so a person who arrives through one product and converts in another is one contact with a history, not two strangers.

Tags are the contract. A product does not need to know what happens next; it asserts what just happened, and the funnel decides. That keeps the products ignorant of each other, which is the only way three of them stay maintainable by one person.

The discipline this demands is naming. A tag emitted as one string and listened for as another is a silent no-op, and the next section is what that costs.

Every active sequence was configured to trigger when a tag was added. The enrolment code only acts when the trigger names a specific tag, and none of them did. So the condition never matched and not one person was ever enrolled by it.

It looked healthy from every angle. The sequences existed, they were marked active, the tags were being applied correctly by the products. The only way to see it was to compare holders against enrolments: one tag had nine holders and zero enrolments, another had two and zero, a third had three and zero.

The one path that did work enrolled new contacts at the moment of creation. Which means every signal that arrives later — trial expired, went paid, asked to go live — reached nobody. Worse, the dashboard had no field for the trigger tag at all, so it could not have been fixed from the interface.

The reason it survives scrutiny is the part worth carrying: the obvious verification passes. Create a test contact, apply the tag, watch it enrol — and it does, because contact creation is the one path that works. The test confirms the system is fine while the failure sits entirely in the path the test never takes. Any check that exercises the happy path cannot detect a failure that lives outside it, which is why the number that found this was a ratio nobody had thought to compute: holders against enrolments, per tag. A funnel stage with zero people in it is either a bug or a stage you do not need, and nothing but that comparison tells you which.

One report showed an open rate above three hundred percent. The cause was two bugs sitting on top of each other.

First, uniqueness was decided by checking whether an event already existed and then inserting one. Scanners fetch the tracking pixel and every link within about forty milliseconds, so parallel requests each passed the check and each counted as unique. Second, the link rewriter touched every href on the page — including the font stylesheet in the document head, present in a hundred and two of two hundred and seventy-seven messages. Merely rendering the message recorded a click.

The fix was to make uniqueness an atomic claim — a conditional update that either wins or does not — rather than a read followed by a write. The recount corrected eleven sequences, every one of them downward, with the old values preserved.

Telling a customer their numbers are going down is not a pleasant conversation. It is a much better one than having their own client discover it.

A contact who fails on one product must stop being contacted by all of them. Otherwise each product independently rediscovers the same dead address and each one pays for it.

Two of the three products had no failure-notification infrastructure at all. The obvious plan was to build it twice. Instead the one product that already had a working listener became the shared one: the other two point their notifications at the same topic, and the processor routes by source domain — handling one locally and forwarding the other two to their own internal endpoints.

One pipeline, three products, and a deliberate limit on its scope: a failure suppresses lifecycle messaging to that contact without touching what the customer is allowed to send their own audience. Those are different permissions and conflating them would have been the easy mistake.

A hundred and sixty-five accounts were waiting for approval that nobody knew existed. Every creation path defaulted them to unapproved, correctly — but the only administrative screen required typing an organisation identifier to look one up, so there was no way to ask who was waiting.

It compounded. Approving an account notified nobody. One creation path bypassed the policy entirely. And because the onboarding job skipped unapproved accounts, those hundred and sixty-five also received nothing at all — a signup followed by silence.

The queue that fixed it is unremarkable. The part worth copying is what happened on first run: the alerting swept the existing backlog and marked it as already notified rather than sending a hundred and sixty-five alerts. A monitoring system's first act should never be to punish you for switching it on.