Running booking across multiple locations

The second shop breaks the assumption, not the calendar

A single-site booking system carries one assumption everywhere: there is one place, so the place never has to be asked about. The address is on the confirmation email as static text. Opening hours are "our hours". A service takes 45 minutes, full stop. A stylist is available Tuesday, full stop.

Every one of those sentences loses its meaning at two sites. Tuesday where? Available at which one, and can she get there? Forty-five minutes — is that true at the smaller shop with one basin?

That's why migrating to a second location so often feels like the software has started lying. Nothing broke. The system is answering a question that no longer has a single answer, and it will keep answering confidently until a customer arrives at the wrong address.

Location stops being a label the moment a customer can choose it

Here's the test that separates tools that will hold up from tools that won't. Ask: can a service exist at one location and not another?

If the answer is no — if the service list is global and location is a field you set on the booking afterwards — location is a label. That model survives until the day the second shop doesn't offer colour correction, or the first one is the only one with a massage room. Then you either list services you can't deliver at half your sites, or you create duplicate services called "Colour — Northside" and "Colour — Riverside" and live with a menu that doubles every time you open a shop.

If the answer is yes, location is a dimension: it constrains the service list, the staff list, the hours and the resources together. Availability then has to be computed as the intersection of all four — the site is open, the staff member is working there, the service is offered there, and the room or chair is free. That's a different calculation from checking a calendar for a gap, and it's the one thing worth verifying before you commit to a platform. Availability being computed rather than stored is also the point where staff scheduling and appointment scheduling stop being the same problem.

What was implicit and now needs a value

Four things, in the order they bite:

Get the first two right at setup and the rest is admin. Get them wrong and you'll be maintaining parallel service catalogues for as long as you own the business.

One booking page, or one per site?

This is the decision people ask about most and it has a real trade-off rather than a best practice.

One page with a location picker. The customer lands, chooses a site, and continues. Better for repeat customers, better for people who don't know your locations by name, and it keeps one set of analytics and one link to put on the card. It's also the only sane option once you pass three or four sites — nobody maintains eight booking pages.

A page per location. Better when your sites have genuinely separate local demand: distinct neighbourhoods, distinct Google Business Profiles, people searching "hairdresser Praga" rather than your brand. Each page can carry the local address, local reviews, local photos, and be the link on that site's profile. It costs you duplicated setup and split analytics.

What I'd do: one page per location if the sites are in different towns or different enough neighbourhoods to have separate local search demand, one page with a picker if they're in the same city and customers move between them. Two or three sites in one city almost always wants the picker.

What I can't tell you is which one will rank better for your business — that depends on whether your locations have distinct local search demand, and the only honest way to find out is your own Search Console data, not a rule in an article.

Staff who float between shops are the hard case

One person working at two sites is where most multi-location setups actually fall over, and the failure is specific: the system offers her 14:00 at Northside and 14:30 at Riverside, someone books both, and now she has twenty minutes to cross town.

Three ways this is handled, from worst to best:

1. Split the person in two. Create "Anna (Northside)" and "Anna (Riverside)" as separate staff. Every tool supports this and it's wrong — the two Annas don't know about each other, so the double-booking above happens on day one. It also breaks her commission reporting.
2. Assign her to one site per day. A single staff record whose working pattern names the location: Mon/Tue Northside, Thu/Fri Riverside. This handles the majority of real rotas and it's what I'd set up first.
3. Travel buffers between sites. One record, a schedule that can change site mid-day, and a gap enforced between the last booking at one location and the first at another. The correct model, and the one fewest tools implement.

Most salons and clinics are fine at level 2. If your staff genuinely move mid-day — mobile therapists, a doctor doing mornings at one clinic and afternoons at another — check for level 3 explicitly during a trial, because every product's marketing page describes level 1 and level 3 with the same words.

Where the money and the reporting split

The question to ask a vendor is not "do you support multiple locations". It's: can I see one location's numbers without exporting everything?

Revenue per site, per staff member, per service is the reporting that tells you whether the second shop is working. If it takes a CSV export and a pivot table, you won't do it weekly, and the second site will be six months into underperforming before anyone puts a number on it.

Payments are the other half. Some businesses want one Stripe account and one payout, with location as a reporting dimension; franchise-shaped ones need separate accounts so each site's money is genuinely its own. Both are legitimate, and the second is much less commonly supported than the first — worth confirming before you sign, not after.

What to test before you migrate the second location

A trial that only tests one site tells you nothing. Set up both, then try to break it:

• Book a service at a site that doesn't offer it. You should not be able to.
• Book the last slot of the day at the site that closes earliest, for your longest service. It should be refused.
• Put a floating staff member on both sites the same day and try to book her across town in the same half hour.
• Change one site's opening hours for a bank holiday and confirm the other site is untouched.
• Pull last week's revenue for one location only, in under a minute.
• Cancel a booking at one site and check the refund lands in the right account.

If a platform passes those six, the rest of the migration is data entry.

What this costs, per seat or per booking

Multi-location is where per-seat and per-location pricing hurts. Plenty of platforms charge per location, per staff member, or both, so the second site adds a fixed monthly cost from the day it opens — which is the day it earns least. A chain of three with twelve staff can be paying a few hundred a month before it takes a single booking.

Opencals prices per completed booking instead: $0.99, with locations, staff and services unlimited on the same account. A new site that does forty bookings in its first month costs about forty dollars, and a quiet January costs whatever January actually was. That's the reason the model exists — the full pricing is one line.

The limit worth stating plainly: Opencals schedules appointments against staff availability, it doesn't build the rota. It assumes you've already decided who works where and when, and it computes bookability from that. If your real problem is planning shifts across sites — labour cost, overtime, who covers a sick call — that's a workforce-management tool, and Opencals sits next to it rather than replacing it.

Beyond that, the sequence I'd follow: get the per-site service menus and hours right before you touch anything else, model floating staff as one person with a site-aware schedule, and pick one booking page or several based on whether your locations have separate local demand. The reporting question is the one to ask vendors first, because it's the one they're least likely to have thought about.