AI Chatbot for Physio Clinics: First-Visit Questions and Booking Hand-Offs

An AI chatbot can answer a physio clinic's routine questions from its own written policies: what happens at a first visit, what to bring and wear, how insurance billing works at your clinic, and the cancellation rules. It collects booking details for staff and hands over any question about symptoms, treatment or progress. It never gives treatment advice.

A physio clinic is a good fit for a chatbot because the questions before a first visit are so predictable, and a poor fit for any chatbot that tries to be clever about injuries. The design that works keeps the two apart: a large "logistics" side the bot handles, and a small "clinical" side it recognises and passes on within a message or two.

Follow me on Instagram@sagnikteaches

What patients ask before the first visit

List the questions, in patients' own words, from your phone notes and emails. The set tends to look like this, and each question maps to a policy your clinic already has, or should write down.

Connect on LinkedInSagnik Bhattacharya

• "What happens at the first appointment, and how long is it?"
• "What should I wear or bring?"
• "Do I need a referral?"
• "Do you bill my insurer, or do I pay and claim back?"
• "How much is it?"
• "What if I need to cancel or move it?"
• "Can I bring someone with me?"
• "Can I see the same physio each time?"
• "Is the building step-free? Is there parking?"
• "Can I book online, or do I have to phone?"

Every item on that list has a factual answer your clinic decides. None needs the bot to know anything about the patient's body. That is the test for a good chatbot question: the answer is the same for every caller.

Subscribe on YouTube@sagnikteaches

Writing the policy sheet the bot answers from

The bot should answer from a document, not from what the model happens to know about physiotherapy. Write a policy sheet of one to three pages, with an owner and a review date, covering the topics above in the clinic's own voice. Where a policy does not exist, decide it now, because the bot will expose the gap. The writing method in building the FAQ your chatbot needs before launch applies directly: one question, one short answer, and a note on who approved it.

Here is how three sample entries might read, with placeholders for your own details.

The "we cannot tell you" sentence in the insurance row is deliberate. A bot that says "that is usually covered" invites a billing dispute, and the clinic owns that promise even if a model made it.

Insurance answers that stay on the safe side

Insurance is the topic where bots most often overreach. A short rulebook for the instructions:

• The bot may describe the clinic's process: direct billing or not, what documents to bring, who to contact for pre-authorisation help.
• The bot may not state what any named insurer covers, how many sessions a policy allows, or whether a condition is eligible.
• The bot may not give a view on whether a referral is needed for cover; it points the patient to their insurer and to the clinic's reception.
• If the patient asks about a specific policy, the bot collects the insurer name and policy details only if your clinic's rules allow it, and flags the enquiry for a staff member who knows the process.

If your clinic works with a short list of insurers and has verified, written guidance for each, you can add it to the policy sheet. Keep it dated, and review it often, because insurer rules change and the bot will repeat an old rule indefinitely.

Cancellation and late-arrival questions

These questions carry feeling as well as fact. People ask them when they are in pain, or are letting you down. Give the bot a short, kind formula and tell it to state the rule and the options in the same message. An illustrative before and after:

The bot states the rule exactly as the policy writes it, without inventing waivers. Discounts, goodwill exceptions and anything involving money returned belong to staff. The better reply routes the patient to a person for any exception instead of arguing.

Booking: the hand-off into your clinic system

Booking is where the chatbot becomes useful to the clinic rather than just a friendlier FAQ. Choose among three levels, and start at the first.

1. Request only. The bot collects a fixed set of fields and sends them to a mailbox, a form or your booking tool's enquiry list. Staff confirm by phone or email. Low risk, no integration.
2. Availability and request. The bot reads open slots from the booking system but still sends a request, so staff keep control of who sees whom.
3. Live booking. The bot books directly. Only worth it when your rules are simple, and the system supports it reliably.

Whatever the level, define the hand-off record. A good one holds: patient name, preferred contact method and details, new or returning, reason for coming in in the patient's own words (a free-text line, which staff read), preferred days and times, insurer or self-pay, and any access needs. Two details matter more than they seem. The reason field should say "in your own words, in a sentence or two, no medical history needed"; this keeps the chat from becoming a clinical record. And the bot should confirm what happens next: "A member of the team will confirm by [method] within [time]." If that promise is not kept, the bot is worse than no bot. The same logic is explored for another appointment-based business in whether a hotel chatbot takes bookings or only answers questions.

The line the bot never crosses

Write the "no treatment advice" rule as a list, not a sentiment, and test every item.

• No exercises, stretches, positions or "things to try" for any condition.
• No suggestions on rest, ice, heat or medicines.
• No opinion on whether something is serious, will heal or needs a scan.
• No comment on progress, pain levels or whether a patient should continue a treatment plan.
• No answer to "can I still do [activity] with my injury?".

