How do you architect revenue operations for a digital health company in 2027?

The scenario that breaks a horizontal SaaS playbook

Picture a Series B digital health company selling a remote cardiac monitoring program. It has 40,000 patients using the app weekly, a 4.7 app-store rating, and a RevOps stack copied straight from a B2B SaaS template: seats in the CRM, MQL-to-SQL conversion dashboards, a monthly new-logo target, and reps compensated on closed-won ARR. The board asks why forecast accuracy is 40% and why net revenue retention swings from 78% to 140% quarter to quarter with no obvious pattern.

The diagnosis is almost always the same. Nothing in that stack maps to how the money actually moves. The 40,000 patients are not customers — they are covered lives inside eleven contracts held by three self-insured employers, two regional health plans, and six health system service lines. Nobody in the CRM represents the population itself, so nobody can answer the only questions that matter: how many lives are eligible under each contract this month, how many of those are engaged, and how close each contract is to its outcome thresholds.

That gap has downstream consequences that look like unrelated problems. Billing disputes appear because eligibility files from the employer's benefits administrator arrived late and the invoice went out against a stale member count. A renewal is lost because the health plan's medical director asked for an outcomes report the company could produce only by hand-assembling six months of claims and engagement exports. A rep quits because the deal they sourced fourteen months ago finally closed the week after their quota year reset. A forecast misses because three signed pilots were counted at full enterprise value, and only one converted.

The scenario is worth sitting with, because it clarifies what a digital health revenue architecture actually is. It is not a CRM configuration exercise. It is the design of a system that keeps four things synchronized: the contract (what was promised and to whom), the population (who is eligible and engaged), the evidence (what clinical and economic result was produced), and the money (what can be invoiced and recognized). Every operational decision below is downstream of keeping those four in agreement. The adjacent industries that face the same shape — medical device companies selling into value-based arrangements, pharmacy benefit adjacent tooling, and even education technology selling per-student to districts on outcome guarantees — solve it the same way, which is a useful sanity check when a horizontal vendor tells you their platform "handles healthcare."

How the buyer map and the money actually move

The first architectural decision is which of four buyer channels is your primary revenue engine, because each implies a different sales motion, cycle length, comp plan, and data dependency. Trying to serve all four with one undifferentiated motion is the most common and most expensive mistake in the category.

Provider channel. You sell to a chief medical officer, chief medical information officer, or VP of clinical operations at a health system. You integrate with the EHR — Epic, Oracle Health, athenahealth — and you survive a security review. Cycles run long because the buying committee spans clinical, IT, security, revenue cycle, and legal. The upside is stickiness: once you are embedded in a clinical workflow and an interface is live, displacement is genuinely hard. The downside is that implementation is a project, not an install, and your services capacity becomes a growth constraint before your sales capacity does.

Payer channel. You sell to medical directors and VPs of clinical strategy at health plans. Contracts are typically PMPM against a defined covered population, sometimes with a portion of fees at risk. Contract values are the largest of the four channels, cycles are the slowest, and the proof bar is the highest — plans have actuaries who will model your claimed savings independently and are unimpressed by engagement metrics that do not tie to utilization or cost.

Employer and benefits channel. You sell through benefits consultants and brokers into self-insured employers, and the calendar owns you. Decisions cluster around the annual benefits enrollment cycle, which means a deal that slips past the decision window does not slip a quarter — it slips a year. This is the channel that produced the best-known scaled companies in the category, and it rewards a distribution strategy (consultant relationships, benefits platform partnerships) more than a direct-sales strategy.

Consumer channel. Cash-pay or subscription. Fast cycle, low contract value, high acquisition cost, high churn. It is a legitimate business but a different company, and running it alongside an enterprise motion splits your data model, your comp philosophy, and your engineering roadmap.

Pick a primary. Architect routing, comp, and reporting around it. Treat the others as deliberate, resourced secondary plays with their own stage definitions rather than as opportunistic exceptions your reps chase when the primary pipeline is slow.

The mechanism that makes this diagram operational rather than decorative is the object model underneath it. In a horizontal SaaS CRM, the account is the company and the contract is a line item. In digital health you need at least four distinct objects: the contracting entity (who signs and pays), the population (the eligible cohort, which may span multiple employers under one plan or multiple service lines under one system), the contract terms (PMPM rate, minimum lives, outcome thresholds, at-risk percentage, true-up cadence), and the evidence record (engagement and clinical results attributable to that population). Salesforce Health Cloud and comparable configurations support this, but the configuration is the work — no platform gives it to you by default.

