How do you architect revenue operations for a telemedicine platform in 2027?

A telehealth platform that grew fast and could not tell you what it earned

Picture a virtual-care company with a straightforward-sounding business: 340,000 completed video visits a year, a mix of employer-sponsored contracts, three national payer agreements, a state Medicaid managed-care plan, and a cash-pay direct-to-consumer product for dermatology and mental health. On paper, revenue operations should be simple. In practice, the finance team closes the month eleven business days late, and the number they publish moves by six to nine percent when it is revisited ninety days later.

The reason is structural, not clerical. In a normal B2B SaaS company, the revenue event is a contract signature, and everything downstream — invoicing, recognition, renewal — is a bookkeeping consequence of that one moment. In telemedicine, the contract signature authorizes nothing on its own. A signed payer agreement means the platform *may* submit claims; it does not mean any specific visit will be paid. The revenue event is the encounter, and each encounter carries roughly a dozen independent conditions that must all be true for money to arrive: the clinician had to hold an active license in the patient's physical location at the moment of the visit, the patient's coverage had to be active that day, the service had to be a covered benefit under that plan, the modality had to be reimbursable under that payer's telehealth policy, the documentation had to support the billed code, the claim had to be submitted inside the timely-filing window, and the encounter had to not duplicate another one already billed.

That is the architecture problem. A conventional RevOps stack has no place to store any of it. Your CRM knows about accounts and opportunities. Your billing system knows about invoices. Neither knows that a patient in Ohio saw a clinician licensed only in Michigan, which means the encounter was clinically fine and financially worthless. So the failure shows up sixty days later as a denial code in a clearinghouse report, at which point the revenue was already recognized, already forecast, and already reported to the board.

Compound that across a few adjacent realities and the picture gets worse. Employer contracts often bill on a per-member-per-month basis with utilization guarantees, meaning revenue is partly subscription-shaped and partly usage-shaped, and the two components reconcile on different calendars. Cash-pay revenue is instant and clean but subject to refund and chargeback tails. Medicaid managed care pays reliably but slowly, with reimbursement rates that vary by state and by plan within a state. A single platform is therefore running four fundamentally different revenue models simultaneously, and the finance stack usually models exactly one of them well.

The adjacent version of this problem is worth naming because the architecture generalizes: any healthcare-adjacent platform that bills third parties for service delivery — remote patient monitoring, digital therapeutics, at-home diagnostics, behavioral health networks — has the same shape. So do non-clinical usage businesses with eligibility gates, like tuition-benefit platforms or insurance-funded wellness programs. The common signature is that the customer who signs is not the payer, the payer is not the user, and the revenue only exists after a delivered event clears a set of conditions nobody in the sales org can see.

How the encounter-to-cash spine actually works

The core design decision is where you place the system of record for the encounter. Get this wrong and every downstream reconciliation becomes a manual join. The correct answer for almost every telemedicine platform: the encounter record is owned by the clinical platform, mirrored into a warehouse-native revenue layer, and never re-keyed into the CRM.

Concretely, the spine has five stages. Eligibility and routing happens before the visit — a real-time eligibility check against the payer, a licensure and modality check against the clinician roster, and a benefit check for the specific service. Encounter capture happens during and immediately after the visit — the clinician's note, the diagnosis codes, the procedure code, the place-of-service code, and the modality flag. Charge creation translates the clinical record into a billable claim, applying the fee schedule for that payer and contract. Adjudication is the external round-trip: submit to the clearinghouse, receive an acceptance or rejection, then receive the remittance advice showing what was actually paid, adjusted, or denied. Cash application and reconciliation posts payment against the original charge and closes the loop.

The architectural insight is that every one of those five stages produces a distinct state, and your revenue model needs to hold all five simultaneously. A visit that has happened but not been coded is not revenue. A charge that has been submitted but not adjudicated is estimated revenue with a probability attached. A charge that has been adjudicated but not paid is a receivable. Most telehealth RevOps failures come from collapsing these into one field called "revenue" and then arguing about which stage it means.

