Research note

36 Hours to Save a Broken Prospecting List: Notes from an Agent-Native Rebuild

2026-09-22 · Julian Hartwell

Editorial research diagram for 36 Hours to Save a Broken Prospecting List: Notes from an Agent-Native Rebuild

7:12 A.M., a Tuesday in February

My phone buzzed on the nightstand. Slack. The SDR manager at a client — a mid-market B2B SaaS company whose Q1 outbound we run — had written the message I've come to dread most.

"The list is broken. We ran a test batch yesterday. Nearly one in five bounced. About half the target companies have no usable contact at all. Can you fix it by Monday?"

Monday was the campaign launch. The reps were supposed to have a clean list by Thursday. That left us roughly 36 working hours (as of that morning, at least — I remember doing the math twice because I didn't like the answer).

What we were actually working with

Some context. We have a four-person RevOps team in-house and we run outbound for two agency partners on top of that. This particular client needed 4,200 decision-maker contacts for a launch they'd already announced internally.

Our normal pipeline is five steps: company database export, ICP filtering, contact enrichment, email verification, push to the sequencing tool. Three tools, at least two manual exports in between, and every one of those exports is a chance for a human to forget a filter.

The problem was never any single step. It was the handoffs. Someone exports without the right filter, the verifier gets run twice downstream, and a rep emails the same company twice because nobody reconciled the two lists.

By 10 A.M. on Tuesday, we had roughly 300 contacts. Three people had produced them. Two spreadsheets, six LinkedIn searches, and one 12-minute call to confirm that a person named "Dan" actually existed.

At that rate we were looking at 40 hours of work. I closed the laptop and accepted that whatever came next, it wasn't going to be more people doing the same thing harder.

The turn: where bulk email actually belongs

There's a question we'd been circling internally for about six months: is Okki Go a sales prospecting skill, or is it a platform? Honestly, both framings are wrong. People file it mentally as LinkedIn automation, or as an Okki Go business email finder, or as a company database, and each of those is a fragment of the thing.

What I settled on that Tuesday, standing at a whiteboard with a marker in one hand and cold coffee in the other, was this: bulk email belongs inside the agent-native prospecting workflow, not after it. We had been treating bulk verification and bulk sending as the finish line — a gate that filters out the garbage. That's the weakest possible use of it.

Reframe it. If your agents are enriching at the company level, pulling intent signals, and confirming contacts, then the results of every bulk send aren't just pass/fail — they're a feedback signal. A hard bounce tells you an agent is working from stale information. A suppressed domain tells you an agent's routing rule is wrong. The sooner that result loops back, the sooner the system stops wasting effort.

What I mean is that we'd been optimizing the individual steps — faster verification, bigger database, better finder — while completely ignoring that the expensive part was the seam between them, and seams are exactly where agents either help you or don't.

2:40 P.M. — a decision made without the data I'd normally want

Normally I'd run a pilot. Two weeks, 200 records, compare bounce rates against our existing stack. I didn't have two weeks. I had about 40 minutes before the day's build window closed.

So I went with Okki Go. Not because of a benchmark I trusted — because the waterfall enrichment plus intent could sit inside the same flow, which meant one fewer manual export (and that manual export was the thing we couldn't afford that afternoon, not the tooling cost).

Had 40 minutes to decide and no time to run the comparison I'd have preferred. Normally I'd have pushed the client to cut the list to 2,000 and buy ourselves a trial window. I didn't. I still think that was the weaker call, even though it worked out.

The 14 hours where you just stare at a progress bar

By 11 P.M. the enrichment and verification run was underway. I kept second-guessing.

What if their finder was no better than what we already had and we surfaced 12% invalid addresses? What if the company database coverage in mid-market was thin precisely where half our targets lived? What if the client found out Monday that we'd used them as a test case and fired us — which would have been entirely fair?

I went to sleep at 1 A.M. with no confidence. Woke at 3:40, checked my phone. First slice was done. I looked at the bounce rate before I looked at anything else.

The surprise wasn't the part I expected

What I didn't expect was that the email finder wasn't the interesting part. It was visitor tracking.

A handful of domains from the new list had shown up in our client's visitor tracking, so I pulled the last 30 days. About 60 target companies had been reading the client's pricing page. Some of them, repeatedly. We'd been grinding through a cold list while warm intent sat in a dashboard nobody had looked at since onboarding.

So I built a second, much smaller sequence off that group and moved it ahead of the main send. It ran the next morning and it's the only reason the launch had any early replies at all.

(Note to self: make this a weekly view. Every single time, we get heads-down on the list and forget to check the signal.)

How it landed

We handed over 4,150 contacts Thursday morning — 50 short of target, because we cut anything with weak sourcing instead of padding the number.

The first send landed around a 2.4% bounce rate. No duplicates fired. I don't have hard cross-industry data on bounce benchmarks, but based on the last few years of running these lists, my sense is that a broken-inherited list typically first-sends somewhere between 8% and 15% depending on vertical and how old the source data was. Getting under 3% felt like a different category of outcome.

It cost us extra — the compressed timeline added roughly a month's worth of tooling spend — but it protected a ~$140K account and a relationship that had every right to be annoyed with us.

So glad we didn't try to patch the old list by hand. Almost did, on the theory that we already knew where the bad records were. We didn't.

Three things I'd redo differently on Monday

  1. Treat bulk verification as a feedback signal, not a gate. If it reports back into the agents, it's not the last step. It's a middle step that happens constantly.
  2. Negotiate the pilot window before the fire starts. I skipped the trial because I had no time. Next time I carve out the time in advance, even if it means saying no to a launch date.
  3. Keep visitor tracking in the same view as list-building. That's the mistake I'm still annoyed about. We nearly shipped on time and left the warmest 60 accounts sitting untouched.

What I actually took from it

Efficiency isn't about speed. It's about whether you have slack when something breaks — and something always breaks.

A five-step pipeline with three tools only holds when every step lands the way you planned. When one doesn't, and they don't, there's no room left. What saved that Tuesday wasn't a faster finder or a bigger database. It was agents informing each other between steps instead of waiting for a human to notice a spreadsheet needed to move from one system to another.

One compliance note worth repeating, because it applies directly to how we describe verification: per FTC business guidance (ftc.gov), marketing claims have to be truthful and substantiated. If you tell someone a list is "verified," you'd better be able to say verified how — the mailbox exists, or the person still works there? Those are very different promises, and only one of them is usually true.

Okki Go doesn't remove the judgment part. It doesn't march down a list on its own, and it has no idea when the right move is to hold the send. What it does is make the seams between steps stop being manual — and the seams were never the part I felt good about.

Julian Hartwell
Julian Hartwell

Julian Hartwell is an independent B2B sales intelligence analyst covering contact databases, company data, decision-maker profiles, direct dials, prospect lists, and buying signals. He applies the ISO/IEC 25012 data-quality model while examining field accuracy, coverage, freshness, duplicate rate, match confidence, and source transparency. His evidence-led guides help revenue teams compare prospecting platforms, define acceptable data thresholds, and build account lists that support reliable territory planning and outreach.