Companion & communication
Appointment-request router
The practice phone rings for the fifth time this hour, while reception has three patients waiting at the desk. This call is about a prescription, the one before was an acute case, and the one before that just wanted to know if the practice is taking new patients.
You'll get …
- 1
A quieter practice phone
Appointments, prescriptions and referrals arrive in writing, ready to process – the phone stays free for the cases that need a person.
- 2
Requests that arrive ready to process
Reception works through a list instead of one call after another – with the details it needs to get back to people.
- 3
Acute cases always go to the phone
For anything medically urgent, the router shows the phone number, and 112 in an emergency – never a form.
01Intro
The appointment-request router sorts these requests before they reach the phone: two or three questions on the website establish what it's about – acute or routine, existing or new patient, appointment, prescription or referral. For anything medically urgent, the router makes the phone number impossible to miss (and 112 in an emergency), while admin requests arrive in writing, ready to process. For the practice, that means the phone is free for the cases that need a person.
The router replaces neither an appointment booking system nor a medical assessment – that's what Doctolib and the like, and the doctor's judgement, are for. It structures requests and points the way. For symptoms and acute cases, it always leads to a person (phone, out-of-hours service, emergency number). And patient data is only collected with a data protection concept and consent.
02How it works
- 01
Map your requests
What comes in by phone – appointments, prescriptions, referrals, admin, acute cases? Which paths exist for them, and where is the pressure greatest? That gives us the map the router works from – with the urgency check at the very top.
- 02
Find the deciding questions
Two or three are usually enough: how urgent, what kind of request, existing or new patient? Worded the way patients talk – and so that anything acute leads straight to a phone call, never to a form.
- 03
Build the flow and embed it
The router becomes part of the practice website – in the practice's design, mobile first. It sits where patients arrive: home page, contact, services.
- 04
Connect the end points
Every outcome leads somewhere: appointment requests go to the team in a structured format, prescription and referral requests arrive ready to process, acute cases go to the phone, emergencies to 112. No path is a dead end.
- 05
Observe and refine
After a few weeks you can see where patients still call or drop out. We then adjust the questions and paths – and the router takes more pressure off reception every week.
03Stages
The router is one of the most rewarding places to start. Tier 1 needs no AI and takes pressure off the practice phone straight away.
Starter: the guided path
A rule-based flow with fixed questions and clear branches – with the urgency rule at the very top. Reliable, quick to build, noticeable from day one.
Next step: it understands free text
Patients can describe what they need in their own words – an AI works out the request and drops them into the flow at the right point. The branching stays rule-based, and anything acute always leads to a person.
Full build: deeply connected
The router hands requests over in a structured format to reception or an existing appointment system and shows you in a report what patients need most often – without making bookings itself.
04Try it yourself
You'd like an appointment at the fictional “Dr Winter Practice”. Instead of a phone queue: two questions – and your request lands prepared in the right place. Try different paths through.
No magic: behind it is a switch – questions with clear branches. That's exactly why Tier 1 is so reliable: no AI that could guess. Only when visitors are meant to phrase things freely (Tier 2) does a language model classify the entry point – the switches stay.
Play a path through in the “try it out” tab – it lights up here.
05Technical implementation
- The router lives on the practice website – no external widget window, no third-party branding.
- Tier 1 is a decision tree with a fixed urgency check: acute cases and emergencies are never routed to a form, but clearly to the phone or emergency number.
- From Tier 2, a language model interprets requests in the patient's own words – the branching behind it stays rule-based and predictable.
- No appointment booking and no medical assessment – the router structures and directs; no model takes on those tasks.
- Handovers as needed: a structured message to reception, a connection to an existing appointment system, a prescription or referral form.
- Patient data only with a data protection concept and consent; data stored on EU servers.
for context · This shows how something like this usually gets built – not how it has to be built for you. What actually fits is worked out in the project: around your existing setup, your team, and what stays easy to maintain.