How to do saas pricing?

Start with the constraint: medtech SaaS is bought, not just used

In medtech, pricing isn’t only a marketing decision—it’s a go-to-market decision shaped by hospital procurement, compliance, and reimbursement. A clinician may love your product, but the buyer might be a department administrator, IT/security, or a value analysis committee. That means your pricing must be:

• Procurement-friendly (clear SKU, annual terms, predictable budget line)
• Defensible (why this price vs alternatives, including “do nothing”)
• Aligned to value (time saved, avoided adverse events, reduced length of stay, improved throughput, fewer denials)
• Compatible with regulatory status (non-device vs SaMD; FDA pathway like 510(k), De Novo, or PMA if applicable)

Before you pick numbers, decide what you’re selling: a workflow tool (often budgeted as software/IT), a clinical decision support product (may trigger SaMD considerations), or a revenue-cycle/reimbursement enabler (often budgeted from finance). The budget owner strongly influences what pricing model will actually close.

Pick a value metric that matches clinical workflow (not vanity metrics)

A value metric is the unit you charge for that scales with customer value. In generic SaaS, “per seat” is common. In medtech, “per seat” often fails because the value is tied to patients, procedures, sites, or throughput—not logins.

Common medtech SaaS value metrics (and when to use them)

• Per facility / per site: Best when value is operational and cross-departmental (e.g., sepsis surveillance, bed management). Procurement likes it because it’s predictable.
• Per department / service line: Useful when adoption is localized (e.g., radiology QA, cath lab workflow).
• Per clinician (named user): Works when usage is truly individual and measurable (e.g., documentation assistant for a specialty clinic). Beware “shared accounts” and credentialing friction.
• Per patient / per encounter: Strong alignment when value scales with volume (e.g., remote monitoring, digital therapeutics, post-op follow-up). Requires clean volume definitions and often integration.
• Per study / per scan / per case: Natural for imaging and procedure-heavy products (e.g., AI triage per CT, per echo read). Easier to justify with throughput and turnaround time.
• Outcomes/revenue share (gainshare): Sometimes attractive (e.g., reducing denials, improving coding). Harder in hospitals due to compliance, attribution, and contracting complexity—use carefully.

Rule of thumb: choose the metric that (1) the buyer already tracks, (2) is hard to game, and (3) scales with the value you create. If your metric requires a new reporting process, you’ve added friction to the sale.

Design tiers around risk, evidence, and integration—not just features

Medtech SaaS buyers evaluate risk as much as features: security, liability, clinical governance, and integration burden. Your tiers should map to those realities.

A practical 3-tier structure for medtech SaaS

1. Starter (low-risk, low-lift): Single site or department, limited integrations, standard support, basic reporting. Goal: fast procurement and proof of value.
2. Clinical (operationalized): SSO, audit logs, role-based access, advanced analytics, EHR integration (HL7/FHIR), workflow customization, onboarding/training. Goal: embed into daily workflow.
3. Enterprise (system-wide): Multi-site, centralized admin, SLA, dedicated support, security reviews, custom integrations, data residency options, governance tooling. Goal: scale across the health system.

Instead of “Feature A vs Feature B,” consider tiering by:

• Integration depth (none → one-way → bi-directional)
• Clinical governance (basic alerts → configurable protocols → committee-level reporting)
• Implementation effort (self-serve → guided → managed)
• Support/SLA (email → business hours → 24/7 with uptime commitments)

This aligns price with what actually costs you money (implementation, support) and what creates switching costs for the customer (integration and governance).

Build a pricing narrative that survives procurement: ROI, reimbursement, and evidence

Hospitals don’t buy “software,” they buy outcomes: fewer complications, faster throughput, lower staffing burden, better documentation, fewer readmissions, fewer denials. Your pricing must be paired with a simple, defensible business case.

ROI model: keep it simple and auditable

Create a one-page ROI worksheet with inputs the customer can verify. Avoid questionable assumptions. Use ranges (“varies”) when needed. Typical buckets:

• Time savings: minutes saved per encounter × encounters per month × loaded labor cost (use customer’s numbers when possible)
• Throughput: additional cases enabled (if capacity constrained) × contribution margin (often sensitive—let them fill it in)
• Avoided costs: fewer adverse events, fewer unnecessary tests, reduced length of stay (harder—use cautiously unless you have evidence)
• Revenue capture: improved coding/documentation, fewer denials, better prior auth (tie to finance metrics)

Reimbursement and CPT: know when it matters

If your product touches billable services (e.g., remote patient monitoring, chronic care management, digital therapeutics), pricing may be constrained by reimbursement economics. You don’t need to promise specific CPT revenue, but you should understand:

• Whether there are relevant CPT codes or payer pathways (details vary by use case and payer)
• Who captures the revenue (hospital vs physician group)
• What documentation burden your product adds or removes

If you’re pre-reimbursement clarity, avoid pricing that assumes reimbursement will fund the contract. Instead, price to operational value (time saved, workflow improvement) and treat reimbursement upside as optional.

Regulatory status affects willingness to pay (and sales cycle)

If your SaaS is SaMD (Software as a Medical Device), the FDA pathway (often 510(k), De Novo, or PMA depending on risk and predicate availability) can influence buyer confidence and contracting. But don’t overprice just because you pursued clearance—buyers pay for value. Also, if you’re not yet cleared and clearance is required, your “commercial” pricing may need to be framed as a limited, compliant evaluation (often via IRB if it’s research) rather than routine clinical use.

Choose a contracting model that matches hospital buying behavior

Medtech SaaS pricing often fails because founders copy consumer SaaS motions (monthly self-serve) into an enterprise procurement world. Common contracting patterns that work better:

Annual subscription (most common)

Annual prepaid is procurement-friendly and reduces churn risk. Many hospitals prefer predictable annual budgeting. If you offer monthly, expect it to be used mainly by small clinics or as a bridge.

Implementation + subscription

If integration, training, or workflow configuration is non-trivial, separate it:

• One-time implementation fee (covers your real costs and signals seriousness)
• Recurring subscription (covers ongoing value, support, hosting, updates)

This also prevents your subscription price from looking “too high” when it’s really bundling services.

Pilot pricing (paid, time-boxed, success criteria)

Free pilots often become endless. A better structure is a paid pilot with:

• Fixed duration (e.g., 60–90 days; exact length varies)
• Defined success metrics (adoption, turnaround time, documentation completeness, alert response time)
• Pre-agreed conversion path (pilot fee credited toward annual contract)

If the evaluation involves patient outcomes research, consider whether IRB approval is needed. If it is, bake that timeline into your pilot plan and pricing expectations.

How to set the actual price: a founder-friendly method

Use a three-lens approach and pick a number you can defend in a meeting with finance, IT, and clinical leadership.

1. Value-based ceiling: Estimate conservative annual value created for the buyer. Price as a fraction of that value so the ROI is obvious.
2. Market anchors: What do adjacent solutions cost (not just direct competitors)? Consider EHR add-ons, workflow tools, and staffing alternatives.
3. Cost-to-serve floor: Hosting, support, security/compliance work, implementation hours, and any third-party fees. If enterprise customers require heavy security reviews and custom integrations, your floor is higher than you think.

Then pressure-test with procurement realities:

• Can this fit into a department’s discretionary budget, or does it require system-level approval?
• Is the price simple enough to become a line item?
• Does the contract structure reduce perceived risk (pilot, termination clauses, SLAs)?

Finally, document your pricing logic internally. Your sales team (even if it’s just you) needs a consistent story for discounting, multi-site expansion, and renewals.

What to do next

1. Define your value metric (site, department, encounter, case) and write one paragraph explaining why it matches how hospitals measure value.
2. Create a 3-tier packaging table with integration/support/governance differences (not just features) and decide which tier you’ll sell by default.
3. Build a one-page ROI worksheet with customer-fillable inputs and conservative assumptions; use it in every sales call.
4. Design a paid pilot offer with time-box, success criteria, and a pre-negotiated conversion to an annual contract.
5. Run a competitor and “do nothing” study to set realistic anchors and identify where you can charge more (or must simplify).

If you want to pressure-test your pricing page and packaging against medtech procurement reality, run it through /roast or map your tiers against competitors in /Competitor_study.