What PoolBoss Says
You import an existing customer list with a CSV file: export your spreadsheet or your old software's customer list, upload it, and map each column to the right field. Good software previews the parsed rows before anything saves and skips customers you already have, so a second upload cannot double your list.
Leaving the spreadsheet is the hard decision, and if you are reading this you have already made it. What is left is the part nobody warns you about: three years of names, phone numbers, addresses, and pool notes sitting in one file you built by hand, and a brand-new system that starts out completely empty.
Retyping 60 accounts is most of a working day you do not have, and rushing it is exactly how the same house ends up with two customer records. The whole job is really a file and a few clicks. What follows is the file you need, how your columns get matched to the right fields, what comes over besides contacts, and what an import deliberately leaves for you to set up yourself.
At a glance
Key takeaways
- Export your list to CSV before anything else - it is the only format the importers accept, and Sheets or Excel saves one out in two clicks.
- Leave your column names alone; the importer matches headers like "Client Name" and "Svc Address" to the right fields on its own.
- Run the four imports in order - customers, then pools, then routes and service history - so each one can attach to what came before it.
- Read the 5 sample rows in the preview before confirming; it is the only check that catches good data landing in the wrong field.
- Re-uploading a customers, pools, or history file skips what you already have, so a second attempt after a bad first run is safe.
- Do not re-run a routes file you already committed - routes are never deduped, and you will end up deleting a duplicate set.
- Budget a little time after the import for recurring schedules and billing, because the file moves your records and not your setup.
How do I import my existing customer list into pool service software?
You import a customer list in five steps: get the list into a CSV file, upload or paste it, check the columns the importer matched, read the preview, and confirm. For a book of 60 accounts the whole sequence runs in a few minutes, and nothing is written to your account until that last click. If you are still weighing whether to leave the spreadsheet at all, that decision comes first - this guide assumes it is already made and covers only the mechanics of getting the data in.
- Get your list into a CSV. Google Sheets and Excel both save one out from their download or save-as menu. If your accounts live in another pool service tool, look for a customer export in its settings - that lands as a CSV too.
- Upload the file or paste it in. The wizard takes a CSV either way, so a straight copy out of your spreadsheet works when you would rather not go hunting through your downloads folder.
- Check the column matching. The importer reads your header row and matches columns like "Client Name" or "Svc Address" to its own fields on its own. Scan what it picked and fix anything it read wrong.
- Read the preview. The dry run shows the matched columns, how many rows will import, how many will be skipped as customers you already have, and the first 5 parsed rows exactly as they will be stored.
- Confirm. This is the only step that writes anything. Then run the same motion again for your pools, your routes, and your service history.
A CSV file is all you need to start
The only format the four importers accept is CSV - comma-separated values, the plainest spreadsheet export there is. You can hand one over two ways: pick the file off your computer, or paste the raw text straight into the wizard. Pasting is the quicker path when the list is already open in a browser tab.
An .xlsx file will not upload as-is. Excel and Numbers both save one out as CSV in a couple of clicks, and that converted file imports normally. A customer export from QuickBooks Online works the same way: export it to CSV, then run that file through the importer like any other list. That is a file import rather than a live account connection - how PoolBoss works with QuickBooks is a separate question with its own answer.
If you have no file to adapt - a paper route book, or a list that mostly lives in your head - you do not have to guess at the format. Each of the four importers offers a downloadable template: a header row naming the fields it expects, plus one example row showing what a filled-in record looks like. Fill it in, save it, upload it.
You do not have to rename your columns to match
Your header row can keep saying whatever it has always said. The importer reads your headers and matches them to its own fields automatically, so "Client Name," "Cell," and "Svc Address" land on name, phone, and address without you opening a mapping screen. A dependable pattern-matching pass runs first on every import, and a smarter matching layer runs on top of it that only ever improves the result rather than degrading it. Where a header is genuinely ambiguous the importer says so instead of guessing, and you set that one column by hand. Matching that bends to your file instead of making you rewrite it is most of what operators mean when they call pool service software easy to switch to.
Take a solo operator in Mesa, Arizona running 60 residential accounts off the same Google Sheet for three years. His columns read "Client Name," "Cell," "Svc Address," and a scratch note saying chlorine or salt. A few cells are blank and his service-day notes switch between "Sat" and "Saturday." He copies the sheet out as a CSV, pastes it into the customer importer, and every column he cares about is matched before he has finished reading the screen. The preview flags 2 rows as customers he already has - leftovers from a test import the week before - and skips them instead of doubling them. He confirms, 58 customers land, and the inconsistent service-day column becomes a note he tidies later rather than a wall that stopped the import.
Customers, pools, routes, and history import separately - in that order
There are four importers, not one, and they are meant to run in sequence: customers first, then pools, then routes and service history. The order matters because each later importer matches its rows against records that already exist. A pool row finds its owner by the customer's email or name. A routes file is one row per stop, and each stop is resolved against pools you have already imported. A history row attaches to a pool by that pool and the date of the visit. Run routes before pools and most rows have nothing to attach to.
This is strong guidance rather than a locked gate - the importers will accept the files in any order - but going out of sequence turns clean rows into per-row errors you then have to chase down. The upside of doing it in order is that the structure you already keep survives the move: a routes file carries your route names and the stop order your sheet has held for years, and it comes across the way you drive it. Service history is worth importing even when it feels skippable, because it is what lets a customer ask what you did in April and get a real answer.
Re-importing will not double your customers, but it will double your routes
Three of the four importers protect you from a second upload and one does not, and knowing which is which saves a genuinely irritating cleanup. Customers, pools, and service history each carry their own duplicate check, so re-running a file that overlaps what you already have skips those rows rather than making second copies of them. Routes do not dedupe. Every routes import inserts fresh routes by design - routes are few and usually hand-checked before they go live - so re-running a routes file you already committed leaves you with a second set of them to delete.
Two details are worth knowing before your first upload. A pool skipped as a duplicate is also left out of the pool-count check against your plan, so a re-import cannot push you up a tier on pools you already had. And a customer row with no email always imports rather than being quietly dropped as a suspected duplicate, which matters when part of your book is phone-only.
| Import | Counts as a duplicate when | Re-running the same file |
|---|---|---|
| Customers | Same source record ID, or the same email address | Skips the customers you already have |
| Pools | Same source record ID, or the same customer and pool nickname | Skips the pools you already have |
| Service history | Same source record ID, or the same pool and service date | Skips the visits you already have |
| Routes | Never - routes are not deduped | Creates a second set of routes |
Nothing saves until you confirm the preview
Every import runs as a dry run first, and that dry run is the whole safety net. Before a single row is written you see the columns the importer matched to its fields, how many rows will import, how many will be skipped as duplicates, any rows that failed validation with the reason attached, and the first 5 parsed rows rendered exactly as they will be stored. Read those 5 rows properly. They catch the mistakes a column-name check never will - a phone number that landed in the address field, or a date read as month-day when your sheet meant day-month.
Two things will not look finished the second you confirm, and both are normal. Map pins for imported addresses fill in shortly afterward rather than instantly, because addresses are geocoded by a background pass instead of at the moment of import. And an import moves your records, not your operating setup: recurring service schedules, billing details, and technician assignments are all yours to configure afterward, which is the rest of getting your account set up. The import is the part that would have cost you a day. What is left is an hour of decisions only you can make.
FAQ
Frequently asked questions
What should I clean up in my spreadsheet before I import it?
Fix the two things that create real work later - duplicate rows and split contact fields - and leave the rest alone. Scan for the same household appearing twice, which usually happens when a customer cancelled and came back, and delete the stale row before you upload rather than merging records afterward. If your name lives in two columns as a first name and a last name, combine them into one, and if a single cell holds both an address and a gate code, split the gate code into its own notes column so it does not end up inside the street address. Everything else can stay messy. Blank cells import fine, inconsistent notes import fine, and extra columns you do not need are simply left unmatched rather than causing an error. The instinct to spend an evening making the sheet perfect first is the wrong one, because the preview will show you exactly which rows have problems in about 30 seconds.
Can I import a QuickBooks Online customer export?
Yes, as a CSV file. Export your customer list out of QuickBooks Online, save it as a CSV, and run that file through the customer importer the same way you would run a spreadsheet you built yourself. The column names QuickBooks writes are recognizable to the matching pass, so in most cases the fields line up without manual work. What this is not is a live connection: there is no button that signs into your QuickBooks account and pulls the customer list across on its own, and no ongoing sync that keeps the two lists matched afterward. It is a one-time file handoff. That distinction matters mostly for what happens next - a customer you add in QuickBooks later will not appear in your pool software by itself, so once you have imported, pick one of the two as the place you add new customers and let the other follow.
How long should I expect the import to take?
Under 20 minutes for a typical book, counting all four imports rather than just the customer list. The upload and preview steps take a minute or two each because the work is reading a screen rather than typing, and the confirm step is effectively instant regardless of whether the file has 30 rows or 300. The time you actually spend is in getting the CSV out of wherever your list lives, which is a couple of minutes for a spreadsheet and longer if you are typing a paper route book into a template first. What that replaces is the better part of a working day retyping accounts by hand, and the retyping version has the worse failure mode: transcription errors that are invisible until a tech drives to a mistyped address. If an import is taking much longer than this, it is usually because the source file needs splitting - the limit is 1,000 rows per file.
What if my customer list is on paper and I have no spreadsheet?
Start from the downloadable template rather than building a spreadsheet from scratch. Each importer offers one, and it comes with the header row already written and one example row showing the shape of a filled-in record, so you are typing into a structure that is guaranteed to import instead of guessing at column names. Work through your route book one customer per row. The only fields worth being careful about are the ones you will actually route and bill on: name, phone, and the service address. Everything else can be added later on the customer record itself, and it is faster to add notes and gate codes in the software over your first few weeks than to try to capture everything up front. If your book is large, split the typing across a few sittings and import each batch as you finish it - later batches skip anyone already imported, so overlapping between batches is harmless.
Should I import my customers before or after I invite my technicians?
Invite your technicians first if you plan to assign routes during the import, and it makes no difference otherwise. A routes file can name the technician who runs each route, and that name only resolves if the technician already exists on the account - otherwise the route imports without an assignment and you attach a tech to it by hand afterward. Inviting people takes a minute each and does not depend on any of your data being in place, so doing it before the import costs nothing and removes a step from the other side. The one thing worth not rushing is what your techs see on day one. A technician who logs in before your pools and routes are imported sees an empty app and reasonably concludes the software does not work, so either invite them and mention the data is landing this week, or wait until the imports are confirmed before sending the invitations.
Do I need to import everything before I can send my first invoice?
No. Customers are the only import an invoice depends on, and you can invoice an imported customer as soon as that first file is confirmed. Pools, routes, and service history make the invoice more useful rather than making it possible - a service report attached to an invoice needs the visit history behind it, and per-pool line items need the pools imported - but none of it blocks billing someone for work you have already done. A practical order for a mid-month switch is to import customers, invoice normally out of the new system for that cycle, and bring pools, routes, and history across over the following week while the billing side is already running. The one thing worth checking before you send anything is that the imported email addresses are right, since an invoice sent to a stale address from an old spreadsheet fails quietly.
What if I have more than 1,000 customers to import?
Split the file. Each import accepts up to 1,000 rows at a time, so a book of 1,400 accounts imports as two files rather than one, and there is no penalty for doing it in batches. Splitting is safe specifically because of how duplicate detection works on customers: rows that match something already imported are skipped rather than duplicated, so an overlap between your two files - or a re-run of a batch you lost track of - does not create second copies. Sort the source sheet before you split so each file is a coherent chunk you can keep straight, by route or by area rather than at a random row. The one import to be careful with when batching is routes, which does not dedupe at all, so track which route batches you have already committed and do not re-send one.
