Short answer: Multi-location booking works when every enquiry is tagged with a location before it reaches anyone, routed to the team that owns that location, and confirmed against a calendar only that location controls. Most multi-site problems are routing problems wearing a scheduling costume.
One location is a scheduling problem. Two or more is a routing problem, and the failure modes are completely different.
The three ways multi-location booking breaks
Enquiries land in the wrong place. A customer near the second branch fills in the form on the main site and the request goes to head office, sits for a day, then gets forwarded. By then they have booked elsewhere.
Availability gets answered from the wrong calendar. Someone on the phone says "we can do Thursday" while looking at a calendar for a different site.
Nobody owns the enquiry. Two locations both assume the other is handling it, or both call the same customer within an hour. Both are bad, and the second is worse.
Every fix below is aimed at one of these three.
Ask for location first, not last
The most common design mistake is putting the location field at the end of a form. By then the customer has already answered questions that only make sense for a specific site, and you may have shown prices or availability that do not apply.
Location should be the first or second thing you establish. Not because it matters most to the customer, but because everything after it depends on it.
The friendlier version is not asking directly. Postcode, town, or "which of these is closest to you?" gets there without making the customer do your routing for you. If you only have two or three sites, list them and let people pick.
Route the request automatically
Once you know the location, the request should reach that location's team without a human forwarding it. Manual forwarding is where hours disappear.
An AI chat widget can do this at the point of capture. Clerkzo captures leads conversationally or as an in-chat form with custom fields, so a location field sits alongside preferred time and service type. Notifications go by email, webhook or Telegram, which means each site can receive its own enquiries directly, or you can push everything into your own system by webhook and route it there.
The important part is that the location is captured as structured data, not buried in a paragraph of free text that someone has to read before deciding where to send it.
Decide what is shared and what is local
This is the strategic question and it is worth answering explicitly.
Things that are usually better shared across locations: your brand tone, your service definitions, your policies on cancellation and deposits, your response-time standard, and the record of who has been contacted.
Things that are usually better local: the calendar, the availability, staff assignments, and knowledge of local constraints like parking, access or seasonal demand.
Trouble comes from mixing these up. A shared calendar that nobody at a specific site controls tends to get out of date. Locally invented policies tend to contradict each other and produce awkward conversations when a customer visits both sites.
One pipeline, filtered by location
Even with local calendars, there is a strong case for one enquiry pipeline that everyone can see, filtered by location.
It means head office can tell whether one site is slow to respond. It means an enquiry that arrives at the wrong site can be reassigned rather than forwarded and lost. It means nobody double-calls a customer, because the status is visible.
A leads inbox with a New, Contacted, Qualified, Won or Lost pipeline gives you that shape. The status is the shared part; the calendar stays local.
Keep location-specific content accurate
If each site has different hours, different services or different staff, your website needs to say so, and whatever answers questions on your website needs to know it.
An AI chat widget trained by crawling your site will only be as accurate as your location pages. If the second branch page still lists last year's opening hours, expect that answer to come back to customers. Keep location pages current, and use the corrections loop to fix any answer that comes out wrong.
The reverse is also useful: the questions people ask through chat tell you which location details are missing from your site.
Handle the "any location" customer
Some customers do not care which site they visit; they want the soonest appointment. This is an opportunity most multi-site businesses waste, because their process assumes location is fixed.
Ask the question directly: are you flexible on location if it means an earlier slot? If yes, that request can go to whichever site has capacity. This effectively pools your availability without merging your calendars, and it is one of the few genuinely free wins in multi-site scheduling.
Set one response-time standard
Different sites replying at wildly different speeds creates an inconsistent brand and hides your worst performer. Set one standard, measure against it per location, and treat a site that lags as an operational problem rather than a personality difference.
If the gap is caused by enquiries arriving outside staffed hours, the fix is capture rather than staffing. Take bookings 24/7 without hiring covers that pattern, and how to get more online bookings covers the demand side once your routing is sound.
Frequently asked questions
Should each location have its own website page?
Yes. Separate pages with accurate hours, address, staff and services help customers, help search engines, and give an AI chat widget the source material it needs to answer location-specific questions correctly.
Should I use one shared calendar or separate ones?
Separate calendars owned by each location, with one shared enquiry pipeline on top. Shared calendars that nobody locally controls tend to drift out of date.
How do I stop two locations calling the same customer?
Keep one pipeline with a visible status. When an enquiry is marked as contacted, the other site can see it. Forwarding by email without a shared record is what causes duplicate calls.
Can Clerkzo route enquiries to different branches?
It captures location as a custom field and delivers requests through email, webhook or Telegram, so each site can receive its own or you can route centrally through a webhook. It captures and delivers the booking request rather than writing to any location's calendar.
What if a customer picks the wrong location?
Build reassignment into the process rather than treating it as an exception. A shared pipeline makes moving an enquiry a status change instead of a forwarded email that nobody owns.