Products, Pricing, Taxes, and Checkout in Gymizen: A 10‑Day Approval‑Gated Setup + QA Plan (So Every Sale Reconciles)

Your checkout setup is where “small exceptions” become permanent revenue leakage. In boutique fitness, most leakage isn’t fraud—it’s inconsistency: a different discount this time, a tax that wasn’t applied, a “quick comp” that never got logged, a pack sold under the wrong product, or a membership change made without context. Gymizen is built to be operator-led: you decide the rules, then you put approvals in the right places so your team can move fast without winging it.

This guide walks you through a concrete 10-day rollout to configure products, pricing, taxes, and checkout workflows in Gymizen with approval gates and a QA plan that ensures sales reporting matches what actually happens at the front desk.

This is not a theoretical best-practices article. It’s a setup-and-adoption plan you can run with your owner, manager, front desk, and coaches—so that by the end, you can answer: “Can our team sell the right thing, at the right price, with the right tax treatment, every time—without asking the owner for every transaction?”

What you’ll implement (and what “success” looks like)

• A product catalog that matches how you operate: memberships, class packs, drop-ins, trials, retail, events, fees—each with consistent naming and definitions.
• Pricing rules that don’t rely on memory: defaults for common scenarios (new member, upgrade, downgrade, hold return, retail add-on) and clear boundaries for exceptions.
• Tax configuration you can defend: taxes applied consistently where needed, and not applied where they shouldn’t be (varies by locale—use your accountant’s guidance).
• Approval gates that protect margin and policy: discounts, comps, refunds/credits, and plan overrides require the right approver—without blocking normal sales.
• A QA checklist that proves it works: test transactions, edge cases, and reconciliation checks with sign-off before go-live.
• Operational adoption: front desk can run checkout smoothly, managers can handle 90% of exceptions, and owners review a tight “exceptions + adjustments” queue instead of being pinged all day.

Prerequisites (do these before Day 1)

This plan assumes you have a Gymizen workspace and a clear decision-maker. If you’re still early, start with Operator onboarding checklist for Gymizen and make sure your baseline workspace setup is complete.

• Current price sheet (membership tiers, packs, intro/trial offers, drop-ins, retail).
• Policies: late cancel/no-show fees, holds, refund/credit policy, upgrade/downgrade rules.
• Tax guidance from your accountant/bookkeeper (what’s taxable, what rate(s), and whether any items are tax-exempt).
• Staff roles: who is Owner approver, who is Manager approver, who is Front Desk seller, who is Coach (limited).
• Payment and reconciliation expectations: who closes the day, who reviews weekly adjustments, and how you confirm sales match deposits.

• Standard naming convention: decide how you’ll format product names (examples below).
• “Exception budget” boundaries: which actions are normal (front desk can do), which are exceptional (manager approval), and which are rare (owner approval).
• Legacy cleanup: what old/unused products from your previous system you will not recreate in Gymizen.

Recommended defaults (so your catalog stays clean at scale)

Most gyms don’t need more products—they need fewer products with clearer rules. Here are defaults that reduce confusion and prevent “product sprawl.”

• Memberships: “Membership — Unlimited — Monthly” / “Membership — 8x/mo — Monthly”
• Packs: “Pack — 10 Classes — 6 mo Exp” / “Pack — 20 Classes — 12 mo Exp”
• Drop-ins: “Drop-in — Single Class”
• Trials/intro: “Intro — 3 Classes / 14 Days” (avoid vague names like “Starter” unless you only have one).
• Fees: “Fee — Late Cancel” / “Fee — No-Show” / “Fee — Key Fob”
• Retail: “Retail — T-Shirt” / “Retail — Gloves” (use variants/attributes if your setup supports it; don’t create 30 separate SKUs unless you truly need it).

• Front Desk (no approval): sell standard products at standard prices; apply pre-approved discounts/promos; collect payment; issue standard receipts.
• Front Desk (manager approval required): manual price overrides; comp transactions; changing a member’s active plan; issuing credits outside policy; waiving fees.
• Manager (no approval): approve front desk exceptions within defined rules; apply policy-based refunds/credits; resolve misapplied products; correct taxes when an error is identified.
• Owner approval required: refunds/credits above a defined threshold; any “custom deal”; reinstating expired promos; repeated exceptions for the same member; anything that changes your written policy.

If you already run approval gates for adjustments, align this plan with your adjustments workflow: Refunds, Credits, and Account Adjustments in Gymizen.

Role-by-role responsibilities (so setup doesn’t stall)

• Owns pricing philosophy (what you sell, what you don’t).
• Sets approval thresholds (what requires owner vs manager approval).
• Signs off on the final QA checklist before go-live.
• Reviews exceptions weekly (not ad hoc all day).

