Health-Tech
Writing for a Health-Tech Buying Committee
By Miracle Olajuyigbe 4 min read
Six people are going to decide whether your product gets bought. Possibly ten.
There is a clinician who will use it, or refuse to. A department head whose budget it comes from. A CMIO or IT lead who has to connect it to systems that were installed before some of your engineers were born. A security and compliance officer. Someone from procurement whose job is to find reasons to say no. And frequently a nurse manager, whose opinion is not on the org chart and will decide the outcome anyway.
Now look at your homepage. Which of them is it written for?
Almost always, the answer is one of them, and the rest are being asked to read something aimed at somebody else.
Why healthcare is worse than most
Enterprise software generally involves committees. Healthcare turns the dial up for three reasons.
Clinical veto is real. In most categories a sceptical end user is an adoption problem you manage later. In healthcare, a sceptical clinician can stop the purchase, and will, because patient safety is a legitimate and unanswerable reason to refuse.
The stakes make everyone conservative. Every person in the room is imagining the version of this that ends badly, because in healthcare the bad version involves a patient.
Nobody in the room owns the whole decision. Everyone can block. Almost nobody can approve alone.
Which produces the pattern anyone who has sold into hospitals knows: deals do not get won by one person loving you. They get lost by one person having an unanswered objection.
What each of them is actually asking
The clinician wants to know what happens on a bad shift. Not the accuracy figure. Whether this adds work, whether the alerts will be right often enough to be worth reading, and whether they can override it without writing a justification. They are also, quietly, checking whether you understand their job. One line implying you will replace them ends the conversation, and they will not tell you that it did.
The economic buyer wants a defensible case. Not “improves outcomes” but what specifically changes, by how much, over what period, measured how. They have been sold efficiency before and are wary.
The technical buyer wants to know what integration actually costs. Which standards, which version, read access or write access, what falls back to older messaging, and how much of their team’s time this consumes. Vague answers here read as either ignorance or evasion, and both are fatal.
Security and compliance want to know where data goes, who can see it, what happens in a breach, and whether your documentation exists. This person is looking for reasons to stop, and giving them a clean answer early is worth more than any feature.
Procurement wants comparability, references, and pricing that does not surprise them in year two.
The nurse manager wants to know whether this makes the ward’s day better or worse. Nobody asks them formally. They will be asked informally, and their answer carries.
Where content usually goes wrong
One page trying to serve everyone. It ends up abstract, because abstraction is the only register that offends nobody. “Transforming care delivery through intelligent insights” is what a page sounds like when it has been written for six audiences and revised until nothing specific survives. It serves none of them.
Everything aimed at the economic buyer. Understandable, since they sign. But they are usually the last person convinced, and they get convinced by the clinician telling them this is worth having.
Marketing language a clinician will not forgive. Revolutionary. Replacing radiologists. 99 percent accuracy quoted with no population. Each of those tells a clinical reader that nobody with clinical training reviewed the page, and they will extend that judgment to your product. This is the single most expensive category of error in health-tech content, and it happens constantly.
No answer to the obvious objection. Every product in this space has one. Alert fatigue. Integration burden. What happens when the model is wrong. Content that avoids it does not make it disappear, it just means the objection gets raised in a meeting you are not in.
What to build instead
Stop thinking about pages and start thinking about which person each asset is for.
A clinical page written by or with a clinician. How it fits the workflow, what it adds to a shift, what it gets wrong and how often, how to override it. Name the failure modes yourself. Nothing builds credibility with this audience faster than being the one to raise the limitation.
An economic page with a specific mechanism. Not “reduces costs” but the actual chain: this changes, which affects that, which shows up here. Show your working. Include the assumptions so they can argue with them, because they will anyway, and content that anticipates the argument survives it.
A technical page with real answers. Standards, versions, read versus write, integration timeline, what your API does not cover. Publishing your limitations here is a competitive advantage, because your competitor’s page says “fully interoperable” and the technical buyer has learned exactly what that means.
A security page that exists. Certifications, data flows, incident process. It does not have to be exciting.
One claims spine underneath all of it. This is the part teams skip. Every number, every capability claim, every comparison, in one internal document with its source and its evidence level. Everything public is written from that spine. It is how you stop the clinical page and the sales deck from making incompatible claims, which is the thing that destroys credibility fastest when someone notices.
The test
Take any page you have published. Ask which of the six people it was written for, and what they would do next after reading it.
If the answer is “everyone” and “become generally more positive,” you have written a page that moves nobody.
The strongest thing you can do in this market is unusual and slightly uncomfortable: be specific enough that some readers decide you are not for them. A committee that can tell exactly what you do, including what you do not, can make a decision. A committee that cannot will keep asking for more information, which is what “we’re still evaluating” has meant all along.