By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
revopsAf the podcast

Episode 89: RevOps Isn't a Support Function. It's Product Dev.

Follow us on your favorite podcast platform:

youtube podcast icon
spotify podcast icon
apple podcast icon

What if the most important shift in RevOps thinking right now has nothing to do with AI tools, headcount, or reporting structure, and everything with how your team fundamentally sees itself? For Amani Phipps, Senior Revenue Architect at Bonusly, the answer is clear: RevOps isn't a support function, a ticket queue, or an analytics shop. It's a product team. And once you internalize that framing, everything changes — from how you prioritize work, to how you deploy AI, to how you measure the value you deliver.

In this episode of RevOpsAF, Amani Phipps sits down with host Matthew Volm, CEO and Founder of RevOps Co-op, to walk through the evolution of that thinking at Bonusly, and the very practical AI-powered systems his team has built as a result. The conversation covers everything from internal GPT tools and automated deal desk workflows to a multi-agent analytics system called Signal Forge that Amani is actively building right now.

Why RevOps Should Think Like a Platform Product Team

The philosophical shift Amani describes starts with a deceptively simple observation: as the tools available to operations teams have expanded dramatically, everyone working with them has effectively become a product builder. And if you're building a product, you need a product management mindset.

For Amani, this means moving away from the traditional siloed structure — marketing ops in one lane, sales ops in another, CS ops somewhere off to the side — and instead thinking of the entire unified system as the product. That system encompasses everything from HubSpot and Gong to Chili Piper, Intercom, and Snowflake. The policies, processes, people, and enablement that connect those tools are the product. And the rest of the organization — sales, marketing, product, finance — are the ICPs.

"All of that coming together is our product, and when every person on my team can see that everything is a unified product, we start thinking of modifications. We operate differently because our stakeholders are actually the rest of our teammates and we just happen to have several ICPs." — Amani Phipps

This reframe has real consequences for how work gets prioritized. Rather than assigning team members to functional lanes, Amani structures his team around stages of the funnel — expanding the top, moving the middle, managing the transition point at close, and maintaining the post-sale cycle. One team member is even embedded on a product pod for Bonusly's rewards business unit, giving RevOps direct visibility into where the product is going and whether the product vision actually aligns with business goals.

Matt Volm noted that this framing resonates directly with the broader debate around how RevOps should be structured and who it should report to. The key insight is that organizational structure determines what gets prioritized. So if your structure is siloed, your work will be siloed too.

"The things at the very end of the seesaw that are the heaviest and that meaningfully change things is the organizational structure, the vision, the way that you think your goals, your hierarchy. Then everything else is a consequence of those decisions." — Amani Phipps

How Bonusly Got Here: An Iterative Evolution

Bonusly didn't arrive at this model overnight, and Amani is candid about that. When he joined the company four years ago, there was no RevOps function at all. He was hired as Director of Sales Ops, and the mandate was simply to figure out what RevOps could be. The early structure was sales-heavy. Then a CMO joined and marketing ops got absorbed. CS remained peripheral for longer than it should have.

"It took a few core projects to start realizing, hey, that's something we need." — Amani Phipps

One of those defining early projects was financial in nature: reformatting how Bonusly handled proration. The company had been prorating accounts on a daily basis, which created a constant churn of fluctuating invoices and drove meaningful contraction. By restructuring the financial logic, they achieved a 40% reduction in contraction and saved roughly a million dollars a year in credit card processing fees alone. That project signaled something important — that RevOps could influence revenue directly, not just support the teams that do.

This is the kind of work that's easy to overlook if RevOps is positioned as a support function. It's also a good illustration of what it means to think more broadly about what revenue actually looks like in a SaaS business beyond the familiar ARR lens.

Building an AI-First Workforce: Where They Started

The turn toward AI at Bonusly started not with a grand technology initiative but with something almost embarrassingly simple: a weekly email. Amani wanted to move the company toward becoming AI-first, but he knew that abstract commitment doesn't translate into practice without consistent, accessible education.

So he started sharing. Summaries of podcasts he'd listened to. Links from YC and Anthropic and OpenAI. Anything interesting he'd come across. The goal was to make AI relevant and approachable for the people around him — to normalize the conversation before asking anyone to change how they worked.

"I'd hope that after I shared enough that other people would share too, and eventually that's what ended up happening. We just had conversation to conversation after conversation, and then we found one specific use case, hyper specific." — Amani Phipps

For Bonusly's SVP of Engineering, JT, that use case was immediately obvious: people were constantly coming to him with questions whose answers lived in database tables and views. If you could train a model on that schema, you could deflect a huge volume of inbound questions. So he built it. A Slack-fronted GPT connected to the codebase via MCP, routing questions to prompts and returning formatted answers. The V1 was straightforward. The adoption was immediate.

That internal tool — Bonusly GPT — has now handled roughly 8,000 requests from employees at a 70-person company. Some employees have used it 700 or 800 times individually. The signal was undeniable.

This approach mirrors the guidance in Episode 75: How To Go From AI Experiments to Revenue Machines — start with a specific, high-value use case, prove it out, and let momentum build from there rather than trying to boil the ocean on day one.

Automating the Deal Desk (and Then Some)

Once the internal GPT infrastructure was in place, Amani's attention turned to where he was personally spending the most time: deal desk. A significant portion of his week was going toward reviewing contracts, flagging non-standard terms, and letting reps know what the company could and couldn't approve. He knew the policies. He knew the risk appetite. He knew this was trainable.

So he built it. The result: deal desk tickets dropped from roughly 60 per month to around 20, and the time he spends per ticket dropped by approximately 90%. Reps can now answer most of their own questions through the bot. The remaining tickets that reach Amani are ones that genuinely need human judgment — and because the bot has handled the obvious cases, he can move through six requests in five minutes with high confidence.

"Now it's, to your point, human in the loop. I'm just here to verify. And in many cases I can go through six requests in five minutes because I know that generally it's right." — Amani Phipps

He also built a Gong-to-HubSpot integration using Claude and Cursor (Claude Code) that automatically parses call transcripts and updates deal object properties, removing the data entry burden from sellers entirely. The logic: if a rep's job description never said "populate CRM fields," why are they doing it? Every hour a rep spends on data entry is an hour they're not selling. Automate the quiet part of the job and let them focus on the part that actually appears in the job description.

This connects directly to what RevOps should really be doing to enable sellers: making excellence unavoidable by removing friction from daily workflows rather than asking people to work harder within a broken system.

The Data Foundation Reality Check

One of the most important threads running through the conversation is something less glamorous than agent pipelines and automated forecasts: data cleanup. Amani's team spent the better part of two and a half months doing extensive remediation of property definitions, data hygiene issues, and structural problems that had accumulated over several years.

This wasn't optional. It was the prerequisite for everything else.

"If your foundation isn't impeccable, the rest will suffer from it." — Amani Phipps

The specific reason this matters in an AI context is precise: the models Amani is building read property definitions natively to understand what data is relevant to a given query. If those definitions are wrong, incomplete, or inconsistent, the model's context window is poisoned from the start. Clean property definitions in HubSpot aren't just good hygiene; they're now a core part of the infrastructure that AI agents run on.

This is an argument for investing in the unsexy work before the exciting work, and it applies broadly. The RevOps AI readiness challenges most teams face almost always trace back to data and process foundations, not to the sophistication of the AI tools themselves.

Signal Forge: The Multi-Agent Analytics Team

The project Amani is most excited about, and the one that represents the clearest expression of where the product management philosophy leads, is something he's calling Signal Forge. The concept: replace the majority of reporting and analytics work with a multi-agent system that runs continuously and produces structured insights at daily, weekly, monthly, and quarterly cadences.

The architecture is layered deliberately. A daily agent analyzes deal performance and conversation performance, producing a snapshot of what happened that day for each seller, each deal, and key product feedback themes from calls. A weekly agent aggregates those daily snapshots into a weekly report. A monthly agent does the same with weekly outputs. A quarterly agent handles the final roll-up.

Each layer borrows context from the layer below it rather than re-analyzing raw data from scratch. The result is a self-reinforcing system where the quarterly report is already 80% written by the time the quarter ends, because the work has been done incrementally every day.

"I have a fundamental belief that context is capital in the future. In a world where we're working with more tools and we're willing to switch more frequently, how can we carry context with us?" — Amani Phipps

The deeper value here is historical context. If a product leader asks why a particular deal type underperformed six months ago, the answer should be instantly accessible. Not a week-long archaeological dig through CRM records and call logs. And if a forecast needs a conversation-adjusted view (looking at the most recent calls associated with likely-to-close deals to pressure-test the number), that report can be generated in minutes rather than days.

This vision aligns with what Episode 83: Why You Should Stop "Doing AI" and Start Solving Problems describes as the real opportunity. Not deploying AI for its own sake, but identifying the specific bottlenecks in your operation and building precisely toward solving them.

The Human in the Loop — and Why It Stays There

Both Amani and Matt are clear on one point: automation doesn't mean removing humans from the process. It means repositioning them to do the work only humans should do.

For Matt, the evolution at RevOps Co-op's own content production pipeline illustrates this well — moving from fully manual transcript-to-writeup workflows, to AI-assisted drafts with human review, to a system that handles everything from backlinking to CMS publishing automatically, with a human reviewing and approving before anything goes live. Quality went up. Time went down. The human is still essential — just no longer responsible for the parts of the job that are pure mechanical execution.

For Amani, the same logic applies to every system his team builds. The deal desk bot handles the obvious. He handles the judgment calls. Signal Forge will handle the reporting. He'll handle the strategic interpretation. The goal isn't to remove RevOps from the picture — it's to ensure RevOps is spending its time on work that genuinely requires a person with expertise and organizational context.

"Freeing up that time is the real optimization for people. And I think that's when you get to a really exciting place where you can 10x what people are truly doing." — Amani Phipps

This framing also addresses the anxiety many RevOps professionals feel about automation. Amani's answer is direct: he set out to automate at least 50% of his own job in Q4, not because he was afraid of becoming irrelevant, but because he wanted to make room for the work he actually should be doing. As he put it, there has never been a point in his career when the to-do list got shorter — and there won't be. The new work will always be there.

Key Takeaways for RevOps Leaders

  • Treat RevOps as a platform product team. Your stakeholders are your ICPs, each with different needs. Build for them the way a product team builds for users — with a roadmap, a vision, and a continuous improvement cycle.
  • Reporting structure shapes priorities. Who RevOps reports to determines what gets prioritized. If your structure is misaligned with what revenue actually needs, the work will be too.
  • Start the AI journey with education, not tools. A consistent newsletter or Slack channel of curated resources is a legitimate starting point. Normalizing the conversation comes before changing the workflow.
  • Find the most obvious use case first. The best initial AI project is the one that's most intuitive given your daily work — the thing that's clearly trainable and clearly painful. Start there.
  • Data hygiene is not optional prep work — it's the foundation. Models read your property definitions. If those are wrong, everything built on top of them will be too.
  • Keep the human in the loop, but move them upstream. The goal isn't to remove human judgment from RevOps — it's to remove humans from the work that doesn't require judgment.

Looking for more great content?

Check out our blog, join our community and subscribe to our YouTube Channel for more insights.

Related Episodes

🚀 Reach Your RevOps Goals

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.