Modeling PMPM, at-risk fees, and the numbers that govern the business

Horizontal SaaS bills per seat, and revenue is a function of how many licenses were sold. Digital health increasingly bills per covered life or per outcome, and revenue becomes a function of a monthly eligibility file you do not control and an outcomes calculation you must be able to defend. That is a fundamentally different accounting posture, and it should shape your systems before it shapes your pitch deck.

PMPM. A fixed amount per eligible member per month, billed regardless of whether that member ever opens the app. Revenue is predictable; margin is not, because your cost to serve scales with engagement while your revenue scales with eligibility. A program with strong engagement and thin PMPM can be gross-margin negative in a way that looks fine on a bookings dashboard.

At-risk and value-based. A portion of fees — commonly a meaningful minority of contract value rather than the whole thing — is contingent on hitting clinical or cost targets: reduced A1c, avoided emergency department visits, medication adherence thresholds, readmission rates. These structures win deals in a cost-pressured market because they transfer risk to you, and they punish companies whose measurement infrastructure is weaker than their clinical results.

Hybrid. PMPM base plus a performance bonus or at-risk component is the common structure, and it is the one your systems should assume by default.

The numbers you should actually be tracking, and rough ranges worth calibrating against your own history rather than treating as universal truths:

• Eligible vs. engaged lives. Report both, always, per contract. Engagement rates in this category vary enormously by condition and outreach model, and the gap between the two numbers is the single best predictor of both margin and renewal.
• Pilot-to-scale conversion. The percentage of paid pilots that convert to enterprise contracts. This is the headline growth metric. A company with a strong pilot pipeline and weak conversion is not growing; it is manufacturing future churn.
• Sales cycle. Plan for 9–18 months in payer and provider channels, and treat anything materially faster as a signal to check whether you actually cleared security and legal or just got a verbal from a clinical champion.
• CAC payback. Often 18–30 months given cycle length and implementation cost. If your board is benchmarking you against horizontal SaaS payback norms, that conversation is worth having early and explicitly.
• Net revenue retention on covered lives. Expansion here is lives-based (new service lines, new employer groups under an existing plan) rather than seat-based, which means your expansion motion is closer to account management inside a large institution than to product-led upsell.
• Outcome attainment rate. The percentage of at-risk contracts hitting their thresholds. Finance needs this to recognize revenue correctly; CS needs it to know which renewals are already lost.

Two accounting realities follow from this. First, a signed contract does not equal recognized revenue — recognition depends on eligibility counts and, for at-risk components, on outcome attainment that may not resolve for two to four quarters. Your finance team should be modeling variable consideration, and your RevOps team should be feeding them the data that makes those estimates defensible. Second, your true-up process is a revenue process, not an administrative one. Eligibility files change monthly; members join and leave; an employer sells a division. Reconcile every billing cycle, or you will be issuing credits against revenue you already reported.

The compliance and data layer is revenue infrastructure

In most industries the compliance layer is a cost center that sits beside the revenue stack. In digital health it *is* the revenue stack, because you cannot invoice without eligibility data, cannot renew without outcomes data, and cannot keep the company without protecting both.

The integration map your RevOps function owns typically includes: EHR connectivity through an integration layer or FHIR APIs to exchange clinical data with Epic and Oracle Health environments; eligibility and identity feeds from payers, employers, and benefits administrators that establish who is a covered life — the denominator for every invoice; a HIPAA-compliant warehouse under a signed business associate agreement as the single source of truth for eligible lives, engagement, and outcomes; and a CRM configured for the multi-party account model described above.

Assign a named data owner for this map. Not a committee, not "the analytics team" — a person whose job includes reconciling eligibility every billing cycle and who is accountable when the outcomes pipeline breaks. The failure modes are unglamorous and expensive: stale eligibility means invoicing the wrong number of lives; a broken attribution join means failing a value-based contract you actually satisfied clinically; an access-control gap means a breach in an environment where a breach is existential.

