Your First okki-go Prospecting Workflow: Three Setups, and How to Tell Which One You Need

There is no single right way to set up your first prospecting workflow in okki-go. I've done this four times now for different teams, and the config that made one team fast nearly broke another. So no universal checklist. Instead: three scenarios, and you find yourself in one of them.

Quick background. Six years in sales ops, most recently owning tooling for a 12-seat SDR org. Nine documented mistakes between 2019 and 2025, roughly $41,000 in wasted tooling, bad list spend, and rework. I maintain the pre-launch checklist because I kept being the reason it was needed.

Here's the split.

Scenario 1: You are the entire outbound team

Founder-led sales. Or one SDR. Or a two-person team where prospecting is maybe 20% of someone's job and nobody's full attention.

What I'd actually connect: an email validation API and a spreadsheet import path. That's it. Not the CRM sync. Not the enrichment waterfall. Not the intent layer.

This goes against most advice you'll read, which is "connect everything so it just works." That advice is for teams with someone whose job is maintaining the connections. If that's not you, every integration is a thing that can silently fail at 2am, and you'll find out three weeks later when your bounce rate triples.

I learned this in early 2023. Built a five-integration chain for a solo-operator client — CRM, enrichment, verifier, sequencer, reporting. Every piece worked in isolation. The chain didn't. A field mapping between enrichment and the sequencer dropped the company domain on roughly 30% of records, so the verifier tagged real addresses as unknown and the sequencer skipped them. Nobody noticed for 19 days. By then a quarter-end push had gone out on a list that was 40% short. Not a disaster. Just quietly expensive.

They warned me. The onboarding docs said to verify intermediate fields after connecting. I didn't. Cost about $2,100 in wasted sending volume and one very awkward Monday call.

The version I'd actually recommend: two integrations, manual review of the first 200 records, no automation on the decision of who to contact. Keep the human in the loop until you personally know what "good" looks like in your data. You'll outgrow it in a month or two. Fine.

One thing worth doing even at this size — run firmographic filters at import time, not send time. Cheap. Saves a lot of "why are we emailing a 6-person company in a country we don't sell to" conversations.

Scenario 2: A real SDR team with someone owning RevOps

Five to thirty seats. There is a person — maybe you — whose job is making sure the machine doesn't fall over.

This is where agent-native prospecting starts to make sense, and where firmographic filtering stops being a nice-to-have.

The firmographic question comes up every time, so here's how I'd frame it. In an agent-native workflow, firmographic filters aren't a step. They're a boundary. The agent doesn't "check" employee count or industry before it acts — you define the envelope it's allowed to act inside, and everything outside that envelope never enters the queue. If you're treating firmographics as a post-hoc filter on the agent's output, you're paying for work that should never have been done in the first place.

What my current setup looks like at this size:

• Waterfall enrichment, so a record that misses on one provider gets a second shot before it's discarded. Single-provider enrichment is the most common reason a decent list looks bad.
• Firmographic envelope defined before the agent runs. Not after.
• Email validation as a gate, not a score. Valid / catch-all / invalid. Catch-all goes into a separate pool with lower volume and different copy. Nothing gets "probably fine" stamped on it. It won't guarantee deliverability — nothing does — but it removes the obvious dead weight.
• CRM sync, write-back only. Your SDRs live in the sequencer. If they have to check two systems to know whether to reply, they won't check the second one.

For context: Google's bulk sender requirements, in force since February 2024, apply to anyone sending more than 5,000 messages a day to Gmail addresses, and include keeping spam complaint rates under 0.3%. A validation gate won't get you there on its own, but skipping one makes it a lot harder. Same energy as FTC's CAN-SPAM guidance — accurate headers, a working opt-out honored within 10 business days, valid physical address. Boring, unglamorous, and the thing you'll wish you'd set up before the first complaint.

Now the part that took me two years to accept.

I compared two quarters side by side — Q3 2023 and Q1 2024. Same team, same ICP, same headcount. The difference: in Q1 we had a hard date. A product launch on February 26 and a partner event we'd already committed to. We paid for priority onboarding and a higher tier on the validation API. Roughly $1,800 extra for the quarter.

Q3 had no deadline. We went cheap tier and standard onboarding. Six-week setup instead of eleven days. We missed a window we'd vaguely been aiming at, which — honestly — nobody could name, because there wasn't one.

When I looked at the two quarters together, something clicked. We weren't buying speed in Q1. We were buying knowing it would be done by the 26th. The Q3 savings were paper. The Q1 premium bought a date we could plan around.

If you have a real deadline — launch, quarter close, conference — the cheap-and-uncertain path is almost never cheaper. It's cheaper-looking. You don't find out what it cost until you're explaining to your CRO why the list isn't ready.

Scenario 3: An agency running prospecting for clients

Different animal. Most of the above applies, with one addition people skip: per-client isolation.

Separate workspace per client for enrichment, filtering, and validation. Shared email validation API budget is fine. Shared suppression lists are not. The first time a client's competitor shows up in another client's sequence, you'll understand why I'm being emphatic about this.

Also: don't let client-defined firmographics inherit from your default. Every client ICP is defined by someone who knows their business better than you do. Verify the envelope with them before the agent runs, in writing, even if it's just a Slack message.

I skipped that once in 2024, on the assumption that the ICP written in the kickoff doc was the one their SDR team actually used. Turned out the kickoff doc was written by marketing and the SDRs had been quietly using fleet size for a year. Three weeks of outreach, wrong segment. Nobody blamed us, which somehow made it worse.

Which one are you?

Three questions, answered honestly:

1. Is there a person whose job includes "the tooling"? If yes, scenario 2. If no, scenario 1. Biggest single predictor.
2. Is there a date on the calendar other people are counting on? Launch, board meeting, conference. If yes, pay for certainty. Not because speed is valuable on its own, but because "it'll probably be ready" is the most expensive phrase in sales ops.
3. Are you running this for more than one company? Scenario 3, and read the isolation paragraph twice.

If you're between scenarios, go down, not up. Start smaller than you think you should. The failure mode of an over-connected setup takes weeks to surface and looks like a data quality problem — which means you'll spend a month debugging enrichment before anyone thinks to check the field mapping.

Looking back, that's roughly where my $41k went. Spread across nine mistakes, but the big ones were all the same mistake wearing different clothes: building for the team I imagined instead of the team that actually existed.