Revenue assurance for a managed services provider

The report that started it, and what it actually meant

An account manager noticed a contract expiry date sitting on a won deal that had not appeared on the matching company record, and said so. The record had been modified about ninety seconds before her email — she was looking straight at it.

Investigated read-only, every closed-won agreement since June carrying an expiry date was cross-checked against its company: 23 agreements, 17 propagating correctly, 2 missing entirely, 4 disagreeing with the company record.

The more important finding was the one nobody had reported. A maintenance workflow derives an active-agreement flag from the company-level expiry date, so where the date was blank the flag had been set to false. A paying customer under a live contract was reading, in the system, as a customer with no agreement — feeding renewals, churn reporting and the at-risk register.

That is the difference between a data-quality ticket and a revenue-assurance problem. The blank field is annoying. Everything downstream treating the blank as a fact is the exposure.

Ruling things out before touching anything

Two plausible causes were eliminated with evidence rather than assumption. A duplicate-record hypothesis was closed by confirming an older identifier now redirects to the surviving record. A missing association was ruled out by confirming the relevant association type was present on every single failure.

An earlier fix was also confirmed working — three customers whose agreements had been touched in the preceding days had all propagated correctly. That reframed the job entirely: this was a backlog to clear, not an ongoing leak to plug, and those need different responses.

The six affected customers split cleanly. Two had the date available on a won agreement and could be recovered by copying it. Four had no date anywhere in the system, which no automation can fix — they need a person and the signed contract.

Fixing only what could be fixed safely

Two company records were backfilled from their own won agreements. Both fields were empty beforehand so nothing was overwritten, the before-state was recorded anyway, and the derived flag flipped to true on both within seconds — verified by reading the records back rather than trusting the write response.

Three mismatches were deliberately left alone. Where an agreement and a company record disagree on a date, the CRM cannot tell you which is true; only the signed contract can. Overwriting blind would have replaced a visible disagreement with an invisible wrong answer.

One of those three is the most dangerous record in the set, and it is worth describing. A company date years earlier than its agreement date. It is not blank, so nobody reviewing the record flags it, the renewal will fire against the wrong year, and the derived flag reads false while the customer is plainly active. A stale value is harder to catch than a missing one and does more damage.

The operating rule that came out of it: the flag is derived, so it must never be set by hand. If it reads false on a live customer, the date is the thing to fix — writing the flag directly would mask the fault while appearing to resolve it.

Then the alerting, which was training people to ignore it

The same engagement surfaced a second problem in the layer above: internal notifications arriving roughly four times per account.

The cause was a mismatch of levels. The condition that fires the alert is a property of the company — a milestone the account reached. The workflow was enrolling contacts. Every contact on the account satisfied a condition that was never about them individually, so every one enrolled and every one sent.

The standard remedy is a latch: stamp a marker on the parent the first time it runs and exclude everyone else. That was built, with the race condition it depends on losing written down as a known risk rather than assumed away. Three days later the race fired for real — a live account with three contacts sent three emails inside one evaluation window, because all three were evaluated concurrently and all three read the marker as unset before any had written it.

A latch cannot work here, and that is structural rather than unlucky. Nothing serialises records entering the same evaluation window. The rule is short enough to keep: if the truth lives on the account, enrol the account. Rebuilt at company level, the duplication became impossible rather than merely improbable.

With the pattern named, a second false alert reported the same week was recognisable immediately — same class, truth on the deal, enrolling contacts — and was rebuilt at deal level with a date guard preventing thirty-nine historical records from replaying on enable.

Proving it quiet, and refusing to delete

Seventy-three companies were backfilled with the latch property, each sourced in a defined order of preference and audited as a mapping before it was applied rather than generated on the fly.

Verification was the point. After enabling, companies still eligible came to zero and enrolments on the rebuilt workflow came to exactly one — a deliberate live test, whose marker was restored afterwards. The second workflow correctly enrolled nobody, because it is not meant to touch history.

Three deletions requested during the same period were held rather than actioned. Each destroys data irreversibly — stage-timing history that does not survive even un-deleting a record, and form submissions with no recycle bin — and the exports that would make them safe did not exist yet. Holding a requested deletion is not obstruction; it is the difference between a reversible engagement and an unrecoverable one.