A practical sequencing note. Companies routinely try to bolt HIPAA compliance onto a marketing automation and analytics stack chosen for a consumer product, and it does not work. Every tool that touches protected health information needs a BAA, role-scoped access, and encryption in transit and at rest. That constraint eliminates a lot of otherwise-attractive tooling, so make the choice deliberately and early rather than discovering it during a security review that a $2M deal is waiting on.

Trade-offs worth making consciously

Every meaningful decision in this architecture has a real cost on the other side. The companies that scale well are not the ones that avoid trade-offs; they are the ones that pick knowingly and instrument the downside.

Channel focus vs. optionality. Concentrating on one channel makes your motion, comp, and data model coherent — and makes you fragile to a single procurement climate. The mitigation is not a second full motion; it is a small, explicitly funded secondary channel with its own stage definitions and its own quota, so it never contaminates the primary forecast.

At-risk contracts vs. predictable revenue. Taking risk wins deals and commands better rates, but it converts your revenue into a function of your measurement quality. Do not sign at-risk terms your data pipeline cannot yet defend; a contract you satisfy clinically but cannot prove is worse than one you never signed.

Build vs. buy on integrations. Building direct EHR interfaces gives you control and margin at meaningful engineering cost per site; buying an integration layer trades margin for time and breadth. Most companies should buy until integration volume makes the economics obvious, then reconsider.

Pilots as revenue vs. pilots as qualification. Paid pilots create near-term cash and reference logos. They also consume implementation capacity and can become a comfortable place for deals to die. Every pilot should have written success criteria, a named executive sponsor on the customer side, and a pre-agreed conversion path — or it is a science project you are funding.

Comp on bookings vs. comp on conversion. This one deserves detail. Standard close-and-collect commission breaks in digital health, because a signed pilot is not recognized revenue and a 12–18 month cycle can starve a rep before the deal lands. The workable structure is two-stage: a milestone bonus when a qualified paid pilot signs with valid success criteria, and full commission on the pilot-to-scale conversion. That rewards landing convertible pilots rather than vanity logos. In the employer channel, tie a portion of comp to enrollment-window timing, since missing the window costs a full year. Get this wrong and your best reps quietly migrate toward short-cycle consumer deals and abandon the payer and provider work that compounds.

Common pitfalls and how to avoid them

Treating the pilot as the win. Teams celebrate pilot signatures, comp against them, and report them in board decks at implied enterprise value. Then conversion runs below expectation and the pipeline was fiction. Fix: report pilots and enterprise contracts as separate forecast categories with separate historical conversion rates, and never blend them into a single pipeline number.

Selling clinical value to a financial buyer, or vice versa. The medical director needs evidence; the finance leader needs an economic model in their own units — cost per member per month avoided, not "engagement lift." Bring both artifacts to every committee, and know which stakeholder is currently blocking.

Discovering security review at the end. IT and security can kill a deal the clinical team loves. Run the security questionnaire and BAA review in parallel with clinical evaluation, not after. Maintain a current security packet — architecture diagram, SOC 2 report, subprocessor list, breach response plan — so the review is a document exchange rather than a two-month scramble.

Letting eligibility data rot. The most boring failure in the category. Files arrive late, formats change, an employer restructures. Build automated validation on every inbound file (row count deltas, schema checks, duplicate member IDs) with an alert to a named owner, and reconcile before invoicing rather than after a dispute.

Running CS as generic account management. A PMPM contract renews on demonstrated engagement and outcomes, which makes customer success a clinical-and-data function. Produce a quarterly outcomes and ROI report in the buyer's own terms. Build an early-warning system that flags declining engagement or missed outcome targets 90+ days before renewal, with a named intervention owner and a playbook — outreach campaign, clinical protocol adjustment, scope renegotiation — attached to each flag.

Forecasting in one stage. Long, lumpy, pilot-gated cycles make naive pipeline math useless. Forecast in two stages: pilot pipeline with its own conversion rate, then pilot-to-scale conversion into enterprise revenue. Layer in eligibility-driven revenue variability on the existing base, since even flat logo retention produces revenue movement when covered lives shift.

No forum where the four systems reconcile. Run a monthly revenue council across sales, customer success, finance, clinical, and RevOps, chaired by the head of RevOps or the CRO. Standing agenda: pipeline reality, outcome attainment risk, eligibility data quality, implementation capacity. It is the meeting where the contract, the population, the evidence, and the money get checked against each other — and the absence of that meeting is why most of the pitfalls above go undetected for two quarters.

