The board I saw
HelixVM was scaling fast toward a milestone it would later announce publicly, its 100,000th patient, on a model built to deliver treatment within an hour of a patient arriving. The operating anxiety, as the team framed it, was conversion: too many patients entered the funnel and too few completed care.
I saw two problems underneath that framing, and neither was the one being discussed.
First, nobody could see where in the journey patients were actually being lost. "Conversion is X percent" is a single number laid over a long, multi-stage path, and a single number hides everything that matters. You cannot fix a leak you cannot locate.
Second, and this is the one that changed the whole approach: conversion rate was being treated as a constant to hit, when it is actually a variable. It moves because the things that produce it move. Treating it like a target you can will into place is the mistake. Treating it like an output of a system, one you can decompose and steer, is the operator's move.
The system I invented
Step one: the conversion cascade. Instead of one conversion number, I built a cascade, a stage-by-stage waterfall of the patient's journey from first contact to billable encounter, with the dropoff and the reason for it attached at every step. Intake, then process, then expectation match, then scheduling, then platform, then cancellations, then no-shows, then provider, then billable encounter. Each drop got a cause, not just a percentage. For the first time, the conversion problem had an address at every stage.
Step two: conversion as a variable. With the cascade in place, conversion stopped being one number to defend and became an output I could decompose. Every stage was a term in the equation, and every term could be moved by something specific. That reframe is what turned a vague anxiety into a set of steerable levers, sorted by whether they moved demand or moved capacity.
Step three: the constraint revealed itself. Once intake was strong and the early stages were healthy, conversion still leaked, and it leaked at the stages governed by capacity rather than demand. The bottleneck was not getting patients in. It was the operation's ability to match supply to the demand it was already winning. That is the finding the cascade was built to surface, and it is the one that redirected the whole effort.
What I built
A measurement instrument the operation did not have before: the full cascade, stage by stage, cause by cause, legible to leadership in real time. On top of it, the operating discipline to treat conversion as a system to steer rather than a number to chase, with the levers grouped by whether they moved demand or moved capacity.
The result
The operation could finally see conversion instead of guessing at it, and it could act on the part that actually governed the outcome. The reframe moved the conversation from "why is the number low" to "which stage, which cause, demand or capacity," which is the difference between treating the symptom the operation assumed it had and diagnosing the one it actually had.
Specific internal figures are held under NDA and are not reproduced here. The 100,000-patient milestone and the sub-hour treatment model are HelixVM's own public statements.
What this proves
The transferable move applies to any operation staring at a number it wants to improve: build the instrument before the fix, decompose the number into the system that produces it, and find the constraint before you spend a dollar moving anything. See the board, invent the system, build it. The domain changes; the wiring does not.