• Builds the product catalog and maps it to real workflows.
• Configures taxes using accountant guidance.
• Defines standard checkout scripts for front desk.
• Runs QA tests and documents edge cases.
• Trains front desk and coaches on “what to do” vs “what to escalate.”

• Completes training transactions in a safe test workflow (or during soft launch hours).
• Validates checkout speed: can we complete a standard sale in under 60 seconds?
• Reports friction points: confusing product names, missing common discounts, unclear escalation path.
• Adopts “no improvising” rule: if it’s not in Gymizen or it requires approval, we escalate—no backchannel promises.

• Understand which offers exist and which don’t (so they don’t promise an unsupported deal).
• Know the escalation path: coaches do not negotiate pricing; they route members to front desk/manager.
• Help identify “package fit” signals (e.g., member needs an upgrade path) to reduce churn driven by plan mismatch.

The 10‑day rollout plan (setup → QA → training → controlled launch)

You can compress this into a week if you’re moving fast, but don’t skip QA. Pricing and taxes are where “we’ll fix it later” becomes weeks of cleanup.

Day 1: Build your “source of truth” price sheet (one page)

Before you touch configuration, create a one-page source of truth that Gymizen must match. This prevents the most common failure mode: building products in software that don’t match how you sell in real life.

1. List every active offer you actually sell today (not what’s in your old software).
2. Group into categories: Memberships, Packs, Drop-ins, Intro/Trial, Retail, Events, Fees.
3. For each item, write the operational rules: expiration, billing frequency, access limits, eligibility, and whether taxes apply.
4. Mark each item as Standard (front desk can sell), Conditional (requires manager approval), or Rare (owner approval).

• If your list is longer than ~20–30 active items for a single-location boutique studio, you likely have product sprawl. Identify duplicates to retire.
• Confirm you have exactly one “default” intro offer (or two at most). Too many intros = inconsistent sales + member confusion.

Day 2: Configure your product catalog in Gymizen (clean, minimal, intentional)

Now translate the price sheet into Gymizen products. The goal is not just accuracy—it’s clarity at checkout. Front desk should be able to pick the right item without guessing.

1. Create products in order of importance: Memberships → Intro/Trial → Packs → Drop-ins → Fees → Retail/Events.
2. Apply consistent naming conventions (from the “Recommended defaults” section).
3. Add internal notes/definitions where your team usually gets confused (e.g., what “Unlimited” includes, whether open gym is included, etc.).
4. Disable or archive any legacy offers you do not want sold going forward (don’t keep them “just in case”).

• One product = one operational meaning. Don’t use one product name for two meanings (e.g., “Unlimited” that is sometimes monthly and sometimes annual).
• Avoid “Custom” products except for rare, owner-approved edge cases.
• Use fees as fees, not as negative discounts. Late cancel/no-show should be explicit fee items so reporting and policy enforcement are consistent.

Day 3: Configure pricing logic (and decide what is allowed to vary)

Pricing logic is where you decide: “Is the system the rule, or is the staff member the rule?” In operator-led teams, the system is the rule—and approvals exist for the few times you want to intentionally break it.

1. For each product, confirm the standard price and ensure it matches your source-of-truth price sheet.
2. Define which discounts/promos exist as pre-approved options (so front desk can apply them consistently without “manual math”).
3. Set guardrails: decide whether front desk can do any manual overrides at all. If yes, keep it extremely narrow and manager-audited.
4. Document a simple escalation flow: “If member asks for X, do Y.” Post it at the desk and in internal SOPs.

• Prefer promos over overrides: if a discount happens more than once a month, it should be a defined promo, not a manual price change.
• Cap discretionary discounts at the manager layer (example: manager can approve up to a defined % or $ amount; owner approves beyond that).
• No “coach-negotiated” pricing. Coaches refer. Front desk sells. Managers approve exceptions.

Day 4: Configure taxes (with accountant guidance) + test taxable vs non-taxable items

Tax rules vary widely by state/province/country and by category (services vs goods vs digital). Gymizen can enforce tax application, but you must supply the correct policy. Use your accountant/bookkeeper’s guidance and document it.

1. Create the tax rate(s) you need (for example: sales tax on retail; separate tax rate for certain services if applicable in your jurisdiction).
2. Assign tax behavior per product category (retail vs memberships vs packs vs fees).
3. Identify edge cases that commonly get mis-taxed: initiation fees, drop-ins, training packages, event tickets, and late fees.
4. Run test checkouts that include both taxable and non-taxable items on the same receipt (this is where configuration issues surface).

