Zenoti and an AI receptionist: how the handoff works

Why multi-location changes the problem

A single-site clinic has one version of the integration question: does the enquiry end up in the system automatically, or does someone type it in. A group running several locations on one platform has that question plus a harder one sitting in front of it — which location does this enquiry belong to — and that decision has to be made correctly before any record is written anywhere.

This matters more than it first appears, because getting it wrong is not a neutral error. A consultation booked at the wrong site is worse than no booking at all: the client travels to the wrong address, the slot at the correct location goes unsold, a provider sits idle, and the recovery falls on a front desk that did not create the problem. A missed call costs you one enquiry. A misrouted booking costs you an enquiry, a slot, and some goodwill.

There is also a structural point about where the phone rings. Groups on a platform like this tend to run one of two shapes: a central number that fans out, or per-site numbers that ring locally. Those two shapes need genuinely different intake builds, and a vendor who has not asked which one you run has not thought about your situation yet.

The routing decision that happens before booking

For a multi-location group, location resolution is a required intake step, not a detail captured at the end. These are the signals an intake flow can use, roughly in order of reliability:

The rule that matters is what happens when the signals conflict or run out. The correct behaviour is to ask the caller a plain confirming question and, if it is still unclear, hand the enquiry to a human rather than picking a site. An intake system that silently guesses a location to complete a booking is producing errors that only surface when someone arrives at the wrong address.

Four levels of integration depth

All four of these get described as "integrating with Zenoti," which is why the phrase carries little information on its own. The multi-location column is the one that separates this from a single-site build:

Two cautions before you assume level 4 is the target.

First, levels 3 and 4 depend on what your account is actually permitted to do. Whether an API is available, which operations it exposes, whether third-party access needs approval, and how any of that is scoped across a multi-location organisation are decisions the platform vendor makes, and they can differ by plan and by contract. No AI vendor can promise that access on your behalf. Anyone who does is telling you something they are not in a position to know.

Second, level 4 is where multi-location failure gets expensive. A single-site system writing a bad record creates a duplicate. A multi-site system writing a bad record can create a duplicate and book it at the wrong location and hold a provider's time somewhere the guest will never arrive. That is the argument for starting at notification level and earning your way down the list, not the other way round.

Centralised versus per-site calendars

Before anyone discusses booking automation, a group needs to be clear about how its own scheduling is actually organised, because two arrangements look similar on a screen and behave very differently at the seam:

• Per-site calendars with local control. Each location manages its own availability, service menu, and providers. Booking automation has to respect a different set of rules per site, and "what is bookable" is a question with four or ten different answers. This is more common than groups expect, because sites drift over time even under central policy.
• Centrally governed availability. Services, durations, and booking rules are defined once and applied everywhere. This is far friendlier to automation — one configuration to build and maintain — but it is only true if it is genuinely enforced rather than aspired to.
• Providers who work across locations. The hardest case. A provider's availability is a single resource split across sites, and an automated booking that ignores travel time or site assignment creates a conflict that only appears on the day.
• Services offered at some sites only. If a device or a qualified injector exists at two of five locations, the intake flow must know that, or it will offer a treatment the chosen site cannot deliver.

The honest position: if your group cannot state confidently which of these describes it, that is the first thing to establish, and it is a scheduling governance question rather than a software question. Automation built on top of an inconsistent configuration inherits the inconsistency and makes it faster.

How multi-location changes the matching problem

Single-site duplicate matching is a question of "is this the same person." Multi-location adds a second question: "is this the same person and should this enquiry attach to their existing record at another site." Those come apart in ways that matter.

A workable rule stays ordered, and stays conservative:

1. Normalised phone number first, across the whole group. Strip formatting and prefixes, then match — and match against every location, not only the one the caller is being routed to. Matching within a single site is the mechanism that quietly produces a second record for a guest who visited a sister location last year.
2. Then name, as a secondary check only. A name match with no phone match is a candidate, not a match. Across a group with thousands of guests, shared names are common enough that name-first matching is actively unsafe.
3. Then email, as a tiebreaker. Never as a primary key — shared household addresses are frequent enough to break it.
4. Location is a routing attribute, not an identity attribute. The guest is one person who may visit several of your sites. Treating the location as part of their identity is exactly how a group ends up with the same client held four times.
5. Anything uncertain is flagged for a human, not written as a new record. On an ambiguous match the correct behaviour is to hold. A vendor whose answer is "it creates a new record" has told you their system will degrade your database over time, and at group scale that degradation compounds.

