Multi‑Location Configuration in Gymizen: A 30‑Day Rollout Playbook (Permissions, Shared Members, Reporting, and Approval Gates)

Multi‑location operations are where “small inconsistencies” become recurring churn drivers: different cancellation rules at different sites, staff over‑permissioned in one location, reporting that can’t reconcile, and exceptions handled differently depending on who’s on shift. Gymizen is built to be operator‑led—so a successful multi‑location rollout isn’t just configuration. It’s a rollout plan that standardizes what should be standard, localizes what must be local, and uses approval gates to keep that design intact once real life starts.

This guide is a concrete 30‑day implementation walkthrough for owners and managers rolling out Gymizen across two or more locations (CrossFit, yoga, pilates, martial arts, boxing). You’ll define your location architecture, configure staff permissions, set “shared member” rules, align class and reservation workflows, and launch a reporting rhythm that keeps retention‑first operations consistent—without forcing every site into the same mold.

Who this playbook is for (and what it assumes)

Use this playbook if you have 2+ locations (or you’re opening your next one) and you want Gymizen to support a single operator model: consistent member experience, consistent data, and consistent controls—while still letting each location run efficiently day‑to‑day.

Prerequisites (finish or decide these first)

• Locations list: exact names as you want them in Gymizen (e.g., “Downtown”, “North”, “West”).
• Offer and policy map: which memberships, packs, and rules are global vs. location‑specific.
• Staff roster: who works where, who floats, who needs cross‑location access, and who should not.
• Decision on shared members: whether members can book across locations, and under what conditions.
• Reporting needs: the minimum weekly owner dashboard, plus what each manager needs daily.
• Cutover window: your preferred go‑live week and any dates you must avoid (events, challenges, holidays).

Implementation principle: If you can’t describe the rule in one sentence, you can’t enforce it with an approval gate. Start with a simple, enforceable baseline—then iterate after week 4 of live usage.

The 30‑day rollout timeline (overview)

Multi‑location rollouts fail when teams try to “configure everything” before anyone uses it. This timeline gets you live with the right controls, then improves the system with real operational feedback.

1. Days 1–5: Location architecture + global vs. local standards (your operating model).
2. Days 6–10: Staff onboarding, roles, and permissions by location (with audit checks).
3. Days 11–15: Shared member rules + products + policy alignment (and where to localize).
4. Days 16–20: Scheduling, reservations, waitlist, and attendance workflows per location with QA.
5. Days 21–25: Reporting, review cadence, and escalation paths (exceptions → approvals).
6. Days 26–30: Go‑live rehearsal, location‑by‑location validation, and launch week SOPs.

Step 1 (Days 1–5): Design your multi‑location architecture

Before you touch settings, align on a foundational choice: are you operating one brand with multiple sites, or multiple semi‑independent gyms with shared ownership? Gymizen can support both, but your configuration should reflect the reality you want to enforce.

Define what’s global vs. local (recommended defaults)

Use this table as your starting point. You can localize later—but if you start too localized, you’ll create reporting noise and inconsistent member experience.

• Global (standardize by default): core membership plan names, cancellation window logic, no‑show policy principles, staff roles, approval‑gated exception types, tagging/segmentation standards, and owner KPI definitions.
• Local (allow differences intentionally): class caps (room size), class types unique to a location, coach roster, local promotions, local schedule density, and location‑specific events.
• Hybrid (start global, localize if needed): pricing, late‑cancel fees, intro offer availability, and visitor drop‑in rules.

Location naming conventions (so your reporting stays clean)

• Keep location names short and consistent (avoid “Downtown Studio – Main” and “DT”).
• If you plan to expand, don’t name a location “HQ” unless it’s truly permanent.
• Use the same naming format in staff communication (Slack channel names, SOP docs, staff schedules) to avoid operational drift.

Step 2 (Days 6–10): Staff onboarding + permissions by location (with approval gates)

Multi‑location teams usually have three permission failure modes: (1) everyone can do everything “because it’s easier,” (2) one location becomes the “exception location” with sloppy access, or (3) floating staff get stuck when they legitimately need cross‑location tools.

Your goal is to set role‑based access with location scope, then place approval gates around any action that changes revenue, member standing, or policy outcomes.

Recommended role map (boutique fitness default)

• Owner / Operator Admin (global): full access across all locations; approves policy exceptions; reviews weekly retention KPIs.
• General Manager (per location): manages schedule, coach assignments, day‑to‑day member issue resolution; can request exceptions; limited cross‑location reporting.
• Front Desk Lead (per location): check‑in, basic account support, sells approved products; can initiate refunds/holds only as requests (approval‑gated).
• Coach (per location): roster visibility, attendance marking, notes relevant to coaching; no billing tools; no membership changes.
• Floating Staff (multi‑location): front desk or coach access across specified locations; still constrained by role gates.

Approval gates to enable on day one (multi‑location safety net)

In multi‑location environments, the number of hands in the system increases—so approval gates protect you from “good intentions” turning into revenue leakage or policy inconsistency.

