When an enterprise deal stalls in committee, the easy explanation is that there are too many people in the room.

You quoted $120K. The department head nodded. Then she pulled in IT, compliance, finance, and HR, and the deal went quiet.

Weeks passed, legal came in, procurement asked to see the pricing again.

The instinct here is to blame the committee - too many stakeholders, too long a cycle, enterprise sales cycles being what they are. Etc, etc.

But I'd push back on that. The committee is doing what buying committees always do; what isn't working is what you handed them to look at.

Because nobody in that room is evaluating your software as a whole, and they can't reasonably be expected to. There is no consensus number for what a piece of enterprise SaaS is worth. Two reasonable people looking at the same product can land on wildly different valuations, which means a committee is never going to agree on the whole deal.

So the committee does the only thing it can. It stops trying to judge the whole thing and starts judging the parts.

The CIO looks at what will land on the infrastructure budget. Compliance looks at what hits the compliance budget. Each of them asks the easier question: "is my slice fair?"

Except you didn't send slices. You sent one number.

Which means the CIO has nothing to evaluate, compliance has nothing to evaluate, and nobody can sign off on their part because there are no parts. The deal sits, and eventually the committee concludes that if they can't tell whether it's fair, the safest move is to slow it down.

The fix is to pre-split the deal for them.

• Core licence on the finance line, as a monthly fee they already recognise.
• Cloud and API is IT's number, priced in the units they buy infrastructure in.
• The compliance report belongs to compliance, sized against the reporting fees they already pay.
• Onsite training goes to HR at a per-day rate.

Same product, same customer, roughly the same money.

But now each stakeholder has a line item they can hold against a budget they already own. Each one signs their slice, the primary buyer sees four yesses around the table, and the deal moves.

I call this wallet structuring:

You are running the customer's internal budget negotiation on their behalf, before they have to run it themselves - which is where most enterprise deals go to stall.

Here is a real example of one: A client of mine sells claims-management software to insurers, priced per claim.

The deals kept capping at $180K a year, no matter the size of the insurer. The head of claims was the buyer, and his per-claim math only justified so much - once we hit that ceiling, the conversation stopped.

So, we restructured. The core price stayed with claims, but we peeled off the infrastructure, the regulatory reporting, and the training, and moved each to the department that owned that budget in-house.

Same product, same customer, effective price up more than 50%. Nobody churned, because no single budget owner was left carrying the whole bill.

Now, this isn't always completely straightforward. I've watched wallet structuring backfire in four fairly predictable ways:

1. ACV is too low. Below $25-50K a year the sale has to stay simple. Extra line items add friction the deal can't absorb.
2. The problem is single-budget. If only one department cares, and you can't make a straight-faced argument that anyone else in the organisation would recognise the cost, there is no second wallet to reach into.
3. It gets weird. If the line items feel invented, customers pick up on it and trust drops. If it feels awkward to explain, it will feel awkward to buy.
4. You have no pricing power to begin with. Wallet structuring collects value you have been giving away. It doesn't invent value that isn't there. If you're already priced at what the product is worth, extra line items just put you underwater.

Wallet structuring doesn't raise the value of your product. It stops you handing half of that value back.

Here is how you do it:

Pull your last five enterprise deals, won and lost. Note who sat in the buying committee and what the contract value was.

For each deal, identify the primary buyer - the stakeholder whose business problem your product solves, and whose unit economics justify buying it.

Then map the auxiliary budgets. Which 2-5 other stakeholders did the primary buyer pull into the room? What does each of them already own a budget for?

Restructure your pricing so each of those stakeholders has a line item that lands in a budget category they already manage, priced in the same units they use to buy that kind of thing from other vendors.

Sanity-check against the four fails above.

Test on new deals before you touch the existing base. If it lands, roll it wider. If it doesn't, drop it.

As promised: a point about pricing in your inbox, directly from me.

If you prefer video, here is a 4 minute walkthrough of the concept.

One Idea...

Cost proxies: price on what tracks the cost, not what causes it.

When you want a particular budget to cover a particular cost, you don't need a metric that causes the cost. You just need one that tracks it.

A trading-software provider had a large cost bucket it called "the platform" - the data centre, the cybersecurity, the compliance tooling. What drives that number up over time isn't trades, and it isn't assets under management. It's end clients, and this provider had about a million of them.

So we divided the bucket by a million, landed on roughly $12.50 per client per year, rounded it to $1 a month, and charged it per end client openly, as a cost-cover line.

The pitch is honest and it works: "We charge per end client because that's what drives our security and compliance costs. We don't make a margin on it."

You will never track 100% of your costs with 100% precision, and you don't need to. Get close enough to be useful, especially if you forecast costs at scale and price to hit a target margin as you grow.

Find the metric that tracks the cost. Causation is a bonus, not a requirement.

Spotify | Youtube | Apple

Willingness To Pay News

• The Fair Use Playbook is live. A full playbook for building fair-use into an AI product - how to set the caps, why you measure in cost rather than in actions, how to stage the response from a soft nudge to a hard stop, and a seven-step rollout you can run yourself. Download the playbook here.
• On video: when wallet structuring backfires (with examples.) A three-minute walkthrough of the four fails above, with real deals that hit each one. Watch on Youtube