Write Your Call Handling Rules Before You Automate Anything

Practices evaluate this category in the wrong order. They watch demos, compare voices, and then discover during onboarding that nobody at the practice has ever written down what should happen when a patient calls with a complication at 9pm. The vendor asks, and the answer gets invented in a configuration screen by whoever happened to be on the call.

That is a bad place to make a clinical policy decision. It is being made under time pressure, by the wrong person, inside a tool that shapes what answers are easy to express.

This guide produces one document instead. Eight lessons, roughly 2 hours, and it is useful whether or not you buy anything, because the same document trains a new receptionist and settles arguments that currently get settled differently by whoever is on shift.

Why the rules come before the tool#

A configuration screen is a set of answers to questions someone else chose. Writing your rules first means you arrive with your own questions, which changes what you notice in a demo and makes the difference between vendors visible in a way a feature list never will.

There is a second reason and it is the more important one. Roughly 80% of what a front office handles is genuinely routine, and the remaining fraction is where all the risk lives. A document that only describes the routine part has documented the easy thing.

The lessons below spend most of their time on the fraction that is not routine, because that is the part your practice has to own and no vendor can decide for you.

A vendor can tell you what their product is capable of. Only your practice can say what it is permitted to do.

01List every reason a patient actually calls you#

You cannot write rules for calls you have not enumerated, and memory is a poor source. The list people produce from memory is about 8 items long and the real one is closer to 25.

1. Ask whoever answers the phone to keep a tally sheet for 5 working days, one mark per call, adding a new row whenever a reason does not fit an existing one.
2. Do not pre-print the categories. The value is in the rows they add.
3. At the end of the week, count the rows and sort by frequency.
4. Separately, ask the same person for the 3 calls they least like receiving. Those are usually the ambiguous ones and they matter more than their frequency suggests.
5. Add anything seasonal that did not occur that week but does occur.

The output is a ranked list of real call reasons in your practice's own words. Keep the wording patients actually use, not the clinical term, because the wording is what any system will have to recognise.

Expect surprises in the tail. Most practices find at least 2 or 3 call types nobody in management knew were arriving regularly, and those are frequently the ones with no defined handling at all.

The tally also gives you something the rest of this guide needs: a rough call volume by hour. Mark the hour alongside each tally and you get, for free, the shape of your day. A practice discovering that 30% of its calls arrive in the 90 minutes after opening has learned something about staffing before it has learned anything about software.

One caution on the collection. Whoever is keeping the sheet will be tempted to tidy the categories as they go, merging two rows that feel similar. Ask them not to. Two call reasons that feel similar to an experienced receptionist frequently need different handling, and the merge destroys exactly the distinction lesson 2 is about to make.

02Sort them into what can wait and what cannot#

This is the lesson that requires a clinician and it is the reason this guide asks for 45 minutes of one. The sorting is a clinical judgement and it should not be made by whoever is configuring software.

Sort every row from lesson 1 into one of four bands:

The band boundaries are yours and they will not match another practice's. An aesthetics practice and a dental practice draw the immediate line in very different places, and both are correct for their own risk profile.

Two rules of thumb make this faster. Anything a patient describes with the words pain, bleeding, swelling, or breathing goes into immediate regardless of context. Anything you would be uncomfortable reading in a message queue the next morning is not routine.

Band the ambiguous ones deliberately rather than leaving them out. Every practice has 3 or 4 call reasons that genuinely could go either way, and those are the rows where the document earns its keep, because they are the ones currently handled differently depending on who picks up. Write the decision even if it feels arbitrary; a consistent arbitrary rule beats an inconsistent thoughtful one.

It is worth timing this. If the banding conversation takes longer than 45 minutes, you have found something worth discussing separately rather than something to resolve in the meeting, and the honest move is to park that row and mark it unbanded rather than force a decision the clinician is not comfortable making.

If you would not be comfortable finding it in a queue at 9am, it does not belong in the routine band.

03Write the escalation rule, including the failure path#

An escalation rule that only describes the happy path is not a rule. The useful version says what happens when the first person does not answer, which is the situation it exists for.

• Who is the first point of contact for an immediate call, by role rather than by name
• What number or channel reaches them, and whether it works at 2am
• What happens if they do not answer within a stated number of minutes
• Who is second, and what happens if they do not answer either
• The final fallback, which for most practices is a named emergency instruction to the patient
• Who reviews escalations weekly, and where they are logged

The third row is the one practices skip and the one that matters. "It reaches the on-call clinician" is not a rule until you have said what happens in the 10 minutes after the on-call clinician's phone is face down on a table.

