Gymizen Workspace Setup: A 5‑Day Admin Configuration Checklist (Locations, Policies, Notifications, Approval Gates)

This guide is a concrete, operator-led setup plan for Gymizen—built for boutique fitness businesses (CrossFit, yoga, pilates, martial arts, boxing) that want clean data, consistent policies, and proactive retention ops without accidental messages, permission sprawl, or “we’ll fix it later” configuration debt.

The goal of Day 1–5 is simple: create a workspace that behaves like your business actually runs—then lock the risky parts behind approval gates so your team can move fast safely.

If you remember one principle: defaults become policy. In Gymizen, what you set as the default (products, cancellation windows, notifications, role permissions) is what members experience and what staff repeat 100 times a week.

Who this setup checklist is for (and when to use it)

• Owners who want tighter controls (refunds, discounts, policy exceptions) without becoming the bottleneck.
• General managers / studio managers who run the weekly operating cadence and need clean, consistent workflows.
• Head coaches / program directors who need reliable rosters, attendance, and coaching notes visibility—without finance access.
• Front desk / admin leads who execute day-to-day check-in, sales support, and member support with minimal “ask a manager” delays.

Use this guide before data migration and before your go-live cutover. If you’re already live, you can still follow it—just treat Day 3–5 as a controlled “policy refactor” with a change log and an approval queue.

Prerequisites (what you need before Day 1)

Gather these inputs first. This avoids the most common failure mode: configuring the workspace around guesses, then reworking everything during go-live week.

• Business structure: legal business name, DBA, address, time zone, tax settings (if applicable), and primary support email.
• Location map: if multi-location, define what is shared vs. location-specific (pricing, schedule templates, staff access, reporting).
• Policy decisions written in plain language: late cancel window, no-show definition, refund rules, transfer rules, expiration rules for packs, membership freeze rules, and exception authority.
• Org chart for execution: who approves what (discounts, refunds, policy exceptions, comp classes, membership changes).
• Member communication voice: confirm who “owns the voice” for automated messages and policy comms (usually GM + Owner sign-off).
• Calendar reality: your next 30 days of schedule changes, workshops, holidays, and coach substitutions.

If you haven’t mapped your overall rollout yet, start with Operator onboarding checklist for Gymizen, then come back here to execute the admin configuration sprint.

Your 5-day rollout overview (what gets done each day)

1. Day 1 — Workspace foundation: business settings, locations, time zone, baseline naming conventions.
2. Day 2 — Roles, permissions, and approval gates: role templates, exception authorities, audit expectations.
3. Day 3 — Policies as defaults: reservation rules, cancellation windows, credit behaviors, member-facing rules.
4. Day 4 — Notifications + automations (with safety rails): message triggers, approval-gated sends, internal alerts.
5. Day 5 — QA + rehearsal: scenario testing, staff dry run, sign-offs, and “ready for migration” criteria.

Recommended naming conventions (set this once, save years of confusion)

Most studios don’t fail because of one big mistake—they bleed time because everything is slightly ambiguous. Decide on a naming standard before you import data or publish schedules.

• Locations: “Downtown”, “Westside”, “Dojo North” (avoid internal abbreviations members won’t recognize).
• Programs: “CrossFit”, “Yoga”, “Pilates Reformer”, “Kickboxing Fundamentals”, “BJJ Adults” (program names should map to how you coach and how members self-identify).
• Class types: use a small, consistent set: “Basics”, “All Levels”, “Intermediate”, “Open Gym”, “Competition”, “Mobility”.
• Staff roles: “Owner”, “GM”, “Manager”, “Front Desk”, “Coach”, “Coach (Limited)”, “Accounting (Read-Only)”.
• Tags/statuses: if you use lifecycle tagging later, keep tags short and behavior-oriented (e.g., “Needs Intro Call”, “Risk: 7d No Visit”).

Day 1 — Workspace foundation (business settings + locations)

