01 — THE GROWTH PROBLEM
The first location is a business. The tenth is a system.
Nothing about adding locations is complicated in isolation — each one is just another site with its own calendar and staff. The complication is cumulative: every new location multiplies the number of places where consistency has to be maintained, and consistency only survives when somebody — or something — is holding it together.
One team knows everything. The business lives in people's heads and that is fine — the business fits in one room.
Shared processes start appearing. Someone writes the first version of 'how we do this everywhere.' The first process is born.
Consistency becomes difficult. Ten local calendars, ten price conversations, ten versions of the same service. Growth starts producing drift.
You need governance, visibility and local control at the same time. The business has become a system, whether or not anyone built one.
The numbers are illustrative of the shape of growth, not a claim. What changes at every step is not the number of doors — it is what keeping them consistent requires.
The first location runs on memory. The third runs on habits. The tenth needs rules written down. The twenty-fifth needs rules that are enforced by the system rather than by whoever happens to be diligent that week. This is not a warning about growth — it is the reason growth stops being progress when the operations do not grow with it.
02 — THE REAL PROBLEM
Growth creates a choice you shouldn't have to make.
Most multi-location operators end up pushed toward one of two extremes, and both are expensive. The first mistake is over-centralizing: headquarters controls everything and every local exception becomes a ticket. The second is over-decentralizing: every location runs its own version of the business and leadership loses the ability to see it. The choice between the two is a false one — the product exists precisely because the answer is both, made explicit.
Too centralized
Central change requests queue for days while a local problem waits.
A branch that knows its own afternoon is still locked into someone else's schedule.
Every exception becomes a message, a wait, and a compromise.
The cost: speed. Local teams know their own streets, but they have to ask permission to act on it.
Too decentralized
Ten different processes for the same service, none of them comparable.
Leadership assembles the picture by hand — and by then it is a week old.
The same customer meets a different business at every door.
The cost: coherence. Every location works, but nobody can see the whole business work — or prove it to anyone.
Shared foundation + explicit local control
Not a compromise between the two extremes — a structure that separates what the business should share from what each location should decide. The shared layer is defined once and enforced everywhere. The local layer is deliberate, recorded, and never silently drifts. Each location keeps the freedom to operate its own day; the business keeps the model that made it work in the first place.
04 — THE INHERITANCE MOMENT
Central control without central micromanagement.
This is the idea the rest of the page is built on, demonstrated instead of explained. Below: one central service definition, three branches. Press the button and watch what a central change actually does — which branches inherit it, which keep their deliberate override, and why that combination is exactly what multi-location teams need.
CENTRAL SERVICE
$40
Inherits the central price$46
Local override — stays as set$40
Selected in the bulk updateChange it once at the center. Branch A and C inherit the new price; Branch B keeps its deliberate local override. That is central control without central micromanagement.
Micromanagement is central control without this mechanism — someone checking each site's prices by hand. Autonomy without inheritance is the opposite failure: nobody knowing what the business actually charges where. Inheritance is the difference.
05 — REGIONAL MANAGERS
Give every leader the right amount of the picture.
An owner needs everything. A regional manager needs their region. A location manager needs their site. Staff need their work. The same organization contains all four views, and the system's job is to hand each person precisely the slice they are responsible for — no less, so nothing is missed; no more, so nothing is noise.
The whole business: every region, every location, consolidated numbers.
The hierarchy is an organizational chart rendered as a working surface: each level opens the layer below it and stops there. This is product behavior, not an RBAC diagram — the deep permission model is documented on the documentation and security pages.
06 — PERMISSIONS & CONTROL
Visibility should follow responsibility.
Permissions in a multi-location business are not a technical feature — they are the shape of trust. A regional manager should be able to fix anything in their region and unable to touch anything outside it. The system enforces that boundary on every surface and every server call, so governance survives staff changes, busy weeks and good intentions.
Regional manager
Can
View their region Manage their region's locations Drill into any location in the regionCannot
Change another region Touch platform-level settingsLocation manager
Can
Manage their location's schedule and staff Override local hours and availability Read their location's customers and bookingsCannot
See other locations' operations Change shared service definitionsRoles are checked at the route layer and inside every server function — a permission cannot be bypassed by calling an endpoint directly. For the full permission model, read the documentation and the security page.
07 — CONSOLIDATED REPORTING
See every location without flattening them into one number.
Leadership reporting usually fails in one of two directions: a single consolidated number that hides the location where things are going wrong, or twenty separate reports that nobody has time to read. QUE's reporting moves between the two deliberately — overview, region, location — so the same surface shows the whole business and then opens any part of it.
All locations
Click a region's location row to drill down →
The drill-down is the point: the overview exists so leadership knows where to look; the location view exists so they can see why. Between them, the business stays legible at whatever scale it has reached.
08 — THE MORNING VIEW
Open the dashboard. Know where the business needs you.
The highest-value fifteen minutes of a multi-location leader's day are the first ones — when the whole estate is quiet enough to read at a glance. Four locations, four different stories: one is healthy, one is busier than usual, one has a staffing problem nobody has called about yet, and one is catching unexpected demand. The morning view shows all four before the phone calls start.
Healthy
Openings filling steadily. No exceptions.
Busy
Near capacity all afternoon. Worth watching.
Staffing issue
Two absences on the midday roster.
Unexpected demand
A local event drove walk-in interest this morning.
You do not need four phone calls to know where to focus. The dashboard shows which location needs a manager today — and the drill-down opens that location's day in one step. (The view reflects the data the system records; it does not claim real-time telemetry beyond what the platform supports.)
09 — OPENING A NEW LOCATION
Start the new location from a foundation that already works.
The hardest part of opening a location is usually the systems work: the catalog, the roles, the forms, the brand, the reporting — all of it built from zero while the rest of the business keeps running. A location template turns that into selection. Pick the location whose operating model is closest to the new one, clone what should carry over, override what genuinely differs, invite the local staff, open the doors.
Usually the flagship — the location whose operating model is closest to the new one.
Catalog, services, roles, forms and brand carry over as one operation.
Hours, pricing, staff and local availability — the things that genuinely differ.
The local team joins with the roles the model already defines.
The location books its first appointment on the same foundation as the rest of the business.
What the template carries
Every checkmark above is the operating model arriving finished. Every 'customize' is a deliberate local decision made once, at opening, and recorded from day one. The new location opens as a member of the business — not as a project.
10 — THE OWNER'S MOMENT
The new location shouldn't feel like starting over.
There is a specific feeling every growing operator knows: the new location is exciting, and simultaneously it is the seventh set of systems to configure, the fourth staff roster to build from scratch, the third time rewriting the service list with slightly different formatting. The feeling is 'we are doing this all again.' It should not be.
Without a template
- Rewrite the service catalog with slightly different formatting
- Rebuild the staff roster and roles from zero
- Reconfigure forms, brand details and reporting manually
- Hope the new site ends up consistent with the others
With QUE
- Choose the operating model that already works — clone it
- Override only the things the new site genuinely differs on
- Invite local staff into roles the model already defines
- Open with the same foundation the rest of the business runs on
The excitement of a new location deserves better than being buried under systems work. The operating model should travel — that is what this page is really selling.
11 — CUSTOMER CONTINUITY
Customers shouldn't feel your internal organization chart.
Internally, the business is an org chart: regions, locations, roles, boundaries. To the customer, it should be one business with several doors. When a customer books at one branch, visits another, and books a third — the business should recognize the same person all three times, with the same history and the same relationship.
Books a consultation at the downtown branch. The record starts one identity — no new profile per branch.
Visits the northside branch. The team there sees the same customer, same history, same relationship.
Books again — this time at the eastgate location. The business still sees one customer, not three strangers.
The same customer record at every branch — no new profile per location.
What they booked, where and when — visible as one relationship.
Balances follow the customer across locations where supported.
The customer-facing experience carries the same identity at every door.
Customers pick the branch that suits them — the system handles the rest.
To the customer, it should still feel like one business. That sentence is the entire test of a multi-location operation — and the reason continuity is an operational capability, not a marketing line. Where the platform supports shared identity, wallet and credits across locations, it does so on the same tenant model that keeps everything else consistent.
12 — LOCAL AUTONOMY
Central standards. Local decisions.
Centralization that sounds like headquarters taking over is not what this page sells. The point is the opposite: central standards exist so that local teams are free to make local decisions about the things that genuinely belong to them — without re-negotiating the whole operating model every time.
Central — defined once
Brand Service definitions Roles & permissions Templates & forms Reporting modelLocal — decided on site
Hours Price Staff Local availability LanguageGive locations room to operate without giving up the system. The line between the two columns is drawn deliberately, recorded as overrides, and reviewable at any time — which is what makes autonomy sustainable instead of accidental.
13 — BULK OPERATIONS
Change 40 locations without changing 40 screens.
Some changes belong to the whole business: a holiday hours update, a price revision, a catalog cleanup. Without bulk operations, each one is an afternoon of clicking through location after location — and every click is a chance to miss one. With them, scale turns repetition into one deliberate action.
01 · Select
02 · Change
03 · Preview affected
Notice the three results: applied, skipped because of a local override, and flagged for review. A bulk change that silently overwrites a deliberate local decision is not an improvement — it is centralization by another name. The preview step is what keeps bulk operations honest.
14 — AUDIT & ACCOUNTABILITY
When something changes, you should know who changed it.
In a multi-location business, 'who changed this?' is not a curiosity — it is a governance requirement. A price change at location 17, a hours override at Harbor, a bulk update across a region: each needs a record with a name, a timestamp and a place. Auditing is where trust in the system gets written down.
Updated shared service price
East regionOverrode local hours — Harbor
HarborApproved bulk hours change — 3 locations
East regionWho changed what, when, and where it happened — written to a per-record audit log as it occurs, readable afterward as history rather than reconstructed from memory.
The audit trail covers the operations that matter for governance — configuration changes, booking operations, and the state changes teams need to reconstruct afterward. Combined with role boundaries, it means growth adds accountability rather than obscurity.
15 — THE CUSTOMER'S WEEK
One relationship. Three doors.
Stories make capabilities tangible. Here is one customer's week at a three-branch business — and underneath it, the operational fact that makes the story possible: the business sees one customer, not three strangers.
Monday, the customer books a consultation at Downtown. Wednesday, they visit Northside — and the team there knows them, because the record is the same one. Friday, they book again at Eastgate. The internal machinery — tenant model, role scoping, per-record history — keeps the relationship continuous without anyone at any branch doing anything special.
The business still sees one relationship. The customer still feels one business. That is what shared customer identity is for.
16 — A MULTI-LOCATION DAY
One day at the estate, told through the system.
The best way to understand whether a system can carry a growing business is to watch it through a single day. Same day, four layers of the organization, one continuous record — this is the operational equivalent of the studios day, told at estate scale.
The day opens with every location legible in one view — bookings, occupancy, staffing and exceptions on each site. The first decision of the day is made from the whole picture, not from whichever phone rang first.
A location starts filling faster than its pattern. It surfaces in the overview without anyone refreshing anything or asking anyone — the pattern is visible because the data already flows there.
From the region roll-up into the busy location: its schedule, its staff, its exceptions. The drill-down takes the manager to exactly the slice of the business they own — nothing more, nothing less.
The location manager adjusts the afternoon roster for the staffing issue. The change belongs to that location and stays there — central definitions untouched, local reality handled locally.
HQ revises a shared service definition. Locations without a local override inherit the change; locations that deliberately differ keep theirs. One deliberate action, correct everywhere.
Roll-up numbers across the estate, drill-down into anything that needs it, and an audit trail recording who changed what — so tomorrow morning starts settled again.
The day works because the system already holds the relationships: locations inside regions, roles inside the hierarchy, changes inside the audit trail. Nothing in this timeline is heroic — which is exactly the point.
17 — DIFFERENT MULTI-LOCATION MODELS
However the estate is organized, the model holds.
Franchise networks, company-owned branches, multi-brand groups and regional operations all face the same underlying problem — consistency plus local freedom — but they organize it differently. Pick the model closest to yours and see how the same foundation adapts.
Central standards, regional management, shared reporting.
Every branch is yours, which means consistency is the product. Regional managers carry a region, location managers carry a site, and leadership reads the business as one number it can always open.
Central
Central standards Role model Shared reportingLocal
Local hours Local staff Local availabilityOnly models the product's foundation can actually support are shown here. The tenant model, role scoping and shared definitions are what make each of these four shapes possible — the differences between them live in how the same mechanism is configured.
18 — WHEN MULTI-LOCATION IS A GOOD FIT
You probably need this when growth starts creating coordination problems.
Honesty improves the quality of the customers who sign up. If the description on the left matches your business, this page is about you. If the description on the right does, QUE still serves you well — just not for the multi-location reasons, and it is worth saying so plainly.
Good fit
You have multiple locations, or you are about to open your second. Services need to stay consistent across sites. Pricing varies locally, and you want that variation to be explicit. Regional managers need access to their region and nothing more. Leadership needs roll-up visibility with drill-down when something looks off. Opening locations involves repetitive setup that a template would kill. Customers move between branches and should be recognized wherever they go.Poor fit
You have one simple location with no plans to add another. Your locations are intentionally independent businesses. You do not need shared reporting across sites. You are not ready for centralized governance — and that is fine; QUE works for a single location too.The multi-location surface is built for businesses whose complexity is growing faster than their staffing can absorb it. If your complexity is not growing, the single location experience — the same product, without the estate layer — is the right door.
19 — WHAT THE BUSINESS GETS
Six outcomes, none of them generic.
Not 'save time' or 'increase revenue' — those are consequences, not outcomes. These are the specific operational changes a multi-location team experiences, each one following directly from the shared/local structure demonstrated above.
Shared definitions mean the same service, the same brand and the same standards everywhere — without forcing anyone to re-enter them anywhere.
Explicit overrides mean a location can be different where it should be, and identical everywhere else. The difference is recorded, not improvised.
Roll-up shows the business; drill-down shows the location. Leaders stop assembling the picture by hand and start acting on it while it is still true.
Role boundaries define who sees what; the audit trail records who changed what. Growth adds people, not unmanaged access.
Reusable location templates turn 'open a new site' from a systems project into an afternoon — catalog, roles, forms and brand arrive already done.
One relationship across locations, where supported. The customer books at any branch and the business recognizes them at all of them.
20 — COMPARISON
Scale without multiplying the work.
Six of the problems that multi-location growth reliably produces, side by side: how they are handled without a shared model, and how they are handled with one. Every row describes verified product behavior or clearly-supported capability.
21 — TECHNICAL DEPTH
Governance that still works when the organization gets complicated.
For the technical evaluators: the multi-location surface rests on the same documented architecture as the rest of the platform. Every claim in this section links to documentation that can be verified rather than asserted.
Every business is an organization record that owns its services, staff, locations, resources, bookings, customers, domains and payment accounts. The organization is the boundary the rest of the model is built around.
App roles are checked both at the route layer and inside every server function — a permission cannot be bypassed by calling an endpoint directly. Navigation and server functions are filtered to real capabilities.
Role configuration and location-scoped views determine who sees what — regional managers work inside their region, location managers inside their site. Governance scales without exposing everything to everyone.
A per-record audit log: who changed what, when, and from where. When something changes at a location, the answer to 'who did that?' is one lookup away.
Booking operations, customers and schedules are exposed through a documented API, with webhooks per workspace for the integrations your stack already depends on.
The production architecture is self-hosted: a Docker stack on a dedicated host, every query executed under the tenant's role through row-level security. Tenant boundaries are enforced by the database, not assumed by application code.
22 — BUILT TO GROW WITH THE ORGANIZATION
Architecture that does not need re-platforming at location twenty-five.
Scale claims without methodology are marketing. What can be said honestly: QUE's architecture is self-hosted, tenant-isolated and governed by the database itself. The operational principles below are what make an estate of locations sustainable — whatever number that estate reaches.
A Docker stack on a dedicated host: edge, application, database, queue and observability on private networks. Your data never shares infrastructure with another business.
Every query executes under the tenant's role through row-level security. Tenant isolation is not assumed by application code — it is enforced where the data lives.
The self-hosted stack ships with the monitoring and logging surfaces an operating business needs, so growth shows up in the dashboards before it shows up in the complaints.
The architecture is portable: standard containers, standard databases, standard queues. The estate can move with the stack, because the stack is yours.
No benchmark figures are marketed here — scale capability is demonstrated by the architecture, and the deployment details are documented for evaluation rather than asserted as a number.
23 — COMING TO QUE
Planned, not sold.
A customer must always know whether something is available now or planned. Everything above this section is available. The two items below are explicitly roadmap — shown here because multi-location buyers ask, and because promising nothing honestly beats promising everything vaguely.
Automated royalty calculation and brand-fund tracking per location, inside the platform rather than beside it.
Deployment options that let large operators keep data within defined regions, alongside the existing self-hosted architecture.
24 — QUESTIONS, ANSWERED STRAIGHT
Everything a multi-location operator asks before deciding.
These answers are written to be verifiable: capability questions point at what the platform does, roadmap questions are labeled as such, and nothing here is dressed up as more than it is.
QUE's model treats locations as first-class records inside one organization — you manage as many as the business needs, each with its own schedule and assignments. Very large estates use the same model; governance comes from roles and scoping rather than from a location count.