OKKI Go Configuration Checklist: API Keys, LinkedIn Automation, and Where ABM Actually Fits

When this checklist applies

Two situations usually kick this off. Either you just got an OKKI Go workspace and need to get a small SDR team onto it, or you've been running a pilot for a month and realized some things were never actually decided—usually who owns the API keys, and what's considered safe to send over LinkedIn.

Quick context on me: I run tooling and vendor subscriptions at a 220-person B2B company. I process roughly 60 to 80 software renewals and new tool purchases a year, everything from design software to CRM add-ons. I'm not the person on the phones. But I sign the contracts, fill out the security review forms, and I'm the one who gets pinged six months later when something breaks. So this is written from the "owns the configuration" chair, not the "lives in the tool every day" chair.

Six steps. The order matters—steps 2 and 3 are the ones that come back to bite you if you push them off.

Step 1: Lock down the workspace structure before you invite anyone

The temptation is to add seats first and sort out permissions later. Don't. Retrofitting roles after twenty people are already inside is a genuinely miserable afternoon.

• Decide who gets a full seat and who gets read-only. For us, that's three full seats and everyone else at viewer level.
• Separate the admin login from the billing contact. Use a shared alias like revops-tools@ rather than a person's inbox.
• Set up a notifications alias now. System alerts should not land only in one person's inbox.

Checkpoint: create one test user, log in as them, and confirm they can't see what they shouldn't. This is the step everyone claims to do and roughly nobody does.

Step 2: Decide how API keys will be handled—before you generate one

This is the step most teams skip, and it's the one that causes the most grief. I'd say a solid half of our tooling incidents trace back to how a key was handled six months earlier.

In my first year managing this stuff, I made the classic mistake: I generated an API key from my personal login and handed it to a contractor doing a CRM integration. Worked fine. Then I changed roles internally eighteen months later and the whole handoff got messy—nobody knew which key was mine, which was his, or whether either was still active. Not a disaster, but embarrassing, and it took a week to untangle.

Here's what I'd do now:

• Issue keys from a service account, never a person's login. Owner, purpose, rotation date. In that order, written down somewhere.
• Separate keys per environment. A staging key should never be the same one that touches production records.
• One key per integration. If the CRM connector gets compromised, you revoke that key, not everything the team uses.
• Store them in a secrets manager, not a shared doc, not Slack, not a spreadsheet with the tab color changed.

On rotation: NIST SP 800-57 lays out the key lifecycle as generation, use, storage, archiving, and destruction. In practice, everything I'd read said rotate every 30 days. My experience with a small integration footprint suggests that's mostly theater—with three or four connectors, 90-day rotation plus an alert at day 60 has worked better for us. Monthly rotation just means you're moving keys around more often, which means more chances to paste one in the wrong place.

Step 3: Sort out your LinkedIn Sales Navigator automation boundaries

This is where enthusiasm runs into reality. LinkedIn's User Agreement (linkedin.com/legal/user-agreement) prohibits scraping and restricts unauthorized automation—that's not ambiguous, and a vendor telling you otherwise isn't doing you a favor.

So the question isn't "can we automate LinkedIn." It's "what does the automation actually do, and does it look like a person doing it?"

What's worked for us:

1. Confirm what your seat tier actually permits before connecting anything. API-based access and browser-extension tools are not the same thing.
2. Keep the agent on preparation, not sending. It drafts, it queues, it surfaces context. A human releases.
3. Pace activity roughly like a human would. Twenty connection requests in ninety seconds is a pattern, and patterns get flagged.
4. Never send on a lead that hasn't been verified first. We'll get to verification order in the next step, but it matters here too.

What does a healthy setup look like six months in? Honestly, it's quieter than people expect. The automation doesn't look impressive. It just means nobody spends their morning copy-pasting.

Step 4: Connect your lead sources and fix the enrichment order

Sales leads arrive messy. The order you run them through matters more than which tools you picked.

Verify first, enrich second. This is backwards at a lot of companies—they enrich everything, then discover half the list bounces. Verify the email, then spend enrichment credits only on the survivors.

Some specifics:

• List every source feeding in. Forms, event lists, purchased data, inbound trials. Write it down; you'll forget one.
• Decide precedence when two sources disagree. A known-account record should probably win over a scraped one, but pick a rule and write it down.
• Waterfall enrichment—running a record through multiple providers in sequence rather than stopping at the first miss—has meaningfully improved our match rates. I don't have a clean number I'd defend in court, but the difference was way bigger than I expected.

Checkpoint: pull twenty records at random and trace them through manually. If you can't explain where each field came from, the pipeline has a hole.

Step 5: Define what the agent may do without you

This is the configuration decision that actually determines whether your team trusts the tool.

Human-in-the-loop doesn't mean "we check occasionally." It means you've drawn a specific line. Ours:

• The agent can draft sequences, score leads, and flag accounts. It cannot send.
• Daily volume caps are set at the workflow level, not left to individual reps.
• There's an exception queue for anything the agent isn't confident about. Someone reviews it every morning.

Everything before this point was plumbing. This is the step that makes the difference.

Step 6: Fit ABM on top of prospecting—not underneath it

Here's where I think a lot of teams have the mental model inverted. Account-based marketing usually gets treated as a layer that feeds a prospecting process: pick accounts, then prospect into them. In an agent-native workflow, it works better as the priority layer sitting above prospecting.

What that looks like in practice:

• The target account list lives upstream. The agent starts from accounts, not from a flat list of leads.
• For each account, the agent identifies three or four plausible contacts rather than one. Multi-threading is the whole point.
• Intent data ranks which accounts surface first, but the agent still respects account-level cooldown windows so five people at the same company don't get hit in the same week.
• Reply data flows back into an account stage label, so the next planning cycle starts with something better than a static list.

So how does account-based marketing fit into an agent-native prospecting workflow? For us, it's the thing that tells the agent where to spend attention. The agent handles the mechanics—who to contact, what to reference, when to surface it. ABM decides what matters. You need both, but they aren't the same function, and collapsing them into one step is where I've seen the most confusion.

Things that go wrong, and how to avoid them

Routing everything through one person's inbox. It works until that person takes a vacation or leaves. Set up shared aliases before you need them.

Enriching before verifying. You're paying for data on records that were never going to be usable.

Letting the agent send unsupervised. Even if it's technically allowed, the first bad batch erodes trust in the whole system. Rebuilding that trust takes months.

Skipping the test user. Five minutes, saves an afternoon.

Setting reply-rate targets in week one. Configuration problems show up as performance problems long before anyone connects them. Fix the setup first, then measure.

Treating key rotation as a checkbox. A key nobody owns is a key nobody rotates.

One caveat on all of this: my experience is based on a handful of sales-tool rollouts at one 220-person company, mostly in North America. If you're an eight-person agency or a 900-person org spread across three time zones, some of these details will land differently. The sequencing probably holds. The specifics you'll have to adjust.

What was best practice for this stuff in 2021 genuinely doesn't apply in 2026—the tooling moved too fast. But the underlying questions haven't changed: who owns access, what's allowed to happen automatically, and who checks the work. Answer those three and the rest is configuration.