The identity spine underneath deserves its own attention. You need three stable keys that survive across systems: a patient identifier, an encounter identifier, and a claim identifier — with a deliberate one-to-many relationship from patient to encounter and encounter to claim, because a single visit can generate multiple claims when it spans services, and a single claim can be resubmitted several times. Teams that model this as one-to-one spend the next two years writing exception logic.

The other non-obvious requirement is temporal correctness. Licensure status, payer contract terms, fee schedules, and patient coverage all change over time, and a claim is adjudicated against the state of the world on the date of service, not today. That means your reference tables must be effective-dated. If you overwrite a fee schedule when a contract renews, you lose the ability to explain why last quarter's claims paid what they paid. Slowly-changing-dimension handling is not an academic nicety here; it is the difference between a defensible revenue restatement and a shrug.

Real numbers, ranges, and what good actually looks like

Benchmarks in healthcare revenue cycle vary enormously by payer mix and specialty, so treat these as orientation rather than targets to copy. The useful move is to instrument each of them and watch your own trend line.

Clean claim rate — the share of claims accepted on first submission without rework — is the single most load-bearing operational metric. Immature telehealth billing operations frequently sit well below where established practices land, and each point of improvement compounds because rework consumes staff time, delays cash, and risks running out the timely-filing clock. Instrument it at the level of payer, specialty, and clinician so you can see whether the problem is a bad payer rule mapping or three clinicians who code inconsistently.

Denial rate and denial recovery rate are separate metrics and get conflated constantly. Denial rate is what fraction of submitted charges come back unpaid. Recovery rate is what fraction of those you eventually collect after appeal or correction. A platform with a moderate denial rate and strong recovery can be healthier than one with fewer denials it never works. Categorize denials by root cause — eligibility, coding, authorization, licensure/location, timely filing, duplicate — because the fix for each lives in a different part of the architecture. Eligibility denials are a pre-visit problem. Coding denials are a documentation-template problem. Location denials are a clinician-matching problem.

Days in accounts receivable measures how long the money takes to arrive. Segment it by payer, because a blended number hides everything: commercial, Medicaid managed care, and self-pay have structurally different collection curves, and mixing them produces a figure that describes no actual behavior. Also track the aging buckets, not just the average — a rising share of receivables past ninety days is an earlier warning than a drifting mean.

Net collection rate — cash collected divided by what you were contractually entitled to collect after allowable adjustments — is the honest measure of whether the machine works. Gross collection rate against billed charges is nearly meaningless because billed charges are largely arbitrary relative to contracted rates.

Cost to collect, expressed as revenue-cycle operating expense divided by cash collected, tells you whether automation is paying for itself. It is the number that justifies engineering investment in eligibility automation and claim scrubbing, and it is the number to model before hiring the fourth biller.

On the recurring-revenue side, employer and health-plan contracts need their own metrics that look more familiar to SaaS operators: contracted per-member-per-month value, eligible member count, activated member count, and utilization rate. Utilization is where the two worlds collide — under-utilization threatens renewal even when it improves near-term margin, and over-utilization against a capitated contract destroys margin while delighting the client. Forecast both the fee-for-service line and the PMPM line separately and never blend them into one growth rate, because they respond to entirely different levers: PMPM grows with sales, fee-for-service grows with clinician capacity and visit throughput.

Capacity modeling is the piece most telemedicine RevOps teams under-build. Revenue is bounded by licensed clinician-hours in states with demand, not by lead volume. The practical model is a matrix of clinician supply by state and specialty against forecast demand by state and specialty, refreshed weekly. When demand outruns supply in a state, the constraint is licensure — a multi-week to multi-month process — which means your revenue forecast has a hard physical ceiling your CRM knows nothing about. Building that constraint into the forecast is one of the highest-leverage things a telehealth RevOps function can do.

Trade-offs: build the revenue layer, buy the billing engine, or outsource the cycle

Three structural choices dominate, and each is defensible depending on scale and payer mix.

