OKKI Go Setup: The Permissions Mistake That Burned Our Sending Domain

We thought installing OKKI Go would take 20 minutes

It was mid-March 2025. I'd just gotten sign-off from our VP of Sales, sold the team on adding an agent-native prospecting layer on top of our existing stack, and logged in. Hit "Connect Google Workspace." Hit "Connect LinkedIn." A permissions modal popped up, I skimmed it — I was thinking about lunch, honestly — and I clicked accept.

An hour later the "setup complete" ping showed up. Three months later we were still cleaning up after it. Not because of the tool. Because of the decisions I made that I didn't even realize I was making.

If you're searching for "okki-go installation" or "what permissions does okki go require" right now, I'm guessing you're either standing where I stood in March, or you're close to it. Let me save you something.

Installation looks like the problem. It isn't.

The setup wizard itself is genuinely simple. Connect inbox, connect LinkedIn, pick an ICP, pick a cadence, go. Fifteen minutes, no friction. Everyone's excited. Everyone moves on.

What's actually happening: you're delegating sending authority, contact data, and LinkedIn account activity to a system you first saw a few hours ago, under a permissions prompt you didn't read. For six years I've run RevOps for outbound-heavy teams, and I've botched this twice. The first time cost a few hundred dollars. The second time cost eleven days of outbound blackout.

The trigger event was dumb. On March 11, 2025, we connected the OKKI Go workspace to our primary sending domain without validating a subdomain first. By the afternoon of the 12th, that domain was sitting on two major blocklists. Eleven days of recovery. Roughly $4,200 of pipeline delayed. I'm not going to dress that up.

Problem 1: You don't actually know what you just authorized

When you connect a Google Workspace account to a prospecting tool, you're typically granting at minimum:

• Read access to contacts and directory
• Read access to mail, plus the ability to modify labels and threads
• Send-as privileges on your behalf
• In some cases, calendar access for cadence timing

Most of those scopes aren't about sending. They're about reading your entire historical correspondence. They flow into the vendor's data pipeline, through subprocessors, and into signal or training models — purposes you never explicitly reviewed.

What bugs me is that nobody reads the permission page because the permission page is written for lawyers, not operators. That's not the user's fault. But it's still your problem if you're the one owning the outbound stack. You're signatory to whatever you clicked through.

I have mixed feelings about this. On one hand, it feels unreasonable to expect a RevOps lead to parse OAuth scopes like a security engineer. On the other, ignoring them produced the outcome it produced. So I read them now. Every scope, every line, every release.

Problem 2: The wrong account got connected

This is the one we repeated. 2023, then again in 2025.

The tool prompts you to "connect a Google account." It doesn't prompt you to choose which Google account. The natural instinct is to connect the one everyone already uses. Which is, nine times out of ten, the domain you can least afford to put at risk.

Two quarters after the first incident, I compared our sending setup side by side:

• An outbound workspace warmed on a dedicated subdomain
• An outbound workspace warmed straight off the primary domain

Same contact lists, same copy. The primary-domain setup generated almost three times the spam complaint rate — a number I couldn't unsee once I'd calculated it.

Per Gmail's bulk sender requirements, effective February 2024: bulk senders must keep spam complaint rates under 0.3% to avoid delivery throttling. Above 0.1% is considered a warning zone. Verify current thresholds at Google's Postmaster Tools documentation, as requirements evolve.

The "local / primary-domain is always fine" thinking comes from an era before cold outbound scaled past what any human could monitor. That changed a while ago. If your domain isn't isolated, nothing downstream of your outbound workflow is safe.

Problem 3: Lead generation capabilities aren't lead quality

"Agent-native prospecting" sounds like you point it at an ICP and leads fall out. In practice, the first two weeks produced a list where roughly a third of the accounts overlapped with companies already sitting with named AEs, and another quarter were outside our total addressable market.

This isn't unique to OKKI Go — it's true of any enriched-lead system. The tool delivers records. It doesn't decide which records matter to you. That's what your ICP definition is for, and the operative part of the ICP document usually lives in somebody's head, not on paper.

The same applies to intent data features. An intent signal without a routing rule is just noise with a timestamp. It only converts when someone has pre-agreed that a signal on a target account means a call within six hours, from a named human, following a named script.

Don't skip this. I did, and I paid for it in follow-up cycles that looked like pipeline but never went anywhere.

Problem 4: Nobody defined who owns the output

This is the piece everyone jumps past. Leads come in. Which CRM do they land in? Who follows up? If a lead originates from an intent signal — say a target account opened a research page — who makes the call within six hours?

Our second attempt stalled for three days after install because we'd set everything up smoothly but hadn't decided who was going to triage the output. Sales said "that's marketing." Marketing said "that's SDR." Nobody moved. That's three days of data cost and zero conversations.

Modern outbound runs on handoffs as much as on data. If your handoff document doesn't exist before the tool launches, it won't exist after.

What those mistakes actually cost us

Concrete figures from the March 2025 incident:

• Primary sending domain unusable for eleven days. That stalled all outbound, not just the new workflow.
• Approximately $4,200 of pipeline delayed — those were active opportunities, not theoretical.
• One LinkedIn account frozen for 48 hours. It was the most active operator on the team.
• SDR morale damage. They'd been told to "use other channels" while we fixed a config mistake they shouldn't have had to think about.

The last one is the expensive one. The first three are measurable. The fourth took us months to work out of the culture.

What I'd do now

Before I open any installation wizard again, I run this list. Not a long list. Just enough that I don't repeat the same class of mistake twice.

1. Security review before deployment, not after. Subprocessor list, data residency, retention policy — read it before credentials get handed over.
2. Isolate sending infrastructure from the primary domain. Dedicated subdomain, SPF, DKIM, DMARC configured, warmed for fourteen days before a prospecting tool touches it.
3. Named owner and named backup before launch. If nobody can answer "who handles this in six hours," the workflow isn't ready.
4. Unsubscribe flow that meets RFC 8058. Gmail requires one-click unsubscribes for bulk senders. Pretending otherwise is how you end up back on a blocklist.
5. Evaluation criteria for email outreach, written down. Full funnel — delivered, opened, replied, meetings booked, meetings held. Cost per booked meeting. And critically: what happens after a single bounce or a single complaint. Chasing open rate alone is a comfort blanket, not a metric.

Does that sound like a lot of ceremony for a setup that takes twenty minutes? Maybe. But how you make decisions around your outbound stack is how your company is perceived by every prospect you touch. A domain on a blocklist, a polished message landing in the spam folder — clients don't separate tool problems from your problems. They just remember: this came through as spam.

You can say quality is a priority on your About page, or you can show it in whether a cold email actually arrives in an inbox. Only one of those is a brand asset.