As a CEO it would be reasonable to ask (or as an analyst, to be asked) any or all of the following four questions on a typical Monday morning:
- How many unique customers did we serve across all locations last quarter?
- Are we growing same-location visits year over year?
- What's our retention rate for customers that joined in Q4?
- Which of our metro areas has the highest annual revenue per customer?
None of these are trick questions and they all sound so simple at first glance. They're the kind of thing anyone running a multi-location business should know in order to make smarter decisions, and it shouldn't take days or weeks to get those answers.
And yet, at most companies we've worked for or clients we've worked with, these questions are nearly impossible to answer quickly, accurately, and consistently. This is primarily because these questions sit on top of three data design problems that have to be solved first, and most multi-location rollups haven't solved them properly.
The Scenario
Picture a multi-location fitness chain (smaller versions of concepts like Orangetheory, Pure Barre, etc.). Twelve studios across three major cities, acquired over eighteen months. They offer one-off classes, memberships, and a small amount of retail at each location.
Each acquired studio came with the software it was running pre-acquisition. Three run MindBody. Four run ClubReady. Two are on Booker. Three are on a smaller regional platform that the previous owner swore by. All of them are technically class-based fitness management platforms. All of them have a POS, a member database, a class schedule, and a reporting layer.
Seasoned operators know this type of setup can cause all kinds of operational complexities, and will often try to transition newly acquired locations onto a common operational software. But that's not always a realistic option, and this is where a lack of unified reporting makes it difficult to make the smartest decisions possible: the business starts running on a shared drive full of spreadsheets, a Looker report that only covers eight of the twelve studios, and a growing consensus that "the data isn't clean." Nobody can explain exactly what that means.
Here's what's actually happening underneath.
Problem #1: The systems disagree on what a customer is
This is the problem that blocks the first question, the one about unique customers across the portfolio.
Every platform has a concept of "a customer." Every platform calls it something different. MindBody has clients with a client_id. ClubReady has members with a member_number. Booker has customers with a customer_guid. The regional platform uses email address as the primary key.
The business concept is identical, but the data structures produce 4 different representations of it.
This one is tractable. It's a mapping problem. Someone sits down, writes out which field in each source system corresponds to your internal definition of a "customer", and your data team does the work to line these definitions up in the background. Call it two to four weeks of work the first time, plus small ongoing maintenance when source systems change their schema.
This is table stakes, but the challenges get more complex from there.
Problem #2: The systems disagree on what they're counting
This one blocks the second question, about same-location visit growth, and it's where most internal data teams get stuck without realizing why.
Ask: how many visits did we have last month across the portfolio?
MindBody counts a visit when a client checks into a class. ClubReady counts a visit when a member scans in at the door, which can happen whether or not they take a class. Booker's default reporting counts a visit when an appointment is marked complete. The regional platform counts a visit at time of booking, which includes no-shows.
Four platforms, four different definitions of "a visit," and the business hasn't picked one. The reporting at each individual studio is internally consistent. The MindBody studios all count visits the same way as each other. It's when you try to roll them up that the definitions collide and the portfolio number becomes nonsense.
The fix here isn't technical. The fix is that the business has to pick an internal definition of each metric that matters. Probably "a completed, in-person class or session" for visits, or whatever the CEO decides. Every source system's data then has to be transformed to match that definition before it rolls up. During implementation, this is where data teams and practitioners need to speak up and do their best to get everyone on the same page before it's too late and a lack of trust in reporting becomes a company-wide theme.
This is one of the more difficult parts of "data" work for people who excel at technical development, but less experience with stakeholder management. Some of the hardest work we do is getting multiple people in a room and working with them to agree on what a visit is or how lifetime value should be defined. The data team can't do that unilaterally, but they can promote the importance of starting from defining key metrics and working backwards from there.
Problem #3: The systems don't know two customers are the same person
This one blocks questions three and four, about retention and location performance. It's the hardest of the three, and it's the one that determines whether your portfolio dashboard can answer the questions that actually matter.
A customer who takes classes at two of your studios, one near their office and one near their apartment, exists as two separate records. Different customer IDs, different platforms, different check-in histories. From your warehouse's perspective, that's two people.
If 15% of your customers visit more than one location, which isn't unusual in the fitness class world, your unique customer count is inflated by roughly that amount. Your retention rate is understated, because a customer who stopped coming to Studio A in March and started coming to Studio C in April looks like one churned customer and one new customer instead of one loyal customer who changed locations.
Then there's the messier version. "Jim Smith" at Studio A. "J. Smith" at Studio B. "Jim S." at Studio C, with a different email than the first two. All the same person. Until you resolve that, none of your cross-studio analytics are trustworthy, and you're forced to make impactful decisions on information that is only directionally accurate at best.
This is called identity resolution. Doing it well means matching records across systems using combinations of email, phone, name, date of birth, and behavioral patterns. There are tools that help, techniques that work, and plenty of edge cases. It's more complex engineering work, and it's usually the piece that determines whether your eventual dashboard is grounded in truth or simply a directional barometer.
Why the basic questions are hard
Add up the challenges above and you can see why answering the basics accurately can take months instead of just a same day investigation. The reason the basic questions are hard to answer is that each one sits on top of a foundation problem that most rollups haven't finished solving (or oftentimes, even started solving).
This pattern repeats across every multi-location vertical we've looked at. Fitness, dental, vet, restaurants, early childhood education, etc. Different industries sharing the same foundational problems.
How does AI resolve (or amplify) this problem?
This is going to get louder in 2026 because of AI copilots.
A copilot on top of an unresolved multi-location stack will happily answer the basic questions. It will join whichever tables look most relevant, pick a definition of "visit" based on whichever table it happens to hit first, and report a unique customer count that double-counts multi-location members. Fast, confident, and wrong.
The questions that were hard to answer before AI are still hard, but AI can answer them faster (and incorrectly).
If you're investing in or operating a multi-location rollup thinking about your company's 2026 AI roadmap, a reasonable question to ask is whether the foundation problems have been solved yet. If they haven't, the AI layer is going to amplify whatever's already broken.
The takeaway
If the basic questions are still hard to answer at your company, it's usually not a problem with your tooling or the quality of your analysts. More often, it's a foundation problem that, once solved, can introduce a step-change unlock to the way you run your company.
The good news is that the three foundation problems are known, bounded, and solvable in a predictable order. Schema first, then definitions, then identity. Most rollups we've worked with get the first one done, skip the second, and never finish the third. That's why dashboards may never feel right, even after months of work.
The questions aren't hard. What's underneath them is.