Verification research
The 7-Step Emergency Checklist for Evaluating Intent Data Providers and Wiring the okki go API
2026-09-14 · Julian Hartwell
-
Step 1: Write the trigger sentence before you take a single demo
-
Step 2: Pull 500 closed records before the first demo
-
Step 3: Map every signal to a buying stage, or don't buy it
-
Step 4: Test the enrichment waterfall against records where you know the truth
-
Step 5: Wire the API in a sandbox first — and ask five questions nobody asks
-
Step 6: Verify at send time, not at import time
-
Step 7: Keep LinkedIn prospecting human-in-the-loop
-
What actually costs you money (the part that isn't on the quote)
-
Common ways this checklist gets abandoned halfway
This checklist is for the person who just got handed a pipeline gap with a date attached to it. Not a "let's explore intent data in H2" project. The other kind. In February we had 27 working days to add 400 qualified conversations before a board update, and I rebuilt the whole outbound stack twice in that window. What follows is the version I wish I'd had on day one.
Seven steps. The first four are about not buying the wrong thing. Steps five and six are the technical ones — including the part almost everyone skips. Step seven is the one that decides whether any of it survives past the first month.
One caveat before we start: I can only speak to mid-market B2B with a 30-to-90-day sales cycle and a team of nine SDRs. If you're running enterprise deals with 12-month cycles, some of the signal-to-stage mapping below won't translate cleanly.
Step 1: Write the trigger sentence before you take a single demo
Intent data providers sell at least three different things under one label: third-party intent signals, contact enrichment, and email verification. Sometimes all three, sometimes one, and the pricing models are unrelated to each other.
Before any call, write one sentence: When ______ happens, we contact ______ within ______ hours. If you can't fill in all three blanks from your own funnel data, you're not ready to evaluate vendors — you're just collecting slide decks.
Checkpoint: that sentence should exist in writing, in a doc your SDR lead has actually read.
Step 2: Pull 500 closed records before the first demo
Every vendor will offer to run their data against a sample list. Don't use theirs. Pull your own: 250 closed-won, 250 closed-lost, from the last 18 months, filtered to accounts that resemble your current ICP.
This is your reverse-validation set. You already know the answer. What you're testing is whether the provider's signal would have surfaced the winners before your reps found them — not whether it can retroactively explain a deal you already closed.
When I compared two feeds side by side on the same 500 records, one scored beautifully on the won accounts and just as well on the lost ones. That told me everything I needed: it was measuring company size, not buying intent. Seeing won vs. lost scored identically made me realize I'd been reading the coverage number as a quality number.
Step 3: Map every signal to a buying stage, or don't buy it
Intent signals cluster into roughly three buckets, and they need three different responses:
- Category research. Someone is reading about the problem space. Response: content, not a call.
- Vendor comparison. Someone is reading about alternatives. Response: a call this week, with a rep who knows the competitive landscape cold.
- Active evaluation. Someone is reading about implementation, pricing, or migration. Response: same day, or you're already late.
If your provider gives you one composite score and your team treats all three the same, you'll burn your best reps on the top of the funnel and lose the bottom of it. Which is worse than having no signal at all. Sort of.
Step 4: Test the enrichment waterfall against records where you know the truth
Waterfall enrichment means the platform tries one data source, then the next, then the next, until it gets a match. The pitch is coverage. The reality is that coverage and accuracy move in opposite directions, and your test set from Step 2 is the only way to see where the crossover happens.
Measure three things: match rate, field-level accuracy (is the title right, not just present), and cost per usable record. That third number is usually two to four times the headline cost per record, once you strip out stale titles and role-based aliases.
Step 5: Wire the API in a sandbox first — and ask five questions nobody asks
This is the step that gets skipped when you're behind schedule, and it's the one that costs the most to fix later. Anything with a developer integration — okki go's API included — should be evaluated against the same five things:
- Rate limits and quota behavior. What happens on the 1,001st call? Do you get a clean 429, or a silent partial response?
- Webhook retry semantics. If your endpoint is down for 20 minutes, do you lose the events or do they replay?
- Idempotency. Can you safely retry a write without creating duplicate records? If not, your error handling is now a data quality problem.
- Audit trail. Can you prove where a given field came from, and when? You will need this the first time legal asks.
- Exit cost. How long does it take to export everything you put in, in a format you can actually use elsewhere?
I assumed "API integration" meant an endpoint and a key. Didn't verify. Turned out the rate limits reset hourly, not per-minute, which meant a 50,000-record backfill took three days instead of four hours. We made the deadline anyway, but only because someone noticed on day one instead of day three.
Build the whole thing in a sandbox with a kill switch. Never point a new integration at production records in week one.
Step 6: Verify at send time, not at import time
A record that verified clean in January is not a record that's safe to send to in April. Verification is a timestamp, not an attribute.
This matters more than it used to. Google and Yahoo's bulk sender requirements, in effect since February 2024, apply to anyone sending 5,000+ messages a day to their users — and they include spam-complaint thresholds and one-click unsubscribe requirements. In the US, CAN-SPAM has required a working opt-out since 2003. In the EU, you need a documented lawful basis under GDPR Article 6 before you contact anyone, and "we bought a list" is not one.
Checkpoint: verification runs at the moment of send, and your suppression list is checked after verification, not before. I've watched that ordering mistake put 900 opted-out addresses back into a sequence.
Step 7: Keep LinkedIn prospecting human-in-the-loop
Fully automated LinkedIn outreach is the fastest way to lose the account, and I mean that structurally. LinkedIn's user agreement prohibits scraping and automated activity, and the 2022 hiQ v. LinkedIn ruling didn't change that picture in the way people hoped.
The workable version is human-in-the-loop: the system surfaces the account and the reason it surfaced, a human decides whether to engage, and the message goes out with a person's judgment attached to it. Slower per touch. Much better per account. This also happens to be the only version that survives a compliance review.
If you're evaluating platforms partly on how much human review they let you keep, treat that as a feature, not friction.
What actually costs you money (the part that isn't on the quote)
The seat price is the smallest number in the deal. Total cost of ownership, in the order it usually hits:
- Platform seats, plus credit overage once your reps get comfortable
- Enrichment and verification calls, billed per record, per attempt
- Integration engineering time — budget two to four weeks of someone's attention, minimum
- Deliverability repair: domain warm-up, list remediation, and the pipeline you lose while it's throttled
- Compliance review and legal time
- Migration cost when the contract ends
The $500-a-month option that needs 60 hours of engineering and a domain rebuild is not the $500 option. I now price the whole thing out before I compare two quotes, every time.
Common ways this checklist gets abandoned halfway
Using the vendor's sample list. It's curated to make the product look good. It is not a test, it's a demo.
Testing the API for connectivity and nothing else. A 200 response tells you the auth works. It tells you nothing about rate limits, retries, or what happens under load.
Treating "verified" as "deliverable." Verification reduces hard bounces. It doesn't guarantee inbox placement, and anyone promising that is selling you something they can't control.
Doubling volume on one domain. The fastest way to undo three months of domain reputation in three days.
Buying intent data by seat and then using it by record. Check which unit your contract actually meters on before you sign. This one catches people at renewal, not at signing.
And the meta-mistake: treating the six-week emergency as a one-off. The teams that recover well aren't the ones who move fastest — they're the ones who instrument the loop. Track response rate by signal type, meetings booked per segment, and cost per closed-won from the first week. Otherwise you'll run this same checklist again next quarter with no better information than you have today.
