What PoolBoss Says
Merging combines two records for the same customer into one. Pick the record to keep, then move the duplicate's pools, invoices, quotes, work orders, and service history onto it and archive the duplicate. Good software shows exactly what will move before you confirm, and never merges records on its own.
Nobody notices a duplicate on the day it gets created. You notice it three months later, when an account's invoice history looks half empty, or when a tech logs a visit against a record that has no pool on it. By then the same household has two customer profiles, and the readings, invoices, and notes that should tell one story are split across both.
This is a cleanup job, not a crisis, and it takes about a minute per account once you know where the duplicates surface and what a merge actually moves. What follows is where duplicates come from, how they get flagged, exactly which records land on the survivor, and the two things a merge deliberately does not clean up for you.
At a glance
Key takeaways
- Start the merge from the record you want to keep - history always moves onto the record you have open.
- Duplicates are flagged on two independent signals, the customer's name and the customer's email, so a nickname re-entry with the same email still gets caught.
- A misspelled name with a different email will not be flagged automatically; find those by searching the name when an invoice or history looks incomplete.
- Read the counts on the confirm step - "3 pools, 12 invoices" is the fastest check that you are merging in the right direction.
- Pools, invoices, quotes, work orders, service reports, credits, and service locations all move; where both records priced the same service, the surviving record's price wins.
- A merge does not deduplicate pools - if both records listed the same pool, delete the extra from the survivor afterward.
- Restoring an archived duplicate gives back an empty record, not your pre-merge data, so treat the confirm step as the real decision point.
How do I merge duplicate pool service customer records?
You merge duplicate pool service customer records in four steps: open the record you want to keep, find the duplicate flagged on it, review what will move, and confirm. Start from the account you want to keep rather than the one you want gone - a merge always moves history onto the record you are currently looking at, and there is no picker that reverses that direction mid-flow.
- Open the customer you want to keep. This record survives, so pick the one carrying the pool specs, gate codes, and billing details you want to keep using - not necessarily the older one.
- Find the "Possible duplicate" banner on that record. It lists each likely duplicate with the date it was added, its pool count, and its invoice count, so you can tell at a glance which record is the empty stub and which one holds the history.
- Click "Merge into this customer." That opens a confirm step. Nothing has moved yet, and you can back out.
- Read the summary, then confirm. The confirm step spells out what will move in plain counts - "3 pools, 12 invoices and 1 quote" - and archives the duplicate once you click through.
Duplicate customer records come from three places
Nearly every duplicate traces back to one of three moments, and knowing which one you are dealing with tells you whether the system will catch it for you. The first is a returning pool customer signup: someone cancels in March, comes back in June, and gets added as a brand-new account because nobody searched the name first. The second is an import - a pool customer import duplicate happens when a spreadsheet of accounts gets loaded and one row is already in your pool service customer database under a slightly different entry, which is why importing a customer list skips rows that match what you already have.
The third is plain data entry at intake. A middle initial, "Bob" instead of "Robert," a trailing space after the last name, a work email on one record and a personal one on the other. Each of these creates a second pool service client record that looks new to the software even though the house, the pool, and the person are identical. Roughly speaking, the first two causes get flagged for you automatically and the third one only sometimes does, which is why the next section matters more than it sounds.
How does the software find duplicate customers for you?
Duplicate customer detection runs on two independent signals: the customer's name and the customer's email. Either one matching is enough to raise a flag. Matching is exact on a normalized value - names are trimmed of extra spaces, collapsed to single spaces, and compared without regard to capitalization, and emails are trimmed and lowercased. So "John Smith," "john smith," and "John Smith" with a double space all match each other, and two records sharing one email address match even when the names read differently.
What it deliberately does not do is guess. "Jon Smith" and "John Smyth" are different strings, so a misspelled name alone will not trigger a flag - fuzzy matching was left out on purpose, because near-miss matching fires constantly and trains operators to ignore the warning. The email signal is what rescues most of those cases: a nickname re-entry with the same email still gets caught. In PoolBoss the flag shows up in three places - a needs-attention row on the dashboard, a badge and summary banner on the customers list, and the "Possible duplicate" banner on the customer's own page, which labels whether the match was the name, the email, or both.
That is the difference between a generic contact tool and software built to manage every customer record in one place: operators searching for a pool service CRM or a pool service company CRM usually want exactly this - a pool service customer profile that stays single even when two people type it in twice.
Here is how that plays out on a real route. An operator runs 165 residential stops across Phoenix, Chandler, and Gilbert. A Chandler customer canceled in March and re-signed in June under the same name and email, so she now has two records: an old one with eleven months of chemical readings and three paid invoices, and a new one with a single scheduled visit. That pair gets flagged immediately on both signals. The same week, a 40-row import of an old spreadsheet added a Gilbert customer as "Dave Nguyen" with his personal email, next to the existing "David Nguyen" with his work email. Neither the name nor the email matched, so nothing flagged it, and the office only caught it a week later while hunting for an invoice and finding two rows.
What moves onto the record you keep
Seven categories of records move from the duplicate onto the survivor, and the whole move runs as one transaction - it either completes fully or does not happen at all, so there is no half-merged account with the pools moved and the invoices stranded. After the move, the duplicate is archived rather than deleted.
| Record type | What happens on merge |
|---|---|
| Pools | Move to the surviving customer, with their full reading history attached |
| Invoices | Move as-is, so the balance and payment history consolidate onto one account |
| Quotes | Move to the survivor |
| Work orders | Move to the survivor |
| Service reports | Move to the survivor, keeping the proof-of-service trail intact |
| Account credits | Move to the survivor, so a credit is never stranded on an archived record |
| Service locations | Non-default locations move; pools keep pointing at the right address |
| Saved service prices | The surviving record's price wins on any service type both records priced |
Merging does not clean up duplicate pools
This is the one limit worth knowing before you click confirm: a merge consolidates customers, not pools. If both records had the same physical pool entered by hand, both pool rows land on the surviving customer and you end up with one account listing the same pool twice. The confirm step says so directly - "Pools and service locations move as-is - if both records list the same pool, review for duplicates after merging" - so the two-minute habit is to open the survivor's pool list right after a merge and delete the extra.
The same goes for the rest of the profile. A merge moves history; it does not reconcile the fields on the record itself, so the survivor keeps its own address, phone, notes, and gate code, and anything that only existed on the duplicate needs copying over by hand. Once the histories are together, it is worth a quick pass to make sure the surviving record has everything it should before you invoice against it again.
Can I undo a merge?
Not in the sense most operators mean. The archived duplicate can be restored, so nothing is permanently destroyed, but restoring it does not pull the moved records back - the pools, invoices, quotes, and service history stay on the customer you merged into. What you get back is an empty shell carrying the same name and address as a live account, which is usually worse than leaving it archived.
Because that is easy to misread, the restore path names the survivor explicitly and takes a separate confirmation before it will recreate the record, and the request is refused outright if that confirmation is missing. The practical rule: treat the confirm step as the decision point, not the restore. Spend the extra ten seconds reading the counts before you merge - "3 pools, 12 invoices" tells you immediately if you are about to merge in the wrong direction and strand the account you actually wanted to keep.
FAQ
Frequently asked questions
Which customer record should I keep when I merge?
Keep the record with the most complete profile, not automatically the oldest one. The history follows the merge regardless - pools, invoices, and readings all move onto the survivor - so the thing you are really choosing is which set of profile fields stays: the address, phone, email, gate and access notes, and any saved service prices. In practice the older record usually wins, because it is the one carrying the correct address and the gate code someone wrote down two seasons ago, while the newer record is often a near-empty stub with one scheduled visit on it. Check both before you decide. If the newer record has a corrected phone number or a new address after a move, copy that onto the record you plan to keep first, then merge. The one field that quietly matters is saved pricing: where both records have a price for the same service type, the surviving record's price is the one that stays.
Can my technicians merge duplicate customers, or only admins?
Only admins and managers can merge customers. A technician account cannot, and this is deliberate rather than an oversight. Merging relocates invoices, quotes, and account credits between customers, so it is gated at the same permission level as editing billing documents - the reasoning being that anything capable of moving money documents from one account to another belongs with the people who already handle billing. Your techs can still create customers and log visits normally, and if a tech spots two records for the same house, the useful thing for them to do is flag it rather than try to fix it. Practically, that means duplicate cleanup is an office task. Many operators batch it: once a month, open the duplicate list, work through the flagged groups, and clear them in one sitting rather than handling them one at a time as they surface.
What happens if the duplicate record has an unpaid invoice on it?
The unpaid invoice moves onto the surviving customer along with everything else, and the balances consolidate into one account. This is the main reason not to leave duplicates sitting: an outstanding balance on a second record is invisible when you look at the first one, so the customer looks paid up while an invoice quietly ages on a profile nobody opens. After the merge, the survivor shows the combined balance and the full payment history, and any account credit sitting on the duplicate moves too, so a credit never gets stranded on an archived record. Nothing about the invoice itself changes - the invoice number, dates, line items, and payment status all stay exactly as they were, and a paid invoice stays paid. If autopay is set up on one record and not the other, check the surviving record's billing settings afterward, since payment settings live on the customer profile rather than on the invoice.
How do I find duplicates if I have hundreds of customers?
You do not have to hunt for them one by one - flagged duplicates surface in three places without any searching. The dashboard shows a needs-attention row for each duplicate group, reading like "2 customers named Maria Delgado" and linking straight to the record. The customers list badges each duplicated row and shows a summary banner across the top counting how many possible duplicates exist and how many distinct groups they fall into, which is the fastest way to see the size of the cleanup before you start. And the customer's own page carries the "Possible duplicate" banner with the merge action on it. The gap is the unflagged kind - a misspelled name with a different email. Those turn up when something looks wrong: an account with no visit history, an invoice you cannot find, or a customer who says they have been with you for years on a record created last month.
Should I merge duplicates before or after importing a customer list?
Clean up the duplicates you already know about before the import, then work the flagged list right after it. Importing into a customer database that already has known duplicates multiplies the problem, because each pre-existing pair can pick up a third row from the import file. After the import finishes, the flagged duplicates surface the same way they always do, so the cleanup pass is the same work either way - it is just shorter if you went in clean. One habit that saves real time: before importing, scan the file for the accounts you know are already in the system, and either drop those rows or make sure the name and email in the file match what you already have exactly. Rows that match an existing customer on name or email get flagged for you; rows entered under a variant spelling with a different email will not be, and those are the ones you find months later.
What if two of my customers really do have the same name?
Nothing breaks, and you should leave them alone. A route of any size eventually serves two different households with the same common name, and the software treats that as normal - a duplicate flag never blocks you from saving a new customer, and it never merges anything on its own. It only says "you already have a customer like this" so you can check before creating a second record by accident. If you have confirmed the two are genuinely different people, just ignore the flag and carry on; it costs you a moment of attention, not a workflow. To make them easier to tell apart at a glance, put something distinguishing in the record itself - the street name in the customer name field, or the service address clearly filled in on both - so the next person who opens the list can tell which Maria Delgado is the one on Palm Avenue without opening both records.
Will merging change anything my customer sees?
A merge is an internal record change, so it does not notify the customer or alter any document that has already gone out. Invoices keep their original numbers, dates, and line items, service reports keep their original send history, and nothing gets re-sent as a result of the merge. What does change is what happens next: because the account is now single, the next invoice reflects the full balance in one place, and future service reports come from one record instead of alternating between two depending on which one a visit was logged against. The visible improvement is usually on your side of the relationship rather than theirs - one account to look at when a customer calls with a question about a charge, and one continuous run of readings when they ask what you did in April, instead of half an answer from each of two records.
