A data file is an input, not an output. Five steps take it from delivery to a conversation: specify, load, match, route, work. None of them depend on a particular tool — they depend on being done in that order, because each assumes the one before it. And the whole thing is a loop rather than a project, because what you learn working one delivery should change the specification for the next.
The file is an input, not an answer
Most writing about construction data stops at the purchase. You choose a provider, agree coverage, pick a plan, and the article ends — as though the file arriving were the outcome rather than the starting gun.
It is worth being direct about this because it is where value actually gets created or lost. Two firms can buy identical files covering identical markets and get completely different results from them, and the difference is never the data. It is whether anything happens between the file landing and somebody picking up a phone.
What follows is the process a firm should run around a delivery. It is written to be tool-agnostic on purpose. Whether you work in a full CRM, a shared spreadsheet, a warehouse or a printed list on a clipboard is genuinely your business — the file is designed to fit the system you already have rather than to require a new one. What matters is the sequence, because each step quietly assumes the one before it has happened.
This is also the part nobody markets, which is why it is worth writing down. It applies whether you buy from us, from somebody else, or assemble the records yourself from public portals — and which kind of firm you are changes the emphasis but not the order.
Specify before delivery, not after
The first step happens before anything arrives, and it is the one most often skipped: decide what a usable record looks like for your business, in writing, and have the file cut to that before it is sent.
That means answering four questions concretely. Which jurisdictions do you actually sell into — not which ones you might one day. Which record and property types match what you do. What value threshold makes a project worth a conversation. And which fields your process genuinely requires, as opposed to which ones would be nice to have.
That last one is worth pausing on. There is a real difference between "we want contact details" and "our process cannot start without a phone number." The first is a preference; the second is a filter. Contact coverage varies by authority, so requiring a field costs you volume — sometimes a little, sometimes a lot. Deciding that deliberately is very different from discovering it one dial at a time.
Every filter you apply costs you records and buys you relevance. That trade is the single most consequential decision in this whole process, and it is made before the file is built.
Get this right and everything downstream is easier. Get it wrong and no amount of process discipline recovers it, because you are working the wrong records efficiently. The published field list is the right place to start that conversation, and the jurisdiction list is the other half of it.
Five steps to use construction data, from file to first conversation
Once the specification is agreed, the loop runs the same way on every delivery.
| Step | What happens | What breaks if you skip it |
|---|---|---|
| 1. Specify | Jurisdictions, categories, value thresholds and required fields agreed before the file is cut. | Your team spends its first hour filtering instead of selling, every single delivery |
| 2. Load | The file goes into whatever system your team already opens each morning — CRM, spreadsheet, warehouse, whatever it is. | Records live in an inbox attachment, which is where good data goes to be forgotten |
| 3. Match | New records are checked against the accounts and contacts you already hold. | You cold-call existing customers and miss the fact that a live account just filed again |
| 4. Route | Each record goes to whoever owns that territory, trade or account — by rule, not by forwarding. | Two reps call the same contractor, or nobody does because everyone assumed somebody else had |
| 5. Work and suppress | Records are actioned, outcomes recorded, and anything touched is marked so the next delivery does not resurface it. | The same record gets called three deliveries running, which is worse than never calling it |
Step three is highlighted because it is the one that converts a list into a plan, and the one most often left out entirely.
Two things about that table are worth drawing out. None of the five steps requires particular software. A firm running this in a spreadsheet with disciplined ownership will outperform one running it in an expensive CRM without it. The tooling question is genuinely secondary — how the file is cut and delivered is not.
And it is a loop. Step five feeds back into step one, because working a delivery teaches you things the specification should absorb — a category that never converts, a jurisdiction producing more noise than work, a value threshold set too low. A specification that has not changed after three months is a specification nobody is learning from, and the jurisdictions you take are usually the first thing to move.
Matching is where a list becomes a plan
Of the five, step three deserves its own section, because it is the one that changes what the data means.
An unmatched file is a list of strangers. The same file matched against your own records is something else entirely: it tells you which of your existing customers just filed for new work, which lapsed accounts have started building again, and which names are genuinely new. Those are three different conversations, and only one of them is a cold call.
The mechanics are unglamorous. You are matching on company name and address, both of which arrive in whatever form the authority published them — abbreviations, suffixes, trading names, addresses formatted five ways. Some of it matches cleanly, some needs a rule, some needs a person. It is worth doing anyway, because the alternative is treating a current customer's new project as a cold lead, which is the fastest way to make a good data investment look like a bad one.
The most valuable output is usually the smallest. Existing accounts that just filed are a short list, they are warm, and they are the records most likely to produce revenue this quarter. A firm that does nothing else with a delivery but pull that subset has already justified the file. That is also the argument the supplier case and the general contractor case both rest on, from opposite ends of the same job.
Want to test this on real rows? We can put together a sample cut to your jurisdictions and categories, so you can run it through your own process before committing to anything.
Request a sample file or call 888-888-1214What to watch in the first ninety days
Four measures, in rough order of usefulness. All of them are about the process rather than the data, which is the point.
How long between a record arriving and somebody attempting contact. This is the single best indicator of whether the process is working, because everything else downstream depends on it. If the answer is measured in weeks, the delivery cadence is faster than the team can absorb and should be slowed until it is not.
What share of delivered records were actioned at all. A file where 30% gets touched is not a data problem, it is a capacity or routing problem, and buying more records will make it worse rather than better.
What share of records matched an account you already hold. Useful in itself, and useful as a signal: a very low match rate in a market you have sold into for years usually means the matching rule needs work, not that the market is new to you.
How many times you have changed the specification. Zero after three months is a warning sign, not a success — it means nothing learned in step five has made it back to step one. Adjusting what you receive is meant to be routine.
Notice what is not on that list: conversion rate. It matters enormously and it is the wrong thing to look at first, because a poor conversion rate on records nobody contacted for three weeks tells you nothing about the data. Fix the process measures first, then judge the source.
Why Alliance Data Solutions
The loop above works with any complete records set. The case for this one, in the same terms.
Step one happens at our end. Records across 300+ jurisdictions in 39+ states are deduplicated, scored on how many of their up to twenty fields carry a value, and filtered to the jurisdictions, categories and thresholds you set — before delivery. That is the difference between receiving a working file and receiving a raw one with the instruction to sort it, and the sorting is the expensive part because it happens at sales compensation rather than data cost.
Formats that fit whatever you already run. CSV, Excel or SFTP, which import into effectively any CRM, spreadsheet or warehouse. We deliberately do not sell an interface, because the file needs to land where your account history already lives — and that is what makes step three possible. The twenty published fields are the same in every format. API access is on the 2026 roadmap and is not live today.
A cadence that matches what you can absorb. Refresh frequency is set by plan — monthly on the entry tier, weekly above it, weekly plus on-demand pulls at the top — and nationwide programs are quoted to whatever schedule suits. That matters given the first measure above: the right cadence is the one your team can work through, and a faster file than that only builds backlog. If you are unsure which fits, the plans are published and you can start slower and move up.
The specification is meant to change. Adjusting jurisdictions, categories and thresholds as you learn is a normal part of the arrangement rather than a renegotiation. Published plans run from a single metro up to multi-state, billed monthly with no contract, which is what makes changing your mind cheap.
And the limit, stated the same way it is stated everywhere else on this site: this is public building activity, assembled, deduplicated, scored and filtered at national scale. It is not a proprietary intelligence network and we do not claim one. Nothing above will work if the process is not there, and no provider can supply that part for you.
Common questions
How do you use a bulk construction data file?
Five steps, in order: specify what a usable record looks like before delivery, load it into whatever system your team already works in, match it against the accounts you already hold, route it to whoever owns that territory, and suppress what has already been actioned. The order matters more than the tooling, because each step assumes the one before it has been done.
What format does construction data come in?
CSV or Excel files, or delivery over SFTP, filtered to the jurisdictions, record types and thresholds agreed in advance. Those formats import into effectively any CRM, spreadsheet or warehouse, which is deliberate — the file is meant to fit the system you already use rather than require a new one. API access is on the 2026 roadmap and is not live today.
How often should you receive construction data?
As often as your process can absorb it, and no more. A weekly file that gets worked beats a daily file that accumulates. The constraint is rarely the data — it is how quickly a team can move records from arrival to first contact, and a delivery cadence set faster than that only creates backlog.
Should construction records go into a CRM or a spreadsheet?
Whichever your team already opens every morning. A spreadsheet a rep actually works beats a CRM record nobody looks at, and the reverse is equally true. The one thing worth insisting on is that records land where the rest of the account history lives, because matching new filings against existing customers is the step that turns a list into a plan.