How to Build Your Pricing + Membership Catalog in Gymizen: A 14‑Day Setup Plan (With Approval‑Gated Discounts and Clean Renewals)

Pricing is where ops either gets calm or chaotic. If your catalog is inconsistent—duplicate memberships, unclear renewal dates, “special” discounts that only live in someone’s head—then every edge case becomes a front-desk interruption, a manager override, or a retention risk. This guide is a concrete 14-day rollout plan to build (or rebuild) your pricing + membership catalog in Gymizen in a way that supports proactive operations: clean renewals, predictable entitlements, and approval-gated discounts/overrides so your team can help members fast without training them to ask for exceptions. You’ll leave with a catalog that is (1) easy to sell, (2) easy to support, (3) easy to report on weekly, and (4) difficult to “accidentally” erode through ad hoc changes.

What you’re building (and what “good” looks like)

A Gymizen pricing catalog isn’t just a list of SKUs. It’s your studio’s “operating contract” between sales, scheduling, billing, and retention. A strong catalog has these properties:

• One canonical version of each offer (no “10 Class Pack,” “10-Pack,” and “10 Classes” as three separate things).
• Clear entitlements: what the member can book, how often, and what happens when they run out.
• Clean renewal logic: predictable billing cycles with minimal manual intervention.
• Planned exceptions (approval-gated): discounts, comps, pro-rates, and one-time adjustments require the right role—not whoever is closest to the keyboard.
• Reportability: you can answer weekly questions like “Which products are leaking revenue?” and “Which offers create the most holds/cancellations?” without spreadsheet archaeology.

Prerequisites (before Day 1)

To keep this rollout fast, decide up front what you’re standardizing versus what you’re preserving from your previous system.

• Export your current product list: memberships, packs, drop-ins, intro offers, discounts, and any hidden “manual” prices (e.g., staff member types into a custom amount).
• Export active member billing commitments: current plan name, price, renewal date, and any grandfathered rates.
• Clarify your policy decisions: late cancel/no-show rules, holds, refund policy, and how you handle plan changes mid-cycle (these affect which approvals you need).
• Assign a single catalog owner for this project (usually the GM/ops manager). One editor prevents duplicates and naming drift.
• Define your “go-live” boundary: Are you migrating everyone exactly as-is, or are you taking the opportunity to consolidate offers?

Implementation tip: If you have more than ~25 distinct offers today, you almost certainly have consolidation opportunity. Most boutiques run cleanly on 8–15 core products plus 1–3 time-bound promos.

Roles and responsibilities (so the build doesn’t stall)

Pricing touches multiple teams. Here’s a practical division of labor that keeps the work moving while protecting financial control.

• Owner: approves final price list, grandfather rules, and who can approve discounts/overrides.
• GM / Ops Manager (Catalog Owner): builds the catalog, enforces naming standards, runs QA, and trains staff on “what to sell to whom.”
• Front Desk Lead: validates sell-flow, check-in edge cases, and “what do we do when…” scenarios (refund requests, transfers, comp class requests).
• Head Coach / Program Lead: confirms which memberships can book which class types (especially if you have tiers: strength, Pilates reformer, sparring, advanced skill classes).
• Bookkeeper / Finance (optional but valuable): validates tax settings, revenue categories, payout timing, and reconciliation expectations.

Recommended defaults (operator-led, retention-friendly)

These defaults reduce exception volume and make your policies enforceable without constant staff judgment calls. Adjust them to fit your brand—but choose deliberately.

• Keep your core catalog small: 1–2 intro offers, 2–4 memberships, 2–3 class packs, 1 drop-in, and 1 private training option (if applicable).
• Time-bound promos become separate products (with start/end dates), not “manual discounts.”
• Grandfathering is explicit: create a grandfathered product or a controlled discount rule—not a note in a profile.
• Discounts require approval unless they are part of a published program (e.g., student, military, family).
• Front desk can sell and schedule, but cannot edit pricing or backdate changes. They can request approvals with a reason.
• One-off comps are tracked: comp class / comp month should be approval-gated and reportable, not an invisible “just let them in.”

