# What to Hand Over Before Go-Live > An AI receptionist enforces your rules; it does not invent them. Here is the handover pack that turns setup into a transcription job instead of a series of guesses. **Author:** gethelpdesk-ai **Published:** 2026-09-20 **Category:** guides **Tags:** implementation, onboarding, pms, compliance, front-desk, dental-practice **Canonical:** https://gethelpdesk.ai/blog/what-to-hand-over-before-go-live/ --- ## The Short Version Setting up an AI receptionist is not a technical project. The integration is the easy part. The hard part is that the system needs your practice's actual operating rules written down, and most practices have never written them down. Every launch that goes badly goes badly in the same way: the vendor asks a question nobody at the practice can answer, somebody guesses, and the guess goes live. Every launch that goes well arrives with the answers already decided. This is the handover pack. Six sections. Assemble it before kickoff and your setup becomes a transcription job rather than a series of judgement calls made by a vendor who has never seen your operatory. ## 1. Your Scheduling Rules The single largest section, and the one practices most often discover they have drifted away from. **Appointment types and their real durations.** Not the durations in the system when it was installed. The ones your team actually uses, including the ones they have quietly been overriding for two years. **Provider hours, per provider.** Including the half-days, the alternating Fridays, and the one who does not do Mondays in summer. **Operatory routing.** Which procedures happen in which rooms, and which rooms are shared. **Block-outs and what they are for.** A block that exists to protect a lunch break and a block that exists to hold a hygiene slot until Wednesday are different rules, and a system that cannot tell them apart will book over one of them. **Provider-to-procedure matching.** Not every provider does every procedure. Write the exceptions down. **Which appointment types should never be booked by phone at all.** Post-operative visits, anything the dentist specifically sequenced, anything tied to a lab case. These are clinical decisions wearing a scheduling costume. If this section takes a week to assemble, that is not a delay. It is the audit finally happening. We have gone through why these particular rules are the ones that cause collisions in [can AI schedule without double-booking you](/blog/ai-scheduling-without-double-booking/). ## 2. Your Emergency Protocol Write down what happens when somebody calls in pain, in each of three windows: during opening hours, after hours, and on a closed day. Name the specific route. Forward to the on-call dentist's mobile? Send an urgent SMS to a named person? Read the caller a standing instruction and tell them to attend an emergency clinic? Practices frequently have a protocol that lives entirely in one long-serving team member's head, and it needs to exist in writing before anything automated touches it. Then define your escalation trigger in plain words. What does a caller have to say for this route to fire? "Pain" alone is too broad -- most callers mentioning pain want a normal appointment. Swelling, trauma, bleeding that will not stop, and a knocked-out tooth are usually the list. Decide yours. Give the after-hours contact and say explicitly whether it may be given to patients or only used internally. ## 3. Your Identity and Permission Policy This one is short and it prevents most of the awkward incidents. - **What proof does a caller need to give before hearing anything about an existing appointment?** Name plus date of birth is the usual bar. - **Who may cancel or move an appointment on somebody else's behalf?** A parent for a child, a spouse, an adult child for a parent -- decide which of these you accept. - **What may never be discussed on an inbound call, regardless of who is asking?** Clinical findings, treatment plans, balances, and anything in the record beyond appointment logistics is the common answer. Write down the exact refusal you want the caller to hear when the bar is not met. A polite scripted refusal and an offer to have the practice call back is a far better patient experience than an improvised one. ## 4. Your Practice Management System Access The technical section, and the shortest. Name the system and the exact version or edition -- the difference between a server product, a cloud product and an enterprise edition changes what is possible, and practices routinely tell a vendor the wrong one. If you are not certain, [check which Dentrix your practice runs](/blog/which-dentrix-does-your-practice-run/) or look at the login screen rather than the invoice. Then decide who at the practice owns the credentials, what access level the integration gets, and who is notified if it fails. GetHelpdesk.AI integrates with 16 practice management systems, and every one of them has a dedicated page setting out exactly which actions are supported, partial, or out of scope for that system, because the answer genuinely varies. Read the page for yours before kickoff so the capability conversation happens once, in advance. ## 5. Your Compliance Paperwork Do not leave this until the week you go live. Any vendor handling patient information on your behalf is a business associate, and you need a signed Business Associate Agreement before protected health information moves. Request it at the start of the evaluation, not the end. A vendor who cannot produce one promptly has told you something important. While you are there, settle the questions your privacy officer will ask anyway: where call recordings and transcripts are stored, how long they are retained, who at the vendor can see them, and who at your practice can. GetHelpdesk.AI acts as a business associate and signs a BAA, encrypts protected health information in transit and at rest, and puts transcripts behind role-based access so they are visible to your own authorised staff. Get the specifics for your own file rather than taking any vendor's summary, ours included -- the deeper background is in [HIPAA compliance for an AI receptionist](/blog/hipaa-compliance-ai-receptionist-patient-data-security/). ## 6. Your Phone Routing Decision Last, and easy to forget until it blocks you. Decide what the AI actually answers. Everything, from the first ring? Only calls that overflow when your team is on another line? Only after hours? Most practices start with overflow and after-hours, then widen once they have heard the transcripts. Decide the mechanism with whoever runs your phone system: a forward on busy or no-answer, a new number, or a port. Nothing needs replacing to do this -- we have covered when a new phone system is and is not required in [do you need a new phone system for AI](/blog/do-you-need-a-new-phone-system-for-ai/). And decide what your outgoing message says now, because the moment the AI is live, your old "please leave a message after the tone" is telling patients something untrue. ## What This Buys You A typical GetHelpdesk.AI go-live is five to seven days from kickoff, with guided setup and staff training included. That timeline assumes the six sections above exist. When they do not, the delay is never the integration -- it is waiting on a decision only the practice can make. The practices with the smoothest launches are the ones that arrive with the pack written. The ones that struggle are the ones where three people each have a different answer to "what counts as an emergency" and nobody has ever had to reconcile them. ## Key Takeaways - The system enforces your rules. It does not write them. Somebody at the practice has to. - Scheduling rules are the largest section and the one most likely to reveal drift between what is documented and what your team actually does. - Write the emergency protocol for three windows: open, after hours, and closed days. Name the specific route and the exact trigger. - Decide the identity bar and the scripted refusal before launch, not after an awkward call. - Request the BAA at the start of the evaluation, not the week you go live. - Decide what the AI answers -- everything, overflow only, or after hours -- and update your outgoing message the same day. ## Frequently Asked Questions **How long does assembling this actually take?** A few hours of focused work for a single-location practice, spread over a week because you will need your scheduling coordinator and whoever holds the emergency protocol. Groups take longer, mostly because rules differ between locations and nobody has compared them before. **What if our rules genuinely differ by location?** Document them per location. Calls can be routed per location, so the rules can differ -- but they have to be written per location rather than averaged into one set nobody follows. There is more on this in [what a multi-location group should require](/blog/ai-receptionist-multi-location-dso/). **Can we start with a partial pack and fill in the rest later?** Yes, if you start with a narrow scope. After-hours-only needs the emergency protocol and a small slice of the scheduling rules. Widening later is straightforward once the transcripts show you what callers actually ask for. **Who at the practice should own this?** One person, usually the practice manager or scheduling coordinator. The failure mode is three part-owners and no decision. ## Get the Pack Written First None of this is vendor-specific. If you assemble these six sections and then decide to hire another team member instead, you have still done your practice a favour -- you will have written down operating rules that currently exist only as habit. When you are ready, [see how GetHelpdesk works with your practice management system](/integrations/). Related reading: [rollout tips for a dental practice](/blog/ai-rollout-tips-dental-practice-implementation/) and [what to look for in an AI receptionist](/blog/ai-receptionist-buyers-guide-dentists/).