Most RevOps and finance teams know they should be doing more with AI in their compensation workflows. The harder question is what "more" actually looks like in practice — not in a demo vendor environment, but in the real, messy, exception-filled world of monthly commission cycles, urgent CEO requests, and mid-year plan redesigns.
In a recent RevOps Co-op webinar, Matthew Volm, CEO and founder of RevOps Co-op, sat down with Grayson Morris, CEO of Performio; Jonah Turcotte, Director of RevOps at Performio; and Harshit Kumar, AI Strategy and Operations Lead at Performio, for a live agent-building session focused on sales compensation. The group walked through five practical AI use cases — built and demonstrated in real time using Claude — that covered everything from catching exceptions before payroll runs to communicating plan changes to a skeptical sales team.
A poll run during the session revealed that roughly half of attendees still manage sales commissions in spreadsheets, with another 30 to 40 percent using dedicated incentive compensation management (ICM) software. That split shaped the conversation: every example was designed to work regardless of where an organization sits on that spectrum.
Before the live building started, Grayson Morris grounded the session in a conceptual framework that organizes AI agent design into four buckets: what you ask the model to do, what context the model can see, what tools the model can act on, and what systems it can connect to.
The nine underlying concepts — prompts, instructions, context, memory, tools, skills, and connectors (sometimes called Model Context Protocol, or MCP, servers) — all sit around a central large language model (LLM). As Morris explained, the model itself is becoming increasingly commoditized.
"The model's becoming more and more commoditized, and really it's the harness that sits around it that becomes really critical." — Grayson Morris
Skills, in this framework, are packaged sets of instructions — plain text or markdown files that tell the model how to handle a predetermined workflow. The key insight Morris emphasized is that practitioners do not need to write these skills manually. Claude can generate them through natural language conversation. That framing lowered the technical barrier significantly for the practitioners in the audience, and it became a theme throughout every subsequent demo.
This matters operationally because it changes who can build these systems. The shift toward AI-driven automation in RevOps is already underway, but the barrier has historically been perceived as a technical one. The skill-building demonstration pushed back on that assumption.
The first live demo put Jonah Turcotte in his real-world role as Performio's incentive compensation admin at the end of a month close. The problem being solved is one that most comp admins will recognize immediately: a stream of one-off adjustments and exceptions that arrive across Slack messages, emails, and DMs from managers who noticed something that didn't sync or a bonus that wasn't logged.
The traditional approach involves manually combing through all of those messages, extracting the relevant adjustments, calculating the appropriate amounts, and entering them into the ICM system — a process that is both time-consuming and prone to omissions.
Turcotte's demo replaced that manual process with a single prompt: "Hey Claude, please run the exceptions catcher for July."
What Claude did in response was connect to Slack via an MCP server, scan through message history across relevant channels, identify six manual adjustment requests tied to the July period, calculate the appropriate payment amounts by pulling rate data from Performio, and surface all six for review in a structured table before writing them directly back to Performio upon approval.
The detail that stood out: Claude didn't just transcribe the requests. When a BDR manager posted in a team channel that a meeting hadn't synced from Salesforce before the cutoff, Claude determined the meeting rate independently — in this case, $208.33 — based on the rep's current attainment percentage (72%, below any accelerator threshold) and the applicable commission rate. The human in the loop reviewed the output, approved all six adjustments, and Claude wrote them directly into the Performio manual adjustments table.
"It's very good at catching things that I sometimes miss. And it makes a previously tedious process very quick and simple for me every month." — Jonah Turcotte
The skill that governed this behavior had been built by Turcotte through iterative prompting — not by writing every line of instruction manually. Claude generated the skill file itself during the setup process, creating a set of guardrails and reference behaviors that would run consistently every month.
The read/write nature of the integration is worth noting for teams evaluating similar setups. Claude could pull from Performio and write back to it because a custom connector was established with the appropriate permissions. For teams without an MCP-connected ICM, the same general approach is possible — dropping a CSV or Excel file into Claude rather than connecting directly — though it requires more manual handling on the data preparation side.
The second demo modeled a scenario that will be painfully familiar to anyone who has sat on the receiving end of a frustrated executive question: commissions ran over budget, but the team didn't hit its overall sales goals. How?
In the session, Grayson Morris played the irate CEO and Harshit Kumar played the operations analyst being asked to explain what happened — with a two-minute deadline. Kumar's demo showed what that analysis looks like with Claude connected directly to the ICM.
The prompt was conversational: "How did we end up overpaying our commissions for the last quarter but did not meet our sales goals?"
Claude connected to the relevant tables in Performio — commission records, target data, plan components — synthesized across them, and returned a clear explanation: nine of twenty-one account executives (AEs) had overachieved their individual quarterly quotas and triggered accelerators. Even though the team collectively missed its overall sales goal, those nine reps' accelerated payouts drove total commission spend above budget.
"Nine out of your 21 AEs smashed this quarter... And even though the collective performance of the team did not meet the expectations and did not hit the sales goals, because of these accelerators that were kicked in, we end up paying over in commissions." — Harshit Kumar
The diagnosis pointed immediately to a plan design problem: accelerators were measured quarterly, which created an incentive for reps working longer deal cycles to concentrate closings in a single quarter, hit their quarterly accelerator thresholds, and collect outsized payouts even in periods where the business hadn't met its overall targets.
This is a well-documented risk in sales compensation plan design — accelerator structures that don't align with overall business attainment can produce exactly this outcome. What the demo demonstrated is that diagnosing the problem now takes minutes, not days, when the data is accessible and the model can reason across it.
Once the plan design issue was identified, the session moved into the modeling phase — arguably the most practically valuable section for RevOps practitioners who regularly need to evaluate the financial impact of comp plan changes before committing to them.
Harshit Kumar showed a two-file approach: a compensation plan document (the actual plan being analyzed) and a context document setting out best-practice guidelines for how plans should be evaluated. The context file included goals and rules, rate and accelerator guardrails, governance considerations, and self-checks — the kind of analytical framework that an experienced comp practitioner would apply manually.
The combined prompt to Claude was simply: "Analyze this plan for me."
Claude's first response was to ask clarifying questions: How long are your typical deal cycles? Who controls services scope and pricing? Do you favor multi-year contracts? These questions, generated by Claude after reading both documents, reflected the model trying to understand the organization's specific context before making recommendations — behavior that Harshit Kumar noted was important to leverage intentionally.
"Always try to have a conversation with the chat and ask — let it ask you questions so that you also develop a deeper understanding." — Harshit Kumar
After the context was established, Claude identified the core structural flaw (quarterly accelerators enabling gaming on long-cycle deals) and recommended switching to year-to-date annual attainment, adding pricing guardrails for services commissions, and modeling changes against prior-year actuals.
Jonah Turcotte then demonstrated the modeling output. Having described the problem to Claude and attached prior bookings data from Performio, he asked it to build two alternative plan models — one in HTML, one in Excel. Claude produced both in roughly eight minutes. The HTML version was an interactive dashboard that could be opened in any browser: it showed rep-level detail, deal-by-deal commission calculations under each plan scenario, and total payout comparisons. The Excel version replicated the same analysis with formula-based cells — no hard-coded values — allowing for manual adjustment of quotas and OTE variables.
The financial impact was specific: Plan B, which moved accelerators from quarterly to annual measurement, would have saved approximately $421,000 compared to the current plan when run against prior-year bookings data.
For teams managing the broader challenge of making commissions data work for the business, this kind of rapid modeling capability changes the economics of the design iteration process. Scenarios that would previously take a comp analyst two or three days to build and validate can be produced in under an hour — with real data feeding the model.
The fourth demo addressed the communication problem that follows any plan redesign: how do you explain changes to salespeople in a way that actually answers their questions and reduces the flood of individual emails asking what the change means for their specific situation?
Harshit Kumar demonstrated a comp plan communicator — an HTML dashboard generated by Claude from the new plan document and a set of instructions describing what the dashboard should accomplish. The prompt was minimal: "Help me communicate this plan."
The output was an interactive dashboard with sliders that let reps model their own earnings under different quota attainment scenarios, toggle different deal values, and see how their commission would change in real time. The numbers were calculated — not static — and matched the actual rates and tier thresholds from the plan.
"You can imagine just emailing this HTML file to each of your sales reps and saying, 'Hey, go ahead, you can see the new plans. You can play around with what you're gonna make based on what you're gonna sell.' Extremely powerful tool." — Grayson Morris
This matters because one of the consistent friction points in plan changes is sales team buy-in and shadow accounting. Reps who can see their own numbers, interact with the model, and understand exactly how accelerators will work are less likely to spend time building their own spreadsheets to check the math — and less likely to feel surprised when their first paycheck under the new plan arrives. The dashboard approach is a meaningful improvement over the PDF plan document that most teams distribute and almost no rep actually reads carefully.
This connects directly to a broader RevOps challenge around building approval and communication workflows that reduce downstream friction. When reps can self-serve their questions through an interactive tool, the operational burden on the comp team at plan launch drops significantly.
The session closed with an honest discussion about the dimension of AI-assisted comp work that doesn't get enough airtime: how do you know when to trust the output?
Matthew Volm raised the specific example from the exceptions catcher — the $208.33 meeting credit — and asked how the team has developed confidence in that kind of calculation. Jonah Turcotte's answer was candid:
"I ran it one time and my immediate reaction was, 'Wow, this is so much more thorough than I will ever be.' I did check it because obviously it was replacing a process that was previously manual for me... But ultimately Claude has caught things that I wouldn't have." — Jonah Turcotte
Grayson Morris added a useful distinction that frames the trust question more precisely. Simple pass-through adjustments — "pay Bob an extra $100 this month, we promised him a wedding gift" — present minimal trust challenges. The system is just transcribing a human decision. Commission calculations, where Claude is doing actual math against rate tables and attainment percentages, are different.
"In the former, where Claude actually calculates the commissions, I'm still a little uncomfortable with that. I do think we probably wanna build some evals in there or some verifications to make sure that it's actually calculating correctly." — Grayson Morris
Harshit Kumar countered that every change made through the Claude integration should point back to Claude as the source. This type of audit trail doesn't fully replace verification, but it does make troubleshooting easier when something looks off downstream.
The practical framework that emerged: AI is most trustworthy when it's synthesizing and surfacing information for human review, and requires more scrutiny when it's performing novel calculations. As systems mature and the model builds memory around an organization's specific rate structures and plan logic, the calculation trust gap should close — but for now, it warrants a verification step for anything consequential. This mirrors the broader conversation in RevOps about what AI can own versus what still needs a human in the loop.
A practical question from the audience — can you do any of this without a dedicated ICM system or an MCP connector? — produced a clear answer: yes, with caveats.
Several of the demos, particularly the plan analysis and modeling sequences, required only two documents: the plan itself and a context file. No ICM connection, no MCP server. Just a PDF and a text file dropped into Claude.
The MCP connection becomes necessary when the workflow requires reading from or writing back to a live system of record — as the exceptions catcher demo did when it wrote adjustments directly into Performio. But even without a formal MCP setup, Excel files, CSVs, and PDFs can all serve as context sources.
Jonah Turcotte offered a useful frame for what MCP adds beyond the connection itself: "All the MCP does is streamline the process a bit and make it a bit more structured... The MCP tells your AI model how to interact with that system and it gives some instruction and context and guardrails around there."
Harshit Kumar added that MCP connectors also provide security controls — the ability to specify which tables or system areas the AI can and cannot access — that are harder to enforce when working from a dropped Excel file. Understanding the data governance implications of where AI can read and write is a foundational consideration before connecting any model to a live compensation system.
The closing lightning round produced unusually concrete advice. Each speaker was asked to give one specific recommendation for practitioners who have never done anything with AI in their comp workflows.
Jonah Turcotte recommended using Claude to learn how to use Claude: "If I don't know how to do something in Claude, I will ask Claude... I just ask Claude in plain language, 'Hey, this is the problem I want to solve. Can you recommend how we can do this in a streamlined way?'"
Harshit Kumar pushed back on the impulse to start with a perfectly crafted prompt: "I never wrote that prompt by myself... I usually start super vague... Ask me questions so that we can have a conversation around this, that we can design this together." His recommendation was to start with a vague framing and let the model ask questions that sharpen the direction — then execute once the approach feels right.
Grayson Morris advised starting with a specific, concrete artifact rather than a general goal: "Pick a very specific thing you wanna do, and then do everything that Harshit and Jonah just said, which is just ask Claude how you go about building that. I found that more useful than actually all these videos that people put out in these universities and things like that."
The underlying theme across all three answers: domain knowledge still matters. The practitioners who get the most out of these tools are the ones who understand how their systems are structured — what the objects are, what the fields mean, when data should be populated — even if they no longer need to navigate every interface manually. That foundational expertise doesn't disappear in an AI-first environment; it becomes the thing that makes AI output usable rather than unpredictable.
The through-line across every demo in this session is the same: AI doesn't replace the comp practitioner's judgment, it removes the manual labor that keeps that judgment buried in spreadsheets and message threads. The practitioners who will get the most out of these tools are the ones who understand their systems well enough to know what to ask for — and trust the output enough to act on it.
Learn more about how Performio helps revenue operations teams manage incentive compensation, automate commission workflows, and build the kind of structured, auditable ICM environment that makes AI-assisted comp management reliable at scale.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
