Use case
A multi-location AI receptionist that knows which site the caller wants
A multi-location AI receptionist answers for every site under one build and routes each caller to the right one before anything is booked. The hard part is not answering; it is deciding which location a caller means when they have not said, then holding that location's own calendar, staff and services for the rest of the conversation. AnswerAI builds the routing rules with you first, because a booking sent to the wrong site is worse than a missed call: it turns a won customer into a wasted trip.
Built and running across a 4-location group in med-spa & medical aesthetics. The measured figures below cover one of those locations over one month; the scale of the group and the scale of the measurement are separate facts and this page keeps them separate.
What actually breaks when a business has more than one site?
Four things, and none of them is answering the phone. Each is a decision that a single-site line never has to make and that a template cannot make for you.
- Which location does the caller mean?Most callers do not say. They ask whether you can fit them in on Thursday, and the answer is different at every site you run.
- Which calendar does the booking land in?Live availability is per site and frequently per practitioner within a site. A booking written to the right day at the wrong address is a customer who arrives to an empty room.
- Which staff and services exist there?Sites rarely offer an identical menu. One has the practitioner who does the thing being asked about; another does not, and saying so on the call is what keeps the booking inside the business.
- Whose numbers are these?A group that cannot see calls per site cannot tell a busy location from an under-marketed one. One aggregate number hides exactly the comparison a multi-site operator needs.
One number for the group, or one per location?
Both work and they fail differently. The decision is usually made by what is already printed on your signage and listed on your Google Business Profiles rather than by what is technically neater.
| One number for the group | A number per location | |
|---|---|---|
| How the caller reaches the right site | The agent asks, or infers it from what the caller says | The number itself carries it; no question needed |
| Google Business Profile | Each profile still needs its own number, so this usually means changing them | Matches what each profile already publishes; nothing to change |
| Existing signage, vehicles, print | Unchanged if the group number is already the one advertised | Unchanged, per site |
| Per-site call reporting | Derived from the routing decision on each call | Direct: the number answered is the site |
| Where it goes wrong | A caller who names no location and is routed on a guess | A caller who rings the site nearest their home for a service only offered elsewhere |
| What AnswerAI builds | One agent, per-site rules, routing decided in the conversation | One agent per number, sharing one knowledge base and one dashboard |
The second failure mode is the more common one and it is fixable in the build: an agent that knows which services exist at which site can say "that one is only at the other location, I can book you there for Thursday" instead of booking a service the site cannot deliver. That sentence is a routing rule, not a feature.
What does this look like on a group that is actually running?
A med-spa & medical aesthetics group with 4 locations on an AnswerAI line. The figures below are from one location over one month, a floor for the group rather than a total, and published that way deliberately.
- 340 calls answered at one location in one month, with a 100% answer rate.Measured, first-party. Full scope ledger on /results/sucre.
- 187 of those calls carried booking intent: the caller wanted an appointment rather than information.Measured, first-party. Booking intent is defined and counted on the case study.
- 4 locations on one AnswerAI build, sharing one knowledge base and one dashboard.Client count, current as of the date at the foot of this page.
- The measured window covers one location and one month, a floor for the group rather than a total, and published that way on purpose.Scope note. Every figure on this site carries the window it was measured over.
How is a multi-site build different from four single-site builds?
One knowledge base, one dashboard, and per-site rules layered on top. Four separate builds would mean four places to update a price and four opportunities for them to disagree.
The thing that makes a group build cheaper to run than the sum of its sites is that most of what an agent knows is identical everywhere. Your services, your policies, what may not be said about price, how a cancellation is handled: these belong to the business rather than to an address. They are written once.
What is per-site is narrow and specific: the calendar, the staff, the address and parking, the hours, and any service the site does not offer. Layering those over a shared base is what lets a group change a policy in one place and have it take effect on every line the same afternoon.
Reporting follows the same shape. Every call is logged with the location it was routed to, so a group can compare call volume and booking intent across sites without standing up separate reporting per address. That comparison is frequently the first genuinely new thing a multi-site operator gets out of the build, because it is the number nobody had before.
One honest limit: the routing rules are only as good as the decisions made before the build. If your own staff cannot reliably say which site should take a given call, the agent will not resolve that ambiguity for you; it will apply whatever rule you agreed, consistently, which is better than a coin toss but is not a substitute for the decision.
A booking sent to the wrong site costs more than a missed call, so AnswerAI settles the routing rules before the build (which location, which calendar, which staff) and then applies them identically on every call.
If you run more than one site, the fastest way to see the gap is to ring each location's published number and ask for something only one of them offers.
Start free pilotQuestions multi-site operators ask
Yes, and it is usually the better arrangement: one knowledge base holds everything true of the business, and per-site rules hold the calendar, staff, hours and services that differ by address. Four separate builds would mean updating a price in four places and living with the day one of them is missed.
Either the number they dialled tells it, or it asks. Where a caller gives a hint (a neighbourhood, a practitioner's name, a service only one site offers) the routing rule can use that instead of asking a question the caller has effectively already answered. Which signals are trusted is decided with you at build time.
Not necessarily, but your Google Business Profiles do, and that is usually the deciding factor. If each location already publishes its own number on its own profile, keeping those numbers and pointing them at one shared build changes nothing a customer sees while giving you per-site reporting for free.
Yes, against live availability per site and, where the software supports it, per practitioner within a site. The depth of that write access depends on which booking system you run; the integrations pages state each vendor's ceiling from its own published endpoint index rather than from a capability claim.
The line says so and offers the location that does, which is a routing rule rather than a feature. This is the most common multi-site failure we see, and it is worth deciding explicitly: some groups want the caller offered the other site, some want a callback from a manager, and some want a specific script for services being phased out.
Decide the routing before the phone does.
The pilot runs about 14 days with no call limit. For a group, the first working session is about which caller belongs at which site; get that right and the rest of the build is straightforward.
Start free pilotLast updated