# Users Love It. So Why Won't the Contract Close?
Canonical URL: https://theunclej.com/blog/usage-is-not-buying-evidence
Markdown URL: https://theunclej.com/blog/usage-is-not-buying-evidence.md
Description: Usage does not prove an enterprise will buy. A four-page ledger separates users, payment decisions, procurement, and deployment ownership.
Category: ai-organization
Tags: ai-organization, piece-00000163
Published: 2026-10-10T03:53:28.970Z
Updated: 2026-10-10T03:55:13.817Z

---

![og-cover](https://assets.theunclej.com/uploads/166384e1b4ad950f467ecc5cc616b9e2.png)

> **The short answer: an employee loving a tool and an enterprise agreeing to pay for it are two different kinds of evidence — not two stops on the same funnel. When you tell yourself you're waiting for the right moment, you're actually waiting for a body of work nobody was ever assigned to produce: who pays, how procurement runs, and who absorbs the deployment after signature.**
>
> A scope note before anything else: this piece is about splitting the ledgers, not about "users riding free and never buying." On a small team the user often *is* the buyer — the four pages fold into one, and forcing them apart is pure formalism. For every way this ledger breaks down, see "When This Ledger Stops Working" at the end.

## Praise on Stage, a Contract in a Drawer

The day I came in to run an AI implementation review, the operations department at that company had just taken home the quarterly excellence award. One AI tool, six months of use — weekly reports, data pulls, replies to customer emails, all of it lived inside the tool — and their lead got called out by name at the all-hands as exhibit A of bottom-up digitalization.

That same afternoon, I pulled the contract for that very tool in the procurement system. Stuck at security review. Forty-plus days, nobody pushing it forward. I asked about it casually, and nobody in the room found it the least bit strange that the two facts belonged to the same afternoon.

The department lead told me: "It's working this well — a signature is just a matter of time."

I turned that sentence over for a long while afterward. It stuffs the user and the payer, the people applauding and the people signing, into a single phrase: *a matter of time*. And from day one to that day, nobody at the company owned the job of turning "a matter of time" into a calendar.

Deals like this die quietly. A budget window closes, and "a matter of time" becomes "next year," and then it becomes something nobody brings up at the all-hands anymore. Every step along the way is reasonable: budgets run on cycles, so tabling it a year isn't embarrassing; the quarter got busy, so forgetting is only human. Nobody declares failure. Nobody runs a post-mortem. Nobody carries the blame. It just, slowly, stops existing.

## Where the Universal Funnel Snaps

"Users say it's good → usage climbs → the contract signs." That funnel is the default story of the past two years. Strip away the big words — PLG, bottom-up adoption — and what it actually says is: nobody pushed this from the top; employees found the thing useful and started using it on their own, betting that the company would eventually pay.

The bet works only if there is a conveyor belt between people using a tool and the decision to pay for it — usage crosses some threshold, and the contract arrives at the station on its own.

But a user's enthusiasm and usage, and a buyer's budget and procurement capacity, are two different kinds of evidence. Not two stations on one road.

An employee using a tool happily proves the first kind: the tool has survived inside their daily work. They entrust their actual job to it, they come back to it, they pull colleagues in. That evidence manufactures itself every single day; nobody has to lift a finger.

A signature demands the second kind: who pays, on what procurement terms, and who owns the deployment once the ink dries. None of that gets written into any usage dashboard, and by default nobody is responsible for producing it. Scroll to the very bottom of the prettiest usage report and those three lines simply are not there. Inside the organization, every function owns one segment of the journey — the users sit in the business unit, procurement sits with procurement, security sits with IT, budget sits with finance — and no segment's day job includes pushing this contract across the line.

An unsigned contract gets read as *not ripe yet*. **You think you're waiting for timing. You're actually waiting for something nobody was assigned to produce.**

## How the Best Sellers Keep Their Books: *Connect* Is a Verb

This split is not my invention. The people on the selling side who understand "use it, then pay for it" best keep their own books exactly this way.

On Lenny's Podcast, the growth expert Elena Verna defines product-led sales as, at bottom, one sentence: connect individual self-serve usage to enterprise value and the sales pipeline. Notice that *connect* is a verb. Connecting is work someone has to do. Left unconnected, personal usage and corporate payment are just two pieces that never touch.

The boundary she draws is sharper still: an individual employee usually has no authority to solve problems that cross departments, and the person using the tool may not be the person paying for it at all. The deeper you go into the enterprise market, the more deliberately you have to route usage signals to the one person who can actually make the call.

She even distinguishes two ways of keeping score — aggregating a whole team's usage onto an account, versus pinning the signals to one specific individual. The first is easy and the second is hard, and the difference comes down to the accuracy of the door you knock on. A team can carry gorgeous account-level data up to a door with no decision power behind it — and the more gorgeous the data, the bigger the waste.

She also offered a number on the show: from her time at Netlify, Miro, and Amplitude, the road from employees adopting a tool to an enterprise contract landing often runs a year or longer. That is her experiential read, not an industry benchmark. But the weight of the sentence is not in its length — it is in the posture. She said *a year or more*, not "it will sign eventually." Waiting is not part of this methodology.

## The Most Common False Proximity: Design Partners

Another guest works enterprise sales — Jen Abel, whom Lenny has had on more than once. She flags the most typical case of false proximity: the design partner.

These early customers shape the product roadmap, feed back on usage, sit in the working sessions, iterate alongside you. They look like the last stop before a signature. By her account, they are precisely the customers hardest to convert into a full deployment — do not book design partners straight into the pipeline as million-dollar deals.

Following the thread of conversion, she puts the bottleneck at qualification: before anything else, establish whether the other side is even qualified — whether any path leads from here to a signed contract. Time spent on the wrong target zeroes out every hour invested after it.

And there is a hard edge here: a design partnership is a stage; a contract is a size. The two do not convert into a single "conversion rate." Whoever folds them into the same funnel has built a ledger that will never balance.

## What the Never-Started Evidence Looks Like

So what does that unbuilt evidence actually look like?

The book manuscript I have been writing on what happens to an organization after AI moves in contains a mechanism that is easy to skim past: a pilot operates inside existing authorization, and a date on the calendar is not a license. When the trial period ends, nothing has been granted — deployment is a separate door, and that door has its own gatekeepers.

Abel, on the show, name-checked those gatekeepers one by one.

| Gate | What the gatekeeper recognizes | What it looks like when stuck |
| --- | --- | --- |
| The payment decision-maker | Which executive does this unlock what for | The executive is not excited — so the top-down play gets forced anyway |
| Procurement conditions | The target signature date; which stage procurement, security, and legal are each sitting at | The pilot wins first — only then does anyone find the process jammed, with the enthusiasm all spent in the hallways |
| Deployment ownership | Whether the organization has the structure and maturity to absorb this technology | Signed — and then nobody runs operations, nobody changes the process, nobody owns the mistakes |

The payment decision-maker: the starting point of enterprise sales is not how good the product is. It is which executive this tool unlocks what for. If the executive is not excited, do not force a top-down play.

Procurement conditions: her practice is to back-plan the deal path before the pilot even starts — set the target signature date, then line up who from procurement, security, and legal participates, and which gate each of them controls. Otherwise you win the pilot and only then discover the process is jammed solid, with all that enthusiasm burning off in the corridors. She puts it more bluntly still: until the procurement process has run its course, do not start the work — not a single task of it.

Deployment ownership: the customer organization needs the structure and maturity to absorb the technology; sometimes selling services first — working alongside the client for a stretch — is more viable than shipping technology at them. The book manuscript calls this *business owner first*: the business side signs on before the technology gets through the door.

Payment, procurement, ownership. Not one of the three appears anywhere in a usage report. **Double the usage and the numbers on those three lines do not move.**

## The Industry Backdrop: This Gap Is Not Yours Alone

Someone will say: isn't this just the anecdotal read of one implementation consultant?

In July 2024, Gartner forecast that by the end of 2025, at least 30 percent of generative AI projects would be abandoned after proof of concept — the cited reasons being poor data quality, inadequate risk controls, ever-rising costs, and unclear business value. Every one of those is a gate you clear before any money changes hands. And note the register: this is a forecast, not a verified outcome.

In August 2025, MIT's *State of AI in Business 2025* report put an even harsher ratio on it: roughly 95 percent of enterprise GenAI pilots were producing no measurable P&L impact — and the report attributed the failures to integration and organizational factors, not to the models.

Put the two numbers side by side and they say exactly one thing: between proof of concept and contract there is a gap. Two leading institutions, back to back, delivered the same verdict. They are the industry's backdrop, not evidence for my one case — do not mix the two.

## The Four-Page Ledger: Bring This Sheet to Your Next Review

So the next time you review "why didn't it sign," do not let those four words — *the timing wasn't right* — pass the gate. Take one sheet of paper and draw four pages of ledger:

| Page | What it records | The state of most ledgers |
| --- | --- | --- |
| Page 1: the people willing to try | Who is using it, and how enthusiastically | Usually kept — possibly the prettiest page in the whole company |
| Page 2: the payment decision-maker | Who pays, and what they need to see before signing | Usually blank |
| Page 3: procurement conditions | Security, legal, data compliance, the budget window — which gate each one is stuck at | Usually never walked |
| Page 4: the actual deployment owner | After signing: who runs operations, who changes the process, who owns the errors | Usually never considered |

The usage rule follows from the judgment: whichever page is empty, go produce that page's evidence first. Page 1 full, page 2 empty — what is missing is not time; it is the trip to go book the payment decision-maker. Page 3 jammed at security review — what is missing is not patience; it is the act of scheduling procurement, security, and legal gate by gate.

The four-page ledger is not a repaired funnel. It is the tear itself, laid on the table: page 1 is usage evidence, pages 2 through 4 are buyer evidence — two kinds of evidence, two production processes, and often two different groups of people.

## When This Ledger Stops Working

The failure boundaries, stated first.

First, the user may simultaneously be the buyer. In a small team the boss uses the tool and approves the check; the four pages collapse into one, and forcing them apart is formalism. This piece is about splitting the ledgers, not about "users riding free" — the whole point of splitting is to make sure somebody picks up the paying.

Second, do not bend the four pages backward into a conversion dashboard. Stage and size are different animals; a percentage squeezed out of them means nothing. That is taping the torn funnel back together.

Third, every figure in this piece has a scope. "A year or more" is one guest's experience. The 30 percent and the 95 percent are an industry forecast and an industry estimate. All of it is somebody else's ledger — none of it is your company's forecasting baseline. Take these numbers to your boss as a promise, and the failure is mine, not the numbers'.

Fourth, the opening and closing scenes are composites — similar scenes I have run into across AI implementation work, stitched together for the telling. Experiential, and not to be mapped onto any specific company.

## Back to That Company

Back to the company from the opening. At the second-week review I put the four-page ledger up on the projector. The meeting lasted twenty minutes — page 1 was full to the margins; pages 2 through 4 were white.

Walking out, the department lead took "a matter of time" back, and replaced it with something more concrete: "This week I'm booking finance. And I'll get in line for the security review myself."

**"A matter of time" is what you say with the ledger closed. Open the ledger, and you finally know which door to knock on.**

---

Related reading: [FDE Is Not an Engineer, It's an Organizational Interface](/blog/human-in-the-loop-07-fde-is-organization-interface) covers who absorbs the deployment after signature — sometimes working alongside the client for a stretch beats shipping technology at them. [Why Your Org OS Can't Run AI](/blog/human-in-the-loop-02-why-org-os-cannot-run-ai) traces the absorption problem back to the organization, not the model. Pages 3 and 4 of the ledger are organization work, all the way down.

I'm Uncle J. Eighteen years in HR trained one reflex into me: when something stalls, stop asking *when* and start asking *who* — who pays, who signs, who absorbs the thing afterward. These days I run a one-person AI organization, where every tool has to earn its seat through the same four pages — pages 2 through 4 first, because page 1 fills itself.