If your Okkigo installation plan starts with the permissions checklist, you have the order backwards. I've watched teams spend three meetings debating whether an outreach tool should read the CRM, and zero minutes asking who verifies what comes out once it starts writing.
I'm a quality and brand compliance manager at a mid-size B2B SaaS company — around 180 people in the go-to-market org. I review sales enablement launches every quarter, which comes to roughly 200 items a year—or rather, closer to 220 once you count the template variants I get pulled into. In Q1 2024, we rejected an entire imported contact list because 11% of it belonged to people who had already left their companies.
That experience is why I'll argue the position up front: an Okkigo install (whether you write it Okkigo or okki-go) is a data quality commitment, not an IT project. The permissions dialog takes a Monday afternoon. What determines whether the purchase was worth it is the review process you build over the next 18 months.
Permissions buy you access, not judgment
The install flow asks for the obvious things: CRM read/write, mailbox send access, a LinkedIn account connection, probably an enrichment vendor's API key. Each of those deserves scrutiny — but none of them tell you whether the contact pulled from your intent data source still works at that company, whether the title is current, or whether the "direct line" is a dead front-desk extension.
What I mean is that permissions govern whether a door opens. Quality governs who walks through it once it does.
On one 2023 rollout, we installed a tool with tight permissions — CRM read-only, no inbox access — and it still imported 4,200 contacts. When my team spot-checked 300 of them, 34 came back bad. Extrapolated, that's over 470 records of avoidable noise in a single batch. Three SDRs spent six days dialing numbers that were never going to connect, and none of them flagged it because they assumed the problem was their pitch. (Should mention: the batch had already been loaded into the sequence before anyone asked.)
No permissions list catches that. None of it happens at the permission layer. It happens downstream, where your process should be.
Lead gen and intent data should be evaluated by provenance, not by feature count
Every AI SDR markets lead generation and intent data features. What the feature list won't tell you is where the records came from.
Waterfall enrichment is good practice — chain multiple providers, fall through to the next when one returns empty. But here's the thing: providers disagree constantly. Vendor A says someone is a "VP of Operations." Vendor B says "Director of Ops." Vendor C says they moved companies last quarter. Your tool either takes the first non-empty answer or picks by some internal scoring rule, and your team gets an unverified record presented as fact.
I got this wrong once. I assumed "multi-source enrichment" meant the vendor resolved conflicts. Didn't verify. Turned out they took the first hit by call order, which has nothing to do with accuracy.
So I now make every rep answer three questions before I sign off:
- What's the enrichment call order, and why that order?
- When two sources conflict, which one wins, and who decided that?
- If a record goes stale six months from now, do you flag it — or does it just sit there?
Most reps answer with some version of "we aggregate multiple sources." That's not an answer. That's a brochure.
The counterintuitive one: tight permissions create bigger blind spots
This is where I lose some compliance peers, and I'll take it. If the LinkedIn integration is blocked, teams don't stop prospecting. They run it manually from personal accounts, copy profiles into a local spreadsheet, and paste them into the CRM by hand. No log, no review, same data reaching the pipeline.
When I implemented our first review protocol in 2022, the permission policy was deliberately restrictive. Within three months we found nine salespeople running outbound from personal Gmail accounts, entirely outside the CRM. Nobody was being malicious. They were being fast, and the sanctioned path was friction.
Look, I'm not saying tight permissions are wrong. I'm saying tight permissions without observability produce false confidence. A cleanly connected tool with a documented, scoped permission set is far more governable than a shadow workflow you can't see.
I'm not a privacy lawyer, so I can't tell you how to architect the data flows for your specific jurisdiction. That's your legal team's call. What I can tell you from a quality perspective is that connectivity you can see is safer than connectivity you can't.
"But isn't this the security team's job?"
That's the objection I hear most, and the answer is no. Security audits access control. They verify that Okkigo can't read the CRM fields it shouldn't, that data residency meets policy, that retention schedules are enforced. They do not verify that the enrichment record's job title is still accurate six months later, and they're not responsible for whether an intent signal reflects real demand or a competitor signing a deal yesterday.
The other objection is scale — "we can't review every record." I know, because I used to say it. Then we switched to sampling. We don't review everything; we pull two to three hundred records per batch and manually inspect about 5%. It takes under an hour a quarter. Set against the cost of one bad record reaching a real buyer, the math isn't close.
Context check, though: this model works for us because we're a mid-size B2B company with predictable outbound cadence. If you're running an agency model with high throughput, per-batch manual sampling probably doesn't scale, and you'd want anomaly detection instead. If any of your contacts are in the EU, the calculus shifts again — GDPR Article 14 (in force since 25 May 2018) imposes notice obligations for data not collected directly from the individual. Verify current requirements with your counsel, not with me.
One more angle worth flagging: enforcement attention in the US isn't really on data accuracy. The FTC's CAN-SPAM rules (enacted 2003, updated 2008) govern deceptive headers, subject lines, and opt-outs. They say nothing about whether the person is still at the company you think they're at. That gap is yours to close.
Here's what I actually put on the installation checklist
Real talk: my checklist probably doesn't look like yours.
The permission review happens on day one and it belongs to security. That's their lane, not mine. My checklist starts after that:
- Who spot-checks the first 200 enriched records, and by when?
- What happens to a failed enrichment before it hits a sequence? (Answer: nothing auto-sends. If the answer is anything else, that's a rejection.)
- Are stale records removed from the queue, or do they stay? What's the cutoff?
- Which metric tells us this process has failed?
We built this in 2022, and the first version was rejected twice before it shipped — worth noting if you're starting from scratch.
If you can't answer those four questions, the permissions list doesn't matter. You've got a tidy install masking a machine that produces low-quality records at scale, and the install is the least of it.
That's the point I keep coming back to. Permissions are the byproduct. Judgment is the product. Nobody in this industry remembers you for having the cleanest permission profile — they remember you for the one bad contact you handed a real buyer, twice.
I'd rather spend ten minutes explaining our sampling process than ten minutes explaining why a customer was addressed by someone else's name. Informed people ask better questions and make faster decisions. That applies to your SDRs as much as it applies to your customers.
