Funnel Conversion-Rate Integrity Automation: When 40 Beats 9, the Ratio Is Not a Rate

A stage-to-stage conversion rate is a simple calculation — the count reaching the next stage, divided by the count that reached this one — and that simplicity is exactly what makes it easy to trust without checking a quiet assumption underneath it: that every deal in the next stage necessarily passed through this one first. When a CRM allows a deal to be registered directly at a later stage — a real, sometimes correct behavior for the sales process — that assumption breaks, and a formula that was never wrong on paper starts publishing numbers that cannot exist in reality.

The defect was found the way many of the most damaging reporting bugs are found: not by a failing test, but by a person looking at a live screen with real production data and noticing three numbers that were structurally impossible — 444.44%, 162.55%, and 107.69% conversion between adjacent funnel stages. This happened AFTER the underlying code had already passed a full build, a typecheck, a lint pass, and 147 existing automated tests — none of which constructed a dataset where a later stage held more records than the stage before it, because until this finding, nobody had confirmed that scenario was a real, live possibility rather than a theoretical one.

Investigating the actual numbers behind the three impossible percentages confirmed the mechanism directly: a genuine set of deals had reached an early pipeline stage, and a larger genuine set of deals had reached the very next stage — not because deals moved backward, but because Centriu Orbit's own deal-creation flow allows a new deal to be registered directly at any stage of the pipeline, skipping earlier ones entirely when the sales process calls for it. Both counts were completely real and independently correct; dividing one by the other to produce a "conversion rate" was the part that stopped being valid, because the formula's implicit premise — that the next-stage group is always a subset of the current-stage group — was no longer true.

The fix adds exactly one check to the stage-breakdown calculation: before dividing, it compares the next stage's reached-count to the current stage's reached-count. When the next stage's count is the larger of the two, the function stops treating the pair as a valid conversion measurement and instead returns an explicit "unavailable" result, carrying a plain-language reason that names both raw counts and states directly that some deals were created straight into the later stage without passing through the earlier one. When the next stage's count is smaller or equal — the ordinary, expected case — the original conversion-rate calculation runs exactly as before, unchanged. In both cases, the two raw counts themselves remain fully visible on the report; what disappears is only the invalid division, never the underlying data.

A sales pipeline shows nine deals having reached an early stage and forty deals having reached the very next stage — not because thirty-one deals somehow moved backward through the funnel, but because many were registered directly at the later stage by a valid, separate part of the sales process. Dividing forty by nine produces a headline number well over 400%, a conversion rate that cannot exist in any real funnel. After the fix, that same pair of stages reports its conversion as unavailable, with a plain reason naming both the nine and the forty and explaining why they cannot be divided into a rate — while both raw counts stay exactly where they were on the screen.

No funnel report in Centriu Dash can publish a stage-to-stage conversion rate above 100% again — the specific condition that produces an impossible ratio is now detected and named, with the underlying counts left fully visible, closing a gap that a full build, typecheck, lint pass, and 147 existing tests had not caught.

This automation governs when a conversion ratio is mathematically valid to compute at all — it does not change how or where a CRM allows a deal to be created, and it does not retroactively flag or correct any conversion percentage displayed before this fix shipped.

The easy version of this fix would round the number, cap it visually at 100%, or simply not display anything above that threshold — all of which make the screen look normal again without explaining what is actually happening underneath. Centriu's fix does the harder, more honest thing: it names the specific reason a ratio cannot be computed, in the same place a person would otherwise see a wrong number, so nobody has to wonder whether the dashboard is broken or whether the sales process genuinely allowed deals to skip stages.