Gym Launch Readiness Checklist

Gym Launch Readiness Checklist explains what a gym must review before staff rely on SquareOS for daily operations, payments, communications, access, reports, and member service.

What this page is for

Gym Launch Readiness Checklist explains what a gym must review before staff rely on SquareOS for daily operations, payments, communications, access, reports, and member service.

Who should use it

Owners, managers, front desk, sales, trainers, finance, support, implementation

Where to find it

Pre-launch operating checklist

Before you start

Production readiness evidence ledger: use this page before claiming a gym is ready. It connects staff training, setup review, provider readiness, known limitations, and owner approval into one operating source of truth.
Real gym simulation evidence matrix: treat each launch as a row-by-row evidence table, not a verbal confidence statement.
Simulation proof categories are Setup, People and CRM, Trials, Sales and Billing, PT and Classes, Attendance and Access, Communications, Finance Lifecycle, Reports and Audit, and Security.
Launch readiness states are Not started, Training complete, Verified with real provider, Accepted limitation, and Blocked.
Every launch blocker must be classified as Fixed, Accepted limitation, Deferred non-launch item, or Blocking.
Remaining unproven production boundaries: live provider delivery with production Razorpay/SMS/WhatsApp/email/POS/biometric credentials, final mobile app rollout, unresolved owner policies such as refund approval and recurring mandate rollout, and any newly added workflow not yet covered in this help center.
Production launch remains unproven until real provider credential tests pass for Razorpay, SMS, WhatsApp, Email, POS terminal, and Biometric access.
Mobile Phase 1 acceptance gate must be passed before shipping mobile apps to a real gym.
Mobile acceptance evidence must prove role boundaries, location guards, provider-disabled states, duplicate-write protection, Staff app parity, secret leakage prevention, offline/stale-state blocking, and owner sign-off.
Mobile location and freshness evidence must include inside-gym success, outside-gym denial, denied-permission denial, stale-location denial, low-accuracy denial, duplicate-tap proof, offline-retry proof, request id, and SquareOS denial reason.
Mobile check-in or attendance success may be shown only after server confirmation, never from a local GPS match, QR scan, biometric unlock, cached roster row, or optimistic offline draft.
Mobile manager override evidence must capture role permission, override reason, target staff or person, target gym, original denied reason, request id, and audit row.
Mobile Phase 1 must use the same SquareOS auth, people, scheduling, commerce, CRM, engagement, reports, audit, staff roster, and support records instead of inventing mobile-only sources of truth.
Mobile secure-storage evidence must prove auth tokens, refresh tokens, tenant session keys, push tokens, and device identifiers use platform secure storage rather than plain local storage.
Mobile protected-cache evidence must prove logout, tenant switch, role switch, impersonation exit, session expiry, and app reinstall clear tenant context, push token association, pending non-final drafts, and cached protected data.
Mobile privacy evidence must prove crash logs, telemetry, support attachments, screenshots, push notifications, and offline cache do not expose provider secrets, payment links, invoice links, GPS coordinates, medical history, GSTIN, PAN, staff internal notes, or raw audit payloads.

Daily workflow

Before onboarding a gym, review Admin setup, People, Sales/CRM, POS, Schedule, Communications, Reports, Audit Trail, Staff Roster, provider settings, and support escalation with the owner or manager.
Confirm staff roles, plan types, add-ons, joining fee, offline payment modes, gateway account, POS terminal device, access device, rooms, class categories, appointment categories, and trial definition match the real gym policy.
Run a tenant-specific sanity pass: login, People search, prospect, opportunity and task, trial, POS invoice/payment, schedule booking, provider-disabled state, report, audit row, and self-serve invoice/payment link.
For every failed or unsupported provider path, either configure the provider and rerun the flow or keep the staff button disabled with clear operational guidance.
For mobile launch, run staff attendance and member check-in from inside the gym and outside the allowed radius, then capture the request id, denial reason, and audit row for each expected result.
Retry the same mobile attendance/check-in action after denied permission, stale location, low accuracy, duplicate tap, and offline reconnect so the team proves final success comes from server-confirmed state only.
Before signing off mobile, inspect secure storage, local cache, telemetry/crash payloads, support attachments, push-token cleanup, screenshots, and protected offline state for each role and tenant used in acceptance.
Go-live evidence must record environment, tenant, test account role, workflow result, unresolved limitations, issue references, and owner sign-off.

Watch out

Do not call a tenant production-ready only because setup pages are filled. Real provider settlement, real SMS/WhatsApp/email delivery, physical terminal success, access-device behavior, and staff training still need evidence.
Do not reuse one gym location proof blindly for another gym. A real gym may have different tax identity, plan rules, integrations, staff permissions, biometric vendor, cancellation policy, refund policy, or mobile expectations.
Do not expose provider secrets, payment links, invoice links, medical details, GSTIN/PAN, staff notes, raw audit payloads, terminal receipts, or biometric/card identifiers in launch notes.

Use the left menu to open related pages in Start Here.
Use Ask Docs for questions that are already covered in this public documentation.