# Running booking across multiple locations > What changes when a customer can choose which of your shops to book — service menus, floating staff, one booking page or several, and where the money lands. URL: https://opencals.com/blog/multi-location-booking-system Author: Stanislav Tyshchenko Published: 2026-09-11 Updated: 2026-09-11 Categories: tutorial > **Key takeaway** > > Opening a second site doesn't double the booking problem, it changes its shape. Location stops being a note on the appointment and becomes a thing the customer picks first, which forces four decisions that were previously implicit: what's on the menu where, who works where, when each site is open, and where the money lands. Tools that model location as a tag rather than a dimension fail on the third of those, quietly, about six weeks in. ## 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](https://opencals.com/blog/staff-scheduling-for-appointments). ## What was implicit and now needs a value Four things, in the order they bite: 1. **The menu per site**: Which services are actually bookable where, and at what price. Prices genuinely do differ by site more often than owners expect — a city-centre room costs more to run than a suburban one. If your tool can't price the same service differently per location, you'll end up with duplicate services and a reporting mess. 2. **Opening hours per site**: Not just different hours, but different holiday calendars, different late nights, and a different definition of when the last booking of the day can start. A site that closes at 18:00 cannot take a 90-minute service at 17:30. 3. **Staff, and where each person actually is**: The hard case, below. At minimum every staff member needs a home site; realistically some of them need a schedule that says Northside on Monday and Riverside on Thursday. 4. **Where the money lands and how it reports**: One payment account or one per site, one payout or several, and whether you can pull revenue for a single location without exporting everything and filtering in a spreadsheet. 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](https://opencals.com) prices per completed booking instead: $0.99, with [locations, staff and services](https://opencals.com/features/locations) 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](https://opencals.com/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. - [Multi-location in Opencals](https://opencals.com/features/locations): Per-site services, staff and hours on one account. - [Staff scheduling for appointments](https://opencals.com/blog/staff-scheduling-for-appointments): Why shift tools and booking tools solve different problems. - [Online booking, the complete guide](https://opencals.com/blog/online-booking-system-for-small-business): The single-site version of this, start to finish. - [Salon booking software compared](https://opencals.com/blog/best-hair-salon-booking-software): If you're picking a platform for a salon specifically. ## Frequently asked questions ### What's the best booking system for multiple locations? There isn't a single best one, but there is a test that rules most out: can a service exist at one location and not another, and can the same staff member have a different schedule at each site? Platforms that treat location as a label on the appointment fail both. Opencals, Vagaro and Zenoti all model location as a real dimension; Calendly and most meeting schedulers do not, because they were built for one person in one place. ### Should each location have its own booking page? One page per site if your locations are in different towns or neighbourhoods with separate local search demand — each page can carry its own address, reviews and Google Business Profile link. One page with a location picker if the sites are in the same city and customers move between them. Past three or four sites the picker wins regardless, because nobody maintains eight booking pages. ### How do I handle staff who work at more than one location? Use one staff record with a location-aware schedule — Northside on Monday and Tuesday, Riverside on Thursday and Friday — rather than creating a duplicate person per site. Duplicates don't know about each other, so the system will happily double-book the same human at two addresses. If staff move between sites within a single day, you also need a travel buffer enforced between the last booking at one site and the first at the next. ### Can different locations have different prices for the same service? They should be able to, and it's worth confirming before you commit. Running costs differ by site, so the same cut or treatment is often priced differently in a city-centre room than a suburban one. If the platform only supports one global price, the workaround is duplicate services named per location, which doubles your menu every time you open a shop and makes revenue-by-service reporting much less useful. ### How much does multi-location booking software cost? Most platforms charge per location, per staff seat, or both, so each new site adds a fixed monthly cost from its first day — typically $30 to $130 per location per month depending on the product. Per-booking pricing changes that shape: Opencals charges $0.99 per completed booking with unlimited locations and staff, so a new site that takes forty bookings in its opening month costs about forty dollars. ### Can I see revenue for one location on its own? In a well-built system, yes, without exporting anything. This is the question worth asking a vendor first, because it's the one they're least likely to have answered well. Revenue per site, per staff member and per service is how you find out whether the second location is working, and if it takes a CSV and a pivot table nobody runs it weekly. ### Does a multi-location booking system handle staff rotas? Usually not, and you should assume it doesn't. Booking systems compute appointment availability from a schedule you give them; workforce-management tools build that schedule, handle labour cost, overtime and shift swaps. The two categories overlap in the marketing copy and not in the product. Most multi-site service businesses end up running both, with the rota tool feeding working hours into the booking tool.