Companion & communication

Appointment-request router

The practice phone rings – for the fifth time this hour, and the front desk has three patients at the counter at the same time. This call is a prescription question, the one before was an acute case, the one before that just wanted to know whether the practice takes new patients.

Inquiry router / offer finder

01Appointment-request router

The appointment-request router orders these concerns before they reach the phone: two or three questions on the website settle what it's about – acute or plannable, existing or new patient, appointment, prescription or referral – and everyone lands in the right place in a structured way. First and honestly: for anything medically urgent the router makes the call route unmistakably clear (and in an emergency, 112) – a form has no place there. The organisational side, by contrast, runs in writing and prepared, without a hold queue. For the practice that means: the phone frees up for the cases that really need a person.

Up front: 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 concerns and points the way. With symptoms and acute cases it always leads to a person (phone, on-call service, emergency line). And patient data is only collected with a data-protection concept and consent.

02Demo

simulation · fictional practice

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.

03How it works

  1. 01

    Sort out your concerns

    What actually lands on the phone – appointments, prescriptions, referrals, admin, acute cases? Which paths exist for them, where does the most pressure build? Out of that comes the map the router guides on – with the urgency switch at the very top.

  2. 02

    Find the separating questions

    Usually two or three are enough: how urgent, which concern, existing or new patient? Phrased the way patients speak – and so that anything acute leads straight to a call, never into a form.

  3. 03

    Build the flow and embed it

    The router becomes part of the practice website – in the practice's design, mobile first. At the points where patients arrive: home page, contact, services.

  4. 04

    Wire up the endings

    Every outcome leads somewhere: an appointment request structured to the team, a prescription/referral request prepared, anything acute to the phone, an emergency to 112. No path ends in nothing.

  5. 05

    Watch and sharpen

    After a few weeks it shows where patients still call or drop out. Then we adjust questions and paths – the router relieves the front desk more every week.

04Stages

The router is one of the most rewarding entry points: Tier 1 works without AI and relieves the practice phone right away.

Tier 1

Entry: the guided path

A rule-based flow with fixed questions and clear switches – with the urgency rule at the very top. Reliable, quickly built, felt at once.

Tier 2

Extended: it understands free text

Patients can describe their concern freely – an AI places it and joins the flow at the right point. The switches stay rule-based, anything acute always leads to a person.

Tier 3

Full build: deeply wired

The router hands over in a structured way to your front desk or an existing appointment system and delivers a read-out of what patients most often need – without booking itself.

05Technical implementation

  • The router lives in the practice website – no external widget window, no foreign branding.
  • Tier 1 is a decision tree with a fixed urgency switch: acute cases and emergencies are never routed into a form, but clearly to the phone or emergency line.
  • From Tier 2 a language model places freely described concerns – the switches behind it stay rule-based and predictable.
  • No appointment booking and no medical assessment – the router structures and directs, no model takes that on.
  • Handovers as needed: a structured message to the front desk, a connection to an existing appointment system, a prescription/referral form.
  • Patient data only with a data-protection concept and consent; data held 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.

06Related building blocks

See all levers for your practice