Single‑Location Workspace Setup in Gymizen: A 9‑Step Configuration Checklist (So Your Team Can’t “Wing It” on Day 1)

This guide is for owners and managers who want Gymizen to feel operator-led from the first day—meaning: your team can move fast, but they can’t accidentally create policy by improvising. You’ll set up a single-location Gymizen workspace using an approval-gated approach: define the rules once, make common actions self-serve, and require review for anything that can cause revenue leakage, member confusion, or retention risk.

This is not a data migration guide or a go-live cutover checklist. It’s the configuration foundation you should complete before importing members and before asking staff to learn workflows—so training happens on the real system your team will run.

What “good” looks like after this setup

• Your schedule can be built without guessing (hours, time zone, and location defaults are correct).
• Staff roles map to real responsibilities (front desk can run service; managers can approve exceptions; coaches can coach).
• Members experience consistency (policies don’t change based on who’s at the desk).
• Exceptions are controlled (refunds/credits/holds/overrides route to the right approver).
• You can QA the workspace in under 30 minutes using a repeatable checklist.

Prerequisites (do these before you click anything)

Most workspace setup mistakes come from missing decisions—not missing clicks. Gather these inputs first so configuration is fast and stable.

• Business identity: legal business name, display name, address, phone, website, and your public support email (where member messages should route).
• Time zone and operating hours: include holiday rules (closed days) and “soft hours” (when staff is present but classes aren’t running).
• Facility map: rooms/areas (Yoga Room, Rig, Studio A), capacity constraints, and any bookable resources (reformers, bags, lanes).
• Staff roster: who is an Owner, General Manager, Front Desk Lead, Coach/Instructor, and who needs limited access (contractors).
• Decision owners: who approves pricing changes, refunds/credits, policy exceptions, membership holds, and comped bookings.
• Operational standards: how you define “late cancel,” “no-show,” grace periods, check-in expectations, and how far ahead members can book.

Implementation rule: If your team can’t explain a policy in one sentence, don’t configure it yet. Put it in a “parking lot” and go-live with the simplest version you can enforce consistently.

The 9-step single-location workspace setup checklist

Complete these in order. Steps 1–4 create a stable foundation; Steps 5–7 prevent permission drift and exception sprawl; Steps 8–9 ensure you can confidently train and launch.

Step 1) Create the location shell (identity, time zone, contact channels)

Start by configuring your single location as if you were a member discovering you for the first time. This prevents downstream confusion in receipts, notifications, and staff dashboards.

1. Set the time zone first. Everything else—class times, booking windows, automation timing—depends on it.
2. Confirm display name vs. legal name. Use the display name for member-facing communication; keep legal name for receipts if needed.
3. Set the default support email (the inbox your team actually checks). Don’t use a personal owner email unless you want to become the help desk.
4. Define your location phone and whether it’s front desk or shared.

Recommended default: Use one shared inbox (e.g., support@ / hello@) that can be monitored by your Front Desk Lead and GM. Then add an escalation path to the owner via approvals, not via “everyone DM the owner.”

Step 2) Define operating hours (and distinguish staffed vs. class hours)

Operating hours are more than a website detail. They shape your team’s internal expectations: when support is available, when same-day issues can be resolved, and when a member should expect a response.

1. Set standard weekly operating hours (Mon–Sun).
2. Add holiday exceptions (closed or modified hours).
3. Document your staffed windows separately (even if Gymizen only stores one set of hours, write this into your internal SOP).
4. Decide your response-time promise (e.g., “within 1 business day”). Use it consistently in member communications.

Common mistake: Setting hours to “when classes happen.” Then members assume someone is available at 9:00pm because the last class ends at 9:00pm—creating unnecessary support pressure and inconsistent exceptions.

Step 3) Configure spaces, resources, and capacities (so booking rules have something real to enforce)

If you skip resources and capacities, your team will enforce limits manually—and manual enforcement is where policies become personal. Set your physical reality in Gymizen so the software can protect you.

1. Create rooms/areas that reflect how you run classes (Studio A / Mat Room / Rig / Dojo).
2. Set default capacities by room based on fire code, equipment, and coaching quality.
3. If you have equipment-limited formats (Pilates reformers, boxing bags), create bookable resources and map them to classes where relevant.
4. Decide whether certain classes need buffer time (turnover between sessions). If you run back-to-back, document the cleaning/reset workflow for coaches and front desk.

Recommended defaults (single location): Keep room naming simple and staff-friendly. If a new hire can’t pick the correct room in 2 seconds, rename it. Your goal is speed + accuracy at the front desk.

Step 4) Set your “booking contract” defaults (the rules that should apply unless a manager approves an exception)

Before you build schedules or import members, define the default rules that shape member behavior: booking windows, cancellation windows, and what counts as attended. These are retention levers because they affect friction, fairness, and trust.

