.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
The Definitive Guide to Running a Pricing and Packaging Strategy Project for Healthcare SaaS
Most healthcare SaaS pricing projects begin after the commercial symptoms are already visible. Sales teams ask for larger discounts. Customers buy broad plans but use narrow parts of the product. Implementation work expands after signature. Finance cannot explain why two similar provider groups pay very different rates. Leadership responds by asking a deceptively simple question: “Should we raise prices?”
That question comes too late. Healthcare software is sold into organizations where privacy, security, clinical workflow, procurement, and implementation all shape the buying decision. As of September 3, 2026, HHS guidance makes clear that covered entities and business associates must use written agreements governing the handling and safeguarding of protected health information. Commercial terms therefore cannot be separated from the operating promises a vendor makes to customers.
Our view is direct: a healthcare SaaS pricing project should be run as a business-design effort, not a price-card exercise. The project must identify the buyer segment, build offers around the operating job that segment needs done, select one primary meter tied to accountable scale, set prices from evidence, and make the model work in contracts, systems, and renewals.
Healthcare pricing becomes durable only when leaders settle five linked decisions in order
Monetizely’s 5-Step Pricing Framework prevents teams from treating rate setting as the first decision. The sequence begins with goals and segmentation, then moves to packaging, pricing metric, price points, and operationalizing pricing. Each step narrows the choices in the next one. A health-tech company that has not agreed on whether it is optimizing for faster adoption, larger enterprise contracts, or higher gross margin cannot rationally decide how many packages to offer or which customer behavior to charge for. The same sequence is developed in Monetizing Agentic AI.
A disciplined project has a defined cadence, named decision owners, and clear outputs. The point is not to create more slides. The point is to remove the unresolved choices that later appear as discounting, custom terms, and billing exceptions.
The sequence matters because a price point is the output of the project, not its starting premise.
“Small, mid-market, and enterprise” is too blunt for healthcare SaaS. A 300-provider specialty group, a 300-bed health system, and a 300,000-member health plan may share a rough scale category while buying for entirely different reasons. Their approval paths, implementation needs, and economic logic are not comparable.
A better segmentation starts with who owns the problem and how the customer measures success. The practice owner may want fewer administrative hours. A health-system CIO may want standard workflows across sites. A payer executive may want access for an enrolled population. A life-sciences quality leader may need validated processes, auditability, and deployment support.
| Buyer segment | Economic buyer and operating need | What the package must solve | Recommended primary contract anchor |
|---|---|---|---|
| Independent and small group practices | Owner-clinician seeks lower administrative burden | Fast setup, core workflow, self-service support | Active clinician |
| Multi-site provider organizations | COO or CIO seeks consistent operations across locations | Shared controls, integrations, role-based access, rollout support | Facility or site, with clinician bands |
| Health plans and employers | Population-health leader seeks broad access and engagement | Member eligibility, reporting, service coverage | Enrolled member per month |
| Regulated life-sciences teams | Functional leader seeks compliant execution across a business process | Configured workflows, controlled access, validation and services | Application or business function, with services scoped separately |
The table points to a central rule: segment around the customer’s accountable operating unit, then size the price around that unit.
Public-company filings reinforce the distinction. Teladoc reported in its 2025 Form 10-K that 83% of consolidated revenue came from access fees, with clients paying per-member-per-month, per-employee-per-month, or per-participant-per-month fees; some arrangements also include visit fees. That structure fits a population-access product.
By contrast, Veeva reported for the fiscal year ended January 31, 2026 that 84% of revenue came from subscriptions and 16% from professional services and other revenue. Its model separates ongoing software value from implementation, configuration, and managed-service work. Health Catalyst similarly reported in its 2025 Form 10-K that it derives substantially all revenue from technology subscriptions and recurring professional services.
Those examples do not argue for one universal meter. They show why a healthcare SaaS company must first decide what customers are actually buying.
Packages win when they bundle a complete job, not a random set of features
Healthcare SaaS leaders often inherit packages built feature by feature. A reporting module goes into the top tier because it appears advanced. An integration becomes a paid add-on because it took engineering time. Security terms become an enterprise upsell because procurement requested them. The final offer may look sophisticated, yet fail to match the way customers buy.
A package should make a customer confident that it can complete a recognizable operating job. For a small therapy practice, that job may be scheduling, documentation, and billing. For a health system, it may be standardizing intake across 20 locations while connecting to an existing EHR. The package should make the operating difference visible before the buyer reaches the order form.
SimplePractice offers a useful public example. As of September 3, 2026, its standard plans begin at $49, $79, and $99 per month, while group-practice pricing is tied to the number of clinicians. It also prices e-prescribing separately at $49 per clinician per month plus an $89 one-time setup fee. The structure combines a clear core plan with a role-linked add-on that has a distinct cost and use case.
| Package level | Customer promise | What belongs in the package | What should remain separate |
|---|---|---|---|
| Core | Run one defined workflow reliably | Essential product capabilities, standard onboarding, standard support | Major integration work, bespoke reporting, data migration |
| Scale | Standardize the workflow across a growing organization | Multi-user administration, role controls, shared reporting, higher service levels | New site deployment, complex interfaces, special data conversion |
| Enterprise | Govern the workflow across multiple entities or systems | Enterprise administration, audit controls, advanced integration access, formal rollout plan | Clearly scoped implementation services and exceptional custom development |
The architecture should follow three guardrails:
A package system earns its keep when it reduces custom quotes rather than simply moving customization into a longer order form.
The pricing metric is the contractual answer to a practical question: what are we measuring and billing for? Healthcare buyers will accept a meter when they can forecast it, influence it, and connect it to the product’s value. They will resist a meter that moves for reasons outside their control.
Monetizely’s position is that most healthcare SaaS products should have one primary meter tied to accountable scale. A second variable charge can recover a real transaction cost or capture a discrete event. It should not obscure the core offer.
Phreesia provides a useful contrast. In the fiscal year ended January 31, 2025, it reported $196.5 million in subscription and related-services revenue, $101.7 million in payment-processing fees, and $121.6 million in network-solutions revenue. The model distinguishes platform access from transaction-linked payment activity and from another separately monetized business line.
| Primary meter | Best fit | Why buyers can accept it | Avoid using it when |
|---|---|---|---|
| Active clinician | Clinical documentation, practice operations, care-team workflow | Leaders can count licensed or active users and link them to workflow adoption | The product’s value reaches many users but is bought as a system-wide platform |
| Enrolled member per month | Virtual care, navigation, population engagement | The buyer manages eligibility files and budgets around covered populations | Value occurs only when a discrete paid transaction happens |
| Facility or site | Multi-location provider operations, hospital workflow, shared infrastructure | The buyer can identify each operating location and plan expansion | Site count bears little relationship to usage or support needs |
| Payment transaction | Payment processing, collections, claims-related transaction services | The event is auditable and closely tied to processing cost and customer value | The software’s main value comes from workflow access rather than the transaction itself |
| Visit or completed service event | A product whose value is created at a completed encounter | The event can be objectively defined and reported | Clinical quality, patient eligibility, or attribution creates disputes over what counts |
The implication is straightforward. A care-management platform should not lead with a charge per API call just because the vendor can meter it. A revenue-cycle product can credibly charge for a payment or claim event when that event is central to the buyer’s value and the vendor’s variable cost. The meter must serve the buying logic first and the billing system second.
Competitive pricing is useful, but only as a starting point. A competing price page cannot show why a buyer rejected the offer, which package features matter in a procurement review, or how much implementation uncertainty is depressing willingness to pay.
The research plan should create evidence for specific management decisions. Pricing teams need quantitative data that shows how large an opportunity is and qualitative evidence that explains the buyer’s reasoning. Monetizely’s framework places price-point setting after segmentation, packaging, and metric selection for precisely this reason.
That evidence should lead to a price corridor rather than a single universal number. The corridor sets a target rate for each package and segment, a negotiated floor, and a defined reason for any exception. Sales teams then know when a lower price is strategic, rather than merely expedient.
Many projects fail in the final mile. The executive team approves a new package structure, but product entitlements do not match the order form. CRM tracks contracted clinicians while billing uses provisioned users. Customer success promises implementation help that was never priced. Renewal managers inherit legacy discounts without a migration path.
Operational work must begin before the rate card is finalized. Monetizely’s guidance treats operationalization as the work of turning the chosen metric and price structure into a functioning commercial system, not as an administrative handoff.
| Operating object | System of record | Control that must exist |
|---|---|---|
| Contracted scope | CRM and order form | Clear definition of clinician, member, site, or transaction |
| Product access | Product entitlement system | Each package maps to enabled capabilities |
| Usage or volume | Product and payment-event logs | Customer-visible count, audit trail, and exception process |
| Discounts and services | CPQ and contract repository | Approval rules, implementation scope, renewal treatment |
| Invoice and true-up | Billing platform and finance ledger | Reconciliation between contracted units, actual units, and charges |
A customer should be able to answer three questions from the invoice alone: what they bought, what changed, and what they will pay next period. If the vendor cannot answer those questions quickly, the model is not ready for market.
Monetizely’s position is clear. Healthcare SaaS companies should not chase novel meters or multiply packages to signal sophistication. They should build a small number of buyer-led offers, anchor each contract in an accountable unit, and keep variable charges limited to measurable events that customers recognize as separate sources of value or cost.
Give one executive pair ownership of pricing: make the chief commercial officer accountable for market adoption and the CFO accountable for margin, with product leadership as a formal co-owner of entitlement decisions.
Measure net retention by segment and package, not only by total ARR: a company cannot tell whether its architecture works if expansion, churn, discounting, and service effort are blended into one company-wide number.
Change sales compensation before launch: reward target-package adoption and approved expansion, not headline ACV that is created through excessive discounts or unpriced services.
Treat legacy migration as a board-level commercial choice: decide which customers stay grandfathered, which move at renewal, and which receive a structured transition offer before the new model reaches the field.
Review pricing quarterly as an operating system: use renewal data, implementation effort, usage patterns, and exception requests to decide whether the model is holding, rather than waiting for a broad repricing crisis.
Footnotes
- https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- U.S. Department of Health and Human Services, Office for Civil Rights, “Business Associate Contracts” and “Business Associates,” accessed September 3, 2026. (hhs.gov)
- Teladoc Health, Inc., Form 10-K for the year ended December 31, 2025. (sec.gov)
- Phreesia, Inc., Form 10-K for the fiscal year ended January 31, 2025. (sec.gov)
- Veeva Systems Inc., Form 10-K for the fiscal year ended January 31, 2026; Health Catalyst, Inc., Form 10-K filed March 12, 2026; and SimplePractice public pricing materials accessed September 3, 2026. (sec.gov)