Name roles rather than people. A rule naming a specific person is out of date the moment they take annual leave, and a document that is out of date in one place stops being trusted everywhere.

An escalation rule that does not say what happens at minute 10 is not a rule. It is a hope with a phone number attached.

Test the chain once before you rely on it, and test it at the time it is meant to work. An escalation path verified at 3pm on a Wednesday has verified almost nothing about 2am on a Sunday, which is when it exists to be used. The test takes 5 minutes and it routinely finds a number that rings a desk phone in an empty building.

04Decide what nothing is ever allowed to say#

This is the shortest lesson and the one with the most legal weight. It applies equally to a receptionist, an answering service, and any software, which is the point: it is a practice rule rather than a vendor setting.

• No clinical advice of any kind, including reassurance that something sounds minor
• No interpretation of symptoms, and no triage beyond routing to a band
• No confirmation that a named individual is a patient here
• No discussion of results, medications, or treatment history
• No pricing commitment that differs from your published pricing
• No promise of a specific appointment time that has not been confirmed

Row 1 is broader than it first reads and deliberately so. "That sounds normal after a treatment like that" is clinical advice given by a person with no clinical training and no view of the patient, and it is the single most common way a well-meaning front desk creates exposure.

Row 3 catches people out. Confirming that someone is a patient is itself a disclosure, and a caller asking whether a named person has an appointment is a request you should have a scripted refusal for.

Write the refusal itself, word for word, and put it in the document. "I am not able to confirm anything about who is or is not a patient here, but I can take a message" is a sentence somebody has to say under mild social pressure from a caller who sounds entirely reasonable, and a scripted version is far easier to deliver than an improvised one.

The hardest calls to refuse are the ones that sound completely reasonable. Script those refusals, do not rely on judgement under pressure.

The patient population supports drawing this line hard. Survey data has consistently found 81% of patients want a human for actual medical advice, which is the same boundary this lesson draws for a different reason [1].

The never-say list has a floor set by rule rather than by taste. 45 CFR 164.510 governs the disclosures a practice may make to family and others involved in a patient's care, and it turns on the patient having had an opportunity to agree or object [3]. A system taking calls cannot infer that opportunity, so anything relying on it belongs on the escalation path rather than in the script.

05Write the identity and disclosure rule#

Callers should know what they are talking to, and in some places that is not just good manners. Decide your position deliberately rather than inheriting a vendor's default.

1. Decide whether the system identifies itself as automated, and in what words.
2. Decide whether it uses a persona name, and if so write down that the name is a product convention and not a claim to be a person.
3. Decide what it says when a caller asks directly whether it is a person. The only defensible answer is a straight one.
4. Check your state law, because at least one state has specific requirements.
5. Write the disclosure sentence verbatim into the document, so every channel uses the same words.

California is the concrete example worth knowing. AB 3030, effective 1 January 2025, requires health facilities, clinics and physician practices to include a disclaimer when generative AI is used to communicate clinical information about a patient's health status, together with clear instructions for reaching a human [2].

The scoping matters as much as the requirement. Communications unrelated to clinical information, such as appointment scheduling or billing, are outside it, and communications reviewed by a licensed human provider before they go out are exempt [2]. A booking-only system is largely outside the rule and stops being outside it the moment it discusses a health status.

For audio, the disclaimer has to be given verbally at both the start and the end of the interaction [2]. That is a specific enough requirement that it should be in your document rather than in somebody's memory.

Step 3 deserves its own paragraph because it is where practices most often inherit a bad default. Some systems are configured to deflect the question, answering "I am here to help you book an appointment" when a caller asks whether they are speaking to a person. That is not a lie in the narrow sense and it reads as one to the caller, which is the only reading that matters. Decide on a straight answer and write it down.

The persona question in step 2 is worth 5 minutes of thought rather than 30 seconds. A named voice is easier for callers to refer to and it invites exactly the confusion step 3 has to resolve. Whatever you choose, the document should say in plain terms that the name is a product convention, so nobody downstream turns it into a marketing claim about a person who does not exist.

Disclosure is now something patients expect rather than a courtesy. Pew Research Center, polling 3,488 US adults in June 2026, found 72% said it was extremely or very important that a provider tell them when AI was used in their care, 56% wanted telling specifically about appointment scheduling, and 63% wanted more say in whether it was used at all [4]. Write the sentence the system says about itself into this document, not into a vendor's configuration screen where it can be edited without you.