• Advance booking window: how far ahead members can book (often 7–21 days, depending on your model).
• Late cancel window: how close to class start a cancellation becomes a late cancel.
• No-show definition: what happens if a member is booked but not checked in.
• Check-in method: who marks attendance (front desk, coach, or self-check-in) and when (before vs. after class).
• Waitlist behavior: auto-add when spots open, and how members are notified.
• Drop-in vs. members: any different rules by membership type (keep differences minimal early on).

Approval-gated principle: Defaults should cover 95% of cases. The remaining 5% should be exceptions that route to approval—so you learn what needs a policy change versus what’s truly a one-off.

Step 5) Build staff roles and permissions around real work (not titles)

Your permission model is your operational model. If permissions are too loose, staff will “help” by doing things that should be reviewed (discounts, credits, overrides). If they’re too tight, your team will create side channels (texts, sticky notes, untracked promises).

Role-by-role responsibilities (recommended single-location baseline)

• Owner: final approver for refunds beyond a threshold, pricing/membership catalog changes, policy changes, and any exception that sets precedent.
• General Manager (GM): approves day-to-day exceptions (late cancel waivers, holds within policy, small credits), owns staff training, and owns QA checks weekly.
• Front Desk Lead: executes daily workflows (check-ins, basic account support), submits exceptions for approval, monitors operational inbox, and owns end-of-day reconciliation steps.
• Front Desk Staff: performs check-in/attendance, helps members book/cancel, flags account issues, but does not grant financial exceptions without approval.
• Coach/Instructor: manages class roster and attendance (as assigned), notes member issues for follow-up, but does not edit billing, pricing, or member financial adjustments.

Recommended default: Give coaches the ability to see what they need to coach (rosters, member notes relevant to training) without giving them the ability to create financial outcomes (credits, refunds, overrides). This keeps coaching relationships clean.

Step 6) Configure approval gates (decide what must be reviewed, by whom, and within what SLA)

Approval gates are how Gymizen stays operator-led. They are not “red tape.” They’re the mechanism that prevents your most expensive outcomes—revenue leakage and inconsistent member experience—from being decided in the moment by whoever is on shift.

The core approvals to define before go-live

• Refund requests: Who can submit vs. who can approve; define an amount threshold (e.g., under $X GM can approve, above $X Owner approves).
• Credits/account adjustments: Require a reason code + notes; approvals go to GM by default.
• Policy waivers (late cancels/no-shows): Front desk can submit; GM approves; capture why (first offense, documented emergency, system error).
• Holds/reactivations outside policy: GM approves; Owner for anything that changes standard terms.
• Discounts: Only managers (or owner) can apply; require approval for anything beyond a preset promo.

Set an internal SLA: Decide what “fast enough” approval means. Example: operational exceptions requested during staffed hours should be approved within 2 hours; after hours, by next business day. Publish this to staff so they stop making promises on the spot.

Step 7) Establish reason codes + notes standards (so exceptions become insight, not noise)

Approval-gated operations only work if the why is consistently captured. Otherwise approvals become subjective, and your team will feel like decisions depend on who is approving that day.

Reason codes you should standardize (minimum viable set)

• System / processing error (e.g., duplicate charge, booking glitch)
• First-time courtesy (use sparingly; track volume)
• Documented emergency (only when credible; keep notes factual)
• Staff-directed instruction (e.g., coach asked member to switch sessions)
• Facility issue (e.g., class canceled, equipment broken)

Notes standard (recommended): Require one sentence that would make sense to a manager reviewing it 10 days later: “Member booked 6:00pm, called at 5:20pm due to car accident; first late cancel in 6 months; waived per courtesy policy.”

Step 8) Run a 30-minute QA simulation (before training anyone)

QA is where you prevent Day 1 fire drills. Do a quick simulation using test staff accounts (or temporarily limit your own permissions) to ensure the system behaves as intended.

QA checklist: the 12 checks that catch 90% of setup issues

1. Time zone check: Create a test class and verify it appears at the correct local time.
2. Location identity: Confirm address/phone/support email appear correctly in member-facing communications (where applicable).
3. Room capacity enforcement: Attempt to overbook beyond capacity and confirm the system blocks or routes properly.
4. Waitlist behavior: Fill a class, add one member to waitlist, then free a spot and confirm the promotion flow works.
5. Attendance marking: Confirm front desk and/or coach can mark attendance per your policy.
6. Late cancel/no-show: Simulate a late cancel and confirm the correct outcome (fee, strike, or whatever your policy is).
7. Permission boundaries: Log in as front desk staff and confirm they cannot issue refunds/credits without approval.
8. Approval routing: Submit a refund/credit request and confirm it lands with the correct approver.
9. Reason code requirement: Ensure exception submissions require reason codes/notes (no “blank approvals”).
10. Operating hours sanity: Verify hours reflect real staffed expectations (especially weekends).
11. Notification sanity: Confirm staff notification volume won’t be overwhelming (route operational alerts to leads, not everyone).
12. Audit clarity: Confirm you can clearly see who requested and who approved an exception (this is the backbone of operator trust).