Outsourced revenue cycle management hands claim submission, denial work, and follow-up to a specialist vendor, usually priced as a percentage of collections. It is the fastest path to competence and the right call for platforms under a certain claim volume or with a small number of payers. The cost is visibility: you get summary reporting on someone else's cadence, denial root causes arrive as categories rather than as encounter-level detail you can trace back to a clinician or a template, and your ability to engineer fixes upstream is limited by what the vendor chooses to expose. The percentage-of-collections model also scales linearly with revenue, so it gets expensive precisely when volume makes in-house economics attractive.

Buying a practice-management or billing platform and running the cycle in-house gives you the encounter-level detail and a real workflow for your billers. The trade-off is that most such systems were designed for physical practices, so telehealth-specific concerns — modality codes, cross-state licensure matching, asynchronous visit types — are bolted on rather than native. You will end up writing integration logic and maintaining a mapping layer between your clinical platform and the billing system, and that seam is where most data-quality problems live.

Building a warehouse-native revenue layer on top of whichever engine you use is the piece I would not skip regardless of the other two choices. This is not building a billing system; it is building the analytical and forecasting spine — encounter facts, claim state transitions, effective-dated reference dimensions, cohort and payer views — in your own warehouse, fed from the clinical platform, the billing engine, the clearinghouse remittance files, and the payment processor. It is what lets you answer "why did net collection drop three points in the Southeast last month" without a vendor ticket.

A fourth trade-off deserves a mention because it reshapes everything upstream: how much of the revenue mix is cash-pay. Direct-to-consumer telehealth collapses the entire claim lifecycle into a card charge — no eligibility, no adjudication, no denials, no receivables. The revenue operations problem becomes a subscription and churn problem, which is well-understood territory with mature tooling. Some platforms deliberately weight toward cash-pay for exactly this reason, accepting a smaller addressable market in exchange for radically simpler operations and immediate cash. If you are early and choosing, that trade is worth pricing explicitly rather than defaulting into insurance because it sounds bigger.

Pitfalls that quietly break the model

Recognizing revenue at charge rather than at expected collection. Billing a payer is not earning. If you recognize gross charges and true up later, every forecast you publish is wrong by the size of your denial and adjustment rate. Model expected net at charge time using historical payment behavior for that payer, specialty, and code, and hold the variance explicitly.

Treating licensure as an HR concern. Clinician licensure by state is a revenue constraint with a long lead time. It belongs in the revenue model and the capacity forecast, not only in a credentialing spreadsheet. The tell that this is broken: sales lands an employer account with heavy headcount in a state where you have two licensed clinicians, and nobody notices until members cannot get appointments.

Mutable reference data. Overwriting fee schedules, payer rules, or clinician licensure records destroys your ability to explain historical results. Effective-date everything.

Denial work that has no feedback loop. A denials team that fixes and resubmits claims but never routes root causes back to documentation templates, eligibility checks, or clinician matching is a treadmill. Every denial category should have a named owner upstream and a monthly review of whether that category's volume is falling.

Blending revenue models in one forecast. PMPM, fee-for-service, and cash-pay have different drivers, different seasonality, and different lags. One blended growth rate hides a collapsing line behind a growing one.

Ignoring the patient-responsibility tail. Deductibles and copays mean part of nearly every commercial claim is collected from the patient, not the payer, and patient collection rates are materially worse than payer collection rates. Point-of-service collection — capturing the estimated patient portion before or at the visit — is one of the strongest levers available and is frequently left unbuilt because it feels like a product problem rather than a finance one.

Under-instrumenting the pre-visit funnel. Cancellations, no-shows, and failed eligibility checks are revenue leaks that never appear in any claim report because the encounter never happened. Instrument booked-to-completed conversion by channel, state, and specialty, and treat a no-show as a lost revenue event with a cost attached.

Assuming payer telehealth policy is stable. Coverage rules for virtual care have moved repeatedly and continue to vary by payer, state, and modality. Build the policy mapping as configurable data with an owner and a review cadence, not as logic embedded in code, so a policy change is a configuration update rather than an engineering sprint.

Related questions

What is the single first system to build?

