78% of enterprise technology buyers say they cannot verify what AI vendors claim. 69% say every vendor sounds the same. Both numbers come from 2025 surveys, and they are really one number: when everyone in the room promises "dramatic efficiency gains", the buyer has no way to tell a working system from a good deck.
There is a way to cut through that, and it does not require you to understand the technology. It requires one clause in the agreement. I call it a success metric signed in advance, and after 25 years in management and hundreds of negotiations with vendors, I think it is the single most important clause in any AI engagement. More important than the price.
Why most AI projects are signed without a metric
Because in the short term it suits both sides. The vendor does not want to commit to an outcome in a system that depends on your data and your processes as much as on his software. And the buyer - this is the uncomfortable half - usually never measured the baseline. Nobody knows what it actually costs to process one invoice, how long it takes to answer one inquiry, how many hours disappear into the monthly report. You cannot sign up to improve a number nobody ever wrote down.
That gap is no accident. The State Comptroller report of June 2026 found that only 18% of organizations in Israel hold a written AI strategy, so missing metrics are hardly a surprise. But this clause does not need a strategy. It needs one week of honest measurement.
The result is well documented. That same Comptroller report puts 68% of AI projects in Israel stuck in pilot. A RAND study found that 80.3% of AI initiatives fail to deliver measurable value. A project without a metric never fails - but it never succeeds either. It just carries on.
What the clause looks like in practice
A success metric signed in advance has five components, and not one of them is technical:
- A baseline measured before signing. "Today, preparing the monthly control report takes 3 working days" - measured, documented, agreed by both sides.
- One metric tied to money. Not satisfaction, not adoption - working hours, cost per transaction, response time, error rate. Something the finance director can convert into shekels.
- A numeric threshold. "A reduction of at least 60%", not "a significant improvement".
- A decision date. A named day, usually 30 to 60 days after go-live, when you measure against the baseline.
- A written decision rule. Clear the threshold and we expand, on terms set in advance. Miss it and we stop, with the financial consequences already agreed. No debate, no "let's give it another quarter".
In the language of an agreement it reads like this: "On date X the parties measured a baseline of Y. The system will be assessed on date Z. If it meets the target of W, the agreement extends to the next phase at the price set out herein. If it does not, the engagement ends."
What this clause does - for both sides
For the buyer, three things. It filters vendors on the spot: a vendor who will not sign a number has just told you what he thinks of his own deck. It forces your own organization to measure itself, an exercise worth money even if the project never happens. And it moves the conversation at management level from faith ("it feels like it's working") to investment ("did we hit the target or not").
For a serious vendor it is a gift, and I say that from that side of the table. When I build a system - automated CV intake with cost-per-processing control, a management report that assembles itself overnight instead of eating three days of manual work - I would rather be judged on a number. The number is the best advertising I have, and it takes me out of a contest decided by slides. No accident that industry surveys find 73% of buyers prefer value-based pricing: once there is a metric, the money can be tied to it too.
And the familiar objection, that "we can't commit to an outcome because it depends on your data"? There is truth in it, which is exactly why the clause cuts both ways: it fixes your commitments as well - access to data, an available process owner, decisions taken on time. A serious vendor will happily put that in writing, because he gets burned by projects that stall on the client's side too. A vendor who still refuses once the mutual commitments are on the table is selling a deck, not a system.
The difference between a bet and an investment
A bet is money in and hope. An investment defines in advance what the return is, when you check it, and what you do in each case. The technology does not decide which one your project is. This clause does.
A quick exercise to make the point: take the last AI project your organization approved and try to fill in the five components for it in five minutes. In my experience most organizations stop at the first one, the baseline. That is nobody's failure - it simply means the project was approved on the strength of a story. From the next one on, do not approve a story.
So the recommendation is a simple one: do not sign an AI project - mine or anyone else's - without a success metric signed in advance. Fewer promises, more results, which is the whole point.
Want to see what that looks like in your organization? Pick one process, and I will measure the baseline with you and come back with a demo and a number I am willing to sign.
