AI Receptionists for GP Practices: A Four-Week Trial and Stop Rules

A GP practice should trial an AI receptionist for four weeks, starting only after a data protection impact assessment, and track four weekly measures: abandoned calls, hand-offs to staff, complaints and missed urgent calls. It should stop the trial at once on any missed urgent call, and pause it when agreed thresholds on complaints or hand-offs are crossed.

The unusual part is the order. Most practices decide on the tool, then wonder how to measure it. Here the stop rules come first, are written down and signed before the first live call, and the trial's job is to give the partners a defensible yes, no or "not yet" at the end of week four. Everything else follows from that.

Follow me on Instagram@sagnikteaches

Before week one: the assessment and the paperwork

A trial involving patient calls is not a small experiment. Calls contain names, symptoms, medication names and sometimes information about third parties, and the AI vendor becomes a processor of that data. A data protection impact assessment (DPIA) is the structured way to decide whether and how to proceed. Data-protection law such as the GDPR requires one before processing that is likely to be high risk starts, and it names large-scale processing of health data as one such case; your data protection lead decides whether your trial meets that bar, but for patient calls the safe assumption is that it does. Do it before any live call, not in parallel. The tutorial on whether you need a DPIA for AI tools explains when one is needed, and the worked DPIA example for an AI receptionist shows what a completed one looks like.

Connect on LinkedInSagnik Bhattacharya

For the trial, the assessment should answer at least these, in writing:

Subscribe on YouTube@sagnikteaches

• What the AI hears and records, where it is stored, for how long, and who at the vendor can access it.
• Whether the vendor uses calls to train its models, and how you confirm it does not.
• The legal basis for processing and what patients are told.
• What the AI is not allowed to do (the scope), and how that is enforced.
• How you delete data at the end if the trial stops.
• Who is accountable for each risk, by name.

Also write the scope in one page. In a trial, a narrow scope is a strength: the AI handles opening hours, directions, repeat-prescription ordering status as a message-taking step, appointment-type booking where rules are simple, and message-taking for the practice. It does not give clinical advice, does not triage, and does not decide urgency. The call scripts and escalation tutorial covers writing those boundaries into a prompt.

The four weekly measures, defined so two people count alike

Vague measures produce arguments at the review. Define each in a sentence, state the data source and name the person who counts it.

Two additions keep the picture honest. First, keep a baseline: count the same four measures for the four weeks before the trial from your phone records, so you compare like with like. Second, add a free-text column that staff fill in each day: "calls I would have handled differently". The counts show what happened; the notes show what staff feel, and in a trial with patients' health information involved, both matter.

Stop rules, written before the first call

There are two kinds. A hard stop ends the trial the same day. A pause stops live use while you investigate, with a defined way back.

An illustrative set that a practice might adopt, to be changed to suit its own risk appetite and clinical advice:

• Hard stop: any missed urgent call, meaning a caller who used urgent wording and was not routed to a human or the emergency advice. The clinical lead reviews, and the trial restarts only by a written decision.
• Hard stop: the AI gives clinical advice, states a diagnosis, or reassures a caller about symptoms.
• Hard stop: a data incident at the vendor or any evidence the AI recorded or sent data outside the DPIA.
• Pause: abandoned calls higher than the baseline by more than three percentage points for two consecutive days.
• Pause: two or more complaints in a week that name the AI.
• Pause: unplanned hand-offs above 25 per cent of AI-answered calls in a week.
• Pause: any caller who could not reach a human after asking for one.

Each of those numbers is a placeholder; the exact thresholds matter less than having them, agreeing them in advance and writing down who has the authority to switch the system off. Give that authority to at least two people, so one person's holiday does not leave the AI running.

The switch-off itself needs to be tested. Before go-live, practise it: one named person turns off the AI routing and calls revert to the normal phone flow. Time it. If it takes more than a few minutes, fix that first.

Week by week, with an illustrative practice

Take an illustrative practice with 6,500 registered patients, 14 staff and around 400 inbound calls on a typical day, with a sharp peak between 8:00 and 9:30. Those figures are made up for the example; replace them with your own. In the baseline month, say 22 per cent of calls at the morning peak were abandoned, and the practice wants to see whether an AI can cut that without losing safety.

Week 1: shadow mode, no patient hears it

The AI listens to a copy of calls, or to a sample, and writes what it would have done. No patient is affected. Staff compare drafts against real outcomes. The point is to find what the AI misunderstands: accents, names of medicines, a patient who rings about a relative. Shadow listening still sends real patient audio to the vendor, so it must be covered by the DPIA and the patient notice like live use. The week 1 target is learning, not scores. Write down every error and fix the prompt or the scope.

