Business & onboarding
Org decisions on Member Access OS
This document lists the choices a brand or venue operator actually has to make when adopting the platform. It is intentionally short—enough for a kickoff workshop or sponsor sign-off. Technical implementation detail lives elsewhere (for example first-client-preflight-checklist.md).
Audience: Owners, GM, ops lead—not engineers. Engineers use the preflight checklist to verify that the chosen profile is configured and tested.
Implementation timeline
Plan for roughly one to three weeks of calendar time from scoped kickoff to a configured, tested rollout—not a guaranteed service level; actual duration varies. What moves the needle:
| Factor | Typical effect |
|---|---|
| Upfront decisions | Slow agreement on payments, approvals, wallets, or door model stretches the schedule or forces rework mid-build. |
| Customization | Branding, copy, member flows, and integrations each add coordination and QA. |
| Hardware and venue work | Shipping readers and edge kits is one timeline; anything that needs coordinated trades (for example electricians or locksmiths installing a physical mag-lock, cabling, or egress changes) runs on vendor schedules you do not fully control—book those separately from software work. |
A simple staff-only rollout with decisions locked early skews shorter; multi-site brands, unattended hardware, or late scope changes skew longer.
1. Brand and footprint
| Decision | Typical options | Why it matters |
|---|---|---|
| How many facilities? | One site vs several under one brand | More sites means more slugs, staff scope, and possibly different access rules per location. |
| Naming and URLs | Facility name and slug (used in member links like /portal/{slug}/…) | Slugs are stable identifiers; changing them later breaks bookmarks and printed QR codes. |
Lock in early: Public member links, QR codes, and marketing should use the agreed facility slug.
2. Who runs the system (staff and roles)
| Decision | Typical options | Why it matters |
|---|---|---|
| Who is the org “owner”? | One or more owner accounts | Owners control billing, brand settings, and always add staff. |
| Can location managers invite staff? | Yes vs owner-only | If managers should add desk staff without calling the owner, turn on allow managers to add staff (organization setting). Otherwise only owners add people under Team. |
Lock in early: Disputes about “who can add staff” are operational, not technical.
3. How new members pay (before their key is active)
| Decision | Typical options | Why it matters |
|---|---|---|
| Collection mode | Pay off-site, upload proof (default) vs card checkout (when your deployment supports it end-to-end) | Off-site proof matches bank transfer, Zelle, cash-at-desk, etc. Members upload a receipt photo; staff verify in Approvals. Card checkout requires a live integration—use only when it is truly ready. |
| Instructions | Step-by-step text the member sees on their dashboard | Poor instructions mean bad proofs and slower approvals. Use clear payee names, memo lines, and what to screenshot. Templates (e.g. Zelle vs bank) speed setup. |
| Currency | Facility currency for pricing display | Keeps packages and member-facing amounts consistent at that facility. |
Lock in early: Exactly how members should pay (and what “good proof” looks like) should match what your front desk tells people in person.
4. Membership products (what people buy)
| Decision | Typical options | Why it matters |
|---|---|---|
| Billing shape | Recurring (e.g. monthly) vs visit credit packs (bundle of visits) | Drives how you think about renewals and what appears at approval time. |
| Scope | All facilities vs selected sites vs single location | Multi-site brands decide whether one product works everywhere or only at certain gyms. |
Lock in early: Product names and prices are what members and staff repeat on the phone—keep them aligned with your real-world offers.
5. Promotions and special rates
| Decision | Typical options | Why it matters |
|---|---|---|
| Promo codes | On vs off; rules (dates, limits, one-per-member) | Members can enter a code when they upload proof; finance and marketing need to agree on what codes exist and when they expire. |
6. Approving new members (trust and queue)
| Decision | Typical options | Why it matters |
|---|---|---|
| Default path | Everyone goes through Approvals after proof vs some trusted auto-activation rules | Manual approval gives control; trusted paths reduce desk work for known-good segments—policy must match risk tolerance. |
| Who reviews the queue? | Owner, managers, dedicated front desk | Set expectations for response time (e.g. same day vs 24–48 hours). |
Lock in early: “How long until I get my pass?” is a member expectation—align marketing and operations with how fast Approvals is staffed.
7. Digital membership card (phone wallet)
| Decision | Typical options | Why it matters |
|---|---|---|
| Apple Wallet | Your deployment’s supported mode (e.g. native signing vs a hosted template provider) | Affects certificates, Apple-specific setup, and who maintains templates. |
| Google Wallet | On vs off; org-level issuer configuration when applicable | Members may want Google only—confirm which wallet(s) you support. |
| Phone tap at reader | Use vs not | Tap-to-enter at a fixed reader is a different stack than “show a QR at the desk.” Decide per site. |
Lock in early: “Works in Apple Wallet” is a marketing claim—confirm it for your deployment before advertising it.
8. Physical access at the door
| Decision | Typical options | Why it matters |
|---|---|---|
| Unattended NFC / band | Reader + edge device vs none | Unattended paths need hardware, networking, and support playbooks. |
| Staff-only gate | Browser-based admit vs not | Good for staffed hours without putting readers on the door. |
| Mixed | Wallet tap + band + staff override | Common; each path has its own testing and training. |
Not every site uses the same mix—decide per facility when you have more than one location.
9. Email and notifications
| Decision | Typical options | Why it matters |
|---|---|---|
| Operational emails | Join confirm, alerts to staff, member “key active” messages | Staff need to know when someone is waiting in Approvals; members need to know when to upload proof vs when they are approved. |
Lock in early: If email deliverability or sender domain is wrong, members assume the product is broken before they reach the door.
10. Plan and billing (operator relationship to Member Access OS)
| Decision | Typical options | Why it matters |
|---|---|---|
| Plan tier | Limits on seats, facilities, storage; feature flags | Affects whether optional capabilities (for example enterprise-only payment integrations your operator offers) are available. |
| Who pays the platform | Central brand vs per-site | Contracting and invoice alignment. |
Exact plan names and entitlements are defined in product configuration—use this row to trigger a commercial conversation, not to guess technical behavior.
Using this with implementation
- Workshop: Walk the table top-to-bottom and mark each row: decided / deferred / N/A for us.
- You can capture this directly in the pre-onboarding form:
/preonboarding.
- You can capture this directly in the pre-onboarding form:
- Handoff: Give the filled profile to whoever configures the portal and runs
first-client-preflight-checklist.md. - Change control: When operations change (e.g. “we no longer take Zelle”), update Payments instructions and re-test member + Approvals flows—not only the website copy.
Post-launch observational period (explicitly recommended)
After go-live, run a short observational period (typically 2 to 4 weeks) before declaring the setup "final." The goal is to observe real usage patterns and identify where tuning improves flow, staff workload, and member experience.
What to observe
| Area | What to track | Why it matters |
|---|---|---|
| Join → activation flow | Time from join to active key; where people stall (payment proof, approvals, verification) | Reveals friction points and staffing gaps. |
| Approvals workload | Queue volume by day/time; average response time; repeat edge cases | Helps decide staffing coverage and whether trusted paths should expand. |
| Entry behavior | Channel mix (wallet, QR, tags/fobs, manual admits); denial patterns | Confirms whether the chosen entry model matches real member behavior. |
| Support incidents | Top recurring questions from members/staff | Indicates where copy, training, or defaults should be simplified. |
| Operational consistency | Differences across facilities (if multi-site) | Highlights where policies should be standardized vs site-specific. |
Typical tuning decisions after observation
- Adjust approval policy (manual-only vs selective trusted auto-activation).
- Refine payment instructions and proof requirements to reduce bad submissions.
- Rebalance entry channels (for example, promote tags/fobs at specific sites or times).
- Update staff playbooks and owner/manager responsibilities for queue coverage.
- Tighten member-facing copy (email, dashboard, front-desk scripts) based on real confusion points.
Working rule
Treat the first go-live configuration as a baseline, not the endpoint. Schedule an explicit review at the end of the observational period and record resulting policy/config updates.
Related documents
reading-paths-by-role.md— where to start in this library depending on your job.professional-services.md— optional design, rollout, venue, and training help you can request.new-organization-handover-package.md— checklist for receiving teams before running day-to-day ops alone.first-client-preflight-checklist.md— profile-dependent technical verification.first-client-preflight-checklist-role-based.md— same, vendor-neutral hardware wording.on-site-install-10-minute-runbook.md— quick on-site install when physical access is in scope.