A successful import means your member records arrived. It does not yet mean your front desk can trust every profile, your coaches can recognize every booking, or your managers can act on retention signals without contacting the wrong person. Duplicate profiles, old plan names, missing contact preferences, and ambiguous household relationships often become visible only when staff begin using the new workspace.
This guide starts after an initial member import and ends when a manager has signed off on the records needed for normal operations. It is a proposed operator workflow, not a claim that every correction or approval has a dedicated Gymizen button. Confirm the controls available in your workspace; where a particular approval or field is unavailable, maintain the decision in a controlled issue register and make the final change through an authorized operator. The aim is simple: no quiet guesses about identity, entitlements, or consent.
Define the finish line before editing anything
Set a review window of 10 working days and name one owner for the source export, one Gymizen administrator, and one business approver. The administrator executes authorized changes; the approver decides ambiguous or financially significant cases. They may be the same person at a very small studio, but the decision and the edit should still be recorded separately. Keep the original export read-only, note its creation time, and identify which legacy system remains authoritative until sign-off.
The scope is member identity and operational readiness: matching people to records, validating active status and plan access, checking the information staff need for bookings and follow-up, and confirming that imported communication preferences are not silently broadened. This sprint does not redesign pricing, initiate a new marketing campaign, or turn incomplete billing data into permission to charge someone. Route those projects through their own review.
Prerequisites to gather
- A dated, read-only source export; an import summary or record count; and the field mapping used for the migration.
- Your list of active plans, packs, freezes, and location-specific entitlements, with a named owner for interpreting each rule.
- A staff roster showing who may view records, propose corrections, make edits, and approve exceptions.
- A secure issue register with a case ID, record IDs, issue type, source evidence, proposed change, approver, decision, editor, and verification date.
- A small set of test accounts or consenting staff-member records representing your most common member situations.
If you have not completed the initial field mapping and import, start with the member data migration guide. Do not use this cleanup sprint to compensate for an import that is still changing every hour.
Set the approval rules and recommended defaults
Give routine, evidence-backed corrections a short path and uncertain changes a deliberate stop. A front desk lead may flag a misspelled name or outdated phone number and attach the member’s confirmation. An authorized manager can then verify and correct it. Merging two identities, changing an active entitlement, altering a balance, assigning a child to a different household, or changing a contact preference should require explicit manager or owner approval before anyone edits the live record. Treat a disputed payment detail as a billing investigation, not a profile-cleanup task.
- Default match rule: an email address or phone number is a clue, not proof that two records belong to the same person. Require a second independent identifier before proposing a merge.
- Default uncertainty rule: if source records conflict, leave the live value unchanged and mark the case pending. Do not choose the most convenient answer.
- Default communication rule: an absent or unclear preference does not become marketing permission. Escalate the case before using that channel for promotional outreach.
- Default entitlement rule: preserve a member’s documented access while a plan discrepancy is investigated; do not grant an undocumented upgrade or silently remove paid access.
- Default audit rule: every approved sensitive change gets a case ID and a before-and-after check. Keep supporting exports and notes in an access-controlled location.
Check how permissions, activity history, and approvals are configured in your Gymizen workspace. If an action cannot be gated in-product, enforce the gate operationally: staff submit the case, the designated approver records the decision, and only the authorized editor updates Gymizen. Restrict access to the issue register because it may contain personal and payment-adjacent information.
Days 1–2: Build the reconciliation queue
Record the total number of imported profiles, active members, archived or former members, and records without a usable identifier according to your source export. Compare those totals with the corresponding Gymizen views or exports available to your team. Differences are investigation prompts, not automatic evidence of lost data: imports may treat archived accounts, prospects, and dependents differently. Write down the comparison method so a second manager can reproduce it.
Sort suspected issues into four queues: identity, entitlement, reachability, and operational context. Identity includes likely duplicates and ambiguous households. Entitlement includes active-plan status, pack balances, and booking eligibility. Reachability covers contact details and preferences. Operational context includes home location, appropriate staff-visible notes, and class eligibility where relevant. Attach source and destination record IDs to every case. Prioritize people with a reservation in the next seven days, an imminent renewal, an open support request, or an active follow-up task.
Do not clean by scanning profiles at random. Give each queue an owner, a daily review target based on its actual size, and an escalation lane. The owner should be able to answer, at any point: how many cases are open, how many are awaiting a decision, and whether any member-facing action is blocked.
Days 3–4: Resolve identity and household cases
Start with exact matches across source and destination IDs, then review suspected duplicates separately. Similar names are common in family accounts; shared emails are common for parents and children. For each suspected pair, compare at least two independent identifiers, inspect active plans and upcoming reservations, and check whether the records represent one person, two people sharing contact information, or a legacy account created for administrative convenience.
Use a three-outcome decision: confirmed same person, confirmed separate people, or unresolved. A confirmed match does not authorize an immediate merge if doing so might affect reservations, payment history, or a dependent’s access. The approver should first specify which profile remains the operational record and how linked activity will be checked afterward. For unresolved cases, label the issue in the register and tell staff which record to use for the next scheduled class; avoid leaving two plausible check-in choices without guidance.
For a martial arts school with sibling accounts, test each child independently: correct name on the roster, correct class eligibility, and the right adult contact for operational messages. Do not infer a legal relationship or communication authorization merely because two profiles share an address.
Days 5–6: Verify plans and booking access
Take a sample from every meaningful membership type—not just one easy monthly plan. Include an active recurring member, a pack holder, a frozen account, a recently expired account, a new member awaiting first class, and any location-limited or age-limited offer. Compare the source record and the intended policy with what staff see in Gymizen. Then test the member-facing outcome where your setup permits: can the eligible member reserve the right class, and is an ineligible reservation handled according to the published rule?
When an entitlement looks wrong, distinguish an import mismatch from a policy decision. A pack showing an unexpected balance needs evidence of prior use; an expired plan with future reservations needs an operator decision about those reservations. Log what must happen to existing bookings before changing the plan. Require owner approval for adjustments that affect money or access beyond the documented offer. Never ‘fix’ an account by inventing a credit just so a test passes.
For studios with multiple class types, repeat the check across relevant access boundaries: a yoga member booking a workshop, a CrossFit member booking an introductory session, or a boxing member booking a capped class. The specific names differ; the question stays the same: does Gymizen reflect the access your team has promised?
Days 7–8: Check reachability and train the handoff
Review contact details and recorded preferences without sending a bulk test campaign to the whole membership. Use test accounts and a small, authorized sample to verify that operational messages reach the expected person. If a phone number is shared by a household, confirm which member or guardian should receive which type of message. Keep operational reminders and promotional outreach separate in your review: confidence that a booking reminder can be delivered is not proof that the person agreed to marketing.
Run a 30-minute role drill using three realistic cases: two apparent duplicates with different class bookings; a pack balance disputed at check-in; and a parent reporting the wrong child on a roster. Ask each employee to show the next step rather than simply describe it. Coaches should identify and flag a roster concern, not edit household structure. Front desk should keep the member experience moving within approved policy while opening a case. Managers should decide routine evidence-backed corrections and escalate disputed access or financial outcomes. The owner should make policy calls and review patterns that might affect many members.
Day 9: Run a signed QA pass
Have a second person recheck a risk-based sample of resolved cases. Include at least one case from each issue queue, every sensitive correction type used during the sprint, and records belonging to members booked for the next few days. For each case, verify the source evidence, approval, live record, upcoming booking, and any affected staff-facing note. Compare the new open-case count against Day 1 and document why remaining cases cannot yet be closed.
- Identity QA: a search returns the expected operational profile, and known separate people remain separate.
- Access QA: active members can book the classes included in their offer; restricted accounts follow the intended rule.
- Attendance QA: upcoming rosters show the intended member rather than a duplicate or household contact.
- Communication QA: tested operational messages use the expected recipient and channel; unclear preferences remain flagged.
- Control QA: sensitive changes have a recorded approver, editor, reason, and verification; staff cannot bypass the agreed handoff unnoticed.
If an issue reveals a repeated mapping error, pause individual edits. Determine how many records share the fault, agree on a batch correction and rollback approach with your implementation lead, and retest afterward. Repeatedly fixing one profile at a time can hide the size of the problem.
Day 10: Approve normal operations—or extend the hold
At sign-off, the manager should present four items to the owner: the original and current reconciliation counts, a list of unresolved high-risk cases with named owners, the QA sample and failures, and a recommendation about which workflows are safe to use. Approve normal booking and retention follow-up only for records and channels the team can trust. If identity, access, or recipient errors remain widespread, extend the hold on affected workflows rather than declaring a clean launch because the calendar says Day 10.
The post-sprint rule is equally important: new discrepancies go into the same queue, with the same approval thresholds. Assign a manager a brief daily review during the first month, then incorporate outstanding cases into the weekly operating meeting. A solved migration issue is valuable only if staff know how to prevent its replacement.
Role-by-role responsibilities at a glance
- Owner: approves the risk rules, disputed entitlements, financially significant corrections, and final release of affected workflows.
- Manager: owns queue triage, validates evidence, approves routine sensitive changes within delegated limits, and signs the QA sample.
- Front desk: reports discrepancies with record IDs, confirms member-provided details through the approved process, and avoids improvised credits or merges.
- Coach: checks the roster before class, flags incorrect identity or eligibility, and routes corrections instead of editing administrative records.
- Migration administrator or implementation lead: preserves the source snapshot, investigates mapping patterns, performs authorized edits, and documents any batch correction.
Common mistakes that make cleanup harder
The first mistake is treating a matching email as a definitive identity match. The second is measuring progress only by the number of closed tickets; a quickly closed but wrongly merged household is worse than a clearly owned open case. Third, teams sometimes correct access before checking upcoming reservations, accidentally changing what a member can attend tomorrow. Fourth, a staff member may update a contact channel after a casual conversation without recording who supplied it or what use was agreed. Finally, teams may switch on broad follow-up workflows before they have confirmed recipients and plan states.
Avoid these errors with one simple habit: keep evidence, decision, edit, and verification distinct. When a member challenges an outcome, your team should be able to reconstruct it without asking the person to retell their entire history.
What success should look like in Gymizen
A front desk employee can find the right person and understand their current access without choosing between unexplained duplicate profiles. A coach sees the expected attendee on the roster. A manager can identify open discrepancies and who owns them. The owner can review exceptions and trust that follow-up lists are not inflated by duplicate identities or misclassified plans. These are observable outcomes, not a promise that every historical field will be perfect.
Use your own baseline rather than a universal completion percentage. Track open high-risk cases, duplicate candidates awaiting review, booking-access QA failures, incorrect recipients found in testing, and the age of unresolved decisions. A healthy sprint closes or explicitly contains the cases that could disrupt the next week of classes, while leaving a documented path for lower-risk historical cleanup.
Once records are dependable, connect this work to the broader operator onboarding checklist and your go-live cutover plan. Then introduce follow-up workflows with confidence that they will reach the intended member. The practical payoff of careful cleanup is not a tidier database for its own sake; it is a team that can act early when attendance slips without creating a new service problem in the process.
