Importing your customer list

Your customer list already exists — in a spreadsheet, or exportable from whatever you’re leaving. The importer takes that file and loads customers, properties and even equipment in one sitting, then walks you through the one part a file can’t carry: putting every pin at the water.

The file it wants

A CSV — one customer or property per row. From Excel or Google Sheets that’s Save As → CSV; upload the Excel workbook itself and LakeOps will stop and tell you exactly that, rather than importing garbage. You don’t need to rename your columns to match ours: the importer reads your headings and matches “Owner”, “Service Address”, “Gate Code” or “Lake” on its own, and the mapping screen shows every guess so you can correct it before anything is written.

Useful columns, if you have them: names (or a company — an HOA with twelve properties collapses to one customer, the way it should), email and phone, the street address, the lake, the zone, access notes, and coordinates if your old system had them. Only the street address is required.

Equipment columns come too

A column like “Lifts” or “Dock” is offered as equipment: pick which item type it means and the importer creates the items — “Lifts: 2” becomes two lifts on that property. It’s careful about the difference between a count and a size: “Sections: 6” becomes one dock whose spec says six sections, not six docks — which matters, because a per-section rate would bill six docks six times. A column you don’t confirm is skipped and the preview says so; the importer never invents equipment from a heading it half-recognized.

The preview is the import, stopped short

Before anything is written you read a preview of exactly what each row will create. It isn’t a summary of what the importer will probably do — it’s produced by the same code that does the import, stopped one step before saving. What you read is what you get.

Running it

Each row is imported on its own, so row 214 having no street address doesn’t undo the 213 that were fine. Failed rows are listed with what was wrong; fix the file or the data and run again — only the failed rows are retried, and everything already imported is left alone. Customers repeated across rows collapse to one, and rows matching customers already in your account attach to them instead of creating twins. A lake named in the file that you don’t have yet is created for you.

Nobody loads 400 properties in one sitting, and the importer doesn’t expect you to: come back Thursday and its page picks up exactly where you stopped.

Then fix the pins — this is the real work

Addresses without coordinates are placed on the map automatically, and here is the thing to know about that: a geocoder puts a lake house at the road. Your crew arrives by water. So the import ends in a pin queue, ordered least-trustworthy first: the map moves to each property, you drag the pin to the dock, confirm, and it moves to the next. Fifty pins becomes a rhythm rather than fifty chores. A pin you place by hand is never overwritten by any later re-placement — your drag is the last word. See install and storage pins for where item-level pins fit in.

What to do after

An imported book is customers, properties and items. The pieces a spreadsheet rarely holds — each item’s two map points and the service plans — are the remaining setup, and the dashboard checklist tracks both until they’re done. Then generate your first season.