Day 1 is about making the workspace “real”: correct time zone, consistent location structure, and the basic constraints that prevent downstream reporting and messaging errors.

Step 1: Confirm time zone, business identity, and contact defaults

1. Set time zone first. Reservations, cancellation windows, and message timing all depend on it.
2. Set your business name and member-facing sender identity (what members will see in emails/notifications).
3. Set a support inbox that is monitored daily (not an owner’s personal email).
4. Decide your default location behavior (single-location operators can keep it simple; multi-location should define how members choose a location at booking).

Step 2: Create locations (even if you’re “basically one location”)

If you run training in two rooms, partner facilities, seasonal pop-ups, or a dedicated open gym area, treat that complexity intentionally. It’s easier to add a location now than to split data later.

• Single location default: one location, one schedule, one set of policies.
• Multi-location default: locations share the member database, but classes and staff access can be location-scoped.
• Recommendation: if you’ll open a second location within 12 months, set up locations now and restrict access via permissions—future-you will thank you.

Day 1 QA checks (don’t skip these)

• Create a test class tomorrow at 6:00am and confirm it displays at the correct local time.
• Confirm the default sender identity looks professional on a test email/notification.
• If multi-location: confirm a test staff account can only see the correct location(s).

Day 2 — Staff roles, permissions, and approval gates (your risk-control layer)

Day 2 is where Gymizen becomes operator-led: staff can execute quickly, but the actions that create refunds, precedent, or member confusion are routed through approvals.

Define the three permission tiers (recommended defaults)

1. Tier 1: Execute (Front Desk / Admin) — check-in, basic edits (phone/email), create leads, sell standard products, apply standard policies.
2. Tier 2: Approve exceptions (Manager) — approve policy exceptions, approve comp/discount within a cap, override late cancel in documented cases, edit schedule templates.
3. Tier 3: Set policy (Owner) — change pricing, create/retire products, change cancellation windows, change refund rules, change automation rules, approve high-impact exceptions.

Avoid the common “everyone is an admin” trap. It feels flexible for two weeks—then it becomes un-auditable and inconsistent. Gymizen’s approval gates exist so you can keep service fast while preventing policy drift.

Approval-gated actions to configure on Day 2

These are the actions that most often create revenue leakage, retention damage, or team conflict. Put them behind approvals by default, then loosen later only if you can prove consistency.

• Refunds and reversals: require manager approval; owner approval above a dollar threshold.
• Discounts: allow front desk to apply only pre-approved discounts; require approval for anything ad hoc.
• Membership cancellations outside your policy: require a manager note + owner approval (prevents “quiet cancellations” that later become disputes).
• Late cancel / no-show overrides: require manager approval unless it’s a documented studio fault (e.g., class canceled, booking system outage).
• Manual credit adjustments (adding classes, extending expirations): approval-gated with reason codes.
• Outbound bulk messaging: approval-gated sends (prevents accidental spam and preserves trust).

Role-by-role responsibilities (write this into your SOP)

• Owner: defines policy; approves policy changes; signs off on automation templates; audits exception patterns monthly.
• GM/Manager: runs approvals daily; trains staff on what qualifies for an exception; maintains a short “approved exception reasons” list.
• Front Desk: executes standard workflow; submits approvals with complete context; never promises an exception before it’s approved.
• Coach: focuses on attendance, roster notes, and member experience; flags edge cases via internal notes (not by DM’ing the owner).

Day 2 QA checks (security + speed)

• Log in as a front desk user and confirm they cannot change policy-level settings.
• Submit a test approval (e.g., late cancel override) and confirm the manager can approve/deny with a recorded reason.
• Confirm coaches can see rosters and attendance but not sensitive financial details.

If you want a deeper, role-based permissions rollout, pair this guide with Staff Onboarding + Permissions in Gymizen: A 7-Day Role-Based Access Rollout.

Day 3 — Policies as defaults (reservations, cancellations, credits, and exceptions)

