SaaS Pricing Model? Plans or charge per user?

Start with the buyer: clinicians don’t “buy SaaS,” hospitals buy risk reduction

In medtech SaaS, pricing is less about what feels “standard in SaaS” and more about what fits hospital procurement and the value story you can defend. The key distinction is between:

• Economic buyer: the person/committee with budget authority (often department leadership, IT, supply chain/procurement, or a value analysis committee).
• User: the clinician, tech, coordinator, or analyst who touches the product daily.
• Champion: the internal advocate who pushes adoption (may or may not control budget).

If the economic buyer is a hospital or health system, they usually prefer predictable spend and simple contracting. That often pushes you toward tiered plans (by site, volume, or module) rather than a pure “$X per user per month” model. But per-user can still work when usage is tightly tied to value and the user count is stable and auditable.

Plans vs per-user: a decision framework that works in medtech

Use these five questions to decide. You can score each option (plans vs per-user) from 1–5 and see which wins.

1) What scales with cost and support?

• Per-user fits when marginal cost/support scales with seats: training time, role-based permissions, audit trails, helpdesk load, and PHI access management.
• Plans fit when costs scale with sites, integrations, or data volume (e.g., EHR integration, device fleet, imaging throughput).

2) What scales with value?

• Per-user fits when each additional user creates incremental measurable value (e.g., each clinician using a decision support tool reduces errors or speeds documentation).
• Plans fit when value is department-wide or system-wide (e.g., reduced length of stay, fewer readmissions, improved throughput). In those cases, tying price to user count can feel arbitrary and invites negotiation.

3) How does procurement want to buy?

Many hospitals dislike “metered” pricing that can spike unexpectedly. They also dislike pricing that requires them to constantly reconcile rosters. If your product touches multiple roles (MDs, RNs, techs, coders), per-user can create internal friction (“Who pays for whose seats?”). A site-based plan (per facility) or department plan can be easier to approve.

4) Is adoption broad or narrow?

• Narrow adoption (e.g., a specialized clinic team of 8–30): per-user can be clean and fair.
• Broad adoption (e.g., ED, periop, inpatient units): per-user can become politically and operationally painful; plans or enterprise pricing tends to win.

5) Are you in a regulated workflow?

If you’re in a workflow that may be considered Software as a Medical Device (SaMD), your go-to-market may involve FDA pathways like 510(k), De Novo, or PMA depending on risk and predicate availability (this varies). Regulated deployments often require more validation, training, and documentation. That can favor plans with implementation fees rather than a simple per-seat SaaS price.

The most common winning approach: tiered plans + a scaling metric (not always users)

For medtech SaaS sold to providers, the most resilient pricing architecture is usually:

• A base platform fee (tiered plan) that matches procurement expectations and covers core compliance/hosting/support.
• A scaling metric that tracks value and cost drivers (users, sites, beds, devices, studies, encounters, or modules).
• Optional implementation/integration fees for EHR connectivity, SSO, HL7/FHIR interfaces, validation, and training.

This avoids the trap of underpricing a complex hospital deployment while still giving smaller sites an entry point.

Examples of scaling metrics (choose one primary)

• Per site / facility: great when deployment is operationally site-specific (training, workflows, local champions).
• Per bed (or per department size): sometimes used for inpatient operational tools; can be easier than per-user.
• Per device: if you manage a fleet (remote monitoring, calibration, utilization analytics).
• Per study / per scan / per case: fits imaging/diagnostics workflows where volume is the value driver.
• Per active patient: common in remote patient monitoring and care management; watch definitions carefully.
• Per user: best when access control and training scale with seats and the user list is stable.

How reimbursement and clinical economics should influence your pricing

Even if you’re “just SaaS,” hospitals will ask: Where does the money come from? In healthcare, that can be:

• Cost avoidance: fewer adverse events, reduced overtime, fewer denials, less manual labor.
• Revenue capture: improved documentation/coding, fewer missed charges, better throughput.
• Reimbursement pathways: sometimes tied to billing codes (e.g., CPT codes) or payer contracts. Whether your product directly enables billable services varies widely.

Pricing should map to the economic story you can defend in a value analysis meeting. If your ROI is tied to department-wide outcomes (e.g., reduced readmissions), per-user pricing can look misaligned. If your ROI is tied to clinician productivity (minutes saved per note), per-user can be intuitive.

Also consider evidence requirements. If you need clinical validation, you may run studies under IRB approval (varies by institution and study design). That timeline can push you toward contracts that include implementation and evaluation phases rather than a simple self-serve per-seat subscription.

A practical pricing structure you can deploy early (and not regret later)

Here’s a structure that works for many early-stage medtech SaaS products selling into clinics/hospitals:

1. Starter (Pilot): limited scope (one site or one department), includes a defined number of users or a defined volume cap. Keep it procurement-friendly: clear term length, clear success criteria.
2. Standard (Department): priced per site/department with role-based access and a reasonable user allowance; add-ons for integrations/modules.
3. Enterprise (Health system): multi-site, includes security review support, SSO, audit logs, and negotiated volume tiers; often priced per site or per bed with a floor commitment.

Notice what’s happening: you’re using plans to anchor the purchase, and you can still use users as a secondary limiter (e.g., “includes up to N named users; additional users at $X”) without making seats the entire business model.

When pure per-user is the right answer

• You sell to private practices or small clinics with straightforward buying.
• Each user is a clear unit of value (e.g., each provider using the tool generates measurable productivity or revenue capture).
• Implementation is light (no complex EHR integration) and onboarding is repeatable.

When pure plans (site/enterprise) are the right answer

• Value is system-wide and hard to attribute per user.
• Your product requires heavy integration, validation, or change management.
• User counts fluctuate (rotations, float staff, trainees), making seat audits painful.

What to do next

1. Write your “unit of value” statement: “We create value per ___” (user, site, device, case, patient). Pick one primary unit.
2. Draft a 3-tier packaging page with one scaling metric and 2–3 add-ons (integration, advanced analytics, extra modules). Keep it simple enough to explain in 60 seconds.
3. Run 10 pricing interviews with economic buyers (not just users): ask how they prefer to budget (per seat vs per site), what triggers procurement, and what pricing feels “approvable.”
4. Design a pilot offer with clear success metrics and an upgrade path (e.g., pilot fee credited toward annual contract if KPIs are met).
5. Pressure-test compliance and deployment costs (security review, IRB needs, FDA pathway if applicable) so your price covers real implementation effort.

If you want a structured way to validate your packaging and pricing against competitors and hospital buying behavior, use /Competitor_study and then sanity-check your numbers in /finances.