When a vendor says it sells outcomes, the sales leader’s first question should be what the vendor needs from you to deliver them. In the new pitch, the answer is your data, and I think RevOps should own it.
The vendor’s own list of inputs
HubSpot CEO Yamini Rangan put the argument plainly in an essay dated September 30. She defines context as “the dynamic knowledge about your business, your customers, and your team.” The essay says HubSpot compared results across its customer base of more than 300,000 companies. With good context, MQLs generated improved 264% and deals closed won improved 197%. With bad context, MQLs declined 28% and deals closed won declined 27%, which the essay calls worse than using no AI at all.
Read that list of inputs closely. Business context, customer context and team context cover company goals, the history of every customer relationship, and the workflows, approval rules and escalation triggers inside a revenue team. HubSpot can host those. It cannot invent them. They come from the people who run the pipeline.
Advertisement
SAP is making a version of the same point from its stage in Las Vegas. CEO Christian Klein said in the SAP Connect keynote, “AI also requires significant change management to ensure it delivers the desired outcomes for your business.” Change management on the customer side is work the customer does.
My argument
Whoever signs for an outcome-priced AI product should name an owner for the context that product runs on, and that owner belongs in RevOps. On many teams the work is scattered. Sales ops cleans account records, enablement keeps playbooks current, and finance holds contract terms. A single owner is rarely accountable for whether all of it is accurate, current and relevant to the task, which is the standard the essay sets for good context.
The cost of leaving it scattered is visible in our own coverage. We reported that duplicate CRM records are now an AI agent problem, because an agent acts on whichever record it reads. Rangan’s examples are the same kind of fault: a product no longer in the catalog, an approval routed to a manager who changed roles.
Take the example Rangan gives. An AI that knows a prospect visited the pricing page three days ago, that the deal has stalled for two weeks and that the last demo skipped integrations will write a better email than one that knows none of it. Somebody has to make sure those three facts exist in the system, are recent and reach the agent. That is an operations job with a name attached, and it does not belong to the vendor’s support queue.
The strongest counter-argument
A buyer could say this has the logic backwards. If a vendor sells the outcome, the vendor should carry the risk of missing it, and telling customers to maintain their data shifts the burden onto them. That is a fair worry about any contract, and it is why the order form matters.
But the essay itself places the burden where I do. Context, by its definition, is knowledge about your business that your team holds, and the data it cites says the same model gives different results on different inputs. A vendor can guarantee how its model behaves. No vendor can guarantee the accuracy of records it did not write. The honest version of an outcome contract splits the obligations in writing, so each side can see what it owes.
What I would do on Monday
Pick one RevOps leader as the context owner for every AI product the team runs. Give that person a short audit that checks the three ingredients: are goals and positioning current, are customer records complete and deduplicated, and are approval rules and escalation triggers documented where an agent can read them. Put a freshness target on each, and review it monthly.
Then take that audit into the next renewal. Ask the vendor to write down which results it commits to, which inputs it expects from you, and who decides when a miss belongs to the model and when it belongs to the data. We argued yesterday that pre-launch testing is not a governance plan. The same reasoning applies here. A named owner and a written split of duties are cheap, and they are what turns an outcome claim into something a team can check.
