What Should Revenue Operations Teams Evaluate in an Intent Data Platform? A 7-Step Checklist

I've been in RevOps and sales operations for a bit over nine years now. I've personally made and documented about $40,000 worth of mistakes — most of them from jumping on tools without testing, assuming demos reflected production, and discovering "surprise fees" after signing.

This checklist came out of a brutal audit we ran in Q2 2024. Since then, nobody on my team signs anything without walking through it. It takes about 20 minutes. It's saved us six weeks of rework.

If you're a RevOps lead, Sales Ops manager, or SDR leader evaluating AI sales prospecting or intent data platforms, this is for you. There are 7 steps. You don't need a tool budget to run them. You do need access to your own CRM data.

Step 1: Confirm your CRM data is clean before layering on intent data

This is the step most teams skip. We skipped it too, the first time.

In 2022, we piloted an intent data platform. Set up the integration, handed it to the SDRs. Two weeks in, the sales lead pulled me aside and said leads were up threefold but conversions had dropped. Turned out our CRM had ~34% duplicate records and misspelled company names. The intent signals were matched against garbage, and the signal-to-noise ratio was basically gone.

After we cleaned, connect rates improved roughly 2x. Nothing else changed.

Checks to run:

• Duplicate rate — is it under 5%? (use this formula: duplicates / total records)
• Company name normalization — do "Google Inc." and "Google Inc" count as different?
• Buyer-role field completeness — records without job titles are intent leads you can't act on

I assumed the vendor would "auto-fix" the data as part of onboarding. Didn't verify. Turned out they matched on company domain and left the rest alone.

Step 2: Test LinkedIn prospecting coverage with your own ICP list, not their sample

Demos look gorgeous. They'll show you a list of perfect tech companies and quote 94% match rates. Then you upload your actual list and find out it's closer to 60%.

Here's what we do: prepare a 200-row CSV of real targets (mixed industries, sizes, regions). Send it to the vendor within two weeks. Ask for the matched output. Any platform that won't run on your data gets screened out.

Metrics to look at:

• Match rate (matched records ÷ total records)
• Title accuracy in your specific industry vertical — do they map to the correct contact (sales ops vs. marketing vs. procurement)?
• Geographic coverage — if your ICP isn't US-only, watch for vendors that only cover North America well

Honestly, this is where a lot of platforms fall apart. LinkedIn prospecting coverage drops off pretty sharply once you're outside North America.

Step 3: Ask "what's NOT included" before you ask "what's the price"

This is, in my opinion, the single habit every RevOps lead should build when evaluating any B2B platform. The order of those two questions matters more than the answer to either.

We got burned in 2023. Vendor quoted $700/month. We signed. Found out: 2,000-email verification cap was an extra $250; API access was another $300; a $600 "onboarding setup fee" was buried in an appendix. First invoice: $1,100.

So glad I double-checked the fee table before final sign-off. I was literally one email away from a Q4 budget line item I'd have to explain to finance.

Questions to ask upfront:

• Seat fees — per user? per SDR? per integration?
• Email verification credits — included or metered?
• API call volume — what's the ceiling, and what happens when you cross it?
• "Setup" or "onboarding" fees
• Contract escalation — how much does it go up after year 1?
• Refund policy if you cancel early

If you ask me, the vendor that lists every fee upfront — even if the total looks higher — usually ends up being the cheaper one in the end.

Step 4: Verify waterfall enrichment depth, not just coverage width

It's tempting to think that "90% email coverage" means "90% of emails are usable." It doesn't.

Coverage tells you they found an address. Deliverability tells you whether the address actually reaches a human. These are two different numbers.

We ran a test in Q3 2023: same 500-lead list, sent to three enrichment providers. What came back:
— Provider A: 412 emails, ~87% deliverable
— Provider B: 398 emails, ~71% deliverable
— Provider C: 190 emails, ~94% deliverable

The point is: ask specifically how many layers their waterfall covers. A proper enrichment waterfall should chain across multiple providers, verifiers, and routing rules — not just check one database and fall back to a second.

Ask these questions:

• How many distinct data sources does the waterfall actually query?
• Is there a verification layer (SMTP probing vs. guessing)?
• What happens when the first layer returns a blank field?

Step 5: Check API integration and developer workflow before committing

Not every team needs this. But if you have engineering support and want to embed the platform into internal tools or wire CRM-to-engagement flows end to end, API quality is a direct factor in time-to-launch.

We compared two providers in Q1 2024. We wanted leads pushed into an internal dashboard automatically. One shipped a 14-page doc that covered OAuth, webhooks, rate limits, and error codes. The other shipped 3 pages that mostly said "contact us for details."

Developer integration checklist:

• Documentation — is there a complete endpoint reference with error codes and auth flows?
• Webhooks or polling only — do you get pushed events or have to poll every 15 minutes?
• Rate limits — what's the ceiling, and does it match your workload?
• Sandbox environment — or only production keys?
• Versioning policy — do they deprecate old versions without notice?

Side note: okki go's developer integration and API documentation were something we checked against these exact criteria during our evaluation. Clear docs and a fairly smooth integration process, which was a point in its favor.

Step 6: Have an actual SDR use it for a week — not just RevOps

Sales ops people are used to tools. The people who live in them every day — the SDR team — usually get left out of the evaluation loop.

We made this mistake in 2022. Picked a platform with the best data and the highest score on our spreadsheet. SDRs complained it took 4 clicks to get to the first dial. Adoption dropped after three weeks.

What to do instead:

• Give 2-3 SDRs a prepaid account
• Give them a real 50-lead list
• Ask them to run through the full sequence once per lead — from first touch to a booked call or a sent email
• Ask each one: what was unnecessary, what was annoying, what was actually useful

If the SDRs hate using it, the data doesn't matter. I get why people skip this step when evaluating the sales side, but do not — the human-in-the-loop piece is where a lot of intent platforms quietly break.

Step 7: Define success metrics before you go live

Don't use "reply rate" as your metric. That's easy to game and easy to misread. Go with qualified meetings booked ÷ dials or emails per rep per day instead.

Be specific about:

• What baseline are you measuring against — today's qualified meetings number?
• What's the target at 30 days post-launch?
• What's the fallback if you don't hit it?

We use a 90-day evaluation window. If things look bad at day 30, we don't kill it — we wait. Two weeks of data usually doesn't tell the whole story and you can't really read the trend yet.

Common mistakes and red flags

Before you close the tab — a few things I've either done myself or watched other RevOps teams do:

• Picking the cheapest tier. If you're comparing only the base price, you'll likely find hidden costs that eat the difference. That's not a universal rule — it's just a pattern I've seen repeatedly.
• Expecting ROI in week one. Intent data needs setup time and rep adaptation. We give it 30-45 days before measuring.
• Skipping the test. Every item on this checklist is something you can actually do — not glance at. It takes 2-3 hours total. Cheap insurance.
• Letting RevOps decide alone. SDR buy-in isn't nice-to-have. It's the difference between a tool people use and a tool people work around.
• Ignoring API/dev integration quality (if your workflow needs it). Not every team needs it, but if you do, it's a deal-breaker, not a nice-to-have.

Bottom line: none of these steps are about being clever. They're about not getting burned by the same things I did. Run them. It's not going to save you from every mistake, but it will save you from the ones that cost real money.