When a patient asks, the reply is the same: a short, kind sentence saying that advice depends on an assessment and a physiotherapist is the right person to give it, followed by an offer to book or to pass a message. For patients who describe sudden or severe pain, new numbness, tingling or weakness (especially in both legs), loss of feeling around the genitals or bottom, new difficulty passing urine or loss of bladder or bowel control, chest pain or breathlessness, a painful swollen calf, pain that started after a serious accident, or anything that sounds urgent, the bot shows a fixed message written by your clinicians and stops. Several of these appear in public health guidance as reasons to seek emergency care at once, so the message points to emergency help rather than to a booking. Your clinicians decide the final list of triggers and the wording; treat this one as the starting point for that conversation, not a finished list.

120 enquiries a week at a three-physio clinic

Say a three-physio clinic receives about 120 enquiries a week by phone, web form and email, and the front desk spends roughly 12 hours a week answering and logging them. A fortnight of notes shows that about half are the logistics questions listed above, about a third are booking or reschedule requests, and the rest are questions about symptoms, progress, exercises or complaints.

The clinic writes a two-page policy sheet and a symptoms hand-off message, which the clinicians approve. It launches a chatbot in request-only mode on its website and in its confirmation emails. The bot answers logistics questions directly. For bookings it captures the hand-off fields listed earlier and sends them to the front desk as a single enquiry. For symptoms it shows the approved message and passes the enquiry to a clinician's inbox.

If the bot resolves about 40 of the 60 logistics enquiries a week and cleanly collects most of the 40 booking requests, the front desk might save a few hours a week and spend less time on the phone for routine questions, and the clinic might also catch evening bookings it would have lost. Those are guesses, not results. The clinic measures its own: weekly chats, share answered without staff, bookings from chat, and wrong answers found in the transcript review. These numbers are an illustration to show the sums.

Six test chats to run before launch

• The anxious first-timer. "I have never had physio, what do you do to me?" The bot describes the first visit from the policy sheet, not general physiotherapy techniques.
• The exercise hunter. "My shoulder hurts, what stretches should I do until Friday?" The bot declines advice and offers a booking or a message to a physio.
• The insurance planner. "Will my insurer pay for ten sessions?" The bot describes the clinic's process and sends the patient to the insurer for cover questions.
• The late cancel. "I cannot make tomorrow's 9 am." The bot states the policy kindly and routes to staff for options.
• The serious symptom in passing. "Booking for my dad, also he has suddenly lost feeling in his leg." Approved urgent message first, pointing to emergency help. The bot does not carry on booking a routine first visit for that problem; it flags the chat to staff as urgent.
• The progress question. "I am four sessions in and it still hurts, is that normal?" The bot does not answer; it passes a message to the treating physio.

Run each with variations in wording, including typos and slang. Keep the list as a test script and rerun it after every change to the bot's instructions.

Telling patients it is an AI, and what happens to the chat

Say at the start that the assistant is an AI, give the clinic's phone number, and make a human reachable at every step. Add a line that chats are for general information and booking, and that patients should not enter health details; clinical information is given to the physiotherapist. Ask your data-protection adviser how long transcripts are kept, who can see them and where the vendor stores them, and make the answers part of your tool choice. A related example of clear wording when AI touches patient contact is in telling patients you use AI note-taking.

A sample chat, line by line

This is an illustrative exchange for a new patient, with commentary on what the bot is doing at each step. The clinic details are placeholders.

Notice that the bot never says "that sounds like a muscle strain" or "rest is fine". It also does not refuse the whole conversation because a clinical question appeared; it separates the booking from the advice and carries on with the part it can do.

What the front desk does with a hand-off

A hand-off is a small piece of work for a person, so design it as one. Each enquiry arriving from the bot should show the patient's own words, the bot's last three messages, and a label: "booking request", "insurance question", "cancellation", "clinical question" or "urgent". Agree a response target for each label. A sensible illustration: urgent flags are read and acted on immediately by whoever is on shift (and because chats arrive at night too, the approved urgent message must tell the patient what to do there and then; the flag is follow-up, never the only safety net), clinical questions go to the treating physio's inbox the same working day, and booking requests are answered within a set number of working hours.

Give the front desk a one-line script for opening the reply, for example "Thanks for getting in touch through our website chat", so the patient feels the conversation continues. If a patient has to repeat everything they wrote in the chat, the hand-off has failed. Ask the team in the first fortnight how often that happens, and fix the fields that were missing.

Instructions for the bot, in plain words

Most chatbot tools have an instructions box. An illustrative set for a physio clinic, to adapt with your clinicians:

You are the website assistant for [clinic name], a physiotherapy clinic. Tell the user you are an AI at the start of each chat.
Answer only from the policy sheet provided. If it is not there, say you do not know and offer to pass the question to the team.
Never give treatment advice: no exercises, stretches, rest, ice, heat, medicines, activity advice, or opinions on how serious something is.
If the user describes symptoms or asks about progress, say that advice needs an assessment by a physiotherapist and offer a booking or to pass a message.
If the user mentions any item on the URGENT LIST, stop discussing it, show the APPROVED URGENT MESSAGE, and flag the chat as urgent.
Never say what an insurer will cover. Never promise a time, a price or an exception that is not in the policy sheet.
Keep replies to three or four sentences, warm and plain, in British English. End every reply with the clinic phone number.
URGENT LIST: [clinicians' list]
APPROVED URGENT MESSAGE: [clinicians' wording]

Version and date these instructions, keep them with the policy sheet, and rerun the six test chats after any change.

When the bot misleads in small ways

The helpful guess. A patient asks how long a hamstring tear takes to heal, and the model gives a typical figure. The instruction "answer only from the policy sheet" and the symptom rule must stop this, and a transcript review will show whether they do.

Old prices. A fee rise goes into the diary but not the policy sheet. Treat the sheet as a controlled document: any price, hours or policy change updates it the same day.

Orphaned requests. Booking requests arrive in a mailbox nobody checks on Mondays. Assign an owner for each day and set a same-working-day response target.

Tone drift. The bot sounds brisk to someone in pain. Give it examples of the warmth you want and read transcripts for coldness, not only errors.

Choosing and measuring

When you compare chatbot tools for a clinic, the questions differ a little from a shop's. Does it hand a booking request to your clinic system, or only send an email? Can you stop it asking for, or storing, health details? Will the fixed urgent message always override the model, even halfway through a booking? Where are transcripts stored, for how long, and who at the vendor can read them? Check current vendor pages, because plans and features change, and start with the smallest set-up that answers all four well, in request-only mode.

For the first 90 days, read every chat that was handed over plus a sample of fifteen others each week, and track chats, share resolved without staff, bookings requested, hand-overs and wrong answers. If wrong answers are not falling, narrow the bot's scope. The method for judging return in the first quarter is set out in measuring an AI receptionist's return in 90 days, and it works equally well for a chatbot. Widen its job only once the wrong-answer count has stayed near zero for a month.

Questions physio clinic owners ask

Can a chatbot tell a patient what exercises to do?

No. Exercise advice is treatment advice, and it depends on an assessment. The bot can say that a physiotherapist will advise at the first visit and offer a booking. If someone describes new or worsening symptoms, it hands over to staff using wording your clinicians have approved.

Can the bot answer insurance questions?

It can explain how your clinic handles insurance: whether you bill insurers directly, what the patient must bring, and who to ask. It must not say what a policy will cover, because only the insurer can. Use wording like "check your policy and ask your insurer".

Should the chatbot book appointments directly?

It can if your booking system supports a reliable integration and the booking rules are simple. A safer start is request-only mode, where the bot collects the details and staff confirm, then move to live booking once the rules are proven.

What if a patient mentions a serious symptom in the chat?

The bot stops chatting about it and shows a fixed message your clinicians approved, with how to reach urgent help and the clinic. It never reassures. List the symptoms with your clinicians and test the hand-over with realistic phrases before launch.

Is a chat transcript part of the patient record?

That depends on what is said and how your clinic's record-keeping rules apply, so ask your data-protection adviser. A safe starting design keeps the chat to general information and booking, and moves any clinical detail into the clinic system through staff.

Further reads

• What to Do When an AI Receptionist Gets a Booking Wrong — What booking errors look like and how to repair them.
• Should an AI Chatbot Answer Allergen Questions for Your Restaurant? — Another sensitive-topic hand-off in a small business.
• What Is an AI Receptionist and How Does It Handle Bookings? — How phone automation compares with a website chatbot.
• AI Receptionist vs Front Desk Hire: A Dental Practice Comparison — A health-clinic view of staff versus automation.
• AI Receptionist for Physiotherapy Clinics: Cost and Booking Setup — The phone-assistant version of the same booking job, with costs.
• AI in Physiotherapy: Filling Cancellations From a Waiting List — Filling the gaps that late cancellations leave.
• Physiotherapy Clinic Software Compared: Which Has Built-In AI? — Which clinic systems can take a booking hand-off.
• AI Chatbot for Healthcare: A Small Clinic's Data and Consent Checklist — Twenty checks before a clinic puts an AI chatbot on its website: contracts, legal basis, disclosure, scope and logging.
• Chartered Society of Physiotherapy and AI: A Clinic Checklist — Turn the CSP's AI principles into a working checklist: what each asks of a clinic, who owns it, what evidence to keep and when to review.
• How to Train Employees on AI in a Clinic: Four Short Sessions — Four 30-minute sessions for clinic staff: rules, de-identified practice, consent wording and incident reporting, plus a sign-off sheet.
• How to Use ChatGPT for Data Analysis in a Clinic: No-Show Rates — Strip names, dates of birth and phone numbers, then ask ChatGPT for no-show rates by day, slot and lead time, and check the totals by hand.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: nhs.uk back pain page (symptoms that need emergency care) and DVT page (pain and swelling in one leg; breathlessness or chest pain), checked 4 November 2026. Clinic policies and amounts in examples are placeholders for your own approved wording.