• Refunds and reversals: front desk can draft; manager approves; owner signs off above a threshold.
• Membership changes: downgrades, plan swaps, or special pricing require approval when they deviate from published options.
• Policy overrides: late cancel waives, no‑show forgiveness, and retroactive adjustments should be approval‑gated (especially across locations).
• Cross‑location “comping”: any manual credit intended to “fix” an experience should be treated as a request with reason codes.

QA checks (end of Day 10)

1. Log in as a Front Desk user at Location A: confirm they can check in members, view today’s schedule, and sell only approved items.
2. From that same user, attempt to perform a restricted action (refund, plan change, policy override): confirm it routes as an approval request (not a silent action).
3. Log in as a Coach: confirm they can mark attendance but cannot access billing or global settings.
4. Log in as a Location Manager: confirm they can run location reports and manage location schedule; confirm they cannot change global standards unless intended.
5. Validate a Floating Staff user: confirm they can access only the locations they should—no accidental global scope.

Step 3 (Days 11–15): Shared members, products, and policy alignment

The fastest way to create multi‑location chaos is to allow cross‑location booking without clear rules. The second fastest way is to block cross‑location booking but still market the brand as “use either location.” Decide what you mean, then configure accordingly.

Choose your shared‑member model (pick one to start)

1. Model A — Fully shared: one member record; memberships and packs can be used at any location; consistent policies. Best for a single brand with strong standardization.
2. Model B — Shared member, controlled access: members can visit other locations, but only with specific products (e.g., “All‑Access”) or limited drop‑in rules. Best for brands with different pricing or capacity constraints.
3. Model C — Mostly separate: location‑specific memberships; visits across locations require a special pass or manual handling. Best when locations operate like separate businesses.

Most operators should start with Model B. It gives you a shared customer view (retention wedge) without forcing identical economics at every site.

Recommended defaults for cross‑location products (simple and enforceable)

• All‑Access membership: the only plan that books anywhere without friction.
• Home‑location membership: books only at the home location; cross‑location drop‑ins require a separate product.
• Cross‑location drop‑in pass: limited quantity and clear rules (e.g., “2 visits/month outside home location”).
• Intro offers: decide whether intros are redeemable at any location or only the purchase location; keep the rule consistent and visible to staff.

Policy alignment checklist (what must match if members are shared)

1. Cancellation window (e.g., 8–12 hours): if different by location, you’ll create “policy shopping.”
2. No‑show definition: what counts as a no‑show and when fees apply.
3. Waitlist behavior: how late members can be auto‑moved from waitlist into class.
4. Late arrival rules: whether members can enter after start time and how attendance is recorded.
5. Exception handling: what can be waived locally vs. what requires approval.

Step 4 (Days 16–20): Scheduling, reservations, waitlist, and attendance—location by location

This is where multi‑location rollouts often drift: one site configures “the right way,” the other site copies it but tweaks a few settings to deal with daily friction—then a month later, the brand feels inconsistent and your reporting can’t explain why.

Instead, configure in two passes: (1) standard base templates, (2) location overrides with documented reasons.

Pass 1: Create standard schedule & reservation defaults

• Class naming standards: keep the same class type names across locations when the experience is the same (e.g., “Yoga Flow” vs. “Flow Yoga”).
• Capacity rules: set caps based on true room/equipment limits; don’t “cap lower” as a vibe tactic unless you can articulate the retention impact.
• Reservation window: pick a default (e.g., 7 days) and keep it consistent; only override when you have a capacity rationale.
• Late cancel/no‑show enforcement: define the standard behavior; then decide what gets waived and how (approval‑gated).

Pass 2: Apply location overrides (with a written reason)

Allow location managers to request overrides only when they can give a simple reason you can measure. Examples: “smaller room,” “shared parking restrictions,” “different peak demand pattern,” or “equipment-limited format.”

• Override categories to allow: class caps, buffer times, coach assignments, and location‑specific class types.
• Override categories to restrict: cancellation windows, waitlist rules, and fee logic (these should stay standard unless the business model is truly separate).

QA checks (end of Day 20): schedule and attendance sanity test

1. Create a test member with a Home‑Location plan for Location A; verify they can book A but not B (unless intended).
2. Create a test member with All‑Access; verify they can book both locations and see the correct policies at checkout.
3. Join a waitlist at each location; confirm the auto‑move behavior matches your policy (especially close to class start).
4. Mark attendance from a coach login; confirm the coach can only affect classes they’re assigned to (or as intended).
5. Run a “today” operations pass at each location: check‑in flow, late arrival handling, and exception request flow for a no‑show waive.

Step 5 (Days 21–25): Reporting workflows + the multi‑location operating cadence

Multi‑location reporting is where operators either win (clear visibility, fast fixes) or lose (arguments about whose numbers are right). The trick is to define one source of truth, then run a repeatable review cadence where each role knows what they own.

Role‑by‑role responsibilities (what each person does weekly)

