Case · Sense.ly

Sense.ly: In Clinical AI, the Escalation Design Is the Product

How a virtual nursing assistant earns its place in healthcare — the model’s real buyers and economics, the design question that separates a product from a demo, and what to do as the AI learns to converse.

At a glance

Clinical AI · United States · Care automation

sense.ly

01

The business model

The clinical AI business model sells automated clinical capacity to institutions: a virtual assistant handles patient check-ins, symptom conversations, and chronic-care follow-up, so scarce nursing time is spent only where human judgment is required.

The record. Founded in San Francisco in 2013, Sense.ly built its virtual nurse “Molly” — an avatar-led assistant carrying patient check-ins and chronic-care follow-up — with deployments spanning the NHS in the United Kingdom and major US health systems and insurers.

How the model works. The buyer is never the patient. Health systems, insurers, and pharmaceutical programs pay per enrolled patient or per program, and they are buying two things that appear on their own ledgers: clinical hours returned (a nurse who no longer makes forty routine check-in calls a day) and deteriorations caught early (a flagged decline that becomes an adjusted medication instead of a readmission — which, in systems penalised for readmissions, is direct money). The product’s daily mechanics: enrolled patients interact with the assistant on a schedule — a chronic-care check-in, a symptom conversation, a post-discharge follow-up — and the system continuously sorts every interaction into two streams: absorbed (resolved automatically, logged, no human touched it) or escalated (routed to a nurse dashboard with the reason attached). The entire commercial value of the model sits on the quality of that sort. And between every pilot and every production contract stands the industry’s defining obstacle: integration into the health system’s records and workflow, plus three separate approvals — the institution’s, the clinicians’, the regulator’s.

  • Earns from: per-enrolled-patient and per-program fees from health systems, payers, and pharma programs. – Wins on: the absorption ratio — routine interaction resolved safely without human time, at a cost per interaction far below a clinician’s. – The tension: absorb too little and the buyer saves nothing; absorb too much without safe escalation and the product becomes a clinical risk.

Where this model fails. Escalation noise first: a system that flags too much trains nurses to ignore it, and an ignored alert system is worse than none. Pilot purgatory second: deployments that never cross into production because one of the three gatekeepers — payer, clinician, regulator — was never truly sold. Integration cost third: the engineering of connecting to each health system’s records is routinely underestimated, and it is where the gross margin of “software” quietly becomes the gross margin of services.

02

What the case taught us

The working record stays sealed; the learning is shared.

  • Escalation design is the product. A system that escalates everything is expensive theatre — clinicians drown in false alarms and switch it off. A system that escalates nothing is a liability with a user interface. The product is the boundary between those two failures, and drawing it well requires clinical judgment and structural design working as one discipline.
  • Three gatekeepers must say yes. The institution that pays buys saved hours; the clinician who adopts buys trustworthy escalations; the regulator who permits buys governed process. A model that satisfies one and ignores the others stalls in pilots forever — the pilots-to-production gap that defines this industry is almost always a three-gatekeeper problem, not a technology problem.
  • Automate in order of clinical stakes, not technical ease. Check-ins before triage; follow-up before diagnosis support. Vendors who lead with the most impressive capability frighten the clinicians they need; vendors who automate the boring layer first get invited to automate the next one. Sequencing is the adoption strategy.

In clinical AI, the escalation design is the product.

03

Chitrangana’s transformation advisory

The scripted-avatar generation of clinical AI is giving way to systems that genuinely converse — and that cuts both ways. Conversational depth finally makes the assistant clinically useful; it also makes the escalation boundary harder to draw, because a fluent system inspires more patient trust than its clinical authority justifies. Meanwhile AI-specific regulation hardens across major markets, and the underlying models commoditise. Our advisory to operators of this model, in order:

  1. Make governance the product spec. Document the escalation logic as a clinical artefact — what the system may resolve, what it must route, on what evidence, reviewed by whom — and make every automated decision auditable. This is what the 2030 buyer purchases; the conversational fluency will be table stakes everyone has.
  2. Sell the ledger, not the demo. Rebuild the commercial case on the two numbers institutions actually book — clinical hours returned and readmissions avoided — measured per deployment and warranted in the contract. Deals framed on capability stay in pilots; deals framed on the buyer’s own ledger cross into production.
  3. Industrialise integration. Turn the records-and-workflow connection from a per-client project into a repeatable, priced capability. In this model, integration speed is sales velocity — the vendor who deploys in weeks wins the category against better technology that deploys in quarters.

The moat in clinical AI stops being the model, which commoditises, and becomes the governed deployment — the regulator-visible record of automating care safely at scale. That is the standard the firm’s AI Consulting practice holds every deployment to, in healthcare and beyond.

The question is never what the model can do — it is what the organisation can be trusted to let it do.

Chitrangana

Building in this category?

Every engagement begins with the Business Architect.

A working session on your model, not a pitch. We map where the money is actually made, then agree what to build first.

01ThinkWhere the model earns, and where it quietly leaks.
02ValidateTest the thesis against your numbers before anyone builds.
03ExecuteDeploy it, then hand you the operating system for it.

Each case describes the business and its model as they stood during the period the case draws on; a company’s subsequent history is its own. The cases on this page draw on Chitrangana’s professional work and study, carried out directly or with partner firms, with the working record held in confidence. Brand names and trademarks belong to their respective owners; their appearance does not imply endorsement, affiliation, or partnership.