Podcast
July 30, 2026
Episode 101: RevOps Should Build for Itself First
Shantanu Shekhar of Personio makes the case for RevOps solving its own AI problems first — with 3 concrete use cases and a framework for going multiplayer.
Most RevOps teams spend their days building tools, workflows, and systems for everyone else — sales reps, marketing managers, CS teams — and then wonder why their own operations still feel held together with spreadsheets and manual effort. The cobbler's kids have no shoes, and RevOps has been the cobbler for long enough.
In this episode of RevOpsAF, Shantanu Shekhar, VP of Revenue Operations at Personio, joins co-host Matthew Volm for a conversation that challenges a deeply ingrained habit in the RevOps function: the instinct to always optimize for the stakeholder first and yourself last. Shantanu brings eleven years of RevOps experience across LinkedIn, Nitro, Gong, and now Personio — a German HR tech company operating at scale — and a background as a management consultant at Bain & Company that shows up in how precisely he frames problems. The conversation covers three concrete AI use cases RevOps teams can deploy for themselves right now, how to start building a "RevOps brain" using an LLM, and the genuinely hard problem of going from single-player AI experiments to a coordinated team-wide approach.
There's a structural irony at the center of most RevOps teams' relationship with AI. Within a go-to-market organization, RevOps is almost always in the driving seat for AI adoption — the function most likely to be evaluating tools, standing up agents, and building infrastructure for the rest of the business. And yet when it comes to applying those same capabilities to the problems RevOps itself faces every day, the function consistently deprioritizes itself.
Shantanu is direct about why this happens. It's not negligence — it's pattern recognition working against operators. "Whenever RevOps teams have historically built, they've always built something for the rest of the company, and the RevOps teams themselves are always at the back end of their own queue." The instinct to solve for customer-facing roles first is so deeply embedded that it doesn't feel like a choice anymore. It's just how RevOps works.
The consequence is that the function deploying AI across the organization is often the last to benefit from it. And there's a second-order cost that's easy to miss: if RevOps hasn't solved its own problems with AI first, it's approaching everyone else's problems cold — without the lived experience of what it actually takes to move from idea to working implementation.
"We always, or often, unwillingly [are] the agents of change within the go-to-market organization, where we're trying to drive a new systemic approach or a new process change. And I think the toolkit that we've used is something we're always very familiar with, and we've naturally tried applying the same toolkit to how we drive AI adoption across the company."
— Shantanu Shekhar
The argument isn't that RevOps should stop serving the broader organization. It's that the function needs to experience AI adoption firsthand — on its own problems — before it can guide others through it effectively. This connects to a broader theme the RevOps community returns to often: influencing without authority requires credibility, and credibility comes from having done the work yourself.
Shantanu organizes the AI use cases he's seen work well for RevOps teams themselves into three categories: prioritization and focus, data and capacity planning, and reporting governance. Each addresses a different layer of the operational challenge.
The first and most immediately applicable use case is using an LLM as a daily operating system for prioritization. Shantanu describes building what he calls a "RevOps brain" inside Claude Code, inspired by a framework shared by Kieran Flanagan, SVP of Agentic Go-to-Market at HubSpot. The concept: feed the model everything relevant — QBR outputs, OKRs and work planning documents, and six months of meeting transcripts — and use it to generate daily briefings, pre-call summaries, and end-of-week hygiene checks.
"I now have a today and a shutdown. So I've set up like agents for — so you start the day, it gives me like, 'Here's what I should be focused on. Here's what's happened.' As we go through the day, I start ingesting notes."
— Shantanu Shekhar
The operational detail matters here: the model doesn't just know what's on Shantanu's plate — it knows how he writes, the tone of his communications, and the format his exec team expects. When it generates a team update or meeting brief, it comes out in his voice, not in generic LLM prose.
Matthew draws a direct parallel to how RevOps Co-op has approached the same concept — feeding their public site map and internal content into a model so it can answer questions about community trends, suggest event topics, and produce content that matches how the team actually communicates. The shared principle: start with what's relevant to you, use meeting transcripts as the daily feed, and treat output examples (QBR decks, Slack messages, Google Docs) as essential training material for the model to understand your communication style.
This kind of foundation work is precisely what AI-ready revenue systems require — not just clean data, but context that makes the outputs usable in practice.
The second use case addresses one of the most persistently painful problems in RevOps: headcount capacity planning. The scenario is familiar — a CRO or CFO asks for a current view of rep capacity, and the answer involves reconciling three different spreadsheets that don't talk to each other, each with a slightly different number.
Shantanu describes building an automated roster at Personio that sends Slack prompts to sales managers on a two-week cadence asking them to flag departures or changes that haven't yet made it into the HR system. The system integrates with Personio's own MCP (model context protocol) to pull structured HR data, while the Slack loop captures the informal knowledge that lives in managers' heads but never reaches any system of record.
"There's stuff which is on the HR system — shout out to Personio's MCP, which you can use to bring data in — but there's stuff which is not yet on the system. So we built all that stuff around that so you can use it."
— Shantanu Shekhar
This is a good illustration of what headcount planning done well actually requires: not just a model, but a data collection mechanism that closes the gap between formal systems and real-world information. The automated roster does both.
The third use case is harder: establishing a single source of truth for AI-generated reporting in a world where every stakeholder is showing up to pipeline meetings with their own artifact.
Shantanu describes a familiar breakdown — one sales leader brings their AI-generated pipeline view, another brings a different one, marketing has its own data, BDRs have theirs. The question "Is my AI better than your AI?" is not a rhetorical one; it's genuinely what happens when tools proliferate without governance. For RevOps, this is a problem with a familiar shape. Data management for RevOps teams has always required a clear system of record and clear ownership — AI doesn't change that requirement, it amplifies it.
The solution Personio is piloting involves establishing an AI governance framework that identifies approved systems of record and a tool called Hex, which allows analysts to point at SQL data sources and generate interactive visualizations and scenario plans without heavy coding. The data analyst on Shantanu's team has reclaimed what he estimates as hours — possibly weeks — of work through the tool.
For practitioners who want to build their own version of the RevOps brain, Shantanu offers a concrete starting point organized around three inputs.
First, recent exec-level output: QBR documents, executive updates, anything that captures the kind of output the model needs to aim for. Second, work planning artifacts: roadmaps, OKRs, project tracking documents — even messy, half-updated ones — so the model understands what's being prioritized and why. Third, meeting transcripts: the most operationally rich input, and the one that makes the model genuinely useful over time because it builds continuous context rather than just a static snapshot.
Shantanu went back six months on meeting transcripts when he first set up his system. "I did 30% of my monthly usage in one day," he admits. The investment paid off: the model now has enough context to generate briefings, draft team updates, and flag priorities in a way that actually sounds like him.
Matthew frames the practical implication clearly: you don't need to start at the very beginning. Three to six months of transcripts gives a solid foundation. Pair those with a sample of output artifacts — the emails you've sent, the decks you've built, the Slack threads you've run — and the model has what it needs to understand not just what you're working on, but how you communicate about it.
This kind of personal knowledge infrastructure also sets up the skills portability question Shantanu raises: once you've built a capability in one LLM, can you transfer it elsewhere? He describes creating a "Shantanu-specific skill" for slide creation by asking Claude to interview him for thirty minutes about his formatting and communication preferences, then feeding in examples. The output is a reusable, transferable specification — not locked to one tool, one context, or one team member. The same logic applies to skills for territory planning, lead scoring, or capacity analysis: codifying how RevOps thinks about those problems is valuable intellectual property for any team.
The most honest section of the conversation is also the most unresolved: what happens when a team of three, five, or fifty people all start building their own AI systems simultaneously?
Shantanu calls it a conundrum, and that word choice is deliberate. "I do believe we are still very early, and there is no silver bullet in how to do this." The challenge isn't technical — it's coordination. At Personio, with a go-to-market team of 400 to 500 people, Shantanu has seen the "democratization" problem materialize in real time: a BDR builds their own intent signal engine while the RevOps team is deploying a shared one, consuming tokens disproportionate to their contribution and creating exactly the kind of divergent-output problem the shared tool was meant to prevent.
The approach Personio is piloting involves three layers. First, visibility: a shared artifact in Claude that functions as a registry of approved agents, skills, and plugins — a governance layer that at least makes the current landscape legible. Second, communication: a monthly AI showcase within the RevOps team where everyone shares what they're building, creating a regular checkpoint before duplication takes hold. Third, a scoping check: before building anything new, the question "Has anyone built this already?" gets explicitly asked.
"I'd be very curious if any of our listeners have actually done this well, because that's one place where even I started talking about Kieran Flanagan and what they're doing at HubSpot. Even what they've been doing — he had a phrase which is 'democratization of AI is actually what's causing chaos right now within all companies.'"
— Shantanu Shekhar
Matthew draws the governance parallel explicitly: the argument for centralizing AI operations within a dedicated team has the same logic as the argument for a unified RevOps function over siloed sales ops, marketing ops, and CS ops. Cross-functional problems — upstream/downstream impacts, duplicate effort, version control on data definitions — don't get solved by the individual functions experiencing them. They get solved by a coordinating layer that sees the whole picture. This mirrors the dynamic explored in Episode 97: Everybody Has AI. Nobody Owns It., which examined the governance gap that opens when AI access is distributed faster than oversight structures can keep up.
The trade-off is real: centralization creates queues and backlogs, which is exactly what teams are trying to escape by giving everyone AI access. But Shantanu's counter is that AI doesn't just speed up shipping — it compresses the time from design decision to deployed output, which means the backlog clears faster than it used to. The bottleneck in a well-run AI-enabled RevOps team isn't build capacity. It's design capacity: the time spent defining what you're solving for, making decisions, and scoping requirements. That's where the RevOps brain use case closes the loop — if your AI system is helping you prioritize and focus, you have more mental space to make better design decisions faster.
This dynamic also intersects with what Episode 96: The Rise of the RevOps Architect argued: the practitioners who thrive in an agent-driven world aren't the ones who know the most tools — they're the ones who think systematically about what gets built, maintained, and governed across a portfolio of AI capabilities.
The closing example from the conversation is a useful preview of where RevOps AI adoption is heading. Shantanu describes a scenario planning tool built by a member of his team using Hex — essentially a visual, interactive version of the Excel scenario modeling that RevOps teams have been doing manually for years. Change a variable (churn rate, cross-sell revenue, rep capacity), and the charts repopulate automatically. Historical data is layered in. The entire planning cycle that used to take hours of manual spreadsheet work — including the careful unwinding required to return to a base case — now happens in real time.
The implication isn't just efficiency. It's what becomes possible when the mechanical work of scenario modeling collapses: RevOps practitioners can spend the time they used to spend building models actually analyzing them. The strategic question — what do these scenarios mean, which trade-offs are acceptable, where should we put the bet — becomes the primary work instead of the thing you get to do after the spreadsheet is finally done.
"It's mind-blowing how much time we actually used to spend on this, and unfortunately some of us still end up spending a lot of time on those things until we jump across the hoop there."
— Shantanu Shekhar
That observation is worth sitting with. The gap between teams that have made the jump and teams that are still in the spreadsheet era isn't just a productivity gap. It's a strategic capacity gap. And the path to closing it, as Shantanu frames it throughout this conversation, starts with RevOps deciding to solve its own problems first — not as a luxury, but as a prerequisite for solving everyone else's problems better.
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.
