Audit an AI ROI claim before it enters the revenue plan

A claim that an organization saw return on investment from AI may be useful market evidence without being suitable for a revenue plan. Salesforce's 9 September finance survey says 90% of surveyed finance leaders already using AI report positive ROI. The study is described as double-blind and identifies its sample, countries and fieldwork dates, which is more useful than an unattributed percentage. It is still a vendor-commissioned, self-reported survey. The public article does not give a common cost definition, counterfactual, time horizon or audited financial calculation for every respondent.

This protocol helps RevOps test an ROI claim before using it in a budget, forecast or business case. It presents no observed result and no universal threshold. Its output is a decision record that another reviewer can reproduce from the same population, definitions, costs and evidence.

Classify the claim

First identify whether the claim is a perception survey, a vendor case study, a controlled test, an operational before-and-after comparison or an audited financial result. Each can answer a useful question, but they do not carry the same evidentiary weight. A respondent saying the return is positive establishes the response, not the calculation behind it. A vendor reporting time saved establishes a first-party account, not net financial impact.

Copy the exact claim into the study record and identify its publisher, sponsor, sample, date, geography, included users and excluded users. Preserve the source link and any methodology disclosure. Record what the source does not specify. Do not fill missing definitions with assumptions merely because the headline is precise.

Define the local decision

An ROI study needs a decision: continue a pilot, expand to another workflow, reduce scope, renegotiate, or stop. Name the decision owner and the date at which evidence will be reviewed. Define the workflow and population narrowly enough that costs and outcomes can be observed. AI for the revenue team is not a measurable intervention; one bounded proposal-review-write workflow can be.

State the comparison. It may be the current manual process, a rules-based alternative, a different product or no change. If several process changes occur at once, note the confounding factors. A simple before-and-after comparison may still be useful operationally, but it should not be described as proof that the tool caused the difference.

Build the cost ledger

Include subscription or usage charges, implementation, integration, security review, data preparation, prompt and rule maintenance, human review, exception handling, correction, monitoring, incident response and management time. Treat displacement honestly: time saved is not automatically cash saved, and capacity released has value only if the team defines how it will be used.

Preserve the source for every input. Separate observed invoices and logged hours from estimates. Record the currency, tax treatment, time window and allocation rule for shared infrastructure. If the agent creates new review or repair work, include it rather than counting only the removed clicks.

Define an outcome chain

Start with technical completion, then operational quality, owner behavior, customer effect and financial outcome. For a CRM update workflow, technical success may be a valid write. Operational quality includes correct record identity, supported value and durability after the next sync. Owner behavior may be faster review. Customer or revenue outcomes require separate evidence and longer observation.

Do not skip from model output to revenue. Record drop-offs at each step: unavailable source, no proposal, rejected proposal, wrong association, write failure, later overwrite, no owner action and unresolved customer work. These counts explain where value is lost and which intervention to make. A blended success percentage conceals the repair path.

Pre-register the measures

Before reviewing results, write the included population, observation window, definitions, denominators, missing-data treatment and material failure conditions. Report raw counts alongside rates. Keep abstentions and unresolved cases visible. One severe unauthorized write should not disappear inside a favorable average.

If the decision depends on money, define the financial formula before seeing the outcome. Separate avoided cost, additional capacity, reduced loss and incremental revenue. For incremental revenue, state the attribution method and uncertainty. Do not multiply a survey percentage by company revenue to manufacture a benefit estimate.

Review external evidence without importing it

Salesforce's engineering article offers a different first-party evidence type: a 30-day internal pilot across named teams and a reported maturity curve. It can inform pilot design—bounded cohorts, shared language, context discipline and cost monitoring—without providing a transferable productivity rate. Use external examples to identify measures and failure modes, not to populate the local result column.

Have Finance validate cost treatment, the workflow owner validate operational measures, Security validate risk costs and an independent reviewer challenge the counterfactual. Preserve disagreements. A business case becomes stronger when it records uncertainty instead of smoothing it away.

Publish a decision record

The final record should show the question, source claims, local population, versions, comparison, cost ledger, outcome chain, observed counts, unresolved cases, sensitivity range and decision. State what the evidence supports and what it cannot establish. Link the records behind material values, with appropriate access controls.

Repeat the study after a meaningful model, pricing, mapping, workflow or population change. Retain the earlier version so the team can see whether the operating case changed. The purpose is not to prove AI valuable or valueless. It is to prevent a broad claim from becoming an untraceable assumption in the revenue plan.

Related: Revenue complexity analysis · CRM write-back measurement protocol