Playbook, healthtech app
Explaining how access works when the diary lives somewhere else
Booking questions on a health product are rarely about availability. They are about route: whether this person reaches the service through their employer, an insurer, a health service or directly, and whether they are eligible at all in the country they are in. That question decides everything downstream, it is entirely administrative, and it is the one an assistant can clear completely.
Why this is not the general answer
The handling pattern for appointment booking holds across every trade. What follows is the part that does not.
- The blocker is eligibility and route rather than availability, so the useful answer is about which door to use, not about what is free on Tuesday.
- It writes into no diary, and on a health product it also must not confirm that any appointment exists, because appointment existence is itself health information.
- A booking question sometimes carries urgency inside it, and urgency changes the answer completely from routing to signposting.
- Access routes vary by country and by scheme, so the correct reply usually starts by establishing which scheme rather than by answering.
How it arrives
- how do i book with a clinician
- my employer offers this, how do i get access
- can i change the appointment i already booked
- is there anything available today
- do i need a referral before booking
- can i choose which clinician i see
What has to be indexed for this to work
| Eligibility and access routes by country and scheme | Whether access comes through an employer, an insurer, a health service or directly, which countries are covered, any age conditions, and what somebody does when their organisation is not signed up. High volume, purely administrative, and completely safe to automate. |
|---|---|
| The booking and rescheduling path inside the product | The exact screens for booking, changing and cancelling, and who can do each. Naming the screen is the whole answer to a large share of these, and it requires no view of anybody's diary. |
| The cancellation and rescheduling policy | Notice periods, what happens to a missed appointment, and whether anything is charged. Publish the version you enforce, because it will be quoted back by somebody who then relies on it. |
| Crisis and urgent care signposting | The emergency number and the relevant crisis lines, worded as your clinical team approved them. It belongs in the fallback message itself so it appears immediately, because a booking question is one of the ways an urgent message arrives. |
The reply
How you book depends on the route you have access through, so if it is provided by your employer you register with the workplace code from their benefits page, whereas direct access starts from the sign up page and does not need a referral. Once you are registered, appointments are booked, changed and cancelled under Appointments in the app, with the notice period for changes set out in the policy. I cannot see or change any booking, and I do not discuss individual appointments at all. If you need help urgently rather than at a scheduled time, please use the urgent routes listed above now.
It sorts by route first, because the same booking question has two different answers depending on how the person reaches the service, and answering the wrong one wastes their afternoon. The statement that it does not discuss individual appointments is phrased as a category rather than as a failed lookup, since a search style denial is itself a disclosure on a health product. The closing signpost catches the case where a booking question was really an urgent one.
Where it stops
The trigger. The person cannot identify their access route, is asking about a booking they already have, or describes anything urgent.
Anything about an appointment you already have needs the team rather than me, since I have no access to bookings and do not discuss individual ones. Leave your name, your email and what you need, and somebody will pick it up. If this is urgent, please use the urgent contact routes shown above instead of waiting for a reply.
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
- Confirmation or denial that a named person has an appointment or is registered.
- That a particular slot, clinician or time is available.
- That a booking has been made, moved or cancelled.
- Anything that suggests waiting for an appointment when the message describes urgency.
Questions
- Can it book the appointment if we connect our calendar?
- It does not write into a diary. What it does is clear the questions that stop somebody booking, route them to the correct access path, and hand over when the request concerns a booking that already exists.
- Why can it not confirm somebody has an appointment?
- Because the fact that a named person has an appointment with a health service is health information in most data protection regimes, and it cannot verify who is typing. Even a denial can disclose, which is why the wording declines to discuss individuals as a category rather than reporting that nothing was found.
- What if a booking question is actually urgent?
- Then it stops being a booking question. Put the urgent routes into the fallback wording so they appear in the first reply, and set the caution level so an ambiguous message gets the serious reading rather than the administrative one.
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 appointment booking in generalIt cannot write into a calendar. The job is removing every reason not to book, then handing over with the details already gathered.
- Where a request should go depends on who is typing, and the widget cannot tellPatients, clinicians and buyers need three different destinations. How one question sorts them without the assistant claiming to know who is typing.
- 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.
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.