Companion & communication
Practice FAQ & first-contact assistant
When are you open? Do I need an appointment for a repeat prescription? Are you taking new patients? – Every question fair, every one answerable, and every one tying up the phone right now while real cases wait in the practice.
Website companion & knowledge chat
01Intro
The practice FAQ assistant answers the recurring organisational questions right on the website – around the clock, in the practice's tone: opening hours including holiday exceptions, prescription and referral processes, services, directions and parking, what new patients need to know. It relieves the front desk exactly where the most time is lost today. And it knows its limit clearly: the moment it's about symptoms, diagnoses or a medical assessment, it hands over at once and plainly to the team – with the right numbers, not with an answer it isn't allowed to give. The phone still rings after that, but for what really needs a person.
Straight up: the assistant gives no medical information – no symptom assessment, no diagnosis, no treatment advice. That limit is firmly anchored technically and in behaviour; with symptoms it always leads to a person or the emergency line. It needs a maintained knowledge base (opening hours that change quietly make it lose credibility), and patient data is not part of it.
02Demo
The assistant of the fictional “Dr Winter Practice”. Ask one of the three patient questions – and watch two things: where the answer comes from, and where the assistant deliberately hands over to the practice team.
The living example: Neo, the companion of this website, works exactly to this pattern – only with a real language model. Ask him in the bottom right.
The companion invents nothing: it answers from a curated knowledge base built from your content. And for anything that needs judgement or expertise, there's the built-in switch to a human.
The most important part is the least conspicuous: the maintained knowledge base on the left. It decides whether the companion is useful or merely polite.
03How it works
- 01
Gather the real patient questions
What does the front desk get asked daily, what's in the emails, what rings through on the phone? Out of this comes the list of questions the assistant must handle – and the clear list of ones it must never answer.
- 02
Build the knowledge base – without patient data
Opening hours with exceptions, prescription and referral routes, services, directions, new-patient info: the organisational practice knowledge gets structured. Patient data deliberately stays out.
- 03
Define tone and limits
How does the assistant speak, when does it refer to the team, and above all: where does it stop at once on anything medical? The handover rules are set before it says a word.
- 04
Embed it where patients are
The assistant becomes part of the website – mobile first, because that's where patients look up hours and processes. In the practice's design, not as a foreign widget.
- 05
Watch and sharpen
The conversations show what patients really ask – out of that come better answers, new FAQ entries and hints about what's missing on the website. The assistant relieves the front desk more every month.
04Stages
The entry point is deliberately limited – in a practice especially, the assistant has to be dependable and cleanly bounded above all.
Entry: the FAQ assistant
Curated knowledge on hours, prescription/referral processes and common organisational questions, tight guardrails, a clean handover to the team. Reliable rather than all-knowing.
Extended: first contact with handover
The assistant sorts concerns and hands them over in a structured way: an appointment request to the front desk, a prescription request prepared, anything medical to a person – as a usable message.
Full build: the thinking assistant
The assistant recommends the right page or form and prepares the contact – the model you're experiencing on this website right now, within the tight limits of a practice.
05Technical implementation
- At its core is a language model with the curated practice knowledge base as context – hours, processes, services; at typical volumes cached rather than run through a vector database.
- The medical limit is doubly anchored: as a behaviour rule in the prompt and as a topic switch in the back end – symptom and diagnosis questions always trigger the handover to a person, in an emergency the pointer to 112 / 116 117.
- The assistant runs as a component in the website with its own small back end; no foreign branding, no external widget window.
- Patient data is not part of the knowledge base; what's stored is set beforehand with a data-protection eye – data held on EU servers.
- Handovers to suit your process: a message to the front desk, a prescription/referral form, clearly visible phone numbers.
- Running costs stay manageable: a warm answer typically costs a few cents – that's measured, not guessed.
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.