Implementation note: If your team has historically handled taxes inconsistently (or “we’ll fix it at month-end”), treat this day as mandatory. Fixing tax logic later is painful because it often means revisiting receipts, not just changing a setting.

Day 5: Configure checkout permissions + approval gates (the core control layer)

This is where Gymizen becomes “operator-led” instead of “software that records whatever happened.” Your goal: front desk can complete 95% of transactions quickly, while the 5% that create margin leakage require review.

• Manual price override (any change to standard price).
• Comps (free transactions).
• Discounts outside pre-approved promos.
• Refunds and credits (especially after day-of-sale).
• Waiving fees (late cancel/no-show).
• Membership plan changes that alter billing terms.

1. Define roles: Owner, Manager, Front Desk, Coach.
2. Assign permissions so coaches cannot sell or discount (unless your model truly requires it).
3. Set manager approval rights for defined exception types.
4. Set owner approval for high-impact exceptions (above-threshold refunds/credits, custom deals).
5. Confirm the approval queue is visible and reviewable by the right people (so exceptions don’t stall).

If your team is also implementing tighter adjustment controls, align this with Refunds, Credits, and Account Adjustments in Gymizen so that checkout gates and adjustment gates reinforce each other (instead of creating loopholes).

Day 6: Build your QA test script (don’t rely on “seems fine”)

Your QA script is a list of transactions your team will run end-to-end to prove configuration is correct. The value is not the transactions—it’s the edge cases that create revenue leakage when they’re handled inconsistently.

• Standard membership sale: sell your most common membership at full price; confirm receipt, taxes (if applicable), and member access/entitlement.
• Intro/trial sale: sell intro; confirm expiry rules and that it doesn’t accidentally grant ongoing membership behavior.
• Pack sale + booking: sell a pack and immediately book a class; confirm pack decrement logic and that the right membership/pack is used.
• Retail sale: taxable product (e.g., shirt/gloves); confirm tax application and that revenue reports reflect it.
• Mixed cart: one non-taxable item + one taxable item; confirm taxes apply only where intended.
• Approved discount: apply a pre-approved promo; confirm it is selectable by front desk without approvals.
• Unapproved discount attempt: try a manual price override as front desk; confirm it triggers approval (and cannot be completed without approval).
• Fee charge: late cancel/no-show fee posted; confirm it records correctly and appears in reporting.
• Fee waiver attempt: try to waive the fee; confirm it requires the right approval.
• Refund/credit flow: attempt a refund that should require manager or owner approval; confirm it routes correctly and is visible for later review.

• A single doc with screenshots or notes: what you expected vs what happened.
• A list of issues found + who owns each fix (manager vs owner).
• A final sign-off checklist (end of Day 7).

Day 7: Run QA with real staff (front desk + manager) and fix what breaks

Run QA with the people who will actually do checkout. Owners and managers often know the policy—but front desk knows the reality: how fast checkout needs to be, what members ask for, and where confusion happens.

1. Have front desk run the full QA test script while the manager observes (don’t let the manager “drive”).
2. Track time-to-complete for the top 3 transactions (membership sale, pack sale, retail sale).
3. Document every moment of hesitation: product naming confusion, missing promo, unclear policy, unexpected approval gate.
4. Fix issues immediately where possible (rename products, adjust promo availability, tighten permissions).
5. Re-run the failed scenarios until they pass.

• Pass: front desk can complete standard sales without approvals; approvals trigger only for real exceptions; taxes behave as expected; receipts match expectations; reporting categories are sensible.
• Fail: front desk needs manager intervention for normal sales; taxes apply inconsistently; discounts can be applied freely; fees can be waived without approval; refunds can be processed without review.

Day 8: Train the team (scripts + “what to do when it’s not standard”)

Training should be short, concrete, and role-specific. The goal is not to teach every feature—it’s to teach the 10 actions they do weekly and the 3 actions they must never improvise.

• Top transactions: sell a membership, sell an intro, sell a pack, sell retail.
• Promos: how to apply pre-approved promos; how to explain promos to members without negotiating.
• Fees: how late cancel/no-show fees are applied and how to handle pushback.
• Escalation rules: when you escalate to manager (and how to do it without promising an outcome).
• Approvals: what an approval gate means and what to tell the member while it’s pending.

• How to review and approve/deny exceptions quickly (same day when possible).
• How to document the reason for approvals (so you can spot patterns later).
• How to identify “repeat exception members” and decide whether policy or pricing needs adjustment.

• What offers exist (and what offers do not exist).
• How to hand off: “Front desk can get you set up—here’s what I recommend based on your goals.”
• What not to do: don’t promise discounts, refunds, or special pricing.

Checkout script default: “We have three standard ways to train here. Based on what you told me, I recommend X. If you ever need to change, we can—our manager handles plan changes so it stays consistent.”

