Procurement Resistance to Outcome Pricing

Picture an AI startup that has finished scoping a problem with a customer and is ready to sign. The engineers know what the product should do, and the commercial team has agreed on terms in principle. Then the paperwork reaches the customer's procurement function, and the contract that comes back looks nothing like what was agreed. It has the familiar shape of a standard software subscription, and the terms that tied payment to results have quietly disappeared.

This is one of the most common ways an outcome pricing deal fails before it starts. The source material treats it as a problem with a specific cause and a specific fix. In this article you will follow the problem from the procurement team's side, trace how a contract moves through a standard review, and then look at the role the executive sponsor plays in changing the outcome.

A standard enterprise procurement function is set up for a particular kind of contract. The source calls these SaaS-style contracts and names three features that define them: predictable monthly fees, defined seat counts, and fixed service levels. Every part of the procurement process, from the review checklist to the approval path, is built around these features. A contract that fits the pattern is familiar, easy to compare with past deals, and simple to approve.

Outcome pricing does not fit that pattern. The source states that outcome pricing requires procurement to do something different, and that procurement functions resist doing something different. This resistance is not described as hostility or bad faith. It is what happens when a team is configured for one kind of work and is asked to handle another. The procurement team is trying to be careful with the organization's money and process, and its habits point it toward the structure it knows.

The diagram below traces a contract as a standard review would handle it. It is a simplified illustration built from the three SaaS features the source describes. It is not a literal copy of any real procurement checklist. Follow the contract from the top. At each decision, ask whether the contract shows the feature procurement expects. Notice where a contract with outcome-linked terms leaves the familiar path.

Read the diagram as a mechanism. An outcome pricing contract does not answer yes to a fixed monthly fee in the way a subscription does, so its path leaves the decision that asks about the fee. From there it is routed back toward the structure procurement knows. The source's description of the result is that the terms tying payment to results quietly disappear, and the alignment built during scoping is lost along the way.

The trace shows the default behavior. A contract that does not match the template is not rejected in a dramatic way. It is pushed back toward the familiar structure, and the people involved may do this with good intentions. The source is explicit that without direction from someone with authority, procurement will do this every time, because nothing in its standard process tells it to treat this contract differently.

The source names the way successful AI startups handle this resistance. The executive sponsor, the senior person whose top priority the startup is working on, directs procurement to treat the outcome pricing contract as a special case. The sponsor does not negotiate the individual clauses in procurement's place. Instead, the sponsor's direction tells procurement that this contract falls outside the standard pattern and should be handled on its own terms.

The source describes the sponsor's authority as the thing that makes the contract structure possible in the first place. Authority, in this sense, allows the procurement function to set aside its default pattern for this one case. Without that step, the default pattern wins. With it, procurement has a reason to handle the contract on its own terms rather than measuring it against the template.

The source makes a sharp distinction between two ways a contract can come into existence. The contract that produces the right alignment is the one the sponsor has personally directed procurement to write. The contract that produces the wrong alignment is the one procurement wrote from its standard template. The source also describes the contract as the architectural expression of the relationship the forward deployed engineer built during scoping. The written contract is supposed to reflect that relationship, and the way the contract is produced determines whether it does.