Time saved is a proxy for what AI returns

ICONIQ published a slide this year on how AI is landing inside G&A functions at their portfolio companies. It's a good, specific slide that names sequences of work and leaves tools out. Its footer calls the examples illustrative, observed at select portfolio companies, and not intended to represent benchmarks or survey findings. I'd quote it in a room.

Across the top it carries 4 outcomes. Annual cost savings are $2 to $4 million. Time-to-hire is 40% to 60% faster. Knowledge retrieval and analytics show 45% to 80% time saved. The finance close and reporting show 30% to 80% time saved. One is money and 3 are time.

Faster time-to-hire doesn't say whether the people hired were better, or stayed. Time saved in retrieval doesn't show anyone decided differently with what they found, and time saved on the close doesn't show the close was more accurate or the quarter read correctly. Time saved measures what the work costs, and what the work returned needs a different number.

A proxy is a number that moves with the thing you care about, chosen because it's easier to observe. When it comes loose it keeps reporting, and the number still goes up while the thing underneath stops moving. Three of the 4 are one proxy in different departments, which shows what the market finds easy to measure today.

The $2 to $4 million is the different one. A finance team can put it in a plan and check it against an actual, because it has a denominator, a period and an owner. It's the only one I'd build a case on, and the slide marks it most impactful.

I think a more useful number sits further down the page, buried in a quote. A CFO at a $500M ARR company says their token spend went from near zero to roughly 5% to 10% of payroll, pulled from the future headcount plan. That gives AI spend a denominator every company has, and a budget line to take it from. Most AI ROI numbers are numerators with nothing underneath, so a finance team can't act on them, true or not.

The same CFO says finding the value is hard and controlling the cost is easier. Once a use case is valuable and expensive, the cost work is known, through mid-tier model defaults, caching and tiering by what the task is worth. Their spend came down while usage climbed. The open questions are which use case was worth having, and whether it did what you thought once shipped. A percentage of time saved answers neither.

The slide's practices and their order look right to me. Standardise the manual workflow, put the person who owns the work in the builder seat, then share what they built as governed infrastructure. I'd run an engagement that way. The risk is lifting the outcome row into your board deck, where 3 numbers that measure effort get reported as results. Someone will ask what changed for a customer, and the row has no answer.

For each bet, pick the one number that would look bad if the bet failed, and agree it before the work starts. Read it against the proxy afterwards. When the proxy climbs and that number stays flat, the gap between them is your finding.