A Five-Minute Claim Fails at Setup, and a Four-Practice Test Shows It

This is an illustrative composite that shows the method. The company, the numbers, and the practices are made up. Nothing here says anything about real products or about clinical outcomes.

The product and the claim#

An intake product for independent physician practices. Marketing says a new patient’s intake takes five minutes. A scripted user acceptance test passed in four minutes and forty seconds, using a provisioned account, clean data, configured integrations, a trained user, and an administrator standing nearby.

ICP Acceptance Specification (short form)#

• Include: groups of ten to thirty physicians with a front-desk team and an existing practice management system on one of three named systems.
• Exclude: solo practices, and practices on systems the product cannot import from.
• Actors: the practice manager buys and sets up; the front-desk coordinator does intake; the physician saw the ad; the IT contractor connects systems.
• Trigger: long waits at the desk for new patients.
• Current alternative: paper forms and a partly digital process.
• Unproven assumption: the coordinator can finish setup without help.

Promise audit#

Acceptance Hypothesis#

For a practice manager at a twelve-physician group with an existing practice management system, experiencing slow new-patient intake, if the five-minute claim is true, then starting from the ad, with the practice’s own scheduling data (de-identified by a method the practice’s privacy officer approves) and no help from us, we expect setup in under a day and the front-desk coordinator’s first intake in under five minutes, with no rescue from sales, success, or engineering. We will test twelve practices, and if five or more stall at setup, the claim is false as stated.

The test#

Twelve practices from the ICP with an active evaluation, recruited without a relationship to the team, each started from the real ad and given no support channel for two weeks, after which customer success stepped in. Observers recorded and did not help, except to protect real patient data. A Rescue Ledger was open throughout, with each entry marked planned or unplanned.

What happened#

Five of twelve practices stalled at the schedule export, which met the refutation rule. Where the team would have helped, it did not, and the ledger records the help that was withheld and why. The seven that finished took between 20 hours and 3 days for setup, and one needed a six-hour unplanned setup rescue after the no-support window ended.

Competing explanations#

Some of the five had older scheduling systems, and a few had no IT contractor. The sample is twelve practices in one region. A stall might also come from the test: participants had no stakes beyond an evaluation, and none had the ad’s trigger on the day they started.

Record and decision#

The team wrote an Acceptance Evidence Record and a decision log entry: change the claim to “set up in a day on supported systems,” write a plain-language export guide, and build the import step. A retest with twelve new practices after the guide shipped had three stall. The team narrowed the ICP provisionally to practices on two supported systems, and it recorded the sales lead’s dissent, since the narrower ICP is a smaller market and changes quota. Whether these practices keep using the product needs a later turn of the loop.

Read this as a method, not a result#

Twelve practices can show that a claim is false as stated and where. They cannot show a tight rate, which is why the narrowing is provisional.