Podcast
March 7, 2026
Episode 84: Your CRM Has an Identity Crisis (and What You Can Do About It)
Anders Krohn of Kernel breaks down why bad entity data is killing AI deployments and how RevOps teams can fix the foundation first
What if the biggest obstacle to deploying AI across your revenue organization isn't the AI itself but the data underneath it? That's the argument at the center of this conversation, and it's one that every RevOps professional navigating the current AI moment needs to hear.
In this episode of RevOpsAF, Anders Krohn, CEO and Co-Founder of Kernel, joins co-host Matthew Volm, CEO and Founder of RevOps Co-op, to break down the state of data enrichment in 2026. Anders brings a practitioner's perspective shaped by a deeply uncomfortable discovery: when he tried to build an AI SDR, the underlying CRM data was so broken that it made the whole effort impossible. Rather than paper over the problem, he went back to first principles and built a company around fixing the actual root cause.
Kernel didn't start as a data company. It started as an attempt to build an AI-powered sales development representative.
"We basically spent the better part of six months just crying inside of Salesforce, right? Because the underlying data was nowhere near good enough to be able to reliably automate anything using AI." — Anders Krohn
What Anders and his team discovered wasn't just that headcount fields were stale or emails bounced. The problems went deeper: wrong URLs, duplicate records, misattributed subsidiaries. Vodafone Italy filed under Vodafone Spain. As humans, we intuit those errors because we've seen the context. AI doesn't have that luxury.
"As a human being, I know that I don't trust my Salesforce, but AI doesn't know. It doesn't know, okay, this is actually Vodafone, Spain, it's not Vodafone, Italy." — Anders Krohn
That insight reframed the entire Kernel roadmap from "how do we automate outbound?" to "how do we solve the data behind the data?" It's the kind of working-backwards problem-solving that separates companies building durable infrastructure from those chasing the next shiny object, a trap that Episode 68 on AI tool overload explored in depth.
Anders describes the data enrichment landscape as a three-layer stack, and the distinction between layers matters enormously for how operators should architect their systems.
The foundation. This is where you determine the actual identity of a corporate entity: is it a parent company, a subsidiary, a franchise location, a regional brand? This layer has historically been dominated by providers like Dun & Bradstreet, which sells the same static database to every customer. As Anders puts it, "the CRM has an identity crisis," and entity data is where that crisis lives.
Once you've established what an entity actually is, you attach attributes: firmographic data, contact information, technographic signals. This is the layer most people think of when they say "data enrichment," and it's where vendors like ZoomInfo have historically operated.
The emerging top layer, where platforms like Clay and workflow tools like n8n sit. These tools take the structured data from below and automate workflows that used to require human effort.
The problem with most current approaches is that teams invest heavily in orchestration without fixing what's underneath. As Anders frames it: "When the bottom layer is wrong, then everything else goes wrong." This is the compounding-debt principle that any RevOps operator who's ever tried to fix funnel conversion will recognize immediately: garbage in, garbage out, multiplied at every stage.
One of the most practically important moments in the conversation comes when Anders lays out the right order of operations for building a data strategy. It's deceptively simple, and almost universally ignored.
"You need to have a data strategy that reflects your go-to-market strategy. That's the first thing." — Anders Krohn
This means the conversation about data has to start with the people who own go-to-market, not the people who own the tech stack. What entities matter to your business? What industry classification actually reflects how you sell? Do you care about holding companies at all, or only subsidiaries?
Only after that alignment is established does it make sense to think about data governance, because sales reps will change data to serve themselves, and without guardrails, the equitable distribution of opportunity across the sales org breaks down.
The worst-case scenario, according to Anders: starting with an AI strategy, then realizing you need a data strategy, then discovering you need data governance, then finally confronting the fact that you've never properly defined your ICP. That's the reverse-order death spiral, and it's more common than anyone in the industry wants to admit. Episode 50 on thinking data-first before AI makes the same case from a different angle.
For operators who think this is a terminology debate, Anders makes a practical case for why the account-versus-entity distinction matters operationally.
An account is a record in a CRM. Whatever Salesforce or HubSpot or Dynamics calls the object representing a business you have a relationship with. An entity is the real-world corporate identity that account is supposed to represent.
The problem is that these two things frequently don't align. And when enrichment tools try to match their database onto your CRM, they assume your CRM records are correct. Which, as every operator knows, they are not. A clean, correctly structured account hierarchy is the ideal; what most companies actually have is something considerably messier.
What AI enables, according to Anders, is something much closer to what a human RevOps analyst would do manually: using contextual signals from within the CRM to infer what a record actually represents, then matching it to the correct entity with human-level reasoning. That capability — combined with multi-source data synthesis (careers pages, Wikipedia, LinkedIn profiles, public filings) — produces enrichment that's both more accurate and more customizable than any static database can deliver.
Anders describes a crawl-walk-run framework for building toward an AI-ready data foundation. The "run" state looks like this:
"You end up with a stack that's very like Snowflake, Salesforce, Kernel, cloud code for orchestration and potentially tapping into a few different APIs. I think that's a world where as an ops person, I hold unlimited leverage basically." — Anders Krohn
The key shift in this architecture is that it enables true customization: the kind that makes your data strategy reflect your actual go-to-market motion, rather than forcing your go-to-market motion to fit whatever a third-party database happens to contain. One example Anders cites: a customer estimating total Gong users per account in order to carve territories around that metric, not around generic headcount ranges from a vendor database.
For operators not yet at the run phase, the starting point is straightforward: get the CRM under control, then identify high-leverage workflows where automation could create compounding returns. The build-versus-buy calculus for each piece of that stack is worth thinking through carefully.
Perhaps the most clarifying reframe in the conversation is what Anders says about CRM hygiene. Most of what gets sold as a "hygiene solution" — deduplication tools, fuzzy matching, waterfall enrichment — is actually a bandage on a deeper wound.
"A lot of deduplication initiatives are very like, let's fuzzy match the thing, right? But the underlying challenge would usually be an entity identity challenge. We actually don't know what this thing is." — Anders Krohn
The vision Anders articulates is one where, as entity data quality approaches the standard of what you'd get from Dun & Bradstreet with an unlimited BPO budget on top of it, the hygiene problem essentially solves itself. You don't need a deduplication layer if you know with confidence what every record actually represents. The garbage-in, garbage-out death spiral — layers of fuzzy fixes compounding on top of each other — becomes unnecessary when you fix the root cause.
This also changes the stakes calculus. The universal joke about bad Salesforce hygiene used to be tolerable because the consequences were bounded. Now, with board-level commitments to AI-driven productivity gains on the line, it isn't.
"If you have your board slide that says that agents are gonna improve the productivity of all of your sellers, you can just throw it in the bin — there's zero chance that you can automate anything with an LLM on top of a system of record where you don't have confidence in the underlying data." — Anders Krohn
Anders brings the conversation back to dollars with some numbers that are hard to ignore. Based on data tests Kernel runs with prospects, 80 to 87% of CRM records contain entity data errors of varying severity. The downstream impact on territory design is both direct and measurable.
Between 10% and 25% of accounts assigned to reps are wrong in some meaningful way: out-of-business entities, non-ICP accounts assigned to enterprise reps, misclassified subsidiaries. For a team of 300 sellers with a million-dollar quota, Anders estimates the misallocation amounts to roughly $60 million in lost revenue capacity.
The cost shows up in two forms: time wasted on data disputes (especially when those disputes touch commission calculations) and raw revenue capacity that simply never gets deployed effectively. This is why territory design quality directly affects GTM output — and why the data foundation underneath it deserves the same scrutiny as the quota model on top.
One of the broader mindset points Anders raises is directly relevant to how RevOps teams position themselves internally. Individual sellers can use Copilot or ChatGPT and get incremental productivity gains. That's fine. But the leverage RevOps uniquely controls is at the system level.
"The power of revenue operations is when you take your entire system, take your entire go-to-market, take your entire CRM, and say, okay, like how can we shift this machine to just run faster in the right direction? And that does require some of these infrastructure-level interventions." — Anders Krohn
This is the argument for why data foundations are a RevOps priority, not an IT or data engineering priority. The operators who understand this — and who are investing now in entity resolution, data governance, and AI-ready architecture — are the ones who will have disproportionate leverage when the capability stack matures. The operators still chasing point solutions will be managing their data death spiral from a much harder position.
For a deeper look at what it means to think strategically about RevOps systems rather than tactically about individual tools, Episode 75 on moving from AI experiments to revenue machines is worth the listen.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
Explore Kernel's approach to agentic entity data for revenue operations at kernel.ai.
Our average member has more than 5 years of RevOps experience. That means you’ll have real-time access to seasoned professionals. All we ask is that you’re generous with your knowledge in return.
.jpg)
