AI front desk for multi-location businesses: how routing, calendars, and data isolation actually work

The caller wanted 2 p.m. at the south office. The agent found 2 p.m. and booked it. The event landed on the north office calendar, because that was the calendar the demo used. Staff at the south office have an empty chair. Staff at the north office have a stranger. The model pronounced the time correctly.

Voice, chat, and email on one customer thread is a separate problem, covered in an AI front desk that is more than a phone agent. This article is the location half. The call is already in progress, and the business has more than one site.

Why a single-location agent breaks at the second site

A single-location agent assumes one number, one set of hours, one staff list, and one calendar. The second location does not add a setting. It removes that assumption. These are the four failures that show up in the first week.

• The right time at the wrong office. The slot exists. It exists somewhere else. The caller hears a confirmation for a building they will not visit.
• One location's hours quoted for another. A shared close time says 5 p.m. The office they asked about is open until 7, or closed for a local holiday the other site does not observe.
• A shared provider double-booked across sites. Mornings at one office and afternoons at the other look like two free calendars. Both agents offer 2 p.m. because neither can see the other block.
• One location's records visible to another. A phone-number lookup returns the chart, the notes, or the mailbox from the office that created the contact first. The second office's agent can read it, and sometimes write it.

Three ways to map a call to a location

Vendor pages usually describe this as one platform with centralized scheduling and reporting, without saying whether each office keeps its own number, whether one brand line asks which site, or what gets booked when the choice is wrong. The mapping is the product. There are three of them.

One number per location is the cleanest write-path. The dialed number is the location, before the agent speaks. Transferring a caller who meant the other office is an explicit handoff to that office's number and that office's tools. It is a second call context, not a swapped variable in the same one.

One central number fits a group that spent money teaching the market a single line. The dialed number is the same for every office, so it cannot pick the site. The agent matches an existing record at one site, then asks. 'Which office?' only works if the caller knows the offices by name. 'The one on Main' needs a list the agent can resolve. If the list does not resolve, the agent asks again or takes a message. A default calendar is how the north office fills up with south-office patients.

Hybrid is what most groups already have, whether they planned it or not. Local numbers live on the door and on Google Business Profile. The website and the ads use a tracking number. Both paths have to write the same location field, and both have to match the person before they create a contact. Otherwise Tuesday's ad call and Thursday's call to the office line are two people in the CRM.

Calendars, hours, and staff who work at more than one site

Hours and holidays belong to the location

Each site has its own open hours, its own lunch block, and its own holidays. The agent quotes and books from that set after the location is known. A group-level hours string is the bug in the second failure mode: every office inherits the flagship's Friday close. After-hours behavior is the same policy with a clock on it. Nights and days still write the same calendar for that site, which is the rule in after-hours AI receptionist.

A shared provider is one person and two calendars

A clinician or a technician who works mornings at one site and afternoons at another does not have one free/busy grid the front desk can glance at. Each location has a calendar the agent may write. The person has blocks on both. Booking site A requires two reads and one write.

1. Read site A's open slots for that service and that provider.
2. Read the provider's busy blocks at every other site. The result is a list of occupied times.
3. Offer only the overlap that is free at site A and free for that person.
4. Write the appointment on site A's calendar only.

The cross-site read is a conflict check. It returns occupied times. It does not return the other office's patient name, chart, or reason for visit. If the tools are isolated so thoroughly that site A's agent cannot read site B at all, shared staff need a small group availability service that answers 'busy or free' and nothing else. Giving site A's agent site B's calendar 'so it can check' is how the fourth failure mode comes back.

The check happens during the call

The agent reads open slots and writes the event before the caller hangs up. A message for staff to enter later is a different product, and it recreates the wrong-office booking in the morning when a person guesses. The production bar for that write, including latency, is in how we ship production voice agents. VoiceCake is the live booking proof for dental, healthcare, fitness, and mortgage clients: the appointment is on the schedule the office opens in the morning.

Data isolation is a tool boundary

Dynaris is the worked example. KeenCraft runs its voice agents and tools as separate MCP-based services so each workspace has its own tool servers. The agent serving one location calls that workspace's calendar, that workspace's mailbox, and that workspace's records. A shared tool process with a location id in the prompt will eventually book the other site, because the prompt is not a permission.

What each location's agent can see is its own calendar, its own contacts, and its own thread. What leadership can see is a separate read across workspaces: how many calls were answered, how many became bookings, how many were transferred, what happened after hours. That rollup counts outcomes. It does not hand location B's chart or mailbox to the person, or the agent, working location A.

