The Key AI Decision That Will Shape Your Revenue Org
Thoughts on a centralized vs decentralized AI transformation
Every conversation I have with revenue leaders right now circles back to the same question: how do we implement AI in a way that moves the needle fast? In these conversations, I’ve noticed two distinct approaches emerge.
The first camp takes a centralized approach. A small group of people owns the AI transformation for the entire customer journey, from prospecting through post-sales. They build, optimize, and deploy AI capabilities from the center out. The reps don’t manage agents or run their own tools. They just receive outputs that have been refined and tested by specialists in the workflows that they’re already used to.
The second camp is bottom-up. Leaders encourage their teams to explore their own tools, maybe give them a budget to put on their corporate card, or deploy something they like and let people try things out. People build their own custom GPTs and Gems. They experiment and some of it sticks.
This bottom-up approach has its merits but at Owner, we’ve chosen a centralized approach. Here’s why I think it’s the right call for most revenue organizations.
How we got here
Our centralized model was more emergent than pre-planned. When myself, our head of RevOps, and our head of BizOps started pushing AI into everything we could, nobody else outside of EPD was thinking about it yet. We were living in a different information ecosystem, largely on X and YouTube, where we were just consuming everything about what was possible. It felt like it would be incredibly slow to try to pull everybody along when we could just build the capabilities ourselves and push them into people’s workflows. Moving fast ourselves just seemed like the obvious thing to do in order to get a head start on our competition.
With the benefit of hindsight, I can see that we were very fortunate to take this approach.
What the decentralized model does well
The decentralized approach has real strengths worth acknowledging.
You get way more people coming up with interesting ideas. You’re putting tools in the hands of the people who actually have the problems you’re trying to solve. They’re close to those problems. They have intuition about them, and interesting things will certainly emerge from that.
You also better distribute AI literacy across the organization. When people are building their own things from the bottom up, more of your team develops their AI muscle. There is probably a long-term benefit that we’re missing out on here, but I’m OK asking our sales people to be great at sales and asking our tech people to be great at tech.
Where the decentralized model falls short
That said, what I’ve found with the decentralized approach is that while the outputs are interesting, it’s almost never production-grade. Someone creates a custom GPT or a Gem and they’re cool but very low power compared to what you can build with more sophisticated approaches.
Think about the sophistication ladder: there’s basic chat, then there’s custom GPTs and Gems, then you get into n8n or Make, then Claude Code, then actually building your own AI applications with proper prompt & context engineering, evals, etc. The decentralized model rarely gets past the second rung.
At Owner, our applied AI team is testing multiple prompt variants with the same context, looking for the same output, with evals built for that. They’re connecting Snowflake databases, pulling in Notion folders, doing context engineering at a level that’s just not possible with a custom GPT. And no IC is building evals for their custom GPT and running hundreds of simulations.
That means our AI team can create tens of thousands of emails at a higher quality threshold than any individual rep could have produced, and at a volume that’s probably ten to fifty times what they would have done on their own. Every single person who fits our exact criteria gets enriched in a very specific way, with context pulled in from multiple sources, and they’re getting multiple emails. That’s uniquely unlocked by a centralized model.
The other big win with a centralized approach is that nothing happens in a silo. One of the biggest headaches in sales is losing context. A customer tells the sales rep something important on a call four months ago. By the time the CSM is prepping for a QBR, that’s buried in a transcript nobody remembers exists. Or it’s sitting in a custom Gem and never makes its way into a centralized database. Or the original CSM left and the new person is starting from scratch. A centralized approach solves this by design. When we build something for sales, we’re already thinking about how that same context flows to onboarding, to the CSM, to how we track product usage.
What this means for jobs
Jordan Crawford, CEO at Blueprint GTM, sparked this idea for me recently: a job is really just a bundle of tasks. You can look at any job description and pull those tasks apart, then ask what’s best done by people and what’s best done by machines.
With a centralized model, we’re not asking reps to “manage agents” or run their own AI workflows. Instead, we just do certain parts of the job centrally, and those tasks are no longer in the job description at all. The rep receives outputs as inputs into their actual work. Lead research, account enrichment and pre-call research are good examples of tasks that used to be in the sales JD that shouldn’t be moving forward because they can be done so much better with centralized tools.
Researching accounts is in most BDR job descriptions, but it’s not part of the job at Owner. Finding contacts, getting phone numbers, and building lists with a hypothesis of need is all done centrally now. The rep gets a list with everything already there. They’re not bouncing between Salesforce and Slack and their inbox and whatever other sales tools. They can spend their time on the stuff humans are actually best at: getting on the phone, building relationships, figuring out creative ways to move open pipeline.
Same thing with keeping your CRM up to date. That’s a task we’ve largely taken out of the reps requirements with the help of Momentum, which captures and updates everything for them. It should just be done by AI, with the rep reviewing the output.
Some people get nervous when they hear about jobs being “unbundled.” But the tasks AI is best at are mostly things people don’t actually want to do anyway. Nobody got into sales because they love grinding through lead research databases. Nobody became a CSM because they were passionate about sending check-in emails and updating Salesforce fields. People want to be on the phone with customers. They want to solve problems. And when reps aren’t drowning in admin work, they can manage way bigger books.
Why this matters even more for post-sales
Think about what percentage of a CSM’s job is actually generating value. In my experience, maybe 40%. The rest is manual work: checking dashboards, sending emails, logging activities, chasing meetings.
Post-sales teams have a big advantage here: they’ve got the first-party data. Product usage, support tickets, billing history and all the context that sales teams have to scrape and enrich from the outside, post-sales already has and then some. When you combine customer data with product data in a centralized system, you can do things that aren’t possible when everyone’s running their own tools.
I was chatting with Tom Richards, who runs Trig, about this recently. He made a point that I keep thinking about: most CSMs can only really be effective across thirty, maybe fifty accounts. After that, it’s incredibly difficult for any one rep to be proactive with the accounts they manage. Onboarding slows down, they miss the signals that someone’s about to churn, expansion conversations happen too late or not at all. The default answer has always been to throw more people at the problem, but that math doesn’t really work anymore. His take is that “if you have an AI system like Trig doing the account watching, nudging, and messaging centrally, you can scale the benefits of post-sales in a way that wasn’t previously possible”.
The CSM doesn’t have to spend half their week on check-in emails and CRM updates, because the AI can now handle that side of things automatically. Not only that, but it can do it at a scale and precision that can reach every customer, rather than just the ones you have bandwidth for. The direct impact of that can translate into more customers retained and grown. But indirectly, it also means your revenue org can become significantly more efficient and effective, as reps become fully focused on revenue generating activities (like actually talking to customers who need help). Or in Tom’s words: “Ultimately a centralized AI-first approach - that’s deployed correctly - in post-sales, can translate into a rep covering hundreds if not thousands of accounts.” We’ve started this process at Owner with the Trig team but pushing for the same centralization as sales in CS is a big opportunity.
How to actually do this
If you’re bought into the centralized model, the next question is how to actually build it. Most companies run into two problems.
The first is talent. Most companies don’t have somebody to do this work. These applied AI people are valuable and hard to attract unless you’ve got a top-tier employer brand and a lot of cash. If you have one of these brands and an exciting growth story then certainly hunt for A++ talent. I find most of these folks to be highly entrepreneurial, so make sure that they have the freedom to experiment and explore. More importantly, make sure they know that, and that you won’t bury them in bureaucracy and boring projects. Applied AI talent is still an emerging category so I don’t have any silver bullet advice on finding it. Look for Rev Ops/Growth/Data people that are building cool things on X and LinkedIn, pull someone out of an AI-native Growth consultant, or find GTM AI founders that are struggling with PMF.
If you don’t have one of these brands, someone on your team has to become that person. Find the most technical person in RevOps or Growth who’s already building interesting AI workflows, and let them loose. Tell them that this is their thing now and they can go buck wild on building the future of GTM at your company. Give them the runway to go deep and spend a couple hundred hours learning on X and YouTube, building stuff in Claude Code, making a bunch of things that don’t work until they start to figure it out. Anyone smart and eager from a systems background can learn this. They just need permission and time.
Or you can buy the capability. We’ve been working with Trig on the post-sales side, and what’s interesting is they’ve productized this kind of centralized AI architecture: persistent context across the customer journey, pattern detection, automated interventions. Most companies underestimate how long it takes to build this internally. It can pull engineering away from your core product for years, and you still might not get it right. There are tools out there that can help bridge the technical gap for you but you still need to dedicate the resources to manage it.
Once you start looking for it, you’ll quickly see that GTM AI tools fall pretty distinctly into one of the two camps. We have pretty consistently chosen centralized tools like Trig, Momentum, Datalane, Avarra etc. They’re managed by a few experts who then push the outputs into the surfaces that those teams already use (Salesforce, Salesloft, Slack etc). One of the big benefits of this approach is that you don’t get even more tool/surface creep than already exists. If anything I’m looking for opportunities to collapse surfaces, not expand them.
The second challenge is orchestration. Even if you have the right person, how do you keep all of it organized? You might have three or four different agents engaging with customers across different tools: your website chat, your outbound motion, your post-sales AI, maybe something internal. They all need to share context and stay coordinated, but right now there’s no clean answer for how to unify them. Do you collapse them together so you have fewer agents? Do they need some orchestration layer on top? Even people on the cutting edge are still figuring this out. You hear this problem described as the context or knowledge graph and it’s a big conversation on AI X. If you’ve solved this at your organization, please hit me up so we can share notes!
Where this leaves us
The decentralized approach can work, but if you want production-grade results, speed, and the kind of quality and volume that actually moves revenue, you need to centralize (in my humble opinion).
The centralized model lets you unbundle jobs into their component tasks, reassign those tasks to machines where it makes sense, and let humans focus on the parts they’re actually good at and enjoy doing. I think the gap between companies that figure out the centralized approach and those that don’t is going to widen very fast.