Week 2: out-of-hours and overflow only

The AI takes calls when the lines are busy or the practice is closed, with the emergency wording at the start of the out-of-hours message. For the closed period, the practice's existing out-of-hours arrangement stays in place and the AI adds only a message-taking layer. Read every transcript of a call where urgent wording was flagged. In the illustration, 190 calls a day overflow at the peak, and the AI answers around 120 of them.

Week 3: the morning peak with a human fallback

The AI takes calls at the 8:00 peak, with every call offering "press 1 or say 'person' to speak to someone". Watch the unplanned hand-off count closely. In the illustration, it lands at 18 per cent in the first three days and is fixed to 12 per cent after two prompt changes.

Week 4: steady state and the decision pack

No changes this week. Freeze the prompt and the scope. The trial now measures the system as it would run in practice. On Friday the practice manager compiles the decision pack: the four measures for each week against the baseline, every complaint, every transcript of an urgent call, and the staff notes.

A scoring sheet for the weekly review

Hold a 30-minute review every Friday, attended by the practice manager, the reception lead and the clinical lead. The same sheet each week prevents the conversation drifting.

WEEK 3 REVIEW (illustrative)
Calls handled by AI: 1,140     Baseline equivalent: n/a
Abandoned calls, 8:00-9:30: 14%   (baseline 22%)     OK
Planned hand-offs: 31%            Unplanned: 12%      OK (limit 25%)
Complaints naming the AI: 1       (limit 2)           OK
Urgent-wording calls: 9           Routed correctly: 9 Missed: 0
Calls where caller asked for a person: 74   Reached one: 74
Staff notes: 6 calls handled differently (see log)
Decision: continue to week 4. Prompt frozen after Monday.

If any line hits a stop rule, the sheet says so in capitals and the review becomes an incident meeting. Keep these sheets; the four of them, plus the decision, are the practice's evidence that it ran a controlled trial.

Reading the transcripts of urgent calls

The missed-urgent-call measure cannot be counted automatically; someone must read. Review every call the system flagged as having urgent wording, and a random sample of 20 unflagged calls a week, because the flagging may miss some. Ask three questions of each transcript. Did urgent wording appear? Did the AI give the emergency advice and reach a person within the target? Did anything the AI said sound like reassurance or advice?

A realistic mistake looks like this. A caller says, "my dad's got a pain in his chest but he says he's fine, can I get an appointment for next week?" A tired script reads "appointment" as the intent and offers a slot. A good rule treats the chest pain as urgent wording whatever else is said, gives the emergency advice and hands off to staff. This example is why the sample of unflagged calls matters: a flagging rule built on keywords may not catch the phrase.

Three smaller examples from the trial log

A repeat-prescription call. The patient asks whether their repeat is ready. The AI cannot check the clinical system, and the scope says so. The correct behaviour: take the patient's name, date of birth and the medicine name, state that staff will check and call back, and log it as a planned hand-off. The failure to look for is any statement such as "it should be ready by Friday".

A carer calling for a relative. The AI may give general information such as opening times but must not confirm whether a person is registered or discuss any record. A script line: "I can't discuss any patient's details on this line, but I can take a message for the team."

A caller who cannot be understood. A patient with a strong accent or a poor line gets asked to repeat three times. The rule: after two failures, offer a person. In week 2 of the illustration, 11 calls hit this; four of the 11 hung up before a person could answer. That pattern justified a tighter rule, "after one failure, offer a person", and the abandoned-call figure improved.

Calls to keep out of the trial altogether

A trial is safer when some calls never reach the AI. Decide the exclusions now, and enforce them in the phone menu rather than relying on the prompt. A sensible starting list: anyone pressing the option for a test result, anyone who says they are calling about a child under a set age, anyone calling from a care home or another health service, and any number on a safeguarding or vulnerable-patient list the practice maintains. Those calls go straight to staff.

The exclusions cost something, and that should be visible. Say these routes carry about 15 per cent of calls in the illustration, so the AI can improve the abandoned-call rate only on the remaining 85 per cent. That caps the possible gain, and it is a cap the partners should accept in return for a lower risk.

Cost and contract for a four-week trial

Price the trial as a whole, not per minute. Add the vendor's fees, any set-up charge, the phone-system change, staff time and the cost of the DPIA work. In an illustration, a practice might spend 30 hours of management time on the assessment and scope, 12 hours a week of review time across three people, and a modest monthly vendor fee. The staff time usually dwarfs the software cost. Count it anyway: if the trial succeeds, that review time falls sharply after week four, and if it fails, the practice should know what the lesson cost.