Day 3 is where you stop “explaining your policy” and start enforcing it consistently. The rule of thumb: the system should do the boring, repeatable enforcement so staff can focus on service and coaching.

Step 1: Reservation rules (recommended defaults for boutique fitness)

• Booking window: set a clear window (e.g., 7–14 days) so demand concentrates and schedules remain predictable.
• Cancellation window: define a standard late cancel cutoff and enforce it consistently; exceptions should be approval-gated.
• Waitlist behavior: keep it predictable—members should know when they’re “in” and when they’re not (even if you refine yield later).
• Class cap logic: set caps aligned to coaching reality (not marketing hope). If you need a framework, see Boutique fitness scheduling best practices.

Step 2: Credit and pack behavior (avoid accidental generosity)

Most revenue leakage is not fraud—it’s “helpful” manual adjustments that become precedent. Decide defaults now, and force exceptions through approvals with reason codes.

• Expiration: define pack expiration rules and communicate them clearly.
• Transfers: decide if credits can be transferred between members (most studios should require manager approval).
• Comp classes: create a standardized comp product or adjustment type so you can report on it (avoid invisible manual edits).
• Holds/freezes: define who can apply a freeze, for how long, and whether it’s approval-gated.

Step 3: Write your “exception menu” (so staff stop improvising)

Create a short list of exceptions that are allowed, and what proof is required. This reduces awkward front desk interactions and keeps your policy consistent.

1. Studio fault (allowed, manager can approve): class canceled, coach late replacement, system outage.
2. Documented emergency (allowed, manager approves with note): accident, hospitalization, travel disruption.
3. First-time courtesy (allowed, capped): one courtesy override per member per 6–12 months.
4. VIP/relationship exception (owner-only): rare, documented, and reviewed monthly to prevent quiet policy drift.

Day 3 QA checks (policy reality test)

• Book a class as a test member, cancel inside the late window, and confirm the correct policy outcome occurs.
• Try to override the outcome as a front desk user and confirm it routes to approval (not silent success).
• Confirm member-facing wording matches how your staff will explain it in person (no legalese, no ambiguity).

Day 4 — Notifications + automations (with approval controls)

Day 4 is where teams get excited—and where mistakes can get expensive. The standard is: automation should be helpful, accurate, and auditable.

Start with the “must-have” notification stack

• Booking confirmation: immediate, includes date/time/location and cancellation cutoff.
• Class reminder: timed to reduce no-shows (test timing with your audience).
• Waitlist movement: clear “you’re in” confirmation with next steps.
• Payment/renewal signals: internal alerts for staff + member-facing reminders that are calm and actionable.
• Exception outcomes: if a request is approved/denied, the member should receive a consistent, respectful message (and the staff should see the audit trail).

Where to use approval gates in automations (recommended defaults)

• Bulk sends (policy changes, promos, schedule disruptions): require manager approval before any outbound blast.
• Member risk / retention nudges: approval-gate the first 2 weeks of any new retention automation until message quality is proven.
• Collections-sensitive messages: require owner/GM sign-off to ensure tone is on-brand and compliant with your standards.
• Any automation that changes money or access: prefer approval-gated actions (e.g., granting credits, extending expiration, pausing membership).

If you want a full automation rollout plan, use Approval-Gated Automations in Gymizen: A 14-Day Rollout Plan for Proactive Ops as your Day 4–18 extension.

Day 4 QA checks (message accuracy + tone)

1. Run a test booking → reminder → cancel flow and check every message for correct class info and correct policy wording.
2. Trigger a waitlist movement scenario and ensure the member is not double-notified.
3. Confirm internal notifications go to the right role (front desk vs. manager) so approvals don’t stall.
4. Have two people review tone: one operations-minded, one member-experience-minded.

Day 5 — QA + rehearsal (prove it works before you migrate or go live)

Day 5 is your “confidence day.” You’ll run a rehearsal of the workflows that cause the most chaos in real life: late cancels, exceptions, staff substitutions, and member questions at the front desk.

