When a Purchase Disappoints, the Original Claims Are Missing

← Back · ACT III · Chapter 21: Decision Artifacts That Govern Outcomes

When a purchase disappoints, the standard advice is to return to what was promised before the commitment. It only works if someone wrote those promises down in a place the review can find.

I keep running into the same piece of advice lately, from people in very different seats. A board looking at an acquisition that isn’t paying back is told to separate a bad thesis from bad execution by going back to the claims made before closing. Procurement teams heading into an AI renewal hear that they should ask what the tool was supposed to change. And when a project slips, the review goes back to what the supplier said the date depended on.

It’s good advice, and it’s spreading. The trouble starts when someone tries to follow it.

Where the Claims Actually Live

Ask for the original claims on a large purchase and you rarely get one document. You get a slide from the approval deck, a tab in a financial model, a few pages near the back of the proposal that got picked, an email thread where the sponsor confirmed the savings, and whatever the people in the room remember. Some of those disagree with each other. Most were written by the people who wanted the approval, at the moment they wanted it.

When I built business cases for vendors, the most complete copy of what had been promised was usually ours. We kept the proposal, the model and the version history. The buyer had the signed contract, which says what will be delivered and what it costs, and is mostly silent on what the purchase was supposed to achieve.

So “go back to the original claims” often turns into a reconstruction. Someone assembles the story from the fragments a year later, and the person assembling it usually has a stake in how it reads. A sponsor reads those pages looking for something that can still be fixed, and the vendor usually goes straight to the conditions the buyer didn’t meet. Neither has to be acting in bad faith for the review to land wherever the strongest record happens to be.

What a Findable Record Looks Like

The fix is small and it has to happen at approval, before anyone knows how the purchase will turn out.

The business owner who will answer for the result writes it down in their own words: what the purchase should change, where that number stands today according to the company’s own records, the target, and the date it should be reached. Next to that go the conditions on each side, what the vendor has to deliver and what the company has to do, because most results depend on both. Then the page goes somewhere the review will actually look, with the date of the first check already set.

None of that is new thinking. Most of it already exists in the approval deck. The difference is that it sits in one place the buyer owns, written before anyone knew how things would turn out. When the quarter comes in short, nobody has to reconstruct anything. The board, or the renewal team, opens the page and reads which line missed and whose condition failed.

What It Gives a Vendor That Delivers

This sounds like it works against suppliers, and for some it does. For a vendor whose product actually does what the proposal said, a buyer-held record is the best evidence it will ever have. The product’s results show up in the customer’s own numbers, against a target the customer set before signing, and the renewal conversation starts from that rather than from a fresh pitch. A supplier whose results only show up in its own reports is going to be less happy about it.

It also settles the argument about blame faster. When a date slips because the company never confirmed system access, the record says so, and the supplier doesn’t have to argue that point from memory.

Where to Start

Pick the next significant purchase coming up for approval and ask that the expected result, the baseline, the target date and the conditions on each side be written by the business owner and filed before the contract is signed. That page is a Request for Value. If you want every purchase tracked against the targets it is supposed to deliver, the Purchase Outcome Register holds one row per purchase, with the check dates and whose condition failed when a line falls behind. Both are free on the Guides page.

Keep reading: ACT III · Chapter 21: Decision Artifacts That Govern Outcomes