Playbook, healthtech app
Where a request should go depends on who is typing, and the widget cannot tell
On a health product the phrase can I speak to someone comes from three unrelated people with three unrelated needs. A member of the public wants help with access or has a question the assistant will not touch. A clinician wants to discuss a patient, which is legitimate and still impossible here. An organisation wants to talk about rolling the product out. Same words, three destinations, and no way to verify which one is typing.
Why this is not the general answer
The handling pattern for asking for a person holds across every trade. What follows is the part that does not.
- The destination changes entirely by requester, and the assistant has no means of establishing which of the three it is speaking to.
- One of the three branches has an urgent version, which must be signposted before anything else appears, including the sorting question itself.
- A clinician asking about their own patient is professionally legitimate and still cannot be served through a public widget, so the reply names the authenticated channel instead of refusing flatly.
- The organisational branch is the only one where a slower email route is genuinely the right answer rather than a compromise.
How it arrives
- can i speak to someone
- i am a gp and i need to discuss one of my patients
- who do i contact about rolling this out for our staff
- i need help right now
- is there a phone number for support
- can somebody from your team join our governance call
What has to be indexed for this to work
| Crisis and emergency signposting, in the fallback wording itself | The emergency number and the crisis lines for each country you operate in, worded by your clinical team. It goes into the message that is returned below the match threshold, so it appears in the first reply rather than depending on the right page being retrieved. |
|---|---|
| The authenticated channel for anything patient specific | Where a professional takes a question about an individual: the clinical portal, the named service line, or whatever route can actually verify them. Naming it turns a refusal into a redirection, which is what a clinician needs. |
| The route for organisations and clinical services | Who handles adoption, governance review and procurement conversations, and how they prefer to be reached. This branch is patient about timing and impatient about being sent to a general support queue. |
| What your own support route does and does not cover | So the assistant can be accurate about what happens after the handover. Vague reassurance about somebody being in touch is the fastest way to lose a professional's confidence in the whole product. |
The reply
If this is urgent, please use the emergency and crisis routes shown above now rather than waiting for a reply here. Otherwise it depends on who you are: questions about your own access or account go to the support team through the form, anything about an individual patient has to go through the clinical channel because I cannot verify who I am speaking to or discuss individuals at all, and organisations looking at rolling this out have a separate contact who handles governance and adoption. Tell me which of those fits and I will point you at the right one and take your details.
The urgent branch is handled before any sorting happens, because a person in difficulty must not have to read a routing explanation first. The sorting question asks what the person is trying to do rather than who they are, which gets the same result without the widget appearing to make a judgement about identity it cannot make. The clinician branch is given a reason and a destination in the same breath, which a professional accepts immediately, where a flat refusal reads as an obstruction.
Where it stops
The trigger. Any request for a person, sorted into patient support, the clinical channel, or the organisational route, with urgent signposting taking priority over all three.
If you need urgent help, please use the crisis and emergency routes above straight away. Otherwise, tell me whether this is about your own access, about an individual patient, or about your organisation adopting the product, and I will give you the right route and take your name and email so the right person picks it up.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Any patient details taken from a clinician into the chat, even when they offer them.
- Anything that delays a crisis or urgent route while the request is being sorted.
- Confirmation of anything about a named individual to somebody who says they are that person's clinician.
- Treatment of an urgent message as a routing problem rather than a signposting one.
Questions
- Why not just ask people to say who they are?
- Because the answer cannot be verified and asking makes it look as though it has been. Asking what the request is about gets to the same three routes without the assistant appearing to accept a claim about identity, which matters on a product where that claim would otherwise unlock something.
- A clinician will find this frustrating. Is there a better answer?
- Explain the reason, which is that the widget cannot establish who it is speaking to, and name the channel that can. Professionals understand verification constraints better than almost anybody. What loses them is a vague refusal with no route attached.
- Where should the crisis wording live?
- In the fallback message that is returned when nothing matches well enough, so it is present word for word rather than composed. Have your clinical team write the exact sentence, and set the caution level so an ambiguous message gets the serious reading.
Keep reading
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- Handling asking for a person in generalThe design question at the centre of a support assistant. Offer early, offer once, collect what a reply needs, promise a time you can keep.
- The identity check is against the record, not against an email addressContact details bound to a verified identity, and a parent account that transfers on a birthday. Access questions where a record sits behind the door.
- The reset email arrives and the sign in still failsRecovery codes, a second step and the phone the app trusts. Why nobody in a chat window can reissue a way in, and what can be explained.
- The plan price is not the price of being seenConsultation allowances, the plan that has none, and the medicine priced somewhere else. Publishing a health price so nobody is surprised twice.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.