The Pricing Model Is the First Sales Conversation
Most enterprise software companies think of pricing as a packaging problem. They build tiers, bundle features, and publish a per-unit cost on their website. Then they hand that rate card to a sales team and wonder why deals come in small.
The problem is not the price. The problem is the frame. When you sell by the transaction, the seat, or the unit, you are training the buyer to ask one question: "How few of these can I get away with buying?" That question becomes the anchor for every negotiation that follows. And every negotiation that follows will be smaller than it should be.
What Happens When the Buyer Controls the Scope
Consider a scenario we see often. A healthcare technology company sells a compliance and data management platform. The product is priced per transaction. A large payer organization comes in and says, "We need to process about 50,000 transactions a month." The rep does the math, quotes $200,000 annually, and the deal closes.
Everyone celebrates. But here is what actually happened: the buyer described their current pain in the narrowest possible terms. They named the volume they could see from their desk. They did not account for the five other departments that handle the same data in parallel. They did not think about the compliance exposure they are carrying on manual processes. They did not model what their transaction volume looks like at the end of a growth year, not just the beginning.
The rep never asked those questions because the pricing model did not require it. The pricing model said: tell me how many, and I will tell you how much. That is a vending machine, not a sales process.
The Real Deal Was Twenty Times Larger
In one engagement we led, we worked with a company facing exactly this dynamic. The initial deal was $200,000. After we rebuilt the discovery process and restructured how the sales team framed the conversation, the deal expanded to $4.2 million. Same buyer. Same product. Different conversation.
What changed? The sales team stopped leading with "how many transactions do you need?" and started leading with "what does full operational readiness look like for your compliance infrastructure?" That question forced the buyer to think about the problem across their entire organization, not just the one team that raised the flag.
Why Sellers Default to Unit Pricing
There are three reasons sellers default to transaction-based conversations, and all three are fixable.
- It feels safe. Quoting a per-unit price removes ambiguity. The rep can do the math on a napkin. But safety for the rep is not the same as value for the buyer or revenue for the company.
- It mirrors how the buyer asks. Buyers almost always frame their need in unit terms because that is the easiest way to describe immediate pain. A good seller recognizes that frame and expands it. A mediocre seller accepts it.
- The pricing model incentivizes it. If your rate card only shows per-unit costs, your sellers will only have per-unit conversations. The pricing model is the first sales playbook your team reads every morning.
How to Reframe the Pricing Conversation
If you want larger enterprise deals, you need to change the question the seller asks before the buyer ever sees a number. Here is a practical framework:
1. Start With the Operational Map, Not the Order Form
Before any pricing discussion, the seller should map the buyer's operational footprint for the problem the product solves. Who touches this workflow? How many departments are affected? What happens when this process fails? The goal is to help the buyer see the full surface area of their need, not just the part that hurts today.
2. Quantify the Downstream Cost of Under-Buying
Buyers under-buy because they do not see the cost of doing so. Help them see it. What does it cost when transactions are processed manually in Department B because they were not included in the original scope? What is the compliance risk of running two parallel systems? Put a dollar figure on the gap between "what you asked for" and "what you actually need."
3. Present Pricing as Operational Readiness, Not Unit Cost
Instead of "here is the per-transaction rate," say: "Here is what full operational coverage looks like for your organization. Here is the investment required to eliminate this category of risk entirely." This is not about inflating the deal. It is about being honest with the buyer about what the real scope of the problem is.
4. Build the Business Case Before the Proposal
The proposal should never be the first time the buyer sees a large number. If you have done discovery correctly, the buyer has already built the business case in their own mind. The proposal just confirms what they already know. If the number in the proposal surprises the buyer, you skipped a step.
The Structural Fix
This is not a training problem. It is a structural one. If your pricing model leads with units, your sellers will lead with units. If your discovery framework does not require the seller to map operational scope before quoting, they will not do it. The fix is not a workshop. The fix is rebuilding the conversation architecture so that the right questions get asked before the pricing discussion begins.
Transaction pricing is not inherently wrong. But when it becomes the opening frame for an enterprise sale, it shrinks the deal before the deal even starts. The companies that win large enterprise contracts are the ones that help the buyer understand the full scope of their problem before they ever see a number.
Jeff Aragon, Founder — Jozu Consulting Group