Playbook, healthtech app
The one question where a fluent answer is the wrong one
An outage on most products costs people work. Here somebody may be sitting in a car park with a consultation ten minutes away, watching a screen that will not load. Nothing in the material an assistant reads changes at the moment a service breaks, so the only safe reply admits that and hands over a route that does not depend on the thing that is down.
Why this is not the general answer
The handling pattern for service outages holds across every trade. What follows is the part that does not.
- There is a booked slot behind a share of these messages, with a clock running on it, which is not true of an outage anywhere else, so the alternative route has to arrive inside the first reply.
- The website generally survives while the application does not, which leaves the assistant answering confidently from a page that works about a service that does not.
- A connected device that stopped sending during an incident leaves days missing, and somebody who notices that is asking about their record rather than about uptime.
- Some of these are not outages at all but one handset, one connection or one household, and since none of that can be told apart from here, nothing may be described as normal.
How it arrives
- the app will not load and my appointment is in ten minutes
- is the service down for everyone or just me
- my watch has not synced since yesterday
- the video consultation will not connect
- where do i check if you are having problems
- will i be charged if i miss the appointment because of this
What has to be indexed for this to work
| The status page, handed over rather than summarised | The address and what it covers. Anything the assistant describes was read on a schedule, and the reader needs the position now, so the correct behaviour is to point at the page rather than to report from it. |
|---|---|
| What to do when a consultation cannot start | The telephone route, the number, and whether the slot is held or rebooked. This document has to exist before an incident, because during one nobody is writing it. |
| The published position on a consultation missed because of a service problem | Whether a charge applies and how it is put right. Publish it, since the second message in any incident is always about money and answering it once ends that thread. |
| The urgent route, which must never depend on the product | Worded by your clinical team and reachable from somewhere that is not the application. If the only way to get help runs through the thing that is down, the material has a hole in it. |
The reply
I have no view of the service, so I cannot tell you whether anything is down at the moment. The status page shows the current position and lets you subscribe to updates [1]. If you have a consultation about to start and it will not connect, do not sit waiting on it: the telephone route, and what happens to the slot, are on our contact page [2]. Our published position on a consultation missed because of a service problem is on the same page. If this is urgent and you cannot reach anybody, please contact the emergency services rather than the app.
The limitation goes first, because every sentence after it would otherwise read as reassurance from a company that would know. The consultation line is written as an instruction rather than as information, since somebody with minutes left acts on the first thing that sounds like a next step. The closing line names the route that does not depend on any of this working.
Where it stops
The trigger. The visitor says a consultation will not start, asks when something will be fixed or what caused it, or reports missing data from a connected device.
I cannot see the state of the service, restore anything or say when it will be back. Use the telephone route on our contact page if a consultation is due to start, and leave your name, an email and the time it began if you want the team to look at your own case. If you need help urgently, contact the emergency services.
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
- Never say the service is running normally, unaffected or fine, because nothing here observes it.
- Never estimate when an incident will be resolved, or say what caused one.
- Never tell somebody to wait for a consultation to reconnect when a telephone route exists.
- Never treat missing data from a connected device as unimportant, since a gap in what was recorded is a gap in a record.
Questions
- Should we index the status page so it can answer this?
- No, point at it. Indexed material is read on a schedule, so during an incident the assistant would quote a page that changed twenty minutes ago and attach a citation making the answer look authoritative.
- Will it keep answering while our app is down?
- Yes, because it sits on your site and reads documents rather than the application. That is useful only if it is configured to say clearly that it cannot see the service, which is the wording this page exists to get right.
- What is the single most valuable thing to publish here?
- The telephone route for a consultation that will not start. During an incident that is most of your volume, and it is the one answer where being ten seconds faster genuinely matters to somebody.
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 service outages in generalThe assistant knows nothing about an incident unless your material says so. A status page it can read is the fix, and reassurance is the trap.
- It is a support question until somebody describes how they feelTwo ordinary faults on a health product, and the line where a message stops being technical the moment a symptom turns up in it.
- Most of what blocks a new account has nothing to do with the appEligibility by country and by age, the access code from a sponsor, and the questions asked at sign up. What a first afternoon really runs into.
- The message that has to leave this channel immediatelyTwo routes, one about the software and one about the clinician, with different reviewers and different clocks. How to sort them in one reply.
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.