If you fail more than 2 checks, pause training and fix setup first. Training on a shifting system teaches staff to distrust the software—and they’ll revert to old habits.

Step 9) Train with a “permissions-first” workflow (so adoption sticks)

Most teams train by feature (“here’s the schedule screen”). Operator-led teams train by responsibility: what each role does, what they never do, and how approvals flow. This prevents improvisation—and protects retention through consistent experience.

Role-by-role training agenda (45–60 minutes per group)

• Owners (45 min): approvals dashboard, exception patterns to watch, how to update policies safely, what metrics to review weekly.
• GMs/Managers (60 min): approving/denying exceptions, enforcing reason codes, escalation standards, how to spot “policy drift,” QA routine.
• Front desk (60 min): check-in, resolving booking issues without exceptions, how to submit exception requests, what to say to members while waiting for approval.
• Coaches (45 min): rosters, attendance expectations, how to flag member issues for follow-up, what not to promise (credits, waivers) and how to route requests.

Script to standardize: “I can absolutely request that for you. We run approvals so policies stay consistent. You’ll hear back by [time].”

Recommended defaults for single-location operators (start here, then iterate)

These defaults are designed to reduce support load, prevent revenue leakage, and preserve member trust. You can always loosen rules later—tightening after you’ve created precedent is harder.

• One location, one set of core policies: minimize “special case” rules early.
• GM as primary approver for day-to-day exceptions; Owner only for high-impact thresholds.
• Reason codes required for any financial adjustment or waiver.
• Coaches cannot issue waivers: they can flag and recommend, but approvals stay managerial.
• Front desk can resolve 80% of issues without financial tools: booking help, roster fixes, member education, and clean escalation.

Common mistakes (and the fix)

Mistake #1: Giving “temporary” admin access to solve onboarding problems

Temporary access becomes permanent the moment your team relies on it. Instead, keep roles tight and add an approval flow for the specific problem area.

Mistake #2: Too many exception categories on Day 1

If staff can’t choose a reason code quickly, they’ll choose random ones—or avoid using the system. Start with 5–7 reason codes and expand only when you see repeat patterns.

Mistake #3: Building schedules before capacities and rooms are real

If you schedule first, you’ll retrofit capacities later and discover you’ve promised members a behavior the system can’t enforce consistently. Always configure physical constraints first.

Mistake #4: Not training staff on what to say during approvals

The gap between request and approval is where teams panic and improvise. Train the script, publish the SLA, and make it normal for exceptions to be reviewed.

14-day rollout timeline (single location)

This timeline assumes you’re setting up the workspace foundation first, then moving into migration and go-live planning. Adjust pacing based on staff bandwidth, not urgency.

1. Days 1–2: Inputs + decisions — finalize hours, spaces, capacities, staff roster, and approval owners.
2. Days 3–4: Steps 1–3 configuration — location identity, operating hours, rooms/resources/capacities.
3. Days 5–6: Step 4 defaults — booking contract defaults (booking windows, cancellations, attendance).
4. Days 7–8: Steps 5–7 controls — roles/permissions, approval gates, reason codes + notes standard.
5. Day 9: Step 8 QA simulation — run the 12 QA checks; fix issues.
6. Days 10–11: Step 9 training — permissions-first sessions by role; publish scripts + SLAs.
7. Days 12–14: Pre-migration readiness — confirm your workspace is stable; then begin member data migration and schedule building.

Operating rhythm after setup: keep the workspace clean

Workspace configuration is not “set and forget.” The goal is to keep the system aligned with reality without letting exceptions rewrite your policies.

Weekly (GM, 20 minutes)

• Review exception requests by reason code: what’s trending?
• Spot-check approvals: are notes clear and consistent?
• Confirm no “temporary” permissions were granted.
• Pick one pattern and decide: policy change vs. coaching opportunity for staff.

Monthly (Owner + GM, 30 minutes)

• Review approval volumes and thresholds (are too many items going to the owner?).
• Review any member-facing policy friction (late cancels, waitlists, holds).
• Do a mini QA: time zone, capacities, and routing still correct.

How to measure success inside Gymizen

Your goal isn’t “no exceptions.” Your goal is: exceptions are controlled, consistent, and informative.

• Approval turnaround time meets your SLA (staff stop making promises on the spot).
• Exception reasons concentrate into a few clear categories (not random free-text).
• Front desk resolution rate increases without financial tools (more issues solved by policy + education).
• Fewer “who said I could?” moments because approvals are visible and auditable.
• Member experience becomes consistent across shifts—less churn triggered by perceived unfairness.

Conclusion: configure the rules once—then let the team run fast

A clean single-location workspace setup is the difference between a smooth rollout and a month of “we’ll fix it later.” If you set identity, hours, capacities, defaults, permissions, and approval gates before migration and training, Gymizen becomes the system that protects your standards—so your staff can deliver a consistent member experience without constant manager intervention.

Next, move into migration, then go-live cutover. If you want a structured sequence, use the related resources below.