Opening a second location is the moment your software stops being a convenience and starts being infrastructure. The cracks that one studio could paper over with spreadsheets and Slack messages become operational debt across two or three sites. This is the checklist of what actually has to work before you sign the lease on location two.
We built this from working with 12 multi-location operators across the Nordics and DACH. The pattern repeats: owners scale before checking whether the software scales with them, then spend year two ripping out tools that assumed one site.
The non-negotiable list
Per-location class schedules with a shared instructor pool
Your software has to model two things at once: each location has its own room, its own opening hours, its own schedule. Each instructor can teach at any location. If your platform forces you to create duplicate instructor profiles per site, every payroll run becomes a reconciliation project. Test this by asking your vendor to show you the same instructor teaching at two sites on the same day. If they show two profiles, you have a problem.
Per-location pricing tiers
A drop-in at your central Berlin location might be €25. The Hamburg satellite that opened six months later is testing at €19. Both prices live in the same product catalogue, but each is tied to a location. Cross-location members may pay a blended rate. The schema has to support all three.
Cross-location pass eligibility
This is where most platforms break. A member buys a 10-pack at location A. Can they redeem at location B? Yes, no, or only certain class types? You need rules at the product level, not the customer level. Class Booking handles this with eligibility flags on each pass: all_locations, specific_locations, or home_location_only.
A common pattern: unlimited members get cross-location access, clip-card holders are tied to their home location. This protects the unit economics of the satellite locations without punishing your most loyal members.
Payroll across locations
Instructor pay rates often differ by location, by class type, by tenure, and by class size. The platform has to compute payroll per location, then roll up to a consolidated view for accounting. If you are exporting to CSVs and doing the math in Excel, you are running a payroll department, not a studio.
Instructor commission per location
If instructors get a percentage of revenue, the calculation needs the revenue attributed to their classes at the right location. Sounds obvious. Most platforms either attribute everything to the home location or refuse to split commission at all.
Consolidated reporting
You need two views of every metric: per location, and total. Revenue, member retention, class utilization, instructor payroll, refunds. Without per-location filtering you cannot see which site is underperforming. Without consolidated totals you cannot answer the bank when they ask for portfolio-level numbers.
The two issues that catch European operators
GDPR data residency per region
If your locations cross EU and non-EU borders, you may need member data to live in different regions. A studio chain with sites in Copenhagen and London now has UK data-protection rules layered on top of GDPR. Most US-built platforms ignore this. Class Booking runs each tenant on EU infrastructure by default, with regional pinning available on the Studio tier.
Multi-currency
A three-location chain across Berlin, Copenhagen and London needs EUR, DKK and GBP simultaneously. Each location's revenue lands in the local currency. Payouts flow to the local bank account. Reporting can roll up to a base currency. If your platform supports one currency per tenant, you are about to open three separate accounts and lose all consolidated reporting.
Where US platforms typically fail
| Requirement | Typical US platform | Class Booking |
|---|---|---|
| Multi-location | Charged per location (€80–€150/site/month) | Unlimited on Studio tier |
| Multi-currency | Requires separate accounts per currency | Native, single account |
| EU data residency | Data hosted in US | EU-only infrastructure |
| VAT compliance | Bolt-on, manual | Built into invoicing |
| MobilePay / iDEAL / Bancontact | Not supported | Supported on Studio tier |
Worked example: three-location Pilates chain
A Pilates operator we work with runs three studios: Berlin (flagship, 200 members), Hamburg (satellite, 90 members) and Munich (new, 40 members). Their setup on Class Booking:
- One tenant account, three locations configured
- 22 instructors, six of whom teach at multiple sites
- Three pricing tiers per location, with one cross-location unlimited tier at €189/month
- Payroll calculated per location, exported as a single CSV per month with location breakdown
- Consolidated revenue dashboard plus per-location P&L views
- Total platform cost: €110/month for the Studio tier, regardless of how many locations they add
Their previous platform was charging €380/month for the same three locations and did not support cross-location passes. That difference pays for an additional reformer every six months.
If you are evaluating platforms before opening location two, run the math at five locations even if you only plan two. The per-location pricing model has a way of becoming expensive faster than the studios become profitable.
The checklist, condensed
- Per-location schedules, shared instructor pool
- Per-location pricing tiers
- Cross-location pass rules at the product level
- Payroll computed per location, consolidated for accounting
- Instructor commission attributable to the correct location
- Reporting filterable per location and totalled
- EU data residency if you cross borders
- Multi-currency native, not bolt-on
- VAT handling that matches your jurisdiction
- Local payment methods (MobilePay, iDEAL, Bancontact, SEPA)
If your current platform fails on more than three of these, plan a migration before location two opens. Fixing the foundation after you scale is more expensive than rebuilding it now.