Anatomy of a dialer-ready record: one row, every field, what each is for

Here is a record.

Illustrative record, built to the spec we deliver to. The name and address are invented, the phone is from the reserved 555-01XX range, and the property facts were chosen to show every field populated.

We read 41 vendor pages selling phone data to call centers on 13 September 2026. One of them showed a sample row. It left out the two columns that decide whether a number can be dialed at all — the line type, and the date the number was last verified — which is a fair summary of why so many “dialer-ready” files arrive needing a week of work. The rest of this page walks the record above block by block: what each field is for, which part of the floor reads it, and what happens when it is blank.

Disclosure: Scout Data is our product, and the record above is the shape our call-center files ship in. The column names are ours; the columns themselves are what any dialer needs from anyone.

Block one: who owns the house

Four fields, and the first one is doing more than it looks. The owner name is split into first and last because a dialer merges them into a script — “is this Margaret?” — and a single “name” column merges badly. But the split name is a derived field. The recorded one is owner_name_on_title: OKAFOR MARGARET A & DAVID E, uppercase and ampersanded, because that is how the county typed it on the deed. Two things live in that string. It tells you there are two owners and the phone reached one of them, so a rep who hears “this is David” has a right party, not a wrong one. And it is the evidence of how the match was made: a vendor that returns “Margaret Okafor” and nothing else has either resolved the phone by name and thrown away the proof, or matched it to the address and tidied the resident’s name into the owner’s slot. You cannot tell which from the tidy version.

owner_type keeps trusts, LLCs and estates off a residential dial list, or flags them if a floor wants them. And owner_occupied is not a field a vendor should assert without showing its work, which is why the mailing address sits beside it: when the tax bill goes to the house, the owner most likely lives in it. When it goes to a PO box across town, the flag was a guess.

Block two: the phone

This is the block that separates a dialer record from a lead, and it is eight fields, not one. Taking them in the order a dialer needs them:

• phone and phone_rank. One number per row, ten digits, no punctuation, because a phone column cast to a number in a spreadsheet becomes scientific notation and a phone with brackets fails half the import validators in use. The rank says this is the number the vendor stands behind. A record with four unranked numbers is a record where nobody decided, and the deciding happens at agent wage.
• line_type, with its method and date. Wireless or not decides which dialing mode may touch the number and which consent rules attach to it; it is also the strongest single predictor of whether a homeowner answers. The value carries how it was determined and when, because a number that was a landline in 2019 can be a mobile now. Why this one column runs the whole day is in wireless vs landline homeowner lists.
• owner_verified. The statement that this phone was resolved by name to the person on title, rather than associated with the address. It is the difference between a working line and a working line that reaches the owner, and it is the one field most files leave implicit.
• mobile_activity_12mo and phone_last_seen. Whether the line is in use and how recently anyone confirmed it. Both matter more than they look. On two 25,000-record files a Bay Area solar floor dialed between 31 August and 10 September 2026, records whose mobile showed carrier activity in five or more of the last twelve months produced 3.65 times the appointments per dial of the rest of the file. And phone data moves: on re-enriched paid orders in July and August 2026, 1.4% of records went dead inside six weeks. A file with no last-seen date is a file whose age you cannot know.
• on_dnc_list and dnc_scrubbed_on. A yes/no flag is a claim; the date is the 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 needs scrubbing again before it is dialed, and only the date tells you that. Some floors dial DNC-flagged numbers under their own compliance basis; the flag lets them route on it instead of discarding the row. What the purchased file can and cannot carry for you is in TCPA-compliant homeowner leads.

Block three: the clock

One field, and the most commonly wrong one on files that carry it at all. The calling window runs on the homeowner’s clock, and the law’s window — 8 a.m. to 9 p.m. where the person is — is judged on where they are, not on the prefix of their number. The 972 on the record above is a Dallas area code, and this time it agrees with the house; but area codes stopped meaning where someone lives when numbers became portable, and a homeowner in Plano who kept a 617 from a Boston job is a 7 a.m. call if the dialer trusts the prefix. The record carries a timezone derived from the property ZIP, as its own column, so the dialer can be pointed at it. If your file does not, derive it before load — the method is in dialer-ready lead lists.

Block four: the fields that set the pitch

A name and a live number produce a connect. They do not get anyone past “why are you calling me,” and on a homeowner file that question is answered by the property columns. Which ones matter depends on what the floor sells; the record above carries the set that serves all three of solar, roofing and HVAC:

• year_built and living_sqft start every age calculation and size every quote. A 1998 home is plausibly on its second roof and its second or third air handler.
• last_sale_date is tenure. Ten years in the house means this owner has replaced something already and has a contractor’s number; a sale last spring means they have neither.
• solar_on_roof carries its basis — no permit on file and no panels in aerial imagery — because a permit’s absence alone is not evidence. It is the suppression for a solar floor and the target for a battery or service one.
• last_roof_permit and last_hvac_permit give the setter a fact to open with. “The last permit we can see on the home is a 2013 system replacement — is that still the unit?” is a different call from “are you interested in HVAC.” “None on file” means none the permit feed can see, which is why the feed’s coverage for that county belongs on the order, not in the row.
• heating_fuel decides whether the heat-pump sentence lands or dies.

Every one of those is either recorded by a county, licensed from somewhere, or modelled — and a modelled field is a guess dressed as a measurement. Which common fields are which, and what a blank means in each case, is in homeowner data fields explained.

Block five: where it came from

Three small fields that nobody reads until something goes wrong, at which point they are the only fields anyone reads. source and batch stamp every row with the vendor and the delivery, so a file can be judged apart from every other file on the floor; a list that is blended at import can never be un-blended, and a vendor you cannot evaluate is a vendor you cannot fire. delivered_on is the age of the file. And household_id is the key that makes “attempts per household” mean something, that dedupes the same parcel under an owner’s name and a trust’s, and that matches a suppression file without a fuzzy join.

Who reads what

It helps to notice that two different readers consume the same row, and they read different columns. The dialer reads the phone, the rank, the line type, the timezone, the DNC status and the household key — the fields that decide whether and how a number gets dialed, and it reads them at import, once. The setter reads the owner name, the owner-occupied flag and the pitch fields — the fields that decide what gets said — and reads them on every call. A file can serve one reader and fail the other. A feed with beautiful property detail and no line type serves the setter and stalls the dialer; a compliance-perfect file with nothing but a name and a number loads instantly and gives the rep nothing to say. The record above has to carry both halves because the floor is both readers.

The two columns most sample rows leave out

Back to the one sample row in 41. It omitted line type and the verified date, and the omission is not random: they are the two columns a vendor cannot populate from a property database alone. Line type needs a carrier lookup or a block-and-port check on every number. A last-seen date needs the vendor to have verified the number rather than copied it. Both cost something per row, and both are invisible on a screenshot of a spreadsheet. When a sample row shows every property field and neither of these, it is showing you which half of the record the vendor built — and the half that is missing is the half the dialer reads. Ask for a sample export, not a sample screen, and check those two columns before any other. The rest of what the file has to carry, and the pre-purchase check on a sample, is in homeowner phone lists for call centers.

Frequently asked questions