The 14‑day rollout timeline (build → QA → train → launch)

This timeline assumes you already have Gymizen workspace access and you’re preparing pricing before (or alongside) member migration. If you’re mid-migration, still follow the order—just compress days as needed.

1. Days 1–2: Catalog inventory + consolidation decisions
2. Days 3–5: Build products + naming standards + revenue categories
3. Days 6–7: Configure approval gates (discounts, overrides, refunds, plan changes)
4. Days 8–9: Entitlement mapping (who can book what) + policy alignment
5. Days 10–11: QA test purchases + renewals + edge cases
6. Days 12–13: Staff training (role-by-role) + scripts
7. Day 14: Launch readiness review + freeze changes + go-live

Step 1 (Days 1–2): Inventory what you sell today—and decide what survives

Start by listing every way money changes hands in your business. Most teams forget at least one of these, and that’s where chaos shows up on Day 1.

• Recurring memberships: unlimited, limited monthly (e.g., 8x/month), tiered access (e.g., Reformer vs Mat), family add-ons.
• Class packs: 5/10/20 packs, expiring vs non-expiring.
• Intro offers: trial weeks, “3 classes for $X,” first-month promos.
• Drop-ins: single class, open gym day pass, open mat.
• Private training: single sessions, packages, small group training.
• Retail and fees: apparel, equipment, late cancel fees, no-show fees, upgrade fees.
• Discounts: staff, student, military, founding members, corporate partnerships.
• Manual adjustments: refunds, credits, “we’ll just comp it,” price matching.

Next, make two decisions that prevent future drift:

• Consolidation rule: If two offers exist only because of naming, retire one. If two offers exist because of a meaningful entitlement difference, keep both—and document the difference in the product description.
• Legacy rule: If an offer is no longer sold but must remain for active members (grandfather), mark it as “Not for sale” (or equivalent) and control changes via approvals only.

Step 2 (Days 3–5): Build the core catalog in Gymizen (names, structure, and logic)

Build from the inside out: start with your core recurring memberships, then packs, then intro offers. Your goal is to make sales and service repeatable.

2A) Establish a naming standard (so reporting stays clean)

Use a standard that encodes the entitlement and billing rhythm. Example pattern:

• [Access] + [Frequency] + [Billing] (optional: location or tier)
• Examples: “Unlimited — Monthly,” “8x/Month — Monthly,” “Reformer Unlimited — Monthly,” “10 Class Pack — 6 Month Expiry,” “Intro: 14 Days Unlimited (New Clients)”

Avoid cute internal nicknames. They feel fun in the moment and become painful in training and reporting.

2B) Configure memberships first (because everything else references them)

For each membership, document these fields before you build:

• Who it’s for (persona): new client, regular, advanced, family, student.
• Entitlement: unlimited vs limited visits; allowed class types; any blackout rules.
• Billing cadence: monthly, every 4 weeks, annual.
• Commitment: month-to-month vs 3/6/12-month term (if you use contracts).
• Plan changes: can members upgrade/downgrade mid-cycle? If yes, how do you handle proration (and who approves it)?
• Hold eligibility: allowed/not allowed; maximum hold length; hold fee (if any).

Default recommendation: If your studio has frequent mid-cycle plan changes, create a single approved workflow for it (request → approve → effective date). Don’t let staff “figure it out” live at the desk.

2C) Build class packs and drop-ins with expiration rules you can defend

Packs are where exceptions pile up (“Can I extend my pack?”). Decide your rule, publish it, and then approval-gate the exceptions so you can still say yes when you want—without losing control.

• Expiration: choose a simple standard (e.g., 6 months for 10-pack, 12 months for 20-pack).
• Transferability: allowed vs not allowed; if allowed, require manager approval and a reason.
• Refundability: typically no (unless required by local regulation), but define the exact edge case process.

2D) Intro offers: minimize options, maximize clarity

