Two member records share a phone number, but that does not prove they belong to one person. They could be duplicate entries, relatives using one contact number, or records created at different locations. Deleting one before checking can remove the history you were trying to repair.
Clean gym CRM data by reviewing suspected matches, establishing which source supports each field, reconciling linked records and recording every authorized correction. Treat duplicate detection as a review queue, not permission to merge or delete.
This is a review runbook, not an instruction to run database edits and not a claim that Gym Ledger has an automatic merge facility. Use only supported, authorized correction tools. If your system cannot preserve required relationships, stop and involve its support team before changing the records.
Start with a small, reversible review
Select one bounded group, such as suspected duplicates created during a specific import. Record the date, selection rule and person responsible. Use a restricted export or snapshot through the approved process where available; an export is evidence, not proof that a deleted record can be fully restored.
Keep cleanup separate from outreach. Do not put uncertain records into a new message campaign while staff are still deciding which contact details and communication restrictions are valid. Stop any conflicting automated process through its normal controls before a supported correction, without disabling unrelated operations.
| Review category | Useful signal | What the signal does not prove |
|---|---|---|
| Possible duplicate | Similar name and matching normalized phone | Same person or permission to combine histories |
| Conflicting payment | Same external reference appears twice | Two real payments or an automatic right to delete one |
| Incomplete source | Acquisition source is blank | That the member came from the latest campaign |
| Stale lead stage | Stage has not changed for months | That the lead should be marked won or lost without evidence |
| Contact conflict | An old opt-in and a later opt-out coexist | That retaining the oldest record restores permission |
Normalize display formats only for comparison. For example, remove spaces from a working phone comparison value while retaining the original entered value and country context. Do not guess missing country codes or overwrite an unverified number because it resembles another one.
A completed duplicate review
The following identifiers and amounts are fictional. They illustrate record reconciliation and are not an industry benchmark or accounting advice. A qualified accounts owner must review corrections that affect financial reporting.
| Field | Record DEMO-101 | Record DEMO-208 | Review outcome |
|---|---|---|---|
| Name | Alex Demo | A. Demo | Similar, not sufficient by itself |
| Contact reference | CONTACT-17 | CONTACT-17 | Shared contact requires identity confirmation |
| Plan reference | PLAN-SEP-01 | PLAN-SEP-01 | Compare agreement and start dates |
| Origin | Staff-created account | Later spreadsheet import | Import lineage explains a possible duplicate |
| Payment reference | TX-DEMO-71, 2,000 | TX-DEMO-71, 2,000 | Same external evidence, investigate duplicate recording |
| Contact instruction | Earlier opt-in | Later stop request | Keep the stop instruction effective during review |
The reviewer confirms through the gym’s approved identity process that the records represent one person. The signed membership agreement and original transaction evidence identify the intended account and payment. If identity remained uncertain, both records would stay separate with an open review item.
Choosing DEMO-101 as the proposed surviving account is not the whole correction. First map the memberships, receipts, attendance, access identifiers, notes and communication restrictions attached to both records. A clean-looking member list is not success if check-in stops working or a payment disappears from a report.
| Related record | Proposed handling | Evidence needed before completion |
|---|---|---|
| Membership | Preserve the agreed plan and original dates | Agreement and current status agree |
| Payment | Count the verified transaction once through an approved correction | Original transaction and receipt reference reconcile |
| Attendance | Preserve distinct real visits; review duplicated import events | Date, origin and event identity, not just matching day |
| Access identity | Confirm the correct member-to-device relationship | Authorized access check without inventing a visit |
| Contact restriction | Preserve the effective stop instruction | Restriction remains active after correction |
| Notes | Retain necessary factual history under the access policy | No sensitive material copied into broad dashboards |
If the software cannot perform that relationship-preserving operation, do not imitate a merge by deleting one account and manually recreating the rest. Ask support for a supported route and keep the unresolved record clearly identified in the review sheet.
Reconcile the money before changing the total
Suppose the approved membership charge is 3,000 currency units. There was one real payment of 2,000, but it appears on both records. The imported screen total is therefore 4,000 even though the external evidence supports only 2,000 received.
| Check | Before review | Verified position |
|---|---|---|
| Agreed membership charge | 3,000 | 3,000, unchanged |
| Recorded payment rows | 2,000 + 2,000 = 4,000 | One real transaction of 2,000 |
| Supported payment total | Unreconciled | 2,000 |
| Remaining amount under the agreement | Conflicting display | 3,000 − 2,000 = 1,000 |
Do not issue a real refund of 2,000 to correct duplicate bookkeeping. That would send money back even though there was no second receipt of money. The accounts owner should use the system’s supported correction procedure and verify the ledger, receipt history and member balance afterward.
Conversely, two equal payments with different valid transaction references may both be genuine. Amount and date are not enough to declare a duplicate. If the evidence is unavailable or contradictory, mark the balance disputed and investigate before asking the member to pay again.
Keep a correction log that explains the result
Use a restricted log with enough detail for another authorized reviewer to reproduce the decision. Do not paste card details, passwords, full bank statements or unrelated personal information into it.
| Field | Completed example |
|---|---|
| Review ID | CLEAN-014 |
| Records in scope | DEMO-101 and DEMO-208 |
| Trigger | Later import duplicated the same membership reference |
| Verified evidence | Identity check, agreement PLAN-SEP-01 and transaction TX-DEMO-71 |
| Approved outcome | Preserve intended account and relationships; correct duplicate payment recording only |
| Before and after control | Supported receipts 2,000 before and after; remaining amount 1,000 |
| Reviewer | Accounts owner, with membership administrator |
| Required validation | Receipt, balance, visit history, access relationship and stop instruction checked |
| Status | Pending supported correction until every validation passes |
A proposed outcome is not a completed correction. Record the actual tool used, operator, time and resulting record references only after the operation succeeds. If one relationship fails validation, keep the case open and contain the problem before resuming dependent work.
Prevent the same defects from returning
At entry time, let staff search existing records before creating a new one. When they find a possible match, give them a review route rather than pressuring them to choose quickly. For imports, agree identity keys, source dates and duplicate-handling rules before loading the file.
Separate missing information from guessed information. “Source unknown” is more useful than attributing every old member to social media. Keep stage changes tied to real events, and record why a correction was made instead of silently replacing history with today’s best guess.
Review a bounded sample after cleanup. Check whether the same defect appears again, whether unresolved cases have owners, and whether downstream reports still reconcile. A lower duplicate count is not automatic causal proof of better sales or retention. Deleting disputed rows can make a metric look better while making the data worse.
Use the front-desk checklist to improve entry and handover controls, the weekly owner scorecard to track unresolved issues, and the retention worksheet to keep reporting populations consistent after corrections.
Frequently asked questions
Can matching phone numbers be merged automatically?
No. A shared phone number is a review signal, not proof of identity. Confirm the person and inspect memberships, payments, attendance, access relationships and communication restrictions before any supported correction.
What should happen when duplicate records disagree about payment?
Reconcile the agreement, original transaction evidence and receipt references with an authorized accounts owner. Equal amounts do not prove duplication, and duplicate recording should not trigger a real refund without evidence that money was received twice.
Does this runbook require deleting duplicate members?
No. It requires a documented review and a supported correction path. If the system cannot preserve the required history and relationships, keep the case open and ask support rather than using deletion as a substitute for merging.