Healthcare is where this stops being an operations preference. A phone-number match that opens another office's chart gives the second location a record it was not asked for, and it gives the model a record it can repeat out loud. OptimateMD.health was built with healthcare data-handling standards in the architecture. The same standard on a front desk is minimum access: enough to book this office, and a busy/free answer when a provider is shared. Gmail on Dynaris follows the same rule. Composio connects the mailbox into the customer thread, and that mailbox is the workspace's, not the group's shared inbox.

The appointment has to land in the system that location already uses

The location owns the appointment. The person can exist once for the group. Match on phone or email before creating a second contact. A patient who is seen at two offices should end as one person, two appointments, two location fields, each appointment on the calendar of the office that will see them. The duplicates that matter are two contacts for one person, and one appointment written onto the other office's calendar.

Integrates means the agent reads open slots during the call and writes the appointment into the system staff already open in the morning. Location, source, and channel are fields on that record. A note that says the caller would like 2 p.m. is a message for a human to retype. How those fields survive into a CRM is automation that writes back to HubSpot, Salesforce, and Zoho.

These are the systems KeenCraft has connected in production. A practice system that is not on this list is a new connector, scoped on its own, not a checkbox labeled integrates.

• Google Calendar and Calendly, the usual calendars on a single-location build, and Cal.com when that calendar is the record.
• HubSpot, Salesforce, and Zoho, including the contact, the stage, and the source.
• Gmail through Composio, on the same thread as the call, on Dynaris.
• Custom CRMs, including the live trades CRM for trades and local services.

Report the same five numbers for every location

A group total hides the office that never books. Leadership gets the same five metrics side by side, one row per location, and a total only after the rows exist.

• Answer rate: calls that reached a completed conversation, against calls that rang out or hung up in the greeting.
• Booked rate: of the calls that wanted an appointment, how many ended as a confirmed slot on that location's calendar.
• Transfers: how often a person had to take the call, and whether that person was at the office that can act.
• After-hours bookings: slots created while that office was closed, on that office's calendar.
• Missed-call recovery: callers who hung up or were missed and still ended booked, which is outbound follow-up measured per site.

Each location can see its own row. The group view is the table. Averaging a 90 percent booked rate at one office with a 10 percent rate at another is how a failing site looks fine in a Monday email.

Urgent calls go to that office

An urgent call goes to the people who can act for that location: that office's on-call, that office's manager, that office's after-hours rule. A central queue answers with staff who cannot open the chart, unlock the door, or reach the patient at that building. They can take a message. They cannot finish the job the caller dialed for.

If the office is closed, the path is still that office's path. A sister site that happens to be open is a coverage rule the group writes down, with the hours and the clinical limits attached. It is not what the agent invents because someone, somewhere, is at a desk. The urgent-versus-routine split for a single office is in the after-hours receptionist. Multi-location adds one requirement: the page, the transfer, and the message all carry the location, and they ring that location's people.

When a vertical product is the better buy

A dental group that wants an off-the-shelf agent for one practice system may be well served by a dental-specific product. The fit is one vertical, a practice system the product already writes, and booking rules the product can express. Paying a studio to rebuild that connector is the slower way to the same appointment.

A custom build fits when the group mixes service types, runs a custom CRM, is not a dental business, or has a rule a vertical product cannot express. Shared staff across brands, a location field that has to survive into Salesforce, or a front desk that also has to keep chat and email on the same thread are the usual reasons. No-code, a developer platform, and a studio build are compared in how to choose an AI appointment booking agent.

At KeenCraft, a multi-location build with CRM write-back is typically $12,000 to $30,000, as a fixed price. One location is typically $3,000 to $12,000. The ranges, and what sits at each point, are in what an AI voice agent actually costs in 2026. If a vertical product already writes the system of record and the rules fit, that product can be the cheaper honest answer. That is a fine outcome of the strategy call.

Pilot one location, then add the next

Turning on every site in a weekend multiplies the wrong-office booking by the number of calendars. The rollout that holds up is sequential.

1. Pick one location whose hours, staff, and calendar are already the ones the front desk trusts.
2. Run the agent in parallel with that front desk. Staff still own the line.
3. Check every booking the agent offered against the calendar the office opens in the morning: location, provider, and time.
4. Turn on the live write for that location only after those match.
5. Add the next location as its own workspace: its number or routing rule, its hours, its tools. Do not copy the first location's calendar into the second.
6. Read that location's five metrics for a week before you add another site.

KeenCraft prices this as a fixed Statement of Work. Each location after the pilot is a milestone you can test: the booking lands on that site's calendar, and that site's tools cannot write the previous site. Book a call if you can name the locations, the calendars, and the system the morning staff already open. A proposal typically lands in 2 to 5 business days.