Refunds and credits are where retention, trust, and revenue accuracy collide. If your team handles exceptions by memory (or by whoever’s on shift), you get the worst of both worlds: inconsistent member experience and revenue leakage that’s hard to spot until month-end.
This guide is a practical rollout plan for implementing a clean, approval-gated workflow in Gymizen for refunds, account credits, comp classes, and other adjustments. You’ll set recommended defaults, define role-by-role responsibilities, train staff to route exceptions instead of improvising, and put QA checks in place so you can trust what your reports say.
The outcome you’re aiming for: your front desk can resolve 80–90% of common issues in under 2 minutes, escalations are clean and trackable, and owners/managers approve the truly “policy-breaking” exceptions without becoming the bottleneck.
Who this rollout is for (and what it covers)
- Best fit: CrossFit gyms, yoga studios, pilates studios, martial arts schools, boxing gyms—any boutique operator with recurring memberships, class packs, drop-ins, or appointment packages.
- Covers: refund types, credits, comp classes, price overrides, transfers, cancellations, “make-good” adjustments, and how to route them with approval gates.
- Not a policy document: You should already have basic policies (late cancel/no-show, holds, cancellation terms). This guide shows how to operationalize those policies in Gymizen without constant one-off decisions.
Prerequisites (do these before Day 1)
- One “source of truth” for policy: a short internal doc that answers: When do we refund? When do we credit? When do we comp? When do we say no?
- A defined leadership approver: usually the owner + GM (or ops manager). You need at least one backup approver for weekends.
- Your pricing/membership catalog is stable: if your plans/packages are still changing daily, adjustments will be noise. (If you’re still building the catalog, finish that first.)
- Staff roles exist in Gymizen: at minimum: Owner/Admin, Manager, Front Desk, Coach. (If you haven’t rolled permissions yet, do that first.)
- Payment processor and payout timing clarified: your team should know what “refund” means operationally (money returning to card/bank) vs. “credit” (stored value on account).
Implementation rule: If a staff member can’t clearly explain the difference between refund, credit, and comp, they should not have permission to issue them.
The core model: Four adjustment types (and why they should be distinct)
Most revenue leakage comes from mixing concepts. In Gymizen, treat these as distinct actions with distinct permissions and approval gates:
- Refund: reversing a financial charge back to the original payment method (or processor-supported method). High risk, highest scrutiny.
- Account credit: stored value or balance the member can use later (membership credit, class credit, dollar credit depending on your setup). Medium risk, but easy to overuse.
- Comp / make-good: granting access without changing money (e.g., adding one comp class, waiving a late fee, adding a free week). Great for retention when controlled.
- Correction: fixing a clear mistake (duplicate charge, wrong plan assigned, staff checked in the wrong person, etc.). Low risk if audited and documented.
Your job during rollout is to ensure your team uses the right tool for the job, and that Gymizen records the “why” so reporting stays trustworthy.
Recommended defaults (start here, then adapt)
Below are operator-friendly defaults that typically reduce exceptions, protect retention, and prevent “silent giveaways.” Adjust them to match your brand and market, but avoid letting every staff member invent their own version.
- Refund permission: Owner/Admin only. Manager can request refunds, not execute them.
- Credits/comp permission: Managers can issue small make-goods within a limit; front desk can request; coaches typically do neither.
- Limits: define a “no-approval threshold” for comp classes/credits (example: up to 1 comp class or up to $15 credit once per quarter). Anything above triggers approval.
- Reason required: every adjustment requires a standardized reason code + free-text notes (short, specific, member-safe).
- Cooling-off behavior: do not allow refunds for “forgot to cancel” if your brand relies on policy integrity—use a make-good once, then enforce.
- Single owner of exceptions: one role (usually GM) owns the daily review of the approval queue so requests don’t rot.
Day-by-day rollout timeline (10 days)
This plan is intentionally short. The goal is to get to a working, auditable workflow quickly—then iterate after you have real data.
Day 1: Define your adjustment map (what’s allowed, by whom, and when)
- Owner/GM: list the top 15 scenarios your team sees (late cancel dispute, medical emergency, duplicate charge, schedule change, coach cancel, facility issue, travel, membership cancellation mid-cycle, etc.).
- Owner/GM: decide the default action for each scenario (refund vs credit vs comp vs deny) and the approver requirement.
- Front Desk Lead: review the list and flag anything that will create friction at the desk (e.g., members who expect same-day resolutions).
Deliverable: a one-page “Adjustment Map” that becomes your training handout.
Day 2: Configure roles + permissions for financial adjustments
In Gymizen, configure role-based access so staff can’t accidentally do high-risk actions during a busy shift.
- Owner/Admin role: full access, including executing refunds, editing invoices/charges (if applicable), approving exceptions.
- Manager role: can issue limited credits/comp within thresholds; can request refunds; can approve low-risk exceptions if you want a second tier.
- Front Desk role: can create adjustment requests and add notes; can issue zero refunds; can issue limited comps only if you’re comfortable (most operators keep this as request-only).
- Coach role: no financial permissions. If a coach promises a member a make-good, they must route it through the request workflow.
QA check: log in as each role (or use Gymizen role preview) and verify what the UI allows. If a role can do something you wouldn’t want them doing on a Saturday 9am rush, tighten it now.
Day 3: Build standardized reason codes (so reporting becomes usable)
If you allow free-text-only notes, you’ll never be able to answer: “Why did we issue so many credits this month?” Reason codes make adjustments measurable.
- Policy exception (first-time courtesy)
- Staff error (wrong plan, wrong check-in, wrong charge)
- Schedule change by studio (class canceled, coach called out)
- Facility issue (HVAC, cleanliness, equipment out)
- Medical (note: keep notes minimal; don’t store sensitive details)
- Duplicate charge
- Chargeback prevention (rare, but useful to track)
Recommended default: keep it to 8–12 reason codes. Too many options creates inconsistent selection, which defeats the point.
Day 4: Configure approval gates + thresholds
Approval gates are your anti-chaos lever: they let staff move fast while keeping policy integrity and financial control.
- Choose the threshold for “auto-allowed” comps/credits: start conservative. Example: 1 comp class OR $10 credit without approval, max once per member per 90 days.
- Define what always requires approval: any refund, any change that reduces a membership charge, any manual price override, any backdated cancellation, any credit above threshold.
- Decide your approver tiers: Manager approvals for low-risk; Owner approvals for refunds/high-value changes.
- Set SLA expectations: “All requests reviewed same business day” (or within 24 hours). Without an SLA, staff will keep pinging you in Slack/text.
QA check: create three test requests (small comp, large credit, refund request) and verify they route to the right approver queue.
Day 5: Create the “Exception Request” workflow your team will actually use
Most teams fail here because the workflow is technically correct but operationally annoying. Design it for the front desk reality: fast, repeatable, minimal typing.
- Required fields: member, adjustment type (refund/credit/comp/correction), reason code, amount/value, related booking or invoice (if applicable), notes.
- Notes format (template): “What happened → what member wants → what we propose → urgency.”
- Attach context: link the relevant class reservation, no-show, membership charge, or message thread so the approver isn’t hunting.
- Member communication owner: define who tells the member the outcome (front desk vs manager). Default: the role that closes it communicates it.
Front desk script: “I can absolutely help. We route these through a quick approval so it’s consistent for everyone. You’ll have an answer by tomorrow—often sooner.”
Day 6: Train role-by-role (30 minutes each, not a 2-hour all-hands)
Run three short trainings instead of one long meeting. People only need what they’ll do.
Training 1: Front Desk (30 minutes)
- What they own: intake, de-escalation, documenting the request, setting expectations, and executing allowed comps (if permitted).
- What they do not own: policy negotiation and high-value decisions.
- Practice scenarios: (1) late cancel dispute, (2) member says they were charged twice, (3) class canceled by studio.
Training 2: Coaches (20–30 minutes)
- What they own: logging service issues fast (equipment broken, class disruption) and routing “make-good” requests instead of promising outcomes.
- Coach language to avoid: “They’ll definitely refund you.” Replace with: “We’ll get this reviewed today and make it right within policy.”
Training 3: Managers/Approvers (45 minutes)
- Queue management: how to review, approve/deny, request more info, and close the loop.
- Consistency: use the Adjustment Map; don’t re-litigate policy per member unless you’re intentionally changing it.
- Member experience: how to say no without losing trust (offer alternatives like a make-good when appropriate).
Day 7: Run a controlled pilot (real requests, limited scope)
Pick one operating window to pilot: e.g., Monday–Wednesday for your busiest location, or just “membership billing exceptions.”
- Front desk: route every request through Gymizen—no side texts.
- Manager: clear the queue twice per day (midday + end of day).
- Owner/GM: review 10 completed cases to ensure notes are clean and reason codes match.
Success criteria for the pilot: requests don’t get stuck, members get clear follow-up, and staff feels less anxious (because the process is defined).
Day 8: Add QA checks (so errors don’t compound)
Add lightweight QA checks that catch the most common issues early.
- Daily (5 minutes): Manager checks the approval queue is empty or explained. Anything older than 24 hours is escalated.
- Daily (5 minutes): Spot-check the day’s adjustments: are reason codes used? are notes clear? any suspicious “misc” reasons?
- Weekly (15 minutes): Owner reviews totals by reason code (credits, refunds, comps) and flags anomalies.
- Weekly (15 minutes): Identify repeat offenders: same member repeatedly requesting exceptions, or same staff repeatedly misclassifying adjustments.
Day 9: Expand scope + finalize internal scripts
Once the pilot holds, expand the workflow to include all exception categories (late cancels, booking disputes, membership cancellation timing, and package transfers).
- Finalize the front desk scripts: for “yes,” “no,” and “needs approval.” Consistency prevents escalation.
- Finalize escalation rules: define what constitutes “urgent” (e.g., duplicate charge today, member traveling tomorrow, chargeback threat).
- Publish the Adjustment Map: keep it in your internal knowledge base, and link it in staff onboarding.
Day 10: Go live + set your operating cadence
Make it official. From today forward, no exceptions are handled outside Gymizen. If it isn’t in the system, it didn’t happen.
- Approver cadence: 2x per day queue review (weekday), 1x per day (weekend) with backup approver.
- Weekly owner review: 20-minute review of adjustments by type + reason code + staff origin.
- Monthly policy tune-up: update thresholds and reason codes based on the data you now trust.
Role-by-role responsibilities (what “good” looks like)
Owner / Admin
- Sets the Adjustment Map and approves policy-breaking exceptions.
- Reviews weekly totals and identifies systemic issues (policy confusion, schedule problems, coach coverage gaps, etc.).
- Keeps refund permissions restricted and audits any manual changes.
General Manager / Ops Manager
- Owns the approval queue SLA and ensures nothing ages out.
- Coaches front desk on documentation quality and de-escalation scripts.
- Flags “repeat exception” members for proactive outreach (retention wedge: solve the underlying issue).
Front Desk
- Creates clean requests with the right reason code and links the relevant transaction/booking.
- Sets expectations: timeframe, next step, who follows up.
- Executes only the actions explicitly allowed by permission + threshold (no improvising).
Coaches
- Reports service issues in real time (class disruptions, cancellations) so credits/comp decisions have context.
- Avoids promising specific financial outcomes; routes members to front desk/manager workflow.
Common mistakes (and how to prevent them)
- Mistake: letting front desk issue refunds “because it’s faster.” Fix: keep refunds approval-gated; speed comes from a clean queue SLA, not broad permissions.
- Mistake: using credits as a universal apology. Fix: define when a comp is appropriate vs. a credit vs. nothing; track by reason code.
- Mistake: reason code sprawl (“misc” becomes 70%). Fix: prune reason codes monthly; require a specific selection.
- Mistake: approvals happen in text messages. Fix: “If it’s not in Gymizen, it’s not approved.” Make this a non-negotiable operating rule.
- Mistake: staff writes sensitive medical details in notes. Fix: train “minimum necessary” notes (e.g., “medical exception requested; manager approved one-time credit”).
QA checklist (use this before and after go-live)
- Permission audit: Can any non-owner execute a refund? If yes, fix.
- Threshold test: Does a small comp go through instantly (if intended), and a large one route for approval?
- Reason code compliance: Can an adjustment be created without a reason code? If yes, require it.
- Queue SLA: Are approvers receiving notifications and clearing the queue within your promised timeframe?
- Reporting sanity: Can you see totals by type (refund/credit/comp) and reason code for the week?
- Member communication: Is there a consistent close-out message and owner (who communicates the decision)?
What success looks like in Gymizen (30 days after rollout)
- Fewer repeat escalations: members stop “shopping” for a different answer from a different staff member.
- Shorter resolution time: most adjustments resolved within 24 hours; urgent issues handled same day.
- Cleaner reporting: you can clearly answer: “What did we give away, why, and did it reduce churn risk or just create leakage?”
- Less staff stress: front desk stops feeling like they have to negotiate policy under pressure.
- Policy integrity improves retention: paradoxically, consistent boundaries reduce churn because members experience fairness and predictability.
Next steps (after this workflow is stable)
Once your adjustments are structured and approval-gated, you can move from reactive cleanup to proactive operations: build automation around the most common exceptions, tighten your weekly review cadence, and connect exceptions back to retention actions (save-at-risk members instead of repeatedly comping them).
If you want to keep building your operator-led rollout, pair this workflow with the related implementation guides below.
