> ## Content Index > Fetch the complete content index at: https://www.salesenablementcollective.com/llms.txt > Use this file to discover other available public pages before exploring further. # How AI is rewiring enablement and GTM - URL: https://www.salesenablementcollective.com/how-ai-is-rewiring/ - Published: 2026-08-21T16:52:31.000Z - Updated: 2026-09-08T10:02:08.000Z - Description: Turning on enterprise AI without enablement doesn't scale productivity, but inconsistency. How to build governance before the bill arrives. - Author: Sandy Robinson - Tags: Premium, Membership content, Sales Enablement, Go-to-Market, Articles I've been in [sales](https://www.salesenablementcollective.com/sales-enablement-and-onboarding-how-to-measure-what-really-matters/) and [enablement](https://www.salesenablementcollective.com/behind-the-report-with-spekit/) for 25 years. I've seen a lot of tools come and go, a lot of programs roll out with fanfare and quietly disappear, and a lot of well-intentioned initiatives create more chaos than clarity. But what's happening right now with enterprise [AI](https://www.salesenablementcollective.com/ai-in-revenue-enablement-research-report-2026/)? It's a different kind of challenge. And I think a lot of us in enablement are feeling it. Let me tell you how this really started for me. ## The email that changed everything It was March 18, 2026\. Our CTO sent out a company-wide email. New AI tooling coming your way. Enterprise Claude, turned on for the entire company, effective immediately. Here's Claude 101 and Claude 102\. Go figure it out. And that was it. I've been doing this for 25 years, and not once have I rolled out a tool, a process, or a program without some kind of enablement attached to it. Not once. And here we were, flipping the switch for the whole organization and basically saying, good luck. My anxiety kicked in immediately. Because I know what happens when you hand people a powerful tool without guardrails. Within two days, I had my answer. A [rep](https://www.salesenablementcollective.com/why-sales-reps-need-to-experience-customer-onboarding-and-close-the-empathy-gap/) had built some kind of automated email responder using Claude. It fired off a message declining an internal meeting because the meeting invite didn't have an agenda. The rep had to go back and apologize, explaining that Claude had written it. Then came the LinkedIn posts. Reps generating their own social content, no [branding](https://www.salesenablementcollective.com/designing-an-enablement-brand-identity/), no approved messaging, no talk track, just whatever Claude spat out. Posted publicly. Representing our company. That's when it really hit me. We were scaling inconsistency. ## The anti-scale problem Here's the thing about AI at scale that doesn't get talked about enough. When you give everyone access to a powerful generation tool without training them on how to use it, you don't get efficiency gains across the board. You get everyone doing the same things they were already doing, just faster and at higher volume. The rep who wasn't following [brand guidelines](https://www.salesenablementcollective.com/designing-an-enablement-brand-identity/)? Now they're producing off-brand content at ten times the speed. The AE who was sending vague, unfocused emails? Now they're sending them to twice as many prospects. The person who had a slightly wrong understanding of your ICP? They're now building entire outreach sequences around that misunderstanding. That's the anti-scale. You're not amplifying good behaviors. You're amplifying whatever behaviors already exist in your organization, trained or untrained, consistent or inconsistent. I ran a LinkedIn survey before this keynote, and the results were genuinely surprising to me. Most people were worried about bad data. Which, yes, bad data is a real concern. But almost nobody flagged inconsistent customer experience as a top risk. And that's the one that keeps me up at night. I can manage bad data. I can build processes around it, add validation layers, clean it up. But when a prospect gets five different versions of your value proposition from five different reps, all generated by Claude in five different ways, that's a trust problem. And trust problems are much harder to fix. ## Your enterprise AI tool probably has no owner Here's a quick exercise. Think about whether your company has rolled out an enterprise-wide AI tool. Claude, Gemini, Copilot, OpenAI, anything. Now ask yourself: who owns it? If you said IT, you're probably right. If you said InfoSec, also probably right. If you said anyone in revenue, enablement, or go-to-market, I'd be surprised. That's the reality most of us are operating in. The tool is on. The company expects people to use it. And nobody in your function actually owns how it's being used by the people you support. This creates a genuinely strange dynamic for enablement professionals. We're responsible for consistency, for adoption, for making sure people are showing up to market the right way. But we don't control the primary tool they're using to do that. We have to work around it, collaborate across teams, and build influence with IT and InfoSec in ways we maybe haven't had to before. That's not a complaint. That's just the new reality. And the sooner we accept it and build for it, the better. For expert advice like this straight to your inbox, sign up for Pro+ membership. You'll also get access to 100+ hours of exclusive video content, a complimentary Summit ticket, and so much more. So, what are you waiting for? [Get Pro+ ](https://www.salesenablementcollective.com/pro-plus-membership/) ## Architecture matters more than you think I want to talk about how I think about the tech stack now, because it's shifted significantly even in the last six months. I used to think of Salesforce as the launch pad. The dashboard everything flows through. The source of truth people return to. At my company right now, people's launch pad is Claude. They open Claude first. They ask it questions. They pull information from it. And they don't always know whether the information they're getting is accurate, because they don't understand how the underlying systems are connected. That's a problem worth taking seriously. When you think about your revenue architecture, think about the bow tie framework. The customer sits at the center. On the left, you've got your top-of-funnel activities, marketing, lead generation, opportunity creation. On the right, you've got your post-sale motion: [customer success](https://www.salesenablementcollective.com/what-is-customer-success-enablement/), expansion, retention. The whole thing is one continuous system, and every part of it depends on clean, consistent data and clear processes. Now layer AI on top of that. Suddenly, every connection point matters. Where does your call intelligence write back to? How does your enablement tool pull from your CRM? What happens when someone asks Claude for a pipeline report, and Claude is connected to Salesforce but doesn't have the right field definitions to interpret what it's seeing? At my company, we have call intelligence writing back to Salesforce because, honestly, reps don't fill out fields. So we fill them out for them automatically. We have Microsoft feeding into our attention tool. [The facilitator is now the last role AI cannot replaceHow AI is changing what matters in the enablement profession, and why facilitation now counts for more than content volume.![](https://storage.ghost.io/c/af/0b/af0be61a-605a-42ee-a863-ad9ed41cd9ed/content/images/icon/android-chrome-192x192-5a330e7f-9152-4217-a44c-7c6c68e35567.png)Sales Enablement CollectiveRyan Panzer![](https://storage.ghost.io/c/af/0b/af0be61a-605a-42ee-a863-ad9ed41cd9ed/content/images/thumbnail/Ryan-Panzer-2-5e08b1de-db30-4f99-a1b9-cc30982c7991.png)](https://www.salesenablementcollective.com/why-sales-enablement-needs-fewer-decks/) We have attention pushing into Seismic via API so we can share calls through deal rooms. We have attention connected to Claude so we can reference call intelligence through project folders. That architecture took real thought to build. And even then, it requires constant maintenance. Every new connection is a new potential point of failure, a new place where the wrong data can flow into the wrong place and produce the wrong output. ## Read access only. At least to start. One of the most practical pieces of advice I can give you right now: when you're connecting your systems to your enterprise AI instance, start with read access only. Don't give write capabilities, at least not yet. I know it's tempting. The use cases sound compelling. But the moment you open up write access, you open up a whole set of problems you probably haven't anticipated yet. You'll discover permissions gaps you didn't know existed. You'll find out that someone figured out a loophole and added a bunch of fields to Salesforce that your team never approved. You'll realize that the governance you thought you had doesn't actually cover this scenario. Let people gather information. Let them learn from it. Let them get more efficient at pulling insights. That's genuinely valuable. But keep the writing, the updating, the creating, in human hands for now. I'm also deliberately not connecting certain tools to our enterprise AI instance. We use Clay, for example. I'm not connecting Clay because I don't want reps burning credits without understanding what they're spending. I have ZoomInfo plugged into Clay, and I'm pushing the outputs into Salesforce automatically. If someone needs that information, they can get it through the Salesforce MCP. They don't need direct access to Clay or ZoomInfo to do that. These decisions matter. Every tool you connect is a tool someone can misuse, either intentionally or just through not knowing any better. ## Standardization is the foundation I'll be honest with you. When our enterprise Claude rolled out, one of the first things I felt was a kind of panic about my own house. Because I knew that if people were going to be using AI to pull from our content, our processes, our playbooks, those things needed to actually exist in a findable, organized, reliable way. And mine weren't quite there yet. I had stuff in various folders. Playbooks in progress. Guides that were half-updated. Definitions that lived in someone's head rather than in a document. It was startup-y, which is fine when you're small and moving fast, but it doesn't scale. And it absolutely doesn't work when you're trying to build AI workflows on top of it. So for the last quarter or so, we've been heads-down on standardization. Every definition. Every stage. Every handoff. Every piece of process. All of it documented, in the right place, accessible to the right people, and locked down so nobody can accidentally overwrite it. Read-only is my favorite permission setting. I say that with complete sincerity. This matters because AI is only as good as what it can access. If you want to use Claude to build a new playbook, you point it at your existing materials and tell it what you want to change. If those materials don't exist, or they're scattered across 14 different SharePoint folders that nobody can find, you can't do that effectively. You'll get something generic and vague, which is worse than nothing because it looks official. The standardization step also protects you from the well-meaning chaos that happens when multiple people start building their own versions of things. I had a new SVP of marketing come in and, within his first few weeks, he'd pointed Claude at a playbook that a sales leader had built in some random folder. Not the actual source of truth. Just a draft someone had made. And he was off to the races building an ICP persona based on it. That's the kind of thing that keeps enablement professionals up at night. Not because people are doing anything wrong, but because without clear, accessible, authoritative sources of truth, everyone ends up working from different versions of reality. [What makes a battlecard useful?Most enablement teams have battlecards. Far fewer know whether reps open them before a competitive deal. Three leaders, at Entravision, Uber for Business, and The Standard, built programs that answer that question differently and arrive at the same place.![](https://storage.ghost.io/c/af/0b/af0be61a-605a-42ee-a863-ad9ed41cd9ed/content/images/icon/android-chrome-192x192-6bbfb018-c975-4beb-956b-2cabd716994a.png)Sales Enablement CollectiveIvan Nyagatare![](https://storage.ghost.io/c/af/0b/af0be61a-605a-42ee-a863-ad9ed41cd9ed/content/images/thumbnail/SEC_Website_Article_Images_Doodles--2--822faadf-22ee-4b62-b64c-a3c37d215fe4.png)](https://www.salesenablementcollective.com/what-makes-a-battlecard-useful/) ## The real cost of ungoverned AI usage Let me tell you about Evan. (That's his real name, not Michelle, I accidentally gave it away when I was telling the story live.) Evan is one of our AEs, and he is genuinely enthusiastic about AI. Deeply enthusiastic. When I had him share his screen to show me how he was using Claude, I was looking at something that resembled my teenager's bedroom floor. Fifty project folders. Every deal had its own folder. He had Claude connected to our attention tool, pulling call intelligence, saving documents to his own OneDrive, running daily sweeps across all of it. He'd built this whole personal AI infrastructure around his deals. And look, I respect the initiative. I genuinely do. But when I looked at it, I couldn't figure out how he was actually functioning. And more importantly, I couldn't figure out how much it was costing. All those automations, all those sweeps, all those documents being processed. Tokens add up fast. And he was creating data silos that existed nowhere else, which means the institutional knowledge he was building was completely inaccessible to anyone else on the team. That's the anti-scale problem in action. He thought he was being more efficient. And maybe he was, marginally, for himself. But from an organizational standpoint, he was building a system that couldn't be replicated, couldn't be governed, and couldn't be learned from. The governance question is really about this: how do you let people be productive and exploratory with AI while making sure the organization is moving in the same direction? ## Building toward governance We're working on custom [skill](https://www.salesenablementcollective.com/must-have-enablement-skills-and-why-you-need-them/) packages right now. The good news is that at my company, only IT can create custom skills, which means there's a natural checkpoint before anything gets deployed broadly. We're working with them to build skill packages that reflect our actual processes, our actual definitions, our actual data structures. This is important because generic AI outputs are often confidently wrong in ways that are hard to catch. When someone asks Claude for a pipeline report, and Claude doesn't know what our pipeline stage definitions mean, it'll give them something that looks right but isn't. And they'll trust it, because it came from the system. Custom skills, built on your actual playbooks and process documentation, fix that. But they require that the underlying documentation exists and is accurate, which brings us back to standardization. The governance layer also has to address who gets to decide things. Who approves a new MCP connection? Who can create a custom skill? Who reviews what's being built when someone like Evan goes rogue with fifty project folders? These aren't IT questions alone. They're go-to-market questions, and enablement has a real role to play in answering them. [Challenger sales methodology: Model, process, and coaching guideWe take a deep dive into the Challenger sales methodology to understand what it means to be a Challenger sales rep.![](https://storage.ghost.io/c/af/0b/af0be61a-605a-42ee-a863-ad9ed41cd9ed/content/images/icon/android-chrome-192x192-131e3715-c3e7-4916-aaf9-a185529d75d2.png)Sales Enablement CollectiveIvan Nyagatare![](https://storage.ghost.io/c/af/0b/af0be61a-605a-42ee-a863-ad9ed41cd9ed/content/images/thumbnail/Marketing-enablement-2e5e6626-433e-4797-be3a-6da14d5ea37b.png)](https://www.salesenablementcollective.com/what-is-the-challenger-sales-methodology/) ## A practical tip for overwhelmed enablement teams I want to share something that's been genuinely useful for me while I'm in the middle of standing up our LMS and onboarding a wave of new hires simultaneously. I've set up a Claude workflow that sweeps my calendar and looks for sessions I've named with specific labels: onboarding, training, or enablement. After each session, Claude automatically generates an enablement guide to accompany the recording, pulls the full transcript, and saves everything to the right SharePoint folder. It's not perfect. But it means I'm not manually tracking down recordings, reformatting transcripts, or trying to remember which folder I put things in. The content is there, organized, and referenceable, both by humans and by Claude itself when I need to pull from it later. I've also used Claude to build HTML landing pages that give new hires a structured onboarding track, with links to Confluence pages, knowledge checks, and session recordings. It's a band-aid while the real LMS gets stood up, but it works. And it was fast to build. The other thing I've done is train product marketing to add me as optional on their training sessions and use the same naming convention. That way I capture their recordings too, without having to attend every session. It all flows into the same system. This is what practical AI enablement looks like right now. Scrappy, yes. But intentional and organized. ## Evolve constantly, and teach people to do the same The last thing I'll say is this: whatever you build, plan to rebuild it. Regularly. AI tools are updating constantly. New capabilities, new versions, new connection options. The instructions you gave Claude six months ago might produce different results today. The workflow you built in January might need to be rethought by March. That's just the nature of this environment. More importantly, your reps need to be taught how to use these tools well. Sending out a company-wide email with Claude 101 and Claude 102 and wishing everyone luck is the equivalent of turning on Salesforce and expecting people to become power users by osmosis. It doesn't work. It never worked. And it's not going to start working now. Enablement's job isn't to own AI. It's to own alignment. To own the architecture of how people are being taught to use these tools. To own the governance conversations with IT and leadership. To own the consistency of what gets scaled. That's always been the job. AI just makes it more urgent. So when you get back to your desk, here's where I'd start. Map your bow tie and figure out where AI is touching your revenue process right now, whether you know about it or not. Audit what your reps are actually doing with your enterprise AI tool. And start building governance before the bill arrives, because it will. The companies that get this right aren't going to be the ones who moved fastest. They're going to be the ones who moved most deliberately. --- *Sandy Robinson, VP, RevOps & GTM Enablement, Quavo Fraud & Disputes, gave this talk at our Sales Enablement Festival, London, 2026\.*