okki-go Integration Checklist: 7 Steps Before You Connect Your Sales Email

Who this checklist is for

If you're about to connect an AI SDR platform — okki-go, or anything in that category — to a live production inbox, and there's a deadline attached, this is for you. Seven steps. You can get through them in an afternoon if your data is already clean.

Quick context on where I'm coming from: I run sales ops at a B2B SaaS company, and I've handled maybe 60 outbound launches with hard deadlines. Maybe 55, I'd have to check the ticket system. Quarter-end pushes, post-conference sequences, pilot programs where the board wanted pipeline numbers by a Monday. A fair number of those were "the CRO wants lead flow visible by Thursday" situations.

None of this replaces reading the vendor's own developer docs. But it's roughly the list of things that, in hindsight, would have saved me a suspended sequence or two.

This was accurate as of Q1 2026. OAuth scopes, ESP sending policies, and ESP-to-ESP reciprocity rules change fast. Verify current requirements before you commit anything to production.

Step 1: Map every inbox you're about to hand over

Before you open a single integration page, write down — on actual paper if it helps — every mailbox the platform will touch. Not just the sending mailbox. The reply mailbox. The calendar mailbox if meetings get booked. The shared inbox your SDRs are working out of.

The trap is that "connect your email" sounds like one action. It's usually four or five. I've watched a team connect three sending accounts, forget the reply-to routing, and spend a week wondering why positive replies were landing in a deactivated seat.

Also worth flagging: if any of those mailboxes sit behind a shared tenant or a parent org's admin, get the admin in the room now. Not Friday at 4pm. OAuth consent screens that require tenant-wide admin approval can add a day you didn't budget for.

Step 2: Audit the OAuth permissions line by line

This is the step most teams skip, and it's the one that bites hardest six weeks later.

When the platform asks for authorization, you get a consent screen listing scopes. Read them. Every one. Then go to the vendor's developer documentation and find out what each scope actually grants.

According to the OAuth 2.0 framework (IETF RFC 6749, ietf.org), a scope is a permission request, not a permission guarantee — the authorization server decides what to grant. Practically, that means a scope like gmail.readonly or mail.send tells you the category of access, not the boundary. You need the vendor's mapping.

Two questions to ask every vendor in writing:

1. Which scopes do you require at onboarding, and which do you request later?
2. If I revoke scope X in month three, which product features stop working?

I went back and forth between a vendor that wanted broad mailbox read access on day one and one that wanted it gated behind a two-week activation. Broad access meant faster setup. Gated access meant a slower ramp but a smaller blast radius if anything went sideways. I chose the gated one, mainly because the launch was going to a list we'd never contacted before, and I wanted the option to throttle.

To be fair, the broad-access approach isn't reckless in every context. If you're running a mature program with established guardrails, the friction of a slow ramp might cost you more than the risk it mitigates. It depends on how much of your pipeline is riding on the list.

Step 3: Warm a dedicated sending domain, not your primary one

Standard advice that half the industry still ignores: send cold outreach from a subdomain, not your primary domain. If something goes wrong — a bad list, an over-aggressive volume ramp — you lose the subdomain, not your transactional and customer email.

Set up SPF, DKIM, and DMARC on that subdomain before you send anything. The relevant specs are RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC), all published by the IETF. DMARC enforcement is the one people get wrong most often — p=none is a reporting policy, not protection.

Once DNS is right, warm it. Four to six weeks is realistic for a clean inbox reputation from zero. Three weeks is aggressive. Two weeks is a gamble you'll probably lose.

(Should mention: if you're on a genuinely tight deadline, the honest fallback is sending from an already-warm subdomain you control, not rushing a cold one. I've done both. The rushed one underdelivered against the warmed one by a wide margin.)

Step 4: Lock the enrichment waterfall before you build the sequence

This is where agent-native prospecting workflows differ from traditional list-based ones. In a traditional setup, you buy a list, you send to it, you're done. In an agent-native setup, the platform is enriching while you build, so if your waterfall isn't defined, the agent enriches against whatever defaults it has — and you find out three days later that half your titles are wrong.

Define this before you touch the sequence builder:

• Primary enrichment source (your CRM, or a specific database)
• Fallback source one (usually a second data provider — the two never overlap perfectly)
• Fallback source two (often a pattern-inference layer for emails, with a verification step)
• Verification requirement before send (bounce check, catch-all policy, etc.)

On verification: nobody provides 100% accurate email verification, and any vendor claiming otherwise is overselling. What you want is a waterfall that returns a confidence tier, and a policy for what you do with each tier. My rule is: send to tier-one results, suppress tier-two for a manual pass, discard tier-three.

Step 5: Make intent data pick the sequence, not the other way around

The common mistake here is building the sequence first and then bolting intent signals onto it as a filter. That inverts the value.

Better order: define your intent triggers (job change, tech install, funding event, pricing page visit, whatever your platform exposes), then let those triggers route accounts into sequences. The sequence is the response, not the plan.

I've only really done this at scale for mid-market SaaS accounts — roughly 200 to 2,000 employees. If you're working enterprise with long committee cycles, your trigger-to-sequence mapping will look different, and I can't speak to how well this pattern holds there.

Step 6: Design the human-in-the-loop handoff explicitly

Human-in-the-loop is the phrase every AI SDR vendor uses, and it means something different at every one of them. Pin it down.

Specifically: at what point does a human see the message? Before send, on reply, on positive reply, or never? Who owns the reply once it lands in the platform? What happens if nobody responds within four hours?

If the answer to that last question is "nothing," you don't have a human-in-the-loop workflow. You have automation with a human who occasionally looks.

Granted, a fully specified handoff takes longer to build. But it's the difference between a system that produces meetings and a system that produces activity metrics.

Step 7: Wire compliance into the send path, not into a PDF

Under the CAN-SPAM Act (U.S. Federal Trade Commission, ftc.gov), commercial email must include a functioning opt-out mechanism and a valid physical postal address, and opt-out requests must be honored within 10 business days. Under GDPR Article 6 (eur-lex.europa.eu), you need a lawful basis for processing personal data — for most cold B2B outreach that's legitimate interest, and you need to be able to document it.

Compliance that lives in a legal review document is compliance that stops working the moment someone changes a template. Put the unsubscribe link and postal address into the template itself, locked. Put the suppression list check into the send path, not into a post-send report.

Common mistakes worth avoiding

Three patterns I keep seeing, usually in the same launch:

• Connecting the primary domain "just for this one campaign." It's never one campaign.
• Treating the enrichment waterfall as a setting rather than a design decision. It determines who you talk to.
• Assuming the platform handles compliance because it mentions compliance. The platform gives you the tools; the policy is yours.

Most of these are preventable with a two-hour planning session before you click authorize. The ones that aren't preventable tend to be permission-related, which is why Step 2 is where I'd spend the most time if you're short on hours.

Verify current OAuth scope requirements, ESP sending limits, and email regulations at their official sources before launch. Pricing, feature availability, and compliance requirements referenced here are for general guidance only and may have changed.