Related questions

How is digital health RevOps different from selling medical devices?

Both face clinical validation, procurement, and value-analysis committees. Devices add physical logistics, capital budget cycles, and often per-procedure economics rather than per-member. The buying committee and evidence bar are similar enough that device commercial playbooks translate better than horizontal SaaS ones.

When should a company add a second buyer channel?

When the primary channel's motion is repeatable — consistent stage conversion, a documented security packet, predictable implementation timelines — and you can fund the second channel with its own quota, stage definitions, and enablement rather than asking existing reps to split attention.

What belongs in the CRM versus the data warehouse?

The CRM holds the contracting entity, opportunity, contract terms, and stakeholder map. The warehouse holds eligibility, engagement, and outcomes at member grain. Push aggregated contract-level metrics back to the CRM so sellers and CS see them, but never store member-level PHI in the CRM.

How do you forecast at-risk revenue components?

Estimate as variable consideration using historical attainment rates by contract type, constrain the estimate where measurement periods are long, and track attainment monthly rather than at settlement. Finance and RevOps should agree the methodology in writing before the first at-risk contract is signed.

Does product-led growth work in digital health?

Rarely as the primary enterprise motion, because the user is not the payer. It works well as a supporting layer — member engagement data and clinician-level adoption become the evidence that supports enterprise expansion inside an existing account.

FAQ

What makes revenue operations in digital health different from horizontal SaaS?

The user and the payer are different parties. A patient engages while an employer, health plan, or provider system pays, usually on a per-member-per-month or outcomes basis, through a 9–18 month cycle gated by HIPAA review, clinical validation, and procurement. Your systems must track contract milestones and clinical engagement, not sign-ups.

Should we pursue one buyer channel or several from the start?

Pick one primary. Each channel has different contract structures, compliance requirements, stakeholder maps, and calendars. Serving all four early spreads implementation and evidence-generation capacity too thin, and it produces a CRM configuration that fits none of them properly. Add channels deliberately, with dedicated quota and stage definitions.

How do you forecast when deals take 9–18 months?

Model stages specific to this category — clinical evaluation, security and HIPAA review, procurement and BAA, then pilot, then scale conversion — with historical conversion rates at each. Forecast pilot pipeline separately from enterprise pipeline, and layer eligibility-driven variability onto the existing revenue base.

What should customer success measure?

Clinical outcome attainment and member engagement or utilization per contract, because those determine renewal and expansion on PMPM deals. Traditional satisfaction metrics are secondary. Build the renewal-risk view on engagement trend and outcome trajectory, flagged at least 90 days before the renewal date.

How do you handle compliance across the RevOps stack?

Every tool touching protected health information needs a signed business associate agreement, encryption in transit and at rest, and role-scoped access. Choose the stack with that constraint in mind from the start rather than retrofitting, and keep a current security packet ready so reviews are document exchanges rather than fire drills.

Which revenue model fits best for enterprise digital health contracts?

A PMPM base with a performance or at-risk component is the common structure, because it matches how payers and self-insured employers budget. Per-seat pricing does not map to covered populations. Direct-to-consumer subscriptions work but carry lower lifetime value and higher acquisition cost than enterprise contracts.

Sources

• https://rockhealth.com/insights/
• https://www.cms.gov/priorities/innovation/innovation-models
• https://www.hhs.gov/hipaa/for-professionals/index.html
• https://www.hl7.org/fhir/
• https://www.himss.org/resources
• https://www.kff.org/health-costs/
• https://www.cbinsights.com/research/
• https://www.klasresearch.com/

Related on PULSE

• [Digital CSM vs High-Touch CSM Tier Design in 2027](/knowledge/ra0480)
• [Health Score to Action Playbook Architecture in 2027](/knowledge/ra0486)
• [How to design CS health scores that predict renewals 90 days out in 2027](/knowledge/ra0314)
• [Customer Health Score Design for SaaS CS in 2027](/knowledge/ra0275)
• [Revenue Architecture for Population Health Platforms in 2027 (VBC Performance, Big-4 + Payer Channel)](/knowledge/ra0139)