← All articles

Where Did This Name Come From? Building a List You Can Defend

September 26, 2026 · 4 min read · By Growth7

A spreadsheet lands in your inbox from a vendor. Two thousand rows, job titles, emails, a column labeled "industry" that is mostly blank. You upload it, send a campaign, and the bounces start. A few unsubscribes arrive with a note: who are you? Somewhere around the third complaint, someone asks the question nobody can answer — where did this name come from?

That question is the whole problem. Not the bounce rate, not the deliverability hit, not the awkward reply. The fact that no one on your team can explain why a specific person is on your list means you cannot fix the list, repeat what worked, or defend the outreach to anyone who asks. You're guessing at scale, which is just guessing with a bigger bill.

A List Is a Set of Criteria, Not a File

The useful reframe: a good list isn't a file you acquired. It's a set of criteria you can state out loud. "Independent HVAC contractors within forty miles of Columbus with a Google listing and fewer than fifty reviews." "Operations leads at logistics companies in the Southeast who list warehouse automation on their profile." Say that sentence and you already know what to write, what the offer should be, and whether the campaign failed because the message was wrong or because the audience was.

This is why sourcing from Maps and LinkedIn behaves differently from buying rows. When you pull businesses from Maps, the criteria are the search: category, geography, presence of a listing, what the business publicly says it does. When you pull from LinkedIn, the criteria are role, company, and stated focus. Every record arrives attached to the reason it's there. That reason survives into the campaign, into the reporting, and into next quarter when someone new asks why you're emailing plumbers in Tucson.

It also changes how you handle a bad result. If a segment underperforms, you don't discard the list — you adjust the criteria. Too broad on geography, too junior on title, too many businesses that clearly don't have a marketing budget. A file you bought offers no such handle. You can only throw it away and buy another one.

Sourcing Only Matters If the Record Lands Where the Work Happens

The second half of this is plumbing, and it's where most sourcing efforts quietly die. A team runs a good search, exports a CSV, and then that CSV sits in someone's downloads folder. Or it gets imported into a tool that isn't the tool where campaigns actually run, so the contact exists twice, in two states, with two versions of the truth.

The point of sourcing inside the platform is that a newly found business is a contact in the same audience as everyone else from the moment it's found. It can enter an email sequence, receive an SMS, get an AI voice call, and be targeted socially — without a handoff. More importantly, engagement scoring starts working on it immediately. The record doesn't need to prove itself in a staging area first. It starts accumulating behavior on day one, and within a couple of touches you can tell the difference between a cold name and a warm one.

For operators running several brands, this matters twice over. Sourcing criteria are rarely portable — the search that fills a regional roofing client's pipeline has nothing to do with a B2B software client's. Keeping each brand's sourcing, audience, and scoring separated means you can run a tight, specific search for one client without polluting another's list or confusing your own reporting.

The Practical Test

Before your next campaign, open your audience and pick five contacts at random. For each one, try to answer in a single sentence why that person is in your database. Not "they're a lead" — the actual criteria that put them there.

If you can do it for five out of five, your sourcing is sound and your next move is a messaging question. If you can only do it for two, you don't have a campaign problem. You have a list you inherited rather than built, and no amount of subject-line testing will fix that. The fastest path forward isn't a better email. It's running one specific, stateable search and sending to that instead.