The encounter fact table with stable patient, encounter, and claim keys, fed from the clinical platform. Everything else — forecasting, denial analysis, contract compliance — is a query against it. Build it before buying analytics tooling.

How is this different from SaaS RevOps?

The revenue event is a delivered clinical encounter, not a signed contract, and it can be reversed by a third party sixty days later. Forecasting runs on visit volume and clinician capacity rather than pipeline stages and close rates.

Does a CRM still matter here?

Yes, for employer and health-plan contract sales — that motion is genuinely B2B. Just never let the CRM become the system of record for encounters, claims, or cash. Keep it upstream of the revenue spine.

When does outsourcing the revenue cycle stop making sense?

When percentage-of-collections fees exceed what an in-house team plus tooling would cost, or when denial root-cause detail becomes the constraint on improving margin. Volume and payer complexity both push toward in-house.

What should the board-level metric be?

Net collection rate alongside cash collected, segmented by revenue model. Booked contract value alone tells you nothing about whether delivered care converted to money.

FAQ

Why can't a standard SaaS billing stack handle telemedicine?

Because it assumes the entity that agrees to pay is the entity that gets invoiced, and that an invoice reliably becomes cash. In insurance-funded care, a third-party payer adjudicates each delivered encounter against rules the platform does not control, and can reduce or deny payment long after the service was rendered. Subscription billing tools have no concept of adjudication, remittance, or denial workflow, so the entire back half of the revenue cycle ends up in spreadsheets.

How long does it take to build a workable revenue layer?

For a platform with existing clinical and billing systems, a first useful version — encounter facts, claim state history, denial categorization, and a segmented AR view — is a matter of months rather than weeks, and the long pole is usually data access and reference-data cleanup rather than modeling. Effective-dating the payer and licensure dimensions typically takes longer than expected because the historical data often was not retained.

Should the RevOps function report to finance or to operations?

In telemedicine it works best reporting to finance with a hard operational partnership to clinical operations, because the levers that move revenue — clinician licensure, scheduling, documentation quality — live in clinical ops while the accountability for the number lives in finance. A RevOps team that sits only in sales will optimize contract signings and never touch the collection rate.

How do you forecast when payers can deny claims months later?

Forecast expected net rather than gross, using historical payment behavior segmented by payer, specialty, and procedure code, and carry an explicit reserve for the denial and adjustment tail. Then track forecast-to-actual by cohort so the model self-corrects. The goal is not perfect prediction; it is a stated confidence interval that shrinks as claims age.

What role does the clinician play in revenue operations?

A large and usually under-acknowledged one. Documentation quality determines whether a code is defensible, code selection determines the reimbursement rate, and licensure determines whether the encounter is billable at all. Any architecture that treats clinicians as outside the revenue system will keep generating denials that the billing team cannot fix.

Is a cash-pay model actually simpler enough to justify the smaller market?

Often, yes, for early-stage platforms. Cash-pay eliminates eligibility, adjudication, denials, and receivables, converting revenue operations into a familiar subscription-and-churn problem with mature tooling. The trade is a narrower addressable population and a higher acquisition burden. It is a legitimate strategic choice, not a fallback.

Sources

• https://www.cms.gov/medicare/coverage/telehealth
• https://www.medicaid.gov/medicaid/benefits/telehealth/index.html
• https://www.healthit.gov/topic/health-it-and-health-information-exchange-basics/telemedicine-and-telehealth
• https://www.cchpca.org/
• https://www.hfma.org/
• https://www.ahima.org/
• https://www.cms.gov/medicare/regulations-guidance/electronic-billing/hipaa-eligibility-transaction-system
• https://www.ama-assn.org/practice-management/digital-health
• https://www.nist.gov/
• https://x12.org/

Related on PULSE

• How do you forecast revenue when a third party controls whether you get paid?
• What does a warehouse-native revenue layer look like in practice?
• How do you model capacity as a revenue constraint instead of a staffing metric?
• When should a platform bring revenue cycle management in-house?
• How do you build a denial feedback loop that actually reduces denials?
• What metrics belong on a healthcare platform board deck?