Intro offers should reduce friction, not create a maze. Keep 1–2 intro offers live at a time. Everything else becomes a seasonal promo product with dates.

• Eligibility: first-time clients only (enforced by process and tagging/segmentation).
• Conversion path: define the default “next product” staff should recommend after the intro.
• Auto-renew: if you use trial-to-membership conversion, make the conversion approval-gated (so you’re not surprising members).

Step 3 (Days 6–7): Add approval gates (discounts, overrides, refunds, and plan changes)

Approval gates are the difference between “we have policies” and “we have policies unless someone complains.” The goal is not to be rigid—the goal is to make exceptions intentional, trackable, and consistent.

3A) Define what requires approval (recommended minimum set)

• Discount creation or edits (including “custom price” at checkout).
• Refunds and credits above a small threshold (e.g., anything over $25, or any refund after 7 days).
• Backdating: changing effective dates for plan starts, cancellations, or holds.
• Pack extensions and membership hold exceptions outside published policy.
• Fee waivers: late cancel/no-show, failed payment fees (if you charge them).
• Plan changes mid-cycle (upgrade/downgrade), especially if proration is involved.

3B) Assign approvers by role (so the desk isn’t stuck waiting)

A workable approver matrix keeps service fast without opening the floodgates.

• Front Desk: can request approvals; can apply pre-approved published discounts (e.g., student) if eligibility is verified.
• Manager on Duty (MOD): can approve fee waivers, pack extensions within defined limits, and minor one-time credits.
• GM / Ops Manager: approves plan changes, larger refunds, and non-standard discounts.
• Owner: approves new price points, new products, and any permanent grandfather exceptions.

Guardrail: Make “approvals require a reason” non-optional. Your future self will thank you when you review exception patterns during weekly ops.

Step 4 (Days 8–9): Map entitlements to scheduling realities (classes, reservations, and access tiers)

This is where many implementations break: pricing is set up, but it doesn’t match how booking actually works. Align these before you test.

• Class types: define each class type you schedule (e.g., CrossFit, Yoga Flow, Reformer, Sparring, Foundations).
• Eligibility rules: which products can book which class types? Example: “Mat Unlimited” cannot book “Reformer” unless they purchase an add-on.
• Visit limits: ensure limited memberships decrement correctly (and that staff can explain it).
• Waitlist behavior: confirm what happens when a member is moved from waitlist to confirmed—does it consume a visit, and when?
• Drop-in handling: decide if drop-ins can join waitlists and under what rules.

If you run a martial arts school or skill-based program (levels/belts), decide whether eligibility is based on product (membership tier) or status/tag (member readiness). Either works—just keep it consistent so coaches aren’t constantly overriding the desk.

Step 5 (Days 10–11): QA checks (test like a skeptic, not like an optimist)

Run QA with at least two people: the catalog owner and a front desk lead. If you can, include one coach to validate entitlement edges.

5A) Build a test matrix (minimum scenarios)

1. New member buys intro offer → books class → checks in → converts to membership.
2. Member buys class pack → books 3 classes → cancels one late → confirm fee/penalty behavior matches policy.
3. Unlimited member → books restricted class type → ensure it’s blocked (or allowed) as designed.
4. Waitlist flow → member is promoted → confirm visit consumption timing is correct.
5. Plan change request → requires approval → approved by MOD/GM → change takes effect on correct date.
6. Refund request → triggers approval gate → approved/denied → audit trail remains visible.
7. Grandfathered member renewal → confirm price and renewal cadence remain correct and cannot be edited by non-authorized roles.

5B) Reconciliation sanity checks (quick but critical)

• Product count check: Are there any duplicates with near-identical names? If yes, merge now—before training.
• Price-point check: Compare your new catalog to your old export. Any mismatches should be intentional and documented.
• “Not for sale” check: Legacy/grandfather products must not show up in normal sales flows.
• Approval gate check: Log in as a front desk user and confirm they cannot apply custom discounts, backdate changes, or issue refunds without a request.

Step 6 (Days 12–13): Train the team (role-by-role, with scripts)