Day 9: Soft launch (controlled hours, real transactions, tight monitoring)

A soft launch is not a full cutover. It’s a controlled period where you run real checkout flows while the implementation lead is “on call” for fixes.

1. Pick a 3–6 hour window with typical foot traffic (not your busiest rush).
2. Have the manager available to approve exceptions in real time.
3. Track every approval gate triggered: what was it, why, and was it expected?
4. Rename or reorganize products immediately if staff hesitation appears.
5. At end of window, run a quick reconciliation check: do sales totals and transaction counts look right?

• Approval gates trigger fewer than ~5% of transactions (unless you deliberately ran edge cases).
• Front desk can complete standard sales without help.
• No one uses workarounds (like “we’ll ring it later”).

Day 10: Go-live + week-one monitoring (exceptions review becomes your early-warning system)

Go-live isn’t the finish line. Your week-one goal is to stabilize checkout so exceptions become signal (policy gaps, confusing offers, training needs) rather than noise.

• Approval queue review: manager reviews and clears exceptions at least once daily.
• Discount usage: verify discounts used are the expected, pre-approved ones.
• Fees and waivers: confirm fee waivers are rare and have documented reasons.
• Tax sanity check: spot-check a few receipts across product categories.
• End-of-day reconciliation: ensure sales activity matches what you expect operationally (volume, product mix).

If you want a structured first-week cutover plan across your whole workspace (not just checkout), pair this with Gymizen Go‑Live Week: A 7‑Day Approval‑Gated Cutover Plan.

Common mistakes (and how to avoid them)

• Mistake: too many products with overlapping meanings. Fix: consolidate. If two items exist “because of history,” retire one and migrate members forward.
• Mistake: allowing front desk to manually override prices. Fix: remove override permissions and replace with a small set of pre-approved promos. Use approvals for true exceptions.
• Mistake: hiding policy gaps behind “we’ll just discount it.” Fix: decide policy, then encode it. If members frequently ask for a certain accommodation, create a formal option with approvals, not ad hoc discounts.
• Mistake: mis-taxed fees or mixed carts. Fix: run mixed-cart QA every time you change taxes or add a new taxable retail category.
• Mistake: approvals that stall checkout. Fix: limit what requires owner approval; ensure managers can approve common exceptions quickly; define response-time expectations.
• Mistake: coaches promising deals. Fix: a 10-minute coach briefing with a simple rule: coaches recommend the right plan; they don’t negotiate pricing.

How to know it’s working (Gymizen success signals)

When this rollout is successful, you’ll feel it in operations—not just in reports. Here’s what “working” looks like inside Gymizen and inside your team.

• Front desk confidence: staff can explain options, complete checkout fast, and escalate exceptions without improvising.
• Fewer Slack/text interruptions: owners aren’t constantly asked “can I discount this?” because the system handles normal cases.
• Cleaner member conversations: members hear consistent pricing and policies, which reduces churn driven by perceived unfairness.
• Exceptions are intentional: when an exception happens, it’s because you chose it—not because the system allowed it silently.

• Discounts are predictable: the same promos appear repeatedly; you don’t see a long tail of one-off discounts.
• Approval queues are small and reviewable: approvals don’t pile up because the right people can clear them.
• Fewer adjustments after the fact: refunds/credits become rare and documented, not your default fix for checkout confusion.
• Product mix makes sense: your top 5 products represent most sales volume; you’re not spread across 50 micro-products.

From a retention wedge perspective, a clean checkout system matters because it prevents “policy chaos.” When members feel pricing is arbitrary—or when billing mistakes happen—trust breaks, and churn becomes more likely. Tight checkout controls are a retention tool, not just an accounting tool.

Where to plug this into your broader Gymizen rollout

This checkout setup plan works best when it’s integrated into your broader implementation sequence:

1. Workspace baseline → Single‑Location Workspace Setup in Gymizen
2. People + permissions → Staff Onboarding + Permissions in Gymizen
3. Checkout controls (this guide) → Products, Pricing, Taxes, and Approvals
4. Adjustments discipline → Refunds, Credits, and Account Adjustments in Gymizen
5. Go-live cutover → Gymizen Go‑Live Week

Conclusion: Make the system the rule—and approvals the exception

A clean product catalog and consistent checkout workflow do more than “organize your POS.” They remove ambiguity—so your team can sell confidently, members experience fairness, and you stop bleeding margin through untracked exceptions.

If you implement this 10-day plan, you’ll end up with: (1) fewer products, (2) fewer manual overrides, (3) a real approval process for the exceptions that matter, and (4) a QA-backed setup you can trust. That’s the operator-led standard Gymizen is designed for.