06Define what "captured" actually means#

Every vendor says it captures the caller's details. Write down what your practice needs captured, because that list is what turns a message into something a person can act on without ringing back.

Reading the number back is not optional and it is worth making a hard requirement. A capture that gets the reason perfectly right and the number wrong has produced nothing at all, and the practice will never know the call happened.

Insist on the caller's own words for the reason. A summarised reason has already made an interpretive decision, and the interpretation is exactly the thing lesson 4 says nothing without clinical training should be making.

There is a difference between capturing and confirming that is worth writing into the document. Capturing is recording what the caller said. Confirming is repeating it back and getting agreement, and only the second one catches errors. A capture spec that does not say which fields are read back is not finished, and the 2 fields that always should be are the number and the reason.

Decide also what happens when a field cannot be captured. A caller who will not give a number, or who is calling on behalf of somebody else, is a normal occurrence rather than an edge case, and the document should say whether that produces a partial record or an escalation.

07Write the handoff, in the format the human wants#

The handoff is where most of the promised time saving is won or lost. A capture that arrives as prose in an inbox has moved work rather than removed it, which is the failure mode covered in what "the AI books the appointment" actually means.

1. Decide where a captured request lands, and pick one destination rather than three.
2. Specify the format as fields, not paragraphs, matching lesson 6 exactly.
3. Decide what happens to an immediate-band call in that destination, which should be different and visibly so.
4. Set a target time for a human to action a routine capture, and write the number down.
5. Decide who checks the destination and when, especially first thing and last thing.
6. Decide what happens to anything not actioned within the target.

Step 6 is the one that keeps a queue honest. Without a defined path for the ones that age, the destination becomes a place requests go rather than a place they get handled, which is how practices end up with a well-functioning capture system and unhappy patients.

A target of 1 working hour for routine captures during opening hours is a reasonable starting point for most practices, and the first thing you will learn is whether you currently meet it.

The destination choice in step 1 is more consequential than it looks. A shared inbox, a task list in the practice management system, and a messaging channel all work, and they fail differently: an inbox gets read by whoever is least busy, a task list gets read by whoever it is assigned to, and a channel gets read by everybody or nobody. Pick the one that matches how your practice actually distributes work, not the one the vendor demonstrates.

Whatever you pick, avoid having captures land in 2 places. A practice that sends everything to both an inbox and a channel has created ambiguity about which one is authoritative, and the predictable result is a request that both people assumed the other had handled.

08Set the failure behaviour explicitly#

Everything above describes a system that works. This lesson describes the 3 or 4 percent of calls where it does not, and it is the lesson that most distinguishes a considered deployment from a demo.

• What happens when the caller cannot be understood
• What happens when the caller asks something outside the defined scope
• What happens when the caller becomes distressed or angry
• What happens when the system itself is unavailable
• What the caller hears in each of those cases, written verbatim
• Whether a failed call is logged, and who looks at the log

Row 4 is regularly forgotten. Every system has downtime, and the practice needs a decided answer about whether calls fail over to voicemail, to a mobile, or to the old arrangement, before the day it happens rather than during it.

Row 6 is what turns failures into improvements. A failure log nobody reads is a cost with no return, and 20 minutes a week reading it is usually the highest-value 20 minutes in this entire guide.

Row 3 is the one people find hardest to write, because the honest rule is unsatisfying. A distressed caller needs a person, and the correct behaviour is a fast, unconditional route to one rather than a longer attempt to help. Any system that keeps trying with an upset caller is making the situation worse at a rate of about 15 seconds per attempt, and the document should say so in those terms so nobody tunes it in the other direction later.

Write the verbatim lines in row 5 rather than describing them. "I want to make sure a person hears this properly, let me put you through" is a sentence that either exists or does not, and reviewing it as text is the only way to notice that the version currently in use says something else entirely.

What to do with the document#

Give it to the vendor before the demo rather than after. A vendor who can walk through your bands, your prohibited responses, and your failure paths using their own product is showing you something real, and one who deflects to a roadmap has answered you clearly in a different way.

Then keep it. The document trains new front-desk staff, settles the arguments that currently get settled inconsistently, and is the thing you revise when something goes wrong rather than starting from a blank page under pressure.

Review it every 6 months and after any incident. The most common decay is lesson 1 going stale as a practice adds services, because a new treatment brings new call reasons and nobody thinks to re-band them. If you have not yet sized whether any of this is worth automating, size your missed-call gap is the exercise to run first, and the patient texting guide covers the equivalent rules for messages rather than calls.