Training fails when it’s generic. Make it procedural: “When X happens, do Y. If it’s an exception, request approval with reason Z.”

Front desk training (60–90 minutes)

• What to sell: the top 3 recommended offers and the “default next step” after each intro.
• How to explain entitlements: simple language for visit limits, expirations, and restricted class types.
• How approvals work: when to request, who approves, and how to write a useful reason.
• What not to do: no custom prices, no “temporary” workarounds, no verbal promises that aren’t in the system.
• Exception scripts: “I can request an exception for you—our manager reviews those the same day. What happened so I can document it accurately?”

Manager training (45–60 minutes)

• Approval standards: what you auto-approve, what you never approve, and what requires owner input.
• Consistency rules: if you approve something, you’re teaching members what to ask for next time—decide intentionally.
• Daily review habit: check the approval queue at open and mid-day (avoid end-of-day backlog).
• Escalation path: how to handle “angry in the lobby” situations without breaking policy.

Coach training (20–30 minutes)

• Access rules: which memberships grant access to which programs; what to do if someone shows up incorrectly booked.
• How to avoid “quiet exceptions”: no unofficial “just let them in” decisions—route to desk/MOD so it’s tracked.
• Member experience language: “Let’s get you sorted at the front desk so your account stays clean and you don’t get surprised later.”

Step 7 (Day 14): Launch readiness review (freeze, verify, then go)

On launch day, your goal is not “perfect.” Your goal is: no financial surprises, no broken booking rules, and no uncontrolled discounting.

1. Freeze catalog edits for 7 days unless owner/GM approves (this prevents “fixing” issues by creating duplicates).
2. Confirm staff permissions match your approver matrix.
3. Run a final test sale of each core product (even if only as a $0 test in a sandbox or via a controlled test member).
4. Confirm legacy products are not for sale.
5. Set the first post-launch review: 48 hours after go-live, then weekly for four weeks.

Common mistakes (and how to avoid them)

• Mistake: Too many offers. Fix: Consolidate. If staff can’t memorize the catalog, members can’t buy it confidently.
• Mistake: “We’ll handle exceptions manually.” Fix: Put exceptions behind approval gates with required reasons so they’re visible and reviewable.
• Mistake: Grandfather rates live only in notes. Fix: Make grandfathering explicit through a controlled product/discount rule.
• Mistake: Entitlements don’t match scheduling. Fix: Validate class-type eligibility and visit decrement logic before go-live.
• Mistake: Front desk can edit pricing. Fix: Restrict pricing edits and refunds to approvals; empower desk to request quickly instead.

What success should look like in Gymizen (first 30 days)

In the first month, you’re looking for operational signals that your catalog is doing its job:

• Low exception volume: approval requests exist, but they’re the minority—not the main way your business runs.
• Fast approvals: most requests are resolved same-day with clear reasons and consistent outcomes.
• Clean booking behavior: fewer “can’t book” surprises caused by mismatched entitlements.
• Predictable renewals: members understand when they renew, and staff doesn’t need to manually “fix billing dates.”
• Better retention conversations: when someone asks for a special deal, staff can offer structured alternatives (switch to a smaller membership, buy a pack, take a hold) instead of improvising.

If you see repeated approvals for the same reason (e.g., constant pack extensions), don’t accept that as normal. Treat it as a catalog design issue: adjust policy, clarify communication, or redesign the product so the “exception” becomes unnecessary.

Conclusion: A clean catalog is a retention tool (not just a billing tool)

When your pricing catalog is consistent, approval-gated, and aligned with scheduling, your team spends less time negotiating and more time coaching members toward consistency. That’s the operator-led wedge: proactive operations that prevent churn instead of reacting to it. Follow the 14-day plan, keep the catalog small, enforce approval gates for the handful of actions that create revenue leakage, and use the first 30 days to refine based on real exception patterns—not anecdotes.

If you’re rolling this out alongside a migration, coordinate your product build with your member import mapping so active members land on the correct plan with the correct renewal date—without manual clean-up after launch.