The 12 scenario test (run these in 60–90 minutes)

1. New member books first class → receives confirmation + reminder.
2. Member cancels inside the late window → correct policy outcome happens.
3. Front desk attempts an override → routes to approval with required context.
4. Manager approves the override → audit trail recorded; member notified.
5. Member is added to waitlist → receives correct status.
6. Waitlist member is moved into class → receives “you’re in” message; roster updates.
7. Coach views roster and marks attendance → cannot access finance-only tools.
8. Front desk sells a standard product → cannot create a new product or change pricing.
9. Refund request is initiated → approval-gated appropriately.
10. Membership cancellation request outside policy → requires reason code + approval.
11. Schedule change is made for a class type → member-facing display remains clear.
12. Internal alert goes to the right person (not the whole company).

Sign-offs (don’t skip: they prevent ‘I didn’t know’ later)

• Owner sign-off: approval-gated actions list + refund/discount authority boundaries.
• GM/Manager sign-off: policies and exception menu match real operations; approvals are staffed daily.
• Front desk lead sign-off: can complete common member requests without “admin access.”
• Head coach sign-off: rosters, attendance, and class visibility support coaching workflow.

After Day 5, you should be ready to migrate data and plan cutover. If you want a structured launch week, use Gymizen Go‑Live Cutover: A 7‑Day Launch Checklist.

Common mistakes (and how to avoid them)

• Mistake 1: Setting policies in staff training only (not in the system). Fix: convert policies into defaults + approval-gated exceptions.
• Mistake 2: Too many roles. Fix: start with 5–7 roles max; add nuance only when a real operational need appears.
• Mistake 3: Allowing ad hoc discounts/refunds at the front desk. Fix: create a small set of approved discount options; route everything else through approvals.
• Mistake 4: Turning on automations before message QA. Fix: stage automations, approval-gate early sends, and run scenario tests.
• Mistake 5: No one ‘owns’ approvals. Fix: assign an approvals captain (usually the GM) with a daily SLA (e.g., same-day resolution).

What success looks like after this 5-day setup

You’ll know your workspace setup worked when:

• Front desk can handle 80–90% of member requests without admin permissions—and without “making up” exceptions.
• Managers approve exceptions quickly, with consistent reason codes and an audit trail.
• Owners are not dragged into daily ops, but can still see and control policy drift via approvals and reporting.
• Members receive fewer confusing messages because notifications are tested, consistent, and accurate.
• Policy enforcement becomes consistent (fewer arguments, fewer “but last time you waived it” situations).

From here, your next implementation step is typically data migration and go-live execution. If you haven’t migrated yet, use Member data migration guide for gyms moving into Gymizen and treat the output of this 5-day setup as your “target state” for clean import mapping.

Suggested rollout timeline (optional extension: Days 6–14)

If you have the bandwidth, extend beyond Day 5 with a controlled adoption runway:

1. Days 6–7: migrate a small pilot cohort (staff + a handful of friendly members), validate workflows end-to-end.
2. Days 8–10: staff enablement by role; run daily approvals; tighten reason codes and exception menu.
3. Days 11–14: turn on approval-gated automations gradually; review message logs and exception patterns; adjust defaults once (not daily).

If you want a structured training plan that pairs well with this setup checklist, use Gymizen Team Training & Adoption: A 14-Day Role-Based Enablement Plan and align it to the roles you defined on Day 2.

Conclusion: configure for consistency, then scale with approvals

A Gymizen workspace isn’t “set up” when screens look complete—it’s set up when your defaults match your policies, your team can execute without admin chaos, and the exceptions that create revenue leakage or member distrust are safely routed through approval gates.

Run this 5-day checklist, complete the Day 5 scenario test, and you’ll enter migration and go-live with a workspace that supports proactive operations—so retention improves because the member experience becomes consistent, calm, and reliable.