Keep the contract short: monthly, cancellable, with data deletion on exit. For longer-term costs, the tutorial on AI answering service costs for doctors sets out what ongoing use tends to involve.

Judging the trial on the wrong number

The commonest error is declaring success on the share of calls the AI "handled". That figure rewards an AI that keeps callers talking and penalises one that correctly hands over. A quick sum shows why. If the AI handles 70 per cent of calls but the unplanned hand-off rate is 30 per cent and complaints doubled, the practice has not saved time; it has moved work to the end of the call and made patients wait twice. The measures in this plan are chosen so that handling a call badly looks like what it is.

A second mistake is trusting the vendor's dashboard. Its definitions of "resolved" and "handled" are the vendor's, not yours. Use the phone system's log for abandoned calls, your own complaints log and your own reading of transcripts. Use the dashboard for convenience, never for the decision.

What the vendor must give you, in writing

A trial is a contract in miniature. Before it starts, get answers to these from the vendor, in writing and dated:

1. Where call audio and transcripts are stored and processed.
2. Retention period, and how and when they are deleted at the end of the trial.
3. Whether any data is used to train or improve models.
4. Who at the vendor can access recordings, and under what controls.
5. How the vendor tells you about incidents, and how fast.
6. What changes can be made to the underlying model without notice, and how you will be told.
7. An export of all logs and transcripts at your request.
8. The cost of the trial, and any minimum term that outlasts it.

The last point is often overlooked: a vendor that insists on a twelve-month contract for a four-week trial is not offering a trial. Negotiate a monthly term for the trial, or walk away.

The decision at the end of week four

The decision pack should lead to one of four outcomes, written as options before the review.

Most practices should expect "adopt narrowly" or "extend". A trial that ends with "adopt and widen" after four weeks should be double-checked: was the sample large enough, did anyone read the transcripts, and were the thresholds tight enough? For the longer view of return, the 90-day return tutorial covers what to count once you are live, and the after-hours call rules tutorial goes deeper on the closed-hours scope that many practices adopt first.

What to tell patients and staff

Patients: say at the start of every call that they are speaking to an AI, add a line to the website and phone message, and make a person available on request throughout. Avoid long explanations on the line; put detail on the website.

Staff: explain the scope, show them a few transcripts, say plainly that the trial is not a test of whether they are needed, and give them the right to log concerns without justification. Reception teams are the best source of failures the counts miss. In practice, staff who feel the trial is being done to them tend to stop reporting problems.

If you keep the trial honest, the output is a clear decision on paper: what the AI may do, what it may not, and the numbers that justified the choice. That is worth having whichever way the decision goes.

Questions a practice manager will be asked about the trial

Why four weeks and not a longer trial?

Four weeks covers four Monday peaks, often a public holiday or similar disruption, and enough calls to see patterns. A shorter trial misses rare failures. A longer one without stop rules drifts into permanent use without a decision. You can extend it, but only through a written decision at the end of week four.

Who should sign off the stop rules?

The partners or practice owners, the practice manager and whoever acts as the data protection lead. Agree them in writing before the first live call. Rules written after a bad week tend to be softer than rules written before one.

Do patients need to be told about the trial?

Yes. Tell callers at the start of every call that they are speaking to an AI, add a line to the website and phone message, and keep a route to a person on every call. Whether further notice is needed depends on your data protection assessment.

What if the numbers look good but staff are uneasy?

Treat the unease as a measure. Ask staff to log each call they would have handled differently and why. A pattern in those notes often finds failures the counts miss, and a trial that staff distrust will not survive rollout however good the dashboard looks.

Further reads

• AI Platform for Doctors: One Suite or Separate Scribe and Phone Tools? — One suite or separate scribe and phone tools.
• AI Receptionist vs Front Desk Hire: A Dental Practice Comparison — A front-desk hire compared with an AI receptionist.
• How a Small Clinic Can Use AI at the Front Desk Safely — How a small clinic can use AI at the front desk safely.
• AI Chatbot for a Doctor's Website: Scope, Disclosure, Handover — Scope and hand-over for a patient-facing chatbot.
• What to Do When an AI Receptionist Gets a Booking Wrong — Recovering when a booking goes wrong.
• AI Receptionist or Answering Service for a Booking-Based Business? — Whether a human answering service still suits you better.
• AI for GP Reception: Signposting Scripts and Role-Play Training — Build a bank of reception call scenarios from de-identified themes, then practise signposting and difficult calls with an AI caller.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: the data protection impact assessment requirement in the GDPR (Article 35, checked 4 November 2026). No vendor is named. Thresholds and figures in the examples are illustrative and should be set by the practice's own clinical and data protection leads.