The file lands on Friday afternoon. On Monday the import fails on row 4,118 because a name has a stray quote in it. Fixed by ten. Then the ZIP column has lost its leading zeros and every Massachusetts row is in the wrong campaign. Fixed by eleven. The dialer wants one phone per row and the file has four in one cell. Somebody writes a formula. By the time the floor is dialing it is after lunch, the timezone column was never there, and the West Coast is being called at 7am.
“Dialer ready” is the phrase vendors use for a file that avoids that morning. It is not a format; it is nine properties, each of which is either true of the file or is work your team does instead of dialing. This page is the nine, kept generic — every platform imports a little differently, and the properties that make a file load cleanly are the same on all of them.
Nine things the phrase has to mean
1. A fixed column set, named the same every time
The import mapping is built once. A file whose columns move, rename or multiply between deliveries breaks it every time, silently, and the break shows up as a campaign with blank owner names. The minimum:
| Column | Format |
|---|---|
| household_id | A stable key per property, so attempts count per home |
| owner_first, owner_last | As on title; separate columns, never one “name” field |
| address, city, state, zip | Standardised; zip as text |
| phone | Ten digits, no punctuation, one per row |
| line_type | wireless / landline / voip, never blank |
| phone_rank | 1 for the number the vendor stands behind |
| timezone | Derived from zip, stored as its own value |
| dnc_scrubbed_on | The date the registry scrub ran, as YYYY-MM-DD |
| owner_occupied | Y / N |
| source, batch | Vendor and delivery, stamped before anything else |
| pitch fields | Last permit date, build year, panels on roof, sale date — as your script needs |
2. One number per row, ranked
Dialers count attempts per row. Four phones in one cell is four dials that report as one attempt, and a redial cadence that respects attempt limits will quietly break. The clean shape is one row per number with the household key repeated, a rank column, and the platform configured to cap attempts per household rather than per row. If your platform cannot do that, load rank-1 numbers only and hold the rest for a second campaign — a file where the vendor would not rank the numbers is a file where the vendor did not decide which one reaches the owner, and the reps will do the deciding at their wage.
3. Line type on every number
Wireless or not decides which dialing mode may touch the number and which consent rules apply, and it is also the strongest single predictor of whether a homeowner answers at all. A blank in this column is not a missing nicety; it is a row the compliance setup cannot classify. Send it back, or run a carrier lookup before load.
4. Timezone from the ZIP, not the area code
The calling window is the homeowner’s clock, and the only thing on the row that reliably knows where the homeowner is at 8pm is the property ZIP. Area codes were a location once. Derive the timezone from the ZIP, write it as a column, and point the dialer’s window at that column — never at whatever the platform infers from the prefix.
5. Deduplicated at household level, before upload
Row-level dedupe catches identical strings. Real duplicates are the same parcel under an owner’s name and under a trust, or the same house spelled two ways by two sources. Collapse on the household key before the file goes anywhere near a dialer, and dedupe against every previous delivery, not just inside this one — the household that arrives in two vendors’ files is dialed twice by two reps, which is how complaints start.
6. Suppressed against your own lists
Opt-outs, complaints, customers, litigator flags, the households a rep already booked. These live in one file that belongs to you and never shrinks, and it runs against every load before the load. A purchased list that has not been through it will reintroduce a household that asked you to stop in March. The schema, the matching key and the negative-control test that proves the file is actually connected are in building a suppression list.
7. Scrubbed, with a date on it
A yes/no DNC flag is a claim. A scrub date is evidence. The federal rule requires the registry version used to be no more than 31 days old at the time of the call, so a file scrubbed five weeks ago is a file that needs scrubbing again before it is dialed, and the only way to know is the date. Scrub after the phones exist, not before — a scrub run on an address file appends nothing to the numbers added later.
8. An encoding the platform can read
UTF-8 CSV, one header row, no byte-order mark unless your platform wants one, quoted fields where a name contains a comma or an apostrophe, phones as digits, ZIPs as text, dates as YYYY-MM-DD, no formulas, no merged cells, no colour-coding that was carrying meaning. Most of the damage a list suffers happens inside a spreadsheet between the vendor and the dialer: a ZIP column cast to a number drops the leading zero on every Northeast row, a phone column cast to a number becomes scientific notation, a name with a curly apostrophe becomes three bytes of noise. Open the file in a text editor once before loading. If it looks wrong there, it is wrong.
9. Stamped with its source and batch
Before dedupe, before suppression, before anything: every row carries which vendor it came from and which delivery. A file that is blended at import can never be un-blended, and a vendor you cannot evaluate is a vendor you cannot fire. The staging pass that puts the stamps on, and the nine checks that run before any field is mapped, are in data hygiene for CRM imports.
The ten-minute pre-load check
| Check | How | If it fails |
|---|---|---|
| Row count matches the invoice | Count lines minus the header | Something was truncated or padded; ask before loading |
| Phones are ten digits | Length check on the column; no blanks, no letters | Strip punctuation; blanks are rows you were billed for |
| ZIPs are five characters | Length check; count the Northeast rows with four | Re-open as text and re-export; never from a spreadsheet |
| Line type is never blank | Count blanks and “unknown” | Carrier lookup before load, or send back |
| Scrub date is inside 31 days | Read the column | Re-scrub before dialing |
| No household appears twice | Distinct count on household_id vs row count (per rank) | Collapse before load |
| Nothing on your suppression file | Join on the household key and the phone; expect zero | The suppression step is not wired in; fix that first |
| Timezone present and plausible | Spot-check ten rows against their ZIP | Derive it yourself; do not let the dialer guess |
| Owner names look like names | Sort and read the top and bottom fifty | “Current Resident,” trusts as first names, all caps — clean or return |
What the dialer cannot fix
Everything above makes a file load and dial cleanly. None of it makes the phone belong to the owner. A row can pass all nine properties and still ring a tenant, a previous owner or a relative, because the matching happened upstream and the file carries no trace of how. That is a property of the vendor, not the format, and it is measured on a sample rather than in a pre-load check — what a match has to mean and how to test it before you buy is in homeowner phone lists for call centers. Keeping the file dialable after it lands — dead-number replacement, segment rotation, the reload cadence — is list hygiene for call centers; and the layer under all of this, from telephony up through dispositions, is outbound dialer setup for solar floors.
Disclosure: Scout Data is our product, and the file shape in the panel above is what we deliver. The nine properties hold for any vendor’s file, including ones that are not ours.
Frequently asked questions
What does “dialer ready” mean for a lead list?
That the file loads without anyone editing it and dials without anyone apologising for it: a fixed column set, one ranked phone per row, line type on every number, a timezone derived from the property ZIP, deduplicated at household level, suppressed against your own lists, scrubbed against the registry with a date on it, and saved in an encoding your platform reads. Any of those missing is work your team does on Monday morning instead of dialing.
Should a dialer list have one phone number per row or several?
One row per number, with a household key that ties the rows together, beats several numbers in one row. Dialers count attempts per row, so five numbers in one row means five dials that look like one attempt, and one column of numbers means the platform can pace, retry and report on each line properly. Whichever shape you choose, the file has to say which number is primary and why.
How do I get the timezone for a lead list?
From the property ZIP code, never from the phone’s area code. Numbers are portable and mobiles travel with their owners; a 917 prefix on a homeowner in Phoenix is a 9:30pm call if the dialer trusts the prefix. You already know where the house is. Map the ZIP to a timezone, store it as its own column, and let the dialer’s calling window read that.
What file format should a dialer list be in?
A plain CSV in UTF-8, one header row, no formulas, no merged cells, phones as ten digits with no punctuation, ZIPs as text so leading zeros survive, dates as YYYY-MM-DD. Spreadsheets are where lists get quietly damaged — a ZIP column converted to a number loses every New England zero, and a phone column converted to scientific notation loses everything.