Running a telehealth program at scale, Part 2: eight signs you’ve outgrown your platform

Why platforms fail quietly

A telehealth platform is chosen at launch, when the questions are speed and cost and the volume is zero. It is judged at scale, when the questions are throughput, coverage, data, and risk. The gap between those two moments is where the workarounds accumulate, and because each one is small — a spreadsheet, a macro, a second vendor — nobody adds them up. This post is the sum.

The eight signs

1. Turnaround drifts upward with volume

The first symptom is usually clinical turnaround: the time from a patient submitting intake to a clinician’s decision. It was hours at launch. Now it is a day, sometimes two, and the 90th percentile is worse than the median suggests. The cause is fixed clinician capacity meeting rising demand, and the platform either cannot add licensed clinicians in your states fast enough or has no queue design that routes work to where capacity is. Turnaround is a retention metric in disguise: patients who wait churn, and renewals that wait lapse.

2. Opening a new state waits on coverage

You want to sell in Texas. The platform needs weeks to find a clinician licensed there, or your NP needs a collaborating physician you do not have, or the modality rules require a live visit the platform cannot schedule. Every state you cannot open is revenue you have already paid to acquire — your marketing does not stop at the border. A platform built for scale has clinicians licensed in all fifty states before you ask.

3. You cannot export your data through an API

Charts, care plans, encounter history, order history, consent records: if getting them out means a support ticket and a CSV, you do not own your program. This one matters most at exactly the moment it is hardest to fix — during a migration, a diligence process, or an audit. The test is simple: can an engineer pull a complete patient record with an API call today?

4. Refill lapses happen and nobody can see them

A lapse is a patient running out of medication before the next shipment arrives. It is the most expensive event in a subscription program and the least measured, because it spans systems — the pharmacy knows the ship date, the clinician knows the decision date, your billing knows the renewal date, and nobody joins them. If you cannot answer “what share of patients lapsed last month,” the platform is not giving you the events to compute it.

5. One pharmacy is a single point of failure

A single pharmacy partner means one licensure footprint (states it can ship to), one capacity ceiling, one cold-chain operation, and one outage away from a week of missed shipments. At a few hundred encounters a month this is a risk you accept. At a thousand it is a risk you have already been bitten by. Routing across pharmacies by state, medication, and capacity is a platform capability, not a contract you can sign.

6. Support answers status from email threads

“Where is my medication?” is the plurality of support volume in most programs. If the answer requires a support agent to check the pharmacy portal, the carrier site, and the clinician queue, each ticket costs real money and the patient waits. If order and encounter events flow into your support desk and patient app, most of those tickets never open. The symptom is tickets per hundred encounters rising with volume instead of falling.

7. Pricing penalizes growth

Per-member-per-month pricing that scales with patients rather than encounters. Minimums that made sense at launch and now sit under your run rate. A per-visit fee that never declines. Tiers themselves are not the problem — a tier structure works when the per-visit rate steps down as you move up and you can move at regular volume reviews — but any structure where your effective per-encounter cost does not fall as you grow was designed for a different stage. Model your next twelve months of volume against the contract and see which way the number moves.

8. Compliance evidence is available on request

An acquirer, an investor, a payer partner, or a board asks for audit logs, consent versions, clinician licensure records, or the BAA chain. “We will ask the vendor” is the wrong answer and “here is the export” is the right one. Compliance that lives in the vendor’s systems and reaches you by request is compliance you cannot prove on a deadline.

Process problem or platform problem?

Be honest about which is which, because switching does not fix process. Turnaround can be a queue problem or an intake problem — a clinician reading free text is slow on any platform. Lapses can be a cadence problem: no check-in triggers before supply runs out. Support load can be a tooling problem you could fix with the events you already receive. Fix those in place first; the fixes are worth having regardless.

What you cannot fix in place: clinician coverage you do not control, data you cannot export, a pharmacy footprint that ends at state lines, and a pricing structure designed for a smaller program. Those are structural, and they are the signs that justify a switch.

Pricing the switch against the drag

The cost of switching is real: engineering weeks, migration risk, a parallel-run period, contract exit terms. Put it against the drag: lapses you cannot see, states you cannot open, tickets that should not exist, clinician hours lost to slow review, and the margin your pricing hands back at the top. Programs at scale usually find the drag is a monthly number and the switch is a one-time one. The unit economics model from Part 1 gives you the monthly figure.

If you switch, do not cut over

A live patient base is migrated in waves, by state, timed to refill dates, with a parallel run first and a rollback held open until each wave has cleared a full refill cycle. Prescriptions are re-established by clinicians rather than ported as data. Patients stay in your app and, in most migrations, are never told. Part 5 of this series is the full playbook; the migration page has the short version.

Frequently asked questions