Two cases produce most real-world duplicates: a guest calling from a partner's phone, and a returning guest whose number has changed. Ask any vendor how their matching handles both. A group with a central marketing list has a third case — a lead record and a guest record for the same person — and a plan for reconciling those is worth having before anything writes automatically.

What a usable guest record needs

If the intake is not capturing the following, integration depth is beside the point, because your front desk will call the guest back anyway:

• Resolved location, with the evidence for it. Not just which site, but why — dialled number, stated preference, prior history, or campaign — so a person reviewing it can see whether the routing was sound.
• Full name and a verified mobile number. Read back and confirmed on the call. Most downstream matching and messaging failures trace to a mistyped number.
• New or returning, checked group-wide. Returning guests usually need a different path entirely, and this is the field that prevents the most common multi-site duplication.
• Treatment interest matched to that location's actual menu. Not the group menu. If the chosen site does not offer it, that has to surface during the call, not on arrival.
• Provider preference, where stated. Including whether that provider is available at the resolved location at all.
• Stated goals in the guest's own words, captured verbatim in the transcript rather than compressed into a dropdown.
• Self-reported flags, logged not assessed. Pregnancy, recent procedures, or allergies a caller volunteers are recorded and flagged for your clinical team. The system never evaluates them, advises on them, or decides candidacy.
• Enquiry source and campaign, so group-level marketing reporting can be attributed to a site rather than guessed at.
• Transcript and recording, attached, so the provider hears the original description rather than a summary.

What it cannot do

Being specific about limits is more useful than a feature list:

• It cannot invent API access you do not have. If your plan or contract does not expose it, or third-party access is not approved for your organisation, levels 3 and 4 are unavailable regardless of what any demo showed you. That is a commercial gate, not a technical one.
• It cannot standardise your locations for you. If service menus, durations, and booking rules differ site to site without central governance, automation will faithfully reproduce that inconsistency at speed.
• It cannot give clinical advice. It does not assess candidacy, discuss safety, contraindications, or outcomes. Anything medical a caller volunteers is logged and flagged for clinical review, never evaluated.
• It cannot handle a complication. Anything reading as a post-treatment concern leaves the booking flow entirely and escalates to the on-call provider — and in a multi-site group, to the right site's on-call provider, which is a routing rule that gets built and tested before go-live.
• It cannot resolve genuine ambiguity. An unclear or distressed caller, or one describing something that maps to no known service, gets escalated rather than guessed at. The same applies to an unresolvable location.
• It cannot fix capacity. If your sites are already fully booked, faster intake lengthens a waitlist rather than adding revenue.

Questions to ask any vendor

Ask these of us and of anyone else you are evaluating. For a multi-location group, the first three matter most:

1. How does your system decide which of my locations an enquiry belongs to, and what does it do when the signals conflict?
2. Does your matching check for an existing guest across all my locations, or only the one being booked?
3. Which of the four levels are you actually proposing for my account — not what is theoretically possible?
4. Does this require API access on my plan and contract, who confirms it exists, and whose job is it to obtain credentials?
5. Exactly which fields do you write, and which are left for a front desk?
6. What happens to an enquiry if the integration is down — silent failure, or fallback to a notification?
7. Show me a record created by your system in a live multi-location account, not a demo environment.
8. Can I hear a recording of your agent handling a caller it did not understand?

The last one is the most revealing question in the list, and the one most vendors will not answer with a real recording.

A sane rollout order across sites

The rollout that fails is the one that goes live across every location at once and writes records from day one. For a group, the sequencing has an extra dimension — scope of coverage, and number of sites:

1. One location, after hours, notification level. Pick a single site with a cooperative manager. Evenings and weekends only. Nothing touches the platform. The downside of a bad transcript is a call that was going to voicemail anyway.
2. Structure the handoff at that site. Fix the field format so entry is mechanical, and confirm the location field is being resolved correctly even when only one site is live.
3. Add a second location. This is the real test, and the point at which routing logic stops being theoretical. Do it before widening coverage hours, not after — routing errors are far cheaper to find across two sites than across ten.
4. Widen the group, still at notification or structured level. Roll across remaining sites once routing reads well for a couple of weeks.
5. Add overflow coverage. The second simultaneous daytime call, per site.
6. Consider direct record creation, last. Only where API access genuinely exists, and only with a person confirming every record for the first fortnight — at one site before all of them.

The reasoning behind this sequencing is set out across the med spa lead response hub, and the call-handling layer itself on the AI receptionist page.

Common questions

Go deeper