How to Forecast Clinician Demand at a Telehealth Company

Almost every clinician pool that ends up the wrong size was built on a forecast of headcount rather than a forecast of demand. Headcount is the output. Demand is the input, and most digital health companies have the data to model it and have never done so.

Forecast visit-hours, not people

The unit that matters is clinician-hours required per week, broken out by state and by visit type. People come later, once you know how many hours you need and how many hours a pool clinician will realistically commit to.

Starting from headcount smuggles in two assumptions at once, about demand and about availability, and hides both.

The four inputs

Historical volume by hour and day of week, over at least ninety days. This gives you shape, which matters more than totals.

Your marketing calendar. This is the input clinical operations most often does not have, and it is the one that causes the worst surprises.

Seasonality, if your product has any. Behavioral health, respiratory, and weight management all move on different curves.

Your state launch schedule. A state going live is a demand event with a licensing lead time in front of it, and the lead time is the part that gets planned late.

The marketing spike problem

This is the single most common cause of coverage failure at growing digital health companies, and it is entirely self-inflicted.

Growth runs a campaign. Volume arrives. Clinical capacity was planned against last quarter's baseline. Visits back up, and the company concludes it has a staffing problem when it has a coordination problem.

The fix is not a bigger pool. The fix is that whoever owns the pool sees the paid media calendar before it runs, not after. If your demand forecast is built without the growth team in the room, it is not a forecast.

Forecast a range, not a number

A point estimate invites false precision and gives you nothing to plan against. Produce a low, expected, and high case, and size the committed pool to the low case with surge capacity covering the gap to the high case.

That structure means you are never paying for guaranteed hours you cannot use, and never fully exposed when the high case lands.

Check the forecast against what happened

Most companies build one forecast and never grade it. Compare forecast to actual monthly. Two or three cycles is usually enough to reveal a systematic bias, and almost every young company has one in the same direction, which is optimism about how much a part-time clinician will actually take.

Frequently asked questions

What should a clinician demand forecast measure?‍

Clinician-hours required per week, broken out by state and visit type. Forecasting headcount instead smuggles in assumptions about both demand and availability at the same time and hides both.

What inputs does the forecast need?

‍Historical volume by hour and day of week over at least ninety days, the marketing calendar, product seasonality, and the state launch schedule. The marketing calendar is the input clinical operations most often lacks.

Why do marketing campaigns cause coverage failures?

‍Because growth runs a campaign, volume arrives, and clinical capacity was planned against the previous baseline. The company then concludes it has a staffing problem when it has a coordination problem. The fix is shared visibility of the media calendar, not a bigger pool.

Should a demand forecast be a single number?

‍No. Produce a low, expected, and high case. Size the committed pool to the low case and cover the gap to the high case with surge capacity, so you are never paying for unusable guaranteed hours or fully exposed on the upside.

How do you know if the forecast is any good?

‍Compare forecast to actual every month. Two or three cycles usually reveals a systematic bias, and at young companies it is almost always optimism about how many hours a part-time clinician will take.

DirectShifts builds internal clinician pools for digital health and virtual care operators, not just hospitals. Talk to us about what a pool would look like at your headcount.