Direct answer: Implementing an AI receptionist in a UK dental practice is a phased operations project—baseline calls, map reasons, set rules and safety, connect telephony and PMS, configure content, test, train staff, pilot, launch, then QA. Duration depends on readiness and complexity. Do not treat “live in minutes” or a fixed 48-hour clock as a contract unless your signed statement of work says so.
This is Clero’s canonical dental implementation resource. Product overview stays in the dental AI receptionist pillar. Use this page for owners, inputs, outputs, risks and acceptance criteria. Keep ROI maths on the ROI guide—implementation success is passing tests and stable diary quality first.
Timeline overview (no false precision)
| Scope | What usually drives duration |
|---|---|
| Narrow (overflow FAQs + one bookable type, supported PMS, clear hours) | Faster—often aligned with Clero’s public “about a week or two with custom onboarding” planning language for straightforward setups |
| Standard (in-hours + OOH rules, several types, identity gates) | Longer configuration and rehearsal |
| Complex (multi-site, mixed NHS/private, multiple PMS quirks) | More workshops, parallel testing and staged pilots |
Clero’s product setup flow collects business details, agent voice/greeting, knowledge, notifications and a test call path; PMS connection and telephony routing are configured for the live practice. Acceptance is readiness and passing tests, not a calendar promise.
Readiness checklist
Complete before you treat configuration as “almost live”:
| Area | Ready when… |
|---|---|
| Phone setup | Published number path known; overflow/forwarding or VoIP routing agreed; fallback documented |
| Call data | 1–2 weeks of call-reason tags or equivalent baseline |
| Appointment types | List of AI-bookable vs staff-only types with durations |
| Hours / holidays | Open, closed and after-hours behaviour written |
| Escalation contacts | Desk, mobile or central numbers; unanswered behaviour |
| Policies | Notice periods, deposits, NHS/private separation where relevant |
| Privacy | Recording/monitoring notice approach; who may access transcripts |
| Integration access | PMS admin access / API credentials for a supported connector |
| Success metrics | Baseline answer rate, booking completion, escalations, corrections |
Metrics to track from baseline through pilot
Use your own numbers—no invented industry targets:
- inbound answered vs abandoned on automated paths
- completed bookings for automation-eligible intents
- escalation rate by reason (identity, rules, urgency, system error)
- booking corrections by staff (wrong type, clinician, time, patient)
- transfer answer rate and abandoned transfers
- complaint or safeguarding flags linked to automated calls
Review weekly in pilot; fortnightly once stable. Share a simple dashboard view with the reception lead so corrections are visible without waiting for a vendor email.
Phase guide
For each phase: Owner | Inputs | Outputs | Risks | Acceptance
1. Discovery and baseline
| Phase field | Details |
|---|---|
| Owner | Practice manager + Clero onboarding lead |
| Inputs | Call volume samples, peak times, current routing, staff pain points |
| Outputs | Written scope (overflow / OOH / in-hours), success metrics, named owners |
| Risks | Automating without knowing why calls are missed |
| Acceptance | Scope and baseline signed off by practice owner |
2. Call-reason mapping
| Phase field | Details |
|---|---|
| Owner | Reception lead |
| Inputs | Tagged calls (book, change, cancel, FAQ, complaint, urgent, other) |
| Outputs | Priority list: automate / message / always-human |
| Risks | Treating rare clinical calls as the main automation target |
| Acceptance | Top reasons mapped with volume estimate |
3. Rules and safety
| Phase field | Details |
|---|---|
| Owner | Practice manager + clinical lead (for urgent script only) |
| Inputs | Appointment rules, NHS/private flags, never-do list |
| Outputs | Scheduling matrix; urgent-language script; complaint path |
| Risks | Vague “use judgement” rules the AI cannot apply |
| Acceptance | Documented rules + clinical sign-off that AI does not diagnose or advise |
Detail: scheduling guardrails and safe-by-design emergencies.
4. PMS and telephony integration
| Phase field | Details |
|---|---|
| Owner | IT/telephony contact + Clero engineer; PMS admin |
| Inputs | Provider details; location/clinic IDs; treatment mappings |
| Outputs | Working availability + create/cancel (and reschedule if in scope) on a test path |
| Risks | Assuming universal PMS support; silent message-only “integration” |
| Acceptance | Demonstrated write-back for approved types in the live or sandbox diary |
Verified Clero booking handlers today: Dentally, CareStack, Semble, Aerona and Exact (via Exact Online Booking when enabled), plus LeadConnector/Calendly where configured. Confirm others in writing. Architecture: PMS integration. Telephony layering: AI vs traditional clinic phone systems.
5. Content and configuration
| Phase field | Details |
|---|---|
| Owner | Reception lead + Clero configurator |
| Inputs | FAQs, fees the practice will publish, greeting, hours, locations |
| Outputs | Agent knowledge, business hours, notification recipients |
| Risks | Unapproved clinical or promotional claims in FAQ text |
| Acceptance | Practice-approved copy loaded; notifications reach a monitored inbox/phone |
6. Testing
| Phase field | Details |
|---|---|
| Owner | Reception lead (execute) + Clero (observe/fix) |
| Inputs | Test-case table below; test patients/slots |
| Outputs | Pass/fail log with recordings or transcripts |
| Risks | Happy-path-only demos |
| Acceptance | All critical cases passed or explicitly deferred with fallback |
7. Staff training and change management
| Phase field | Details |
|---|---|
| Owner | Practice manager |
| Inputs | Escalation playbook; dashboard access; “what AI will/won’t do” |
| Outputs | Trained coverage roster; who reviews transcripts |
| Risks | Staff fear of replacement; ignored escalations |
| Acceptance | Team can transfer, pause route awareness, and explain AI to patients |
Augment, don’t blindly replace: automation takes repetitive overflow and after-hours admin; people keep hospitality, goodwill, safeguarding and clinical judgement.
Change-management notes that actually help
- Announce the pilot scope to the whole team before routing changes (“evenings only this fortnight”).
- Show one passed test call in a short huddle so staff hear the voice and the transfer path.
- Give reception a one-page card: when to expect AI, how to take a hand-off, how to escalate a bad booking.
- Schedule transcript review in the rota—if nobody owns QA, rules drift.
- Invite scepticism: ask staff which call types must stay human and write those into the matrix.
8. Pilot
| Phase field | Details |
|---|---|
| Owner | Practice manager |
| Inputs | Narrow hours or call types (e.g. OOH only) |
| Outputs | 1–2 weeks of metrics and correction log |
| Risks | Expanding before diary quality is stable |
| Acceptance | Rule-error rate and escalation path acceptable to the owner |
9. Launch
| Phase field | Details |
|---|---|
| Owner | Practice manager + Clero |
| Inputs | Pilot sign-off; fallback ready |
| Outputs | Agreed live routing; launch note to staff |
| Risks | Quiet launch with no on-call owner |
| Acceptance | Named on-call owner for first week; rollback steps posted |
10. QA and optimisation
| Phase field | Details |
|---|---|
| Owner | Reception lead (weekly) |
| Inputs | Transcripts, booking corrections, complaints |
| Outputs | Rule tweaks; expanded types only after clean weeks |
| Risks | Metric theatre without listening to failures |
| Acceptance | Cadence fixed (e.g. weekly sample) and ownership recorded |
Test-case table
| Case | Expected behaviour | Pass if… |
|---|---|---|
| Routine booking | Offers approved type; writes diary when confirmed | Slot appears correctly in PMS |
| Existing patient | Identity gate matches practice policy | Right patient linked; no wrong-record book |
| Urgent wording | Stops routine book; safety script / transfer | No clinical advice; correct redirect language |
| Complaint | Acknowledge + human path | Reaches staff with context |
| Ambiguous request | Clarify or escalate—no guess booking | No invented appointment type |
| Outage / unanswered AI path | Telephony fallback | Caller reaches desk, alternate route or monitored path |
| Failed booking write | No false “you’re booked”; offer retry/callback | Diary and caller message consistent |
| Human transfer | Warm or informed hand-off; unanswered rule | Staff can continue without full restart |
Escalation design detail: human escalation mechanics.
Phased rollout and rollback
Rollout pattern
- After-hours FAQ + message capture
- One overflow booking type in-hours
- Reschedule/cancel for clear policies
- Additional types / sites only after clean QA
Rollback / fallback
- Re-route the published number to desk or prior IVR/voicemail path
- Disable AI booking writes while leaving message capture if useful
- Keep a printed “disable steps” card at reception
- Review failed cases before re-enabling
Resilience context: healthcare call-handling resilience.
Example RACI (adapt locally)
| Activity | Practice manager | Reception lead | Clinical lead | Clero / implementer | Telephony / IT |
|---|---|---|---|---|---|
| Baseline & scope | A | R | C | C | C |
| Call-reason map | A | R | I | C | I |
| Rules & safety scripts | A | R | C/A (urgent script) | C | I |
| PMS mapping | A | C | I | R | C |
| Telephony routing | A | C | I | C | R |
| Test execution | A | R | C | C | C |
| Pilot decision | A | C | C | C | I |
| Weekly QA | A | R | I | C | I |
R = responsible, A = accountable, C = consulted, I = informed.
Suggested pilot calendar (illustrative)
Illustrative sequencing—not a promised Clero duration. Compress or extend based on readiness.
| Window | Focus |
|---|---|
| Days 1–3 | Discovery workshop, readiness checklist gaps |
| Days 4–8 | Rules draft, PMS/telephony credentials, content load |
| Days 9–12 | Test-case table execution and fixes |
| Days 13–14 | Staff huddles and fallback rehearsal |
| Next 7–14 days | Narrow pilot (e.g. OOH only) with daily correction log |
| After pilot review | Expand types/hours or roll back |
If readiness items are missing on day 1, the calendar slides—that is normal, not failure.
Data migration and recording—set expectations
Most dental AI receptionist projects are not a bulk patient-database migration. Typical work is:
- mapping appointment types and clinicians in the connected PMS
- loading FAQ/knowledge the practice approves
- configuring hours, locations and escalation targets
- connecting telephony routing
Patient records usually remain in the PMS of record. If a vendor proposes a large one-off data import, ask why—and what reconciliation looks like.
On recordings and transcripts: decide before pilot whether audio is stored, who can play it back, and how long it is kept. Product behaviour can include transcripts and, where enabled, audio access; do not plan as if nothing is retained. Align staff access with least privilege.
Common implementation failure modes
| Failure | Early warning | Fix |
|---|---|---|
| Diary clutter | Staff correcting many AI books daily | Narrow types; tighten duration/clinician rules; pause writes |
| False confirmations | Caller told “booked” but PMS empty | Treat write response as source of truth; retest failed-write case |
| Transfer black hole | Escalations unanswered | Fix destination numbers and unanswered rule before expanding hours |
| Shadow IT FAQs | Unapproved clinical claims in knowledge | Clinical lead reviews FAQ text |
| Scope creep | “Just one more type” every day | Freeze scope until weekly QA is clean |
| Owner vacuum | Nobody reviews transcripts | Put QA on the rota with a named deputy |
Privacy, recordings and compliance (verified caution)
Dental automation may process personal and health-related data. This guide is not legal advice. Ask what audio, transcripts and metadata are retained, who can access them, and how callers are informed. Do not assume zero-retention or “fully GDPR compliant by default.” Use the healthcare call automation security checklist and Clero’s Privacy Policy.
Claims this implementation guide will not make
- Fixed “live in 48–72 hours” or “live in minutes” for every practice
- Unrestricted Exact access beyond Online Booking / universal Pabau write-back as verified fact here
- Zero-retention audio as a blanket product property
- Invented DNA, abandon or “hours saved” benchmarks
- Automation as a drop-in replacement for the reception team
Frequently asked questions
How long does it take to implement a dental AI receptionist?
It depends on telephony, PMS write-back, appointment rules and testing. Clero’s public onboarding FAQ describes custom onboarding often within about a week or two with support—treat that as a planning range for straightforward scopes, not a guarantee for complex multi-site or mixed-pathway practices.
Do we need to change our phone number?
Usually no. Most practices keep the published number and route or overflow selected calls into the AI path. A fuller VoIP migration is a separate decision when the current line cannot support the routing you need.
Which practice systems can Clero book into?
Clero's booking integrations currently include Dentally, CareStack, Semble, Aerona and Exact (via Exact Online Booking when enabled), plus calendar-style connectors such as LeadConnector and Calendly where configured. Confirm your exact system and appointment types before treating write-back as ready.
Should automation replace the reception team?
No. Implementation should augment the team: automation for routine overflow and after-hours admin; people for complaints, safeguarding, clinical judgement and exceptions.
What must be tested before launch?
At minimum: routine booking, existing-patient flows, urgent wording, complaints, ambiguous requests, outage/fallback, failed booking writes and human transfer—including what happens if nobody answers the transfer.
How do we roll back if something goes wrong?
Keep a documented telephony fallback to the desk or voicemail/monitored path, pause AI booking writes if diary quality drops, and assign a named owner who can disable the automated route quickly.
Who owns the implementation inside the practice?
Name a practice owner (often the practice manager or reception lead) for rules and QA, plus a Clero/implementation counterpart for configuration. Dual ownership prevents stalled go-lives.
Next step
If you want a structured readiness review—baseline, rules, PMS/telephony and test plan—book an implementation-readiness discussion before expanding scope. Keep the dental pillar for “what it is,” and this page for “how we deploy it safely.”