What is saas pricing model?

A SaaS pricing model is the way a software-as-a-service company packages its product and charges customers on a recurring basis (usually monthly or annually). “Model” includes (1) what you charge for (users, usage, sites, outcomes), (2) how you sell (self-serve vs sales-led), and (3) how revenue scales as customers grow.

In medtech and digital health, pricing is rarely just “$X per user.” Hospitals buy through procurement, clinicians care about workflow time, and your product may touch regulated claims (FDA) and reimbursement (CPT). A good SaaS pricing model aligns with: clinical value, who has budget, and how adoption spreads inside a health system.

What makes SaaS pricing different from one-time software sales

Traditional software often used a one-time license fee plus maintenance. SaaS flips this to recurring revenue, which matters because:

• Cash flow and runway: You collect smaller payments over time, so you must manage burn carefully.
• Retention is everything: If customers churn (cancel), growth stalls. Pricing must support long-term use.
• Expansion revenue: The best SaaS models grow as the customer gets more value (more sites, more clinicians, more volume).

Two key metrics you’ll hear (business jargon, defined):

• ARPA/ARPU (Average Revenue Per Account/User): what you earn per customer (or user) per month/year.
• Churn: the % of customers (or revenue) you lose in a period. In enterprise hospital deals, revenue churn matters more than logo churn.

The main SaaS pricing models (with medtech examples)

Most SaaS pricing is a combination of these. The “right” one depends on your buyer, your value metric, and procurement constraints.

1) Per user (seat-based) pricing

Charge per named user (e.g., $/clinician/month). This is common for workflow tools and dashboards.

• Works well when: value scales with the number of active clinicians (e.g., care team coordination, documentation assistance).
• Medtech gotcha: hospitals hate paying for “seats” when staff turnover is high or when many users are occasional. You may need concurrent user options or role-based tiers.

2) Usage-based pricing

Charge based on volume: per study, per encounter, per message, per device-month, per API call, etc.

• Works well when: your cost and value scale with volume (e.g., imaging AI per study, remote monitoring per patient-month).
• Medtech gotcha: procurement prefers predictable budgets. Many vendors use a commit + overage structure: a contracted minimum volume plus a per-unit overage rate.

3) Tiered plans (Good/Better/Best)

Bundle features into tiers (e.g., Basic/Pro/Enterprise). This is easy to understand and supports upsell.

• Works well when: different customer segments need different compliance, integrations, or analytics.
• Medtech example: “Enterprise” includes SSO (single sign-on), audit logs, HL7/FHIR integration, and a BAA (Business Associate Agreement) for HIPAA.

4) Per site / per facility pricing

Charge per hospital, clinic, or department. This maps nicely to how health systems budget.

• Works well when: the product is a shared platform used by many roles (ED, radiology, ICU) and seat counting is painful.
• Medtech gotcha: define “site” clearly (campus vs building vs outpatient network) to avoid contract fights later.

5) Outcome- or value-based pricing

Charge based on achieved outcomes (e.g., reduced no-shows, avoided readmissions). This can be compelling but is hard to implement.

• Works well when: outcomes are measurable, attributable, and the buyer shares in the savings.
• Medtech gotcha: attribution is messy (multiple interventions). Also be careful with claims: if you market clinical performance, you may trigger FDA considerations depending on intended use. Regulatory pathway (510(k), De Novo, PMA) depends on risk and claims and varies by product.

6) Freemium / free trial (often limited in medtech)

Freemium means a free plan forever; free trial means time-limited access. In medtech, “try before you buy” is common, but it’s usually structured as a pilot rather than a consumer-style trial.

• Works well when: you can deploy quickly with low integration burden.
• Medtech gotcha: pilots may require IRB review if you’re doing research, and security review even for non-clinical tools. Plan for timelines.

How medtech realities shape your pricing (FDA, CPT, procurement)

In healthcare, pricing is constrained by who benefits, who pays, and what approvals are required.

Hospital procurement and contracting

Hospitals often prefer:

• Annual contracts (budget cycles) with net payment terms.
• Predictable spend (site fees or committed usage) rather than pure variable usage.
• Clear implementation scope: integrations, training, support SLAs (service-level agreements).

If your product requires EHR integration, your pricing should explicitly include (or separately price) implementation, because integration work can dominate early costs.

Reimbursement and CPT codes

If your product supports billable clinical services (e.g., remote patient monitoring workflows), the buyer may anchor ROI to reimbursement. You don’t need to quote specific CPT rates to price well (rates vary by payer and setting), but you should understand:

• Who bills (hospital vs physician group) and whether they see the revenue.
• What operational work is required to capture reimbursement (staff time, documentation).

Pricing can be structured as per patient-month or per enrolled patient, which maps to many reimbursement-driven programs.

Regulatory claims and risk

Your pricing model won’t determine FDA classification, but your positioning and intended use can. If you’re selling clinical decision support or diagnostic functionality, you may need an FDA pathway (often 510(k), sometimes De Novo, rarely PMA for software-only products—varies). Regulatory work increases your cost base, so your pricing must support longer sales cycles and higher support/compliance overhead.

Choosing a SaaS pricing model: a practical framework for founders

Use this simple sequence to avoid “guess pricing.”

1. Define the buyer and budget owner: Is it the CMIO, department chair, nursing leadership, revenue cycle, or IT/security? Your pricing unit should match what they control (users, sites, service line, volume).
2. Pick a value metric: the measurable thing that scales with value (e.g., monitored patients, studies analyzed, facilities). Avoid metrics that punish adoption (e.g., charging per message when you want more engagement).
3. Decide sales motion: self-serve (rare in hospitals), product-led (some clinician tools), or sales-led enterprise. Enterprise usually supports higher ACV (annual contract value) and fewer, larger customers.
4. Design tiers around real constraints: compliance (HIPAA/BAA), integrations (HL7/FHIR), admin controls, and support. Don’t gate core clinical safety features behind higher tiers.
5. Run pricing discovery: in customer interviews, test willingness-to-pay with ranges and tradeoffs (e.g., “Would you prefer $X per site with unlimited users, or $Y per user?”). Document objections—those are your packaging clues.

A common medtech packaging pattern that works

• Base platform fee (per site or per facility) for security, admin, and integrations
• Variable component (per patient-month / per study / per device-month) aligned to value
• Implementation fee (one-time) if integration/training is non-trivial

This hybrid model gives procurement predictability while letting you scale revenue with usage.

What to do next

1. Write your value metric in one line (e.g., “$ per monitored patient-month” or “$ per facility-year”) and list why it aligns with clinical and financial value.
2. Interview 10 target buyers (not just users) and test two alternative pricing structures; capture who signs, who pays, and what budget it comes from.
3. Draft a 3-tier packaging table (Basic/Pro/Enterprise) with compliance/integration differences and a clear “Enterprise = hospital-ready” tier.
4. Model unit economics (support, cloud, integration time) so your price covers real costs; use /finances to sanity-check.
5. Pressure-test your positioning (especially if you make clinical claims) and map likely regulatory needs; then refine your go-to-market plan in /launchpad.