• Owner: reviews brand‑wide KPIs weekly; approves policy exceptions above thresholds; decides on standard changes (not ad‑hoc).
• Location Manager: reviews location dashboards daily; owns schedule health, attendance exceptions, and operational follow‑ups.
• Front Desk Lead: owns daily closeout hygiene (exceptions logged, requests submitted, no silent fixes).
• Coaches: owns attendance marking accuracy, member notes, and early risk signals surfaced to managers.

Recommended multi‑location review rhythm (simple but strict)

1. Daily (per location, 10 minutes): exceptions review (late cancels, no‑shows, policy requests), upcoming class capacity issues, and unresolved member issues.
2. Weekly (owner + managers, 45 minutes): compare locations on the same KPIs, identify 1–2 operational experiments, and approve or reject requested policy drift.
3. Monthly (owner, 60 minutes): decide whether to standardize a successful local change—or remove it.

Approval-gated escalation path (so exceptions don’t become policy)

Your team will face member requests that feel reasonable in the moment. The system works when those requests become structured inputs, not silent one‑offs.

1. Front desk captures the request + reason code and submits as an approval request (no “just do it”).
2. Location manager approves routine exceptions within policy boundaries (if allowed) or escalates.
3. Owner approves exceptions that change economics, undermine standards, or set precedent.
4. Weekly review aggregates recurring exceptions: if the same exception happens repeatedly, you either fix the root cause or formalize the policy.

Step 6 (Days 26–30): Go‑live rehearsal + launch week SOPs

A multi‑location go‑live fails when one location “gets it” and the other doesn’t—because staff confidence and member experience diverge immediately. Your goal is a coordinated launch with localized training reps, plus a single escalation channel for launch week.

Launch week staffing plan (minimum coverage)

• One “Gymizen Captain” per location: manager or desk lead who owns checklist completion and triage.
• One owner/ops admin daily window: a scheduled 30–45 minutes to clear approval requests fast during the first week.
• Coach briefing: a 10‑minute pre‑shift reminder on attendance marking, member notes, and what to do when something looks wrong.

Go‑live rehearsal script (run it twice: once per location)

1. Book a member into a class, then cancel within policy: confirm correct outcome.
2. Book a member into a class, then simulate a late cancel: confirm the correct fee/flag and that any waive is approval‑gated.
3. Join a waitlist, then test auto‑move timing near start time (and confirm staff knows how to explain it).
4. Check in a member at front desk; ensure scanning/manual entry works and attendance reflects correctly.
5. Submit a refund request from a front desk login: confirm it routes to approval and is recorded as a request.
6. Run end‑of‑day: confirm the location manager can reconcile exceptions and the owner can view cross‑location summary.

Common multi‑location mistakes (and how to avoid them)

• Mistake: letting each location invent its own rules “for now.” Fix: start with one standard baseline; only override with a written reason and an owner review date.
• Mistake: giving floating staff broad permissions because it’s easier. Fix: scope by role first, then add location access second; keep approval gates on revenue/policy actions.
• Mistake: inconsistent class naming across locations. Fix: standardize names where the member experience is the same; reserve “unique names” for truly unique formats.
• Mistake: cross‑location booking without cross‑location policy alignment. Fix: either align policies or control cross‑location access via specific products (recommended).
• Mistake: reporting that mixes apples and oranges. Fix: define one KPI dictionary (what each metric means) and run the same weekly review agenda every week.

What success looks like (Week 4 after launch)

By the end of your first four live weeks, you should be able to answer these questions in Gymizen without debate, manual spreadsheets, or “it depends who ran the desk that day.”

1. Are policies consistent? Exceptions exist, but they’re captured as requests and reviewed—no silent overrides.
2. Is access clean? Coaches and front desk staff can do their job fast, but cannot accidentally create revenue leakage or precedent.
3. Is cross‑location behavior intentional? Members can book across locations only when their product allows it; staff can explain the rule confidently.
4. Is reporting trusted? Owners can compare locations and see where retention risk is forming, and managers know what to fix this week.
5. Is adoption real? Each location uses the same daily workflow: check‑in, exception logging, approvals, and closeout—without shadow processes.

Appendix: The multi‑location launch checklist (copy/paste)

• Architecture: locations named; global vs local standards documented; shared member model chosen.
• Permissions: roles created; location scoping applied; floating staff validated; approval gates enabled for refunds, plan changes, and overrides.
• Products: All‑Access vs Home‑Location offerings defined; cross‑location pass rules documented; intro rules clarified.
• Schedule: standard templates created; location overrides applied with reasons; caps and reservation windows verified.
• Workflows: waitlist behavior tested; attendance marking verified; exception requests route correctly.
• Reporting: daily and weekly review cadence scheduled; owner KPI set; manager dashboards confirmed.
• Go‑live: rehearsal completed per location; Gymizen Captain assigned; approval clearing window scheduled for week 1.

Next steps

After your multi‑location rollout is live, your job shifts from “configuration” to “operating rhythm.” Keep standards stable for four weeks, review exceptions weekly, and only then decide what to standardize further or localize intentionally. That’s how you keep retention‑first operations consistent across every class, coach, and front desk shift—without slowing down your teams.