Revenue leakage wasn't a ticketing problem. It was three detection problems.

Revenue was leaking, and everyone knew it. What had grown around that fact was a ticketing habit: when someone noticed a missing transaction — a partner complained, an analyst spotted a gap — it became a ticket. Someone investigated. Sometimes the money came back.

Underneath the habit was a framing: leakage as an operations problem. Each discrepancy was an individual event; chase enough of them and you've done what can be done. The health measure was ticket throughput. Nobody was asking what fraction of the leak ever produced a ticket at all — because recovery began with someone noticing, and most of the leak was invisible by construction.

The tickets weren't a queue of one-offs. They were the visible edge of three distinct systemic channels, each with a different root cause — and each leaking below the line the ticket process could see.

First: transaction types that leave no record in the system you reconcile against. No record means absence never shows up as a discrepancy — there is nothing to notice, so there is never a ticket. Catching these meant detecting one layer upstream, where the transactions actually left a trace.

Second: transactions that arrived but failed to settle because the merchant's identity couldn't be matched. Taken one at a time, these looked like paperwork. At volume they were a pattern — one that could be inferred and resolved automatically.

Third: revenue lost when a member's payment card was lost or replaced. The member did nothing wrong; the link simply went stale. That is a lifecycle event, not an incident. It needed automation, not investigation.

Three channels, three root causes, three different right layers. A ticket process only sees what someone reports — and all three channels leak below the reporting line.

The flag, raised before anything was built: this is not an operations backlog, and faster ticket-chasing will not reach it. It is a detection problem. The leak lives in layers the current process cannot see. Fixing it means moving detection to the right layer for each channel — and making resolution routine instead of heroic.

The build was a detection-and-automation platform shaped by that framing. Detection ran at the correct layer per channel: upstream transaction visibility for the records the reconciliation system never saw, automated inference and resolution for merchant-identity gaps, lifecycle automation for lost and replaced cards.

The work split tellingly: most of the time went to research and validation — proving where each leak actually lived — while the initial builds took weeks each. Once the problem was named correctly, each channel began recovering revenue almost immediately; the following months of improvement raised the rate, they didn't rescue the approach.

Resolution went where the commercial team already worked: automated, prioritized case workflows inside their CRM (Salesforce). An investigation that used to begin with someone noticing now began with the system noticing — and arrived as a case with context attached, not a mystery to reconstruct. Ad hoc effort became a standard operating process.

It was cross-functional by design. The ROI case committed the Engineering and Operations roadmaps to the solution, so the platform landed as an organizational commitment, not a data-team side project.

The fix held because the framing changed first. Detection moved to the layer where each problem actually lived; resolution was placed inside the system where the team already worked. Once the problem was named correctly, the build was almost the easy part — and the recovery persists without anyone having to notice anything. That was the point.