How I diagnose commercial constraints, make trade offs and build operating models that create predictability and scale.
01
Problem
Sales and marketing data lived across disconnected CRM and marketing automation systems with no shared resolution logic. Duplicate and orphaned account records weakened forecast accuracy and pipeline reporting. At the same time, useful call intelligence remained disconnected from the CRM records it should have enriched, leaving representatives to update deal fields from memory rather than call evidence. Both problems had the same root cause: valuable signal had no automated, trustworthy path into the systems driving commercial decisions.
02
Diagnosis
Neither problem required another platform or data warehouse. They required a resolution and governance layer. Full autonomy would have created unacceptable risk because a poor merge or incorrect field update can propagate into forecasting, commission and executive reporting. The common operating pattern was clear: match, score, explain and then let a human decide, with every decision recorded.
03
Decision
I designed both agents to operate in shadow mode as the default state. Each recommendation includes a confidence score and plain language rationale, such as the match keys supporting an account resolution or the transcript evidence supporting a proposed deal update. Nothing writes to Salesforce automatically. Human approvals, edits and rejections create an accuracy record segmented by decision type, allowing individual actions to earn autonomy independently when the evidence supports it.
04
Operating ownership
RevOps owns the operating model, scoring thresholds and promotion criteria
System owners define survivorship and field level rules
Users review, edit or reject every recommendation
The audit history provides evidence for governance decisions
05
Outcome
The work created a repeatable framework for deploying AI agents into revenue systems without accepting ungoverned risk. It established cleaner CRM data as a stronger foundation for forecast and pipeline reporting, connected call intelligence to CRM records and created a defensible path from advisory AI to selective autonomy. Because both agents reuse the same extract, match and score, explain, human gate and log pattern, each future agent can be introduced with a shorter design cycle and an established trust model.
AI agentsData governanceEntity resolutionHuman approval
01
Problem
Commission plans covered multiple team types and payment structures, with different rate tables, gates, retroactive adjustments and manager accelerators. Representatives had no live view of their commission position, could not see how deals in the current period would affect their earnings and had no visibility into accelerator opportunities. Each cycle required manual reconciliation across finance data, quota tables and legal conditions. Payout disputes were slow to resolve because there was no traceable path from a representative's number back to the rules that produced it. Letter generation consumed two full days per cycle.
02
Diagnosis
The bottleneck was not the calculation itself. It was the absence of a single source of truth linking policy, rules, calculation, communication and live representative visibility. Rules lived in spreadsheets, letters were assembled from templates and exceptions were tracked in email. Representatives only saw their commission position at month end, which meant they could not adjust behaviour based on where they stood in the plan. Every cycle rebuilt the same logic, and every dispute traced back to whichever spreadsheet was current at the time.
03
Decision
I designed a modular rules engine with reusable gates, rates, accelerators, retroactive logic and role specific plan structures. I built a live commission calculator fed directly from Salesforce, giving representatives a current view of their commission position, historical performance by cycle and visibility into which deals need to close to hit target and unlock accelerators. Each commission letter is generated from the same versioned rules used by the calculation, so the number in the calculator matches the number in the payout letter. Manager accelerator logic includes safeguards for edge cases where accelerators could otherwise pay managers less than their representatives.
04
Operating ownership
Finance approves policy, rate tables and total cost exposure
RevOps owns versioned calculation logic and audit history
Managers review exceptions and confirm attainment before release
Representatives have live visibility into commission position, accelerator eligibility and deal level impact
05
Outcome
Letter generation reduced from two days to under an hour per cycle. Representatives can now use the live calculator to prioritise deal effort by seeing which deals unlock accelerator tiers, move them closer to target and reflect historical performance in similar periods. Dispute resolution moved from days to minutes because every payout can be traced to the specific rule that produced it. The calculator, letter generator and representative dashboard share the same rules source, so plan changes propagate automatically rather than requiring parallel updates.
CommissionSalesforceGovernanceAutomation
01
Problem
Forecast accuracy sat at around 80%, which appeared acceptable but masked significant inconsistency. Representatives flagged deals as Commit based on instinct rather than defined evidence. Manager coaching varied by individual, so identical deal profiles received different calls across teams. By the time a number reached the CRO it had received little challenge, and risk to the quarter was often surfaced too late for leadership to intervene.
02
Diagnosis
The gap between 80% and 90%+ was not a tooling problem. It was a governance problem. Adding a forecasting tool without changing the underlying inspection discipline would have automated the same inconsistency into a more expensive system. The design requirement was a cadence that separated seller confidence from commercial proof, supported by evidence standards strict enough for Commit to mean the same thing for every representative.
03
Decision
I redesigned the forecasting operating model around three layers of inspection. Representatives inspect their own pipeline against defined evidence, managers inspect with representatives against the same standards, and leadership inspects with managers before the forecast reaches the CRO. Three Commit categories replaced the previous vague middle, and Strong Upside was removed because it functioned as a hedge rather than a forecast call. I also built Pipeline AI on top of Salesforce to score deals for risk, health and account fit, giving managers a clearer evidence base for inspection conversations.
04
Operating ownership
Representatives own deal evidence and documented next actions
Managers own the submitted forecast call
RevOps owns definitions, inspection cadence and pattern analysis
Executives own intervention and resource decisions
05
Outcome
Forecast accuracy moved from approximately 80% to above 90% within two quarters and has remained there. The larger structural outcome is that the discipline survived personnel changes. Representatives and managers have rotated through the team since implementation without the cadence degrading. That is the test I apply to every framework I build: whether the discipline continues when I am not in the room.
ForecastingPipelineGovernancePipeline AI
01
Problem
Pipeline inspection depended on representative supplied signals such as stage, next step, close date and forecast category. Managers reviewed the same fields representatives updated, meaning inspection surfaced only what the representative chose to surface. Deals that looked healthy in Salesforce could be materially at risk without a signal reaching managers until the close date slipped. Manual inspection of every deal at scale was not viable, and spreadsheet based scoring rebuilt the same logic every week.
02
Diagnosis
The gap was between representative reported deal state and objective deal signals. Salesforce held useful evidence such as engagement recency, buying committee coverage, MEDDPICC completeness and activity patterns, but not in a form that supported inspection conversations. A dashboard would surface individual signals without composing them into a defensible view of deal health. The design requirement was a scored and explainable view of every deal that managers could use without interpreting raw signals themselves.
03
Decision
I built Pipeline AI on top of Salesforce as an internal tool that scores every open deal across three dimensions: risk of slippage or loss, health of evidence completeness and account fit against the ideal customer profile. Scoring uses defined weights across signal categories rather than a black box model, so every score can be explained to representatives and defended in manager conversations. Adoption came from placing the tool inside the weekly inspection rhythm and making it useful to representatives preparing for their own reviews.
04
Operating ownership
Representatives use scores to prepare for inspection and identify their own risk deals
Managers use scores as the starting point for inspection conversations
RevOps owns scoring logic, signal definitions and the evolution of weights
Sales leadership uses aggregate scoring for territory and quota calibration
05
Outcome
Pipeline AI was adopted across the full GTM organisation as part of the standard inspection cadence rather than as a separate tool. Inspection conversations now begin with objective deal state instead of a representative summary, changing the coaching dynamic from opinion against opinion to signal against explanation. Because RevOps owns an explainable scoring model, the weights can evolve as the business learns which signals genuinely predict outcomes.
Producing the weekly SLT Revenue Pack consumed approximately three days of RevOps time. The pack pulled data from Salesforce, DealHub, HubSpot and finance systems, then was rebuilt in slides each week. By the time it landed on Monday morning, the numbers were already stale. Coverage framing, budget commentary and pipeline analysis were repeatedly rebuilt even though leadership received the same core information each cycle.
02
Diagnosis
The bottleneck was not analysis. It was the absence of an automation and templating layer between source systems and the presentation. The same joins, filters and formatting were rebuilt every week. RevOps judgement remained essential for the commentary, but roughly 70% of production was mechanical. A BI tool alone would not solve the problem because the pack is a narrative decision document rather than a dashboard.
03
Decision
I built the SLT Revenue Pack production pipeline in Node.js using PptxGenJS, connected to defined data sources through versioned queries. Data extraction, joins, formatting, chart generation and template population are automated. The commentary layer, where RevOps judgement creates value, remains human led and sits on top of automatically generated views. An HTML talk track is produced in parallel so presenters work from the same narrative structure as the pack.
04
Operating ownership
RevOps owns the data pipeline, templates and commentary logic
Finance validates commercial figures used in leadership discussions
SLT presenters own the narrative and message
Executives own the decisions triggered by the pack
05
Outcome
Time to insight reduced from approximately three days to under four hours per cycle. The pack now runs on the same day each week regardless of workload, allowing commentary to focus on judgement rather than assembly. Because the pipeline is templated, adding new views or data sources requires a new commentary layer rather than a complete rebuild.
Executive reportingNode.jsPptxGenJSAutomation
01
Problem
Quoting depended on manual checks across product bundles, pricing tables, discount thresholds and approval routes. Representatives built quotes in spreadsheets and emailed them for review, creating versioning issues and inconsistent commercial governance. Discount decisions varied by representative and manager, and there was no central record of what had been approved for each deal. Quote to cash cycle time depended more on approver availability than on customer readiness to buy.
02
Diagnosis
The core risk in CPQ implementation is treating it as a system configuration project rather than a commercial policy project. Configuring product bundles and pricing tables is straightforward. Designing the commercial policy that the system enforces is where implementations succeed or fail. The requirement was a policy simple enough for a representative to understand at the point of quote, strict enough to protect commercial outcomes and clear enough for exceptions to be routed without ambiguity.
03
Decision
I led the implementation across product architecture, quoting logic, discount tiers, approval routes and adoption. I designed the discount approval framework as a tiered structure with defined flows for the exception scenarios that occur in practice. Each product line has defined pricing, discount tiers and exception paths. The representative experience is built around the decisions a seller needs to make rather than every field the system can support. Controls exist only where the commercial risk justifies them.
04
Operating ownership
Sales owns quote quality and customer context
Managers own commercial exceptions and approval decisions within their tier
Finance owns pricing policy and tier definitions
RevOps owns the rules engine, workflow logic and adoption
05
Outcome
Eight approval flows are now automated, replacing manual email routing with system driven approvals tied to defined discount thresholds and deal characteristics. Quote quality improved because the system enforces product bundle rules that representatives previously had to remember. The larger structural outcome is commercial predictability: discounting patterns are visible to leadership and approval decisions leave an audit trail, changing how commercial policy conversations happen.
DealHubCPQCommercial policyQuote to cash
DISCUSS THE WORK
Looking for a senior RevOps leader?
I can talk through the decisions, trade offs and operating ownership behind any of these examples.