Data Management

This standard governs data quality in the customer record system: the one-person-one-row rule, how duplicates arise, the merge procedure, the search-first discipline, periodic review, and how the directory's figures are to be read. It applies to front desk staff, who prevent duplicates daily and carry out merges, and to managers, who approve doubtful merges and review data quality monthly. The system enforces the rule on every write path: find or create by exact email, so the same person booking twice lands on the same customer row. The desk's duty is everything the system cannot enforce: catching the duplicates that slip in through doors the matching cannot see, and merging them without losing history. Customer data is handled under the Privacy Policy, for the single purpose of serving the customer; no export is permitted without authorization.

How duplicates get in

The matching is exact-email. Everything else is a door

• No email at creation. A walk-in booked without an email cannot be matched later. When they book online next month with an email, that is a second row. This is the most common door, and the fix is at intake, not in the records afterward.
• Spelling variants. Two spellings of one name are the same human and different text; the matching cannot join them.
• Nickname against legal name. The booking says one form, the register says another.
• The older-records split. A record created in the older booking-side customers set and one created directly in the customer record system for the same person, where the carry-over never linked them: usually, again, because of the email.

None of these is anyone's fault; they are the ordinary disorder of a busy desk. Creating one is not the failure. Leaving it is.

The merge

A merged record is marked with a pointer to the record it was merged into. Staff shall carry out a merge in this order

1. Decide the survivor. Usually the row with the most history: appointments, payments, notes. Open both profiles side by side and compare before touching anything.
2. Re-point the linked records. The duplicate's pets, appointments, notes, and payments move to the survivor. This is the step that matters: a merge that moves the customer row but orphans the pets has made things worse.
3. Stamp the pointer. The retired row is marked as merged into the survivor. Nothing is truly deleted; the audit trail stays intact.
4. Reconcile conflicts by hand. Two phone numbers, two addresses, different spellings of the name: the system cannot decide these. Staff can. Call the customer if necessary; a wrong guess propagates everywhere the record goes.
5. Verify afterward. Open the survivor and check: pets present, appointment history complete, notes intact, lifetime value sensible. Then search for the duplicate's name and confirm only one row answers.

Merging is corrective work. When in doubt, do not merge; ask a manager. An unmerged duplicate is messy; a wrong merge is destructive.

The search-first discipline

Prevention beats correction. Before creating any customer, staff shall search

1. The email first: exact match is the matching key.
2. Then the phone: the most reliable key when the email is unknown.
3. Then the last name: catches the spelling variants.

Thirty seconds, every time, with no exceptions for "I'm sure they're new." Certainty is how duplicates are born.

Periodic review

Once a month: more often for a high-volume desk: staff shall sort the directory by last name and scan for near-matches: the pairs the daily discipline missed, such as the same phone with different names, the same address with different emails, and the reused-pet-name problem at the customer level, described in Customer Profile. Merge promptly. Every day a duplicate lives, its history splits further across the two rows and the merge gets harder.

What the figures can and cannot tell you

The directory's aggregates are honest but limited, and data management means knowing the limits

• Lifetime value $0 usually means the ledger has no payments tagged with that customer's identifier, not that they have never paid. Staff shall not "fix" it by hand; fix the payment linkage going forward.
• Outstanding balance $0 across the board is the current truth, not a fault. When balances begin flowing: fee invoices, payment plans: this figure becomes the desk's money list; keep it clean by collecting against invoices promptly.
• A customer missing from the customer record system but present in the older records is almost always the no-email case, under Customers. Add the email to the older record and let the carry-over bring it across; do not create a fresh row by hand and end up with two.

Controls

• No customer record shall be exported, in whole or in part, without authorization. Exports, where authorized, are for the single purpose stated in the authorization.
• Staff shall not keep customer data in spreadsheets or other parallel systems. Under the standing rule, an empty record set means its connection is not built, never that it is unused. The vaccination record set has its structure but no rows; the entry path is not built yet. That is a gap to flag, not permission to track vaccinations in a spreadsheet. Spreadsheets become parallel systems, and parallel systems become the duplicate factory. If the record set exists, the data goes in it; if the entry path does not exist yet, say so plainly so it gets built.
• A doubtful merge shall be referred to a manager rather than guessed.

Records

A merge is recorded by the merged-into pointer on the retired row, with the survivor's re-pointed pet, appointment, note, and payment links. Search-first checks, periodic reviews, and authorized exports shall be carried out as duties under this standard; the customer records themselves are kept in the customer record system.

Escalation and review

Managers review the monthly duplicate scan, doubtful merges, and any request to export customer data. A data fault that the store cannot resolve shall be reported to support@aapawz.com. Legal process concerning customer data, including requests under the Privacy Policy, shall be directed to legal@aapawz.com.