Make Your AI Program Pay for Itself

Companies have quietly accepted a payback period on AI they would have rejected for any other technology. The fix is structural, and it starts with how the deal is built.

An AI program pays for itself when the first use case returns enough measurable money, fast enough, to fund the second one. That depends far less on the technology than on which problem you point it at and how the agreement is structured. Get both right and the program stops competing for budget and starts paying for itself.

Deloitte surveyed 1,854 senior executives and found the typical AI use case delivers satisfactory return in two to four years. Conventional technology investments return in seven to twelve months. Only 6 percent of organizations saw an AI payback inside a single year, and for agentic AI, just 10 percent report significant measurable return today.[1]

This disappointing gap in payback is a new AI phenomenon. If a vendor had walked into your office in 2015 with a system that would pay back in four years, you would have walked them back out. Somewhere in the last three years, the AI hype generated an exemption from the arithmetic that technology has traditionally had to satisfy.

The exemption has proven foolish. Creative deal structures can better align investment with value.

What did value-based pricing teach us the last time?

Value-based pricing works only as well as the outcome is measurable, and that lesson is as old as time. I learned it in Pittsburgh, at FreeMarkets, where deals were structured on the volume of procurement spend covered and related to the savings the customer actually realized. Customers conservatively saved over 15 percent on a sourcing event, and our fees were often only 10 to 15 percent of that savings.[2]

That model worked, and it worked for one specific reason that had nothing to do with how good the technology was. The savings were measurable at the exact moment they occurred. Even when the implemented savings came in lower than what the event produced, there was a significant return on investment. The value was clear, and early success funded ongoing use.

Later, at SmartOps, we sold inventory optimization where the conditions were more complex but the value was still apparent. Value could appear in inventory reductions, service level improvements, other supply chain efficiencies, or all of the above. When this technology moved to the cloud, subscription pricing allowed the initial cost to be lowered and payments extended across the length of the term. The payback period shortened significantly, and the benefits began to fund additional supply chain improvement.

In both cases, alignment of the pricing model to when the value is realized reduced the payback period and fueled additional adoption and innovation.

What are you actually buying when you share risk with a vendor?

You are buying risk transfer, and like every risk transfer ever invented, it costs more when things go well and far less when they do not. This is the part of value-based pricing that rarely is stated plainly, so let me say it plainly.

A conventional deal puts almost all the risk on you. The money leaves your account early, against a promise. If the solution underdelivers, you absorb the whole loss, and the vendor has already banked the license fee. Your exposure is fixed at the start and your outcome is not.

A creative pricing structure moves that line. The vendor lowers the initial cost, which means the vendor is now carrying part of the outcome alongside you. In exchange, the vendor participates in the value created later. Your money starts tracking your results instead of the calendar.

There are two ways to move that line, and the difference matters. You can tie the fee directly to the outcome, which is what we did at FreeMarkets and what AI support vendors do today when they charge by the resolved ticket. Or you can shift the timing, lowering the entry cost and spreading payment across the period when the value actually lands, which is what the move to subscription did for SmartOps. The first requires an outcome both sides can compute to the dollar. The second only requires that the value be real and recurring, which is why it is available to far more companies than the first.

Here is the reality of this arithmetic. If the program succeeds, you will very often pay more in total than a fixed fee would have cost you. The vendor is being compensated for carrying risk, and that premium is real. It is not a discount and no one should sell it to you as one.

With success, you pay more, out of money the program created. With failure, you pay a fraction. That is the trade, and for most companies it is the right one.

The reason it is the right one is that the extra cost in the good case is self-funded. It comes out of savings that would not exist otherwise, not out of a budget you had to defend. And in the bad case, the case that actually kills programs, your exposure is a small share of what you would have written off.

For a company between $10 million and $200 million in revenue, this approach can be the difference between sitting on the sideline and stepping into some high value AI use cases. A failed AI project is a material event at that size if it is positioned with high upfront costs. It does not just lose money, it ends the company's appetite for trying again for years. Capping the downside is worth paying a premium over time, because every business holds large upsides that only become reachable when risk and reward are shared with the vendor.

There is a useful side effect. Ask a vendor to put part of their fee at risk on a use case they have described as proven, and watch what happens. A vendor who genuinely believes their own case study will find a structure. A vendor who will not put a dollar behind the claim has told you something about the claim, and it cost you nothing to learn it. The structural speed advantage a smaller company holds is worth very little if it is spent on the wrong partner.

Which AI use cases can actually fund themselves?

A use case can fund itself when it satisfies three conditions, and the third one decides which of the two structures you can use. This is the test to apply before anyone talks about tools.

One: the baseline already exists in a system you trust. You are not constructing the before-number as part of the project. It is sitting in your ERP, your ticketing system, your billing history. If you have to build the measurement to prove the value, you will spend the savings building it, and the number will be contested anyway.

Two: the unit of value repeats often. Value that occurs weekly compounds inside a fiscal year. Value that occurs twice a year does not, however large each instance is. Frequency is what converts a saving into a funding stream.

Three: the cause is attributable. When the outcome improves, there is an obvious link. This is the condition that determines the structure. Clear the first two and the third, and a fee can ride directly on the result. Clear the first two but not the third, where the gains are real but arrive through several doors at once, and you align on timing instead, lowering the entry cost and paying across the term as the value shows up. That was the SmartOps answer, and it asks far less of your measurement than an outcome-based fee does.

Quote turnaround, candidates processed, invoices handled, orders entered, first-line support, document review, claims triage. These pass all three, and any of them can carry an outcome-based fee. Strategic planning quality, better decisions, faster innovation, improved morale. These miss the first two, which is a different problem entirely. They may still be worth doing. They will not fund anything, and no honest vendor will share risk on them.

Proxigee Services is a Pittsburgh advisory firm that helps small and midsize businesses enter AI on their own terms, and this test is usually the first hour of the conversation, because it settles arguments that would otherwise run for a month.

Why did AI vendors land on per-resolution pricing first?

The market already validated this test, and you can read the proof in vendor price lists. Customer support resolution was the first place AI vendors were willing to put their own revenue at risk, and that is not a coincidence. Intercom charges about $0.99 per resolved conversation. HubSpot cut its customer agent to $0.50 per resolution. Zendesk sits in the $1.50 to $2.00 range.[3]

Ticket resolution passes all three conditions cleanly. The baseline is your existing cost per human-handled ticket, already in the system. It repeats thousands of times a month. And when a ticket closes without a person touching it, nobody has to litigate why.

Notice where that pricing has not spread. The published outcome-based rates cluster in support and service desk work, not in strategy or planning assistance. Only about 17 percent of enterprise SaaS vendors have implemented genuine outcome-based pricing at all, and the blocker they report is measurement and attribution, exactly where you would predict.[4]

Vendors put their own money behind the outcomes they could measure. They had confidence that the solution would deliver provable value.

How do you structure the work so the program funds itself?

You sequence the use cases so the first one pays for the second, then match the shape of the payment to the shape of the value. Two moves, in that order.

Sequence first. Rank your candidates against the three conditions and start with the highest scorer even if it is not the most exciting thing on the list. The first project's job is not to impress anyone. Its job is to produce a defensible number by month three, because that number buys permission and budget for everything after it. Momentum in an AI program is financial before it is cultural.

Then structure the terms. Fix the baseline in writing before the work begins, from the system of record, with both parties reading the same report. Lower the initial payment and let a meaningful share of the fee ride on delivered results. Where the outcome is clean, phase what remains against results rather than calendar milestones. Where it is not, spread the payment across the term instead and let the value arrive on its own schedule.

One note on the term. If you are sharing value with a vendor, put a term on it rather than an open ending. As the outcome becomes better understood on both sides, a pure outcome-based price usually makes the most sense, and a defined term is what gives you the moment to move to it.

What breaks a self-funding arrangement?

Three things break it, and all three are predictable enough to write into the agreement in advance.

The first is a moving baseline. Somebody reorganizes the process, redefines the metric, or renegotiates a supplier contract mid-engagement, and the comparison dies. Freeze the baseline and name what constitutes a change to it.

The second is the "we would have done that anyway" argument. It surfaces the moment savings get large enough to notice, and it is unfalsifiable by design. The only defense is agreeing the attribution rule before anyone knows the answer.

The third is measuring something adjacent to money. Hours saved are not money until the hours are redeployed or a role is not backfilled. Say which one you mean at the start. A program reporting time savings into a P&L that never moves will be cancelled, and it will deserve to be.

Underneath all three is the failure I have written about before, when a pilot succeeds beautifully and still goes nowhere because no one can find the money it supposedly made. Shared risk is the structural answer to that problem. It forces both sides to agree, in advance and in writing, exactly where the money will show up.

None of this requires a new discipline. It is the same goal and governance clarity that makes any AI start work, applied to the money instead of the risk. Decide what a win is worth, in dollars, before you begin. Put some of your partner's compensation on the line for it. Then go earn it, and spend it on the next one.

The best AI programs I have seen were not the best funded. They were the ones that never had to ask for funding twice.