Podcast
November 6, 2026
Episode 115: Why Process Documentation Is the Foundation AI Can't Replace
AI doesn't generate your decision logic — it executes what you give it. Adi Klevit on why process docs are more critical than ever.
Most revenue operations teams treat process documentation as cleanup work — something to do after the system is built, the automation is running, and the dust has settled. The problem with that sequencing is not just inefficiency. It's that the most common failure modes in AI and automation implementation trace directly back to decisions that were never written down, boundaries that were never defined, and handoffs that were never examined before a machine was asked to handle them.
Camela Thompson sits down with Adi Klevit, founder of Business Success Consulting Group and author of Stop Carrying Your Business in Your Head, to work through why process documentation has become more urgent — not less — in the AI era. Adi brings a practitioner's perspective from years of building and implementing process and procedure frameworks across industries. Her argument is straightforward: AI doesn't generate your decision logic. It executes whatever logic you give it. If that logic lives only in someone's head, you don't have a foundation for automation. You have a liability waiting to surface.
The conversation covers what process documentation actually means (it's not a Scribe export), why AI implementations that "make mistakes" are really surfacing process gaps, how to get resistant teams to adopt new ways of working, and why the companies that document well now will compound the advantages of every new tool they adopt.
The most common misconception about process documentation in RevOps is that it means writing down what happens. Adi's framing is more demanding than that. Documentation that actually works needs to capture not just the steps, but the judgment behind the steps — the decision points, the triggers, the principles that govern what happens when a situation is ambiguous.
"A process is understanding judgments, principles, opinions, adjudications. Why? How do I think? What triggers what in order to do that? So there is so much more complexity to it." — Adi Klevit
This distinction matters enormously for AI implementation. A screen-capture workflow tool can record what a person clicks. It cannot record why they made the call they made at the fork in the road. And when that undocumented judgment gets handed to an AI system, the system will fill the gap with something — it just won't necessarily be the something the organization intended.
The practical implication for RevOps leaders is that documentation is a prerequisite for automation, not a byproduct of it. That means sitting down before a build — before an AI tool is deployed, before a Salesforce workflow is turned on — and mapping out not just the sequence of steps but the full decision tree. Where does a human need to intervene? What are the conditions under which the process branches? What does "good" look like at each stage? Getting those answers on paper before the build starts is what separates a smooth implementation from a costly rework. For a deeper look at what well-structured process thinking looks like in a RevOps context, The Process of Building Process is worth reading alongside this conversation.
Camela raises a scenario that will resonate with any RevOps professional who has rolled out an AI-assisted data capture tool: a sales team that went from 0% field completion to 70% when AI was handling deal qualification data entry — then started reverting as reps pushed back on what they perceived as AI "errors." Adi's reframe of that situation is worth sitting with.
"AI is not human. It doesn't make mistakes. It always [performs] according to the data that it's being fed." — Adi Klevit
The AI wasn't wrong. The process inputs were incomplete. In some cases, the reps were more optimistic about deal signals than the data supported, and the AI was surfacing an uncomfortable gap between what a rep believed and what the conversation actually indicated. In other cases, the system was taking literal meaning from something that required contextual interpretation — a sarcastic comment, a hedge, a moment of rapport-building that read differently in transcript than it felt in the room.
Neither of these is an AI problem. The first is a people problem: reps who hadn't been convinced that accurate qualification data serves their interests, not just management's. The second is a process design problem: decision points that required human judgment weren't flagged as requiring human oversight in the system design.
The solution Adi recommends doesn’t involve abandoning AI. It's designing the right human-to-AI handoff. As she describes it, the ideal combination is AI filling in what it can, the human retaining the right to change what’s written according to their recollection, and the process explicitly defining where the human’s responsibility lies.
This connects directly to Episode 107: AI Can't Fix What Your Business Can't Define, which makes a similar argument from a data governance angle: AI amplifies whatever structure you give it, and organizations that skip the definitional work pay for it downstream.
One of the more practically useful distinctions in this conversation is Adi's insistence that non-adoption isn't solved by enforcement. It's solved by understanding.
A finance company Adi worked with had persistent CRM field completion failures that no amount of managerial pressure resolved. The root cause, once surfaced: the people being asked to fill in the fields didn't understand why the fields existed or how the data would be used. There was no visible connection between their effort and any outcome they cared about. That's not laziness — it's a rational response to a poorly explained ask.
"It's always, it's the Zig Ziglar: what is in it for them? It's always going back to that." — Adi Klevit
Adi's recommended diagnostic is an interview, not a mandate. Talk to the people who aren't complying. Ask what frustrates them. Ask what would have to change for them to do it willingly. Ask what they think the purpose of the ask actually is. The answers are almost always more illuminating than the assumption that the problem is attitude.
For sales teams specifically, this means translating operational asks into the language of income and account stability. Accurate deal qualification data isn't just useful for forecasting — it allows customer success to staff appropriately, which reduces account churn, which reduces clawbacks. That's a message that lands differently than "the business needs clean data." RevOps leaders who struggle with this translation will find Influencing Without Authority a useful reference for structuring those conversations.
Process documentation by itself won’t inspire change.
Real momentum comes through change management: culture-building, explanation, iteration, and the willingness to run a pilot team and let results do the persuading. Adi shared that getting a single process followed at one manufacturing company took six months of repetition, surveys, and recommunication before it stuck. That’s normal. New processes take time to implement.
Process mapping surfaces something that gut feel can’t. It exposes exactly where human judgment is being exercised in ways that haven't been codified, and exactly where an automation boundary should be drawn.
"It's really like having an X-ray. It's if it's in your head and you go, 'Okay I have the process of client intake. Let's see where we can document.' … Map it out, write it high level, and then figure out. But not only that, you might be able to automate some of the steps, but it only will save you five minutes. Why even bother? That's not the return on investment." — Adi Klevit
The X-ray framing applies in both directions. Mapping a process reveals where automation will generate meaningful return — and where it will create complexity without payoff. Not every step that can be automated should be. The documentation exercise forces that prioritization to happen explicitly rather than being decided in the moment by whoever is closest to the tool.
It also surfaces quality control gaps that often go unexamined until something breaks. When a step is handed off to AI or automation, someone still needs to own the quality of the output. That ownership needs to be assigned in the process design, not assumed. Without it, you get the scenario Camela describes: people continuing to do manually what the automation is already doing, because nobody told them they could stop — or people stopping entirely, because nobody told them the AI still needed oversight.
This is a version of the problem Episode 94: The Boring Work Behind Great AI addresses at length: the unglamorous maintenance and governance work that determines whether AI implementations compound in value or quietly degrade.
The question of prioritization is one Adi addresses with a clear principle: start where the return on investment is highest, and find the team most likely to become advocates rather than resistors.
Her logic is essentially the same as a product launch strategy. You're marketing internally. You need early adopters who will generate results visible enough that the rest of the organization wants what they have. Finding the department that is both process-receptive and in a position to demonstrate material gains — faster ramp, fewer errors, cleaner handoffs, better data for downstream teams — is the fastest path to organization-wide adoption.
The alternative is starting with the most resistant department because leadership wants universal compliance. That almost always fails to produce the momentum needed to make change stick. A single team with documented, optimized, working processes and tangible outcomes is more persuasive than any top-down mandate.
This maps closely to what RevOps leaders describe when talking about building credibility for larger initiatives — starting with a contained win, letting the results circulate, and expanding from a position of demonstrated value rather than theoretical benefit. Be More Strategic: The Key to Growth in RevOps covers this sequencing in the context of elevating RevOps influence across an organization.
For years, organizations could carry process knowledge in people's heads and mostly get away with it. Turnover was manageable, tools were stable, and the cost of institutional knowledge living nowhere but in a few key individuals was real but tolerable.
AI changes that calculus in a specific way. It compresses the timeline. Tools that could dramatically accelerate execution are available now — but they require structured inputs to function well. Organizations that don't have their decision logic documented can't effectively train or govern an AI system. They're leaving capability on the table, and in competitive markets, that gap will show up in results.
"Look at the AI component as a new employee that is coming in and basically taking some of your jobs away from you that you have to train. If you do not have that documented and identified… you have those powerful tools, but if we don't have the infrastructure, we can't really use them." — Adi Klevit
The analogy to onboarding a new employee is deliberate. No organization would expect a new hire to walk in with perfect knowledge of internal decision frameworks, edge-case handling, and institutional context. They'd document the role, train the person, and build in checkpoints. The same logic applies to AI — except AI has less capacity for inferential leaps than a human does, which means the documentation has to be more precise, not less.
The organizations that treat this as an opportunity rather than overhead are the ones that will compound the value of every new AI and automation tool they adopt. The ones that keep it in their heads will find themselves perpetually behind on the actual value realization — not because the tools aren't good enough, but because the infrastructure to use them well was never built.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
