Podcast
September 11, 2026
Episode 107: AI Can't Fix What Your Business Can't Define
97% of companies have AI initiatives. Only 5% have data ready to support them. Katie Brown on what "AI ready" actually means for RevOps.
Most revenue teams are running toward AI as fast as they can. They're deploying agents, experimenting with predictive models, and layering automation onto existing workflows. Far fewer are asking whether the foundation those tools will rely on is solid enough to support them.
Katie Brown, VP of Revenue Operations at Kami, joined Matthew Volm for a conversation that cuts through the AI excitement to name the more uncomfortable truth: if your data isn't defined, governed, and trusted before you introduce AI, the only thing AI will do is amplify the mess. Katie brings a perspective shaped by six years in RevOps across startups, scale-ups, and a publicly traded company — including hands-on experience with the CRM architecture and data definition problems that follow organizations through every stage of growth.
The gap between AI ambition and AI readiness is not small. Katie cited a Dun & Bradstreet survey of approximately 10,000 companies in which 97% reported active AI initiatives — but only 5% said their data was ready to support them.
"There's so much excitement about the capabilities of AI, but we need to remember this is just like any operating system. If you're gonna have something really unclear at the foundation of what it is that you're trying to build, you're not going to measure what you're trying to measure because you don't know it yourself." — Katie Brown
The illustration she uses is direct: if a company doesn't have a clear definition of what its pipeline is, there's no world in which an AI tool can define it for them. The tool will generate an answer — it will just be the wrong one, confidently delivered. And that outcome is worse than no answer at all, because it builds false confidence in a number that isn't real.
Readiness, in Katie's framing, isn't about how sophisticated your data infrastructure is. It comes down to whether the right data is available in the right format, at the right time, for the right people. The test case is simple: can a pipeline number produced by an individual contributor be walked all the way up to the executive view without breaking? If a team is measuring bookings in annual contract value (ACV) and another is measuring in annual recurring revenue (ARR), and no one has built the bridge between them, that's not a data problem AI can solve. It's a definition problem that has to be resolved before any tool touches it.
This connects to a broader pattern the RevOps community returns to regularly: bad data doesn't just produce bad reports — it degrades every decision made downstream from it. AI accelerates that degradation.
For years, "single source of truth" was shorthand for "get everything into Salesforce." That framing has outlived its usefulness — and Katie is direct about why.
Different definitions can coexist inside the same system. A CRM that houses contradictory metric definitions isn't a source of truth; it's a well-organized source of confusion. The real issue has never been which system holds the data. It's whether the metric, the lineage behind it, and the consistency of its application are agreed upon across the organization.
"To me, it's not necessarily about the system. I think that's part of it, but different definitions can exist in the same system, and I've seen that a bunch of times. So I think it's deeper than that. It's more about the metric, the lineage behind it, and the consistency of that application." — Katie Brown
Katie's example is concrete: ACV calculated on a daily rate versus a 12-month rate produces different numbers. Neither is wrong in the abstract. Both are wrong the moment a company-wide definition exists that specifies one approach and different teams are using different ones. The fix isn't a better CRM. It's a documented, agreed-upon definition that travels with the metric across every system that reflects it.
Matthew's framing aligns: a distributed source of truth is not only possible but appropriate. Finance will always own investor-level metrics. Customer success will operate in tools that sales doesn't touch. The goal isn't to collapse everyone into one system — it's to ensure the definitions are consistent across all the surfaces where they appear. For a deeper look at how CRM architecture decisions intersect with data integrity, Episode 106: Why Good CRMs Fail covers related territory on what breaks when the structural decisions come before the definitional ones.
The question of where to keep a company-wide set of metric definitions is one Katie addresses practically. Finance owns investor-facing metrics; that's non-negotiable and appropriate. But the operational levers — renewal rates, bookings pace, pipeline maturity metrics, and the supportive forecasting metrics behind GRR and NRR — those often fall to RevOps to define and maintain.
Her recommendation for where to house this documentation: wherever the rest of the team already goes to find answers. Confluence, Notion, or whatever the company's standard documentation layer is. The medium matters less than the accessibility. And increasingly, the documentation itself can be made interactive: both Confluence's Rovo agent and Notion AI can be trained on internal definitions so that team members can ask questions rather than hunt through pages.
"While it shouldn't be doing the calculations for you — please don't ask the Notion AI to calculate your GRR after I said that — it can give you the correct definition of it and the different mechanics that are highlighted behind it if you have a clear enough definition in your source of truth to begin with." — Katie Brown
The point is worth sitting with. AI tools trained on well-documented internal definitions can dramatically reduce the friction of onboarding, cross-functional alignment, and day-to-day metric questions — but only if the definitions are documented clearly enough to train on in the first place. The documentation task isn't optional infrastructure; it's the prerequisite for every AI use case that follows.
Matthew adds the corollary: there are genuinely zero excuses for not having this documented. The cat-herding required to get organizational agreement on definitions is real. The act of writing them down once agreement exists is not a hard problem in 2025.
Governance is a word that makes operators nervous — and for understandable reasons. The instinct is that governance means slowdown, and slowdown is something no revenue team can afford. Katie reframes the tension in a way that's worth internalizing.
The problem isn't governance itself. It's governance that manifests as friction for the people who most need to move fast. If a closing rep has to answer four validation questions just to progress a deal, that's not governance serving the business — that's governance becoming the obstacle. Every validation layer in a closing workflow, Katie argues, should create trust rather than friction. The rep should be able to ask "what's this number?" and get a fast, confident answer, not a form.
The structural solution she's used: a governance committee her team calls the Guild (Gosh, I Love Data). One stakeholder arrives with the correct definition based on policy documentation or leadership discussion. The rest of the team works together to build it in a way that's repeatable and accessible. The goal is to keep definitional conflicts out of the workflow layer entirely — resolved upstream, before they become someone's blocked deal.
Her team operates on two-week sprint cycles, with all work ordered by some version of return on investment (ROI) so that prioritization is transparent and stakeholders can anticipate the cadence of changes. This connects to a broader principle: RevOps roadmaps that escape the ticket-taker trap are almost always built around a visible prioritization logic that stakeholders can see and trust. When they can see it, they stop wondering what RevOps is doing — and start seeing it as a partner rather than a bottleneck.
For operators who are already running AI in some form — which at this point is most of the people listening to this podcast — Katie offers a sequence of diagnostic questions worth working through before adding more complexity.
The first: what is the company's objective for this period, and can every contributing team see a shared scoreboard? If the answer is no, that's the first layer to address. Any automation built on top of misaligned objectives doesn't count.
The second: does your bookings pace make sense in the context of your pipeline maturity? A slowed booking pace combined with late-stage pipeline points to something broken in quote-to-cash or negotiation. High lead volume with a starved pipeline and strong bookings pace points to conversion issues at the top of the funnel. Understanding which problem you actually have changes what you should build.
"I would use it more for analysis and insight first before getting into anything predictive. Because again, it has to build that skill of understanding the who and the what your organization is and what you're trying to accomplish before it can ever give you those predictive, really desirable insights that you wanna have." — Katie Brown
The third: does the AI actually know your product and your customer base? If not, she recommends starting with the basics — lead routing, customer base analysis — before moving into anything that requires the model to have meaningful context about what you sell and who buys it. Episode 50: Thinking of AI? Think Data First covers this sequencing in depth, and the principle holds: analytical and insight-generating use cases should come before predictive ones.
The trust-building piece is where Katie's advice gets most practical. She describes the practice of doing chair-sides with stakeholders: sitting alongside a senior leader or an individual contributor and watching how they actually move through the system. What filters are they applying? What date fields are they using and why? Understanding how a CSM distinguishes between a subscription start date and an expected close date — and which one they're using to size their forecast — is the kind of operational detail that can't be designed around from a distance.
This on-the-ground knowledge is also what makes enablement meaningful rather than generic. Unusual behavior in the CRM rarely comes from people doing something deliberately wrong — it usually signals a gap in enablement. For Katie, enablement and definitions are inseparable: you can't write good enablement without understanding how people are actually living in the system, and you can't define good metrics without understanding what questions people are actually trying to answer.
The analogy Katie reaches for when thinking about where RevOps and AI are headed is configure-price-quote (CPQ). CPQ started as a paper-based system in the early 1990s. Today, a well-instrumented CPQ is foundational infrastructure for most revenue organizations. Nobody at a scaling B2B company argues about whether they need one. The question is only how well it's implemented.
AI, she thinks, follows a similar arc. The technology will become ambient infrastructure — not something operators debate implementing, but something that shapes the interface through which sales reps, CSMs, and marketing leaders interact with their data day to day.
"I would hope that in five years it's more... It's just far less administrative for individuals to get the answers that they want about their metrics and their day-to-day." — Katie Brown
The interface she imagines looks less like a CRM and more like a Slack canvas: a lightweight, personalized view of what matters for that person's role today, with the depth of the underlying database available when needed but not constantly in the way. As tools like Claude's MCP connector to HubSpot evolve, the specific agents and surfaces that sit on top of the data will shift. What won't shift is the underlying need for clean definitions, trusted metrics, and a team that understands both GTM processes and data well enough to govern all of it.
That's why, in Katie's view, RevOps doesn't become less relevant in an AI-forward world. It becomes more relevant — because what agents and AI systems ultimately need is exactly what RevOps has always been responsible for building: governed, trustworthy, well-defined operational infrastructure. As Matthew put it, there's no better team equipped to be at the center of that work. The caveat, as Katie is quick to add, is that it only works as a collaborative effort. Influencing without authority has always been a core RevOps skill, and in an AI-enabled org, it doesn't go away — it becomes the thing that determines whether the infrastructure RevOps builds actually gets used.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
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.
