Understanding pricing architecture questions properly as of 2027

Some pricing questions get argued in every company, at length, without resolving, because the argument is not really about the thing being discussed. Each question below is one of those. For each: what is actually being disputed, what decides it, and the cheapest way to settle it so that the argument stops recurring.

None of these have a universally right answer. All of them have a wrong way to be settled, which is by whoever is most senior in the room that day.

What to take away

• Most pricing arguments are two people optimizing different constraints. Name the constraints and the argument becomes a decision.
• Agreeing what would settle a question is easier than agreeing the answer, and it ends the argument permanently.
• Every answer here belongs in a written rule applied to everyone, not a judgment made per deal.

Questions about what you tell the market

Should we publish our prices?

The real dispute is about who you want to arrive. Published prices filter buyers before they reach you, which saves everyone time and removes your ability to read the room. Unpublished prices keep flexibility and cost you every buyer who needed a number to justify a meeting internally.

What decides it: whether your price varies for reasons a buyer would accept. If two similar customers pay materially different amounts for reasons you would not want to explain, publishing will force a conversation you are not ready for. The honest first step is fixing the spread rather than deciding the policy.

Settle it cheaply by publishing the structure without the number: what you charge for, how it scales, what is included at each level. Most of the benefit of publishing is comprehension, not the figure.

Should the price differ by segment or region?

The dispute is usually framed as fairness and is actually about leakage. Differential pricing works where the segments cannot easily buy from each other and where you can explain the difference in a sentence a customer would accept.

What decides it: whether prices leak. Inside one industry, one procurement network, or any market where the same consultants advise everybody, they leak. Settle it by asking what happens when the two prices meet in one conversation.

If you have no answer, you have your answer. Where the buyers compete with one another there is a legal dimension as well, set out in the federal price discrimination provision, and it is worth reading with a lawyer before a differential is published.

Questions about what goes on the invoice

Should onboarding or implementation be charged separately?

The dispute is between winning the deal and funding the work. Free onboarding is a discount whose size is unknown at the point it is granted, which is why it tends to be granted freely.

What decides it: whether the work varies materially by customer. If it is broadly the same for everyone, folding it into the recurring charge is simpler and honest.

Where it varies, a separate charge protects you from customers who need the most and pay the same as those who need the least. That is the logic behind service models.

Settle it by measuring what a handful of onboardings actually consumed in people and time. That is an afternoon of work and it ends the argument, because everyone is arguing from an impression until somebody counts.

Should support be its own line?

The dispute is about who your customer thinks they are paying. A separate support charge makes the value explicit and makes cutting it an option the customer can see. Bundled support is invisible and cannot be declined, which is usually what you want, and it means heavy users are funded by light ones.

What decides it: whether support demand tracks account size. If a small account can generate as much support as a large one, separating it is the only way the structure can reflect what it costs you to serve, and that cost is worked out in unit economics.

A customer wants a metric of their own. Do we agree?

Almost always the answer should be no, and the reason is operational rather than commercial. A custom metric means a billing configuration nobody else has, a reconciliation nobody else needs, and a dispute nobody else's records can settle.

If you do agree, the conditions are: it can be recorded automatically, it appears in the same reports as everything else, and it has an end date. A metric nobody else uses is also a definition nobody else can check, which is the trap described in business model types metrics.

Questions about time

How large should the discount for annual prepayment be?

The dispute looks like arithmetic but is a question about what you are buying. Prepayment buys two separate things: cash now, and certainty for a year.

Decide which one you actually need, because the trade is different. If you need cash, you are effectively borrowing from your customer, so compare with your other sources of finance, exactly as taught in MIT's entrepreneurial finance course; if you need certainty, you are paying for a forecast.

Settle it with a written rule that says what the discount is exchanged for, and apply it to everyone. A discount that is bought buys something specific; a discount that is given teaches every subsequent buyer that waiting is profitable.

What do we do when a customer's usage collapses?

The dispute is between the contract and the relationship. The contract usually says they owe you the commitment. The relationship says an invoice for unused capacity will be remembered at renewal.

What decides it: why usage fell. A customer whose own business shrank differs from one who found your product unhelpful; only the second warns about your model.

Settle it in advance with a written policy on what may be renegotiated mid-term and what may not, since deciding per account under pressure makes precedents you did not choose.

Do we raise prices for existing customers or only for new ones?

The dispute is between fairness and risk. Holding existing customers indefinitely creates a book where your oldest and often largest accounts pay the least, and that gap widens on its own.

What decides it: what your contracts allow and how much of the book is protected. Find that out first. A policy that half your agreements forbid is not a policy.

Then choose a rule and write it down, including how long protection lasts. Expect the result to be hard to read afterwards, because your mix will have moved at the same time.

When an argument will not settle

Two moves work when a pricing debate has run for weeks.

Name the decision rule instead of the decision. People who cannot agree on an answer can often agree on what would decide it. Write that down, go and find it, and the argument ends when the evidence arrives rather than when someone gets tired.

Ask which constraint is binding. Most pricing disagreements are two people optimizing different constraints: one is protecting cash, the other is protecting win rate. Neither is wrong and neither can win by argument. Deciding which constraint is currently binding is a management decision, and it is a different conversation from the price. Which constraints apply to you at all follows from how the money arrives, which is set out in the revenue models overview.

Common questions

Who should own pricing?

One person with the authority to refuse a discount, supported by someone from delivery who knows what an account costs to serve. Committees produce structures that satisfy committees.

How often should any of this be reopened?

When something structural moves: a new segment, a new intermediary, a cost you cannot control any more. Calendar reviews mostly produce changes nobody needed.

Should any answers be public?

The change rule and the scaling behavior, yes. Buyers who cannot find them assume the worst case, and they are not wrong to.

Where do these answers belong?

In one dated document with an owner, so that whoever answers a customer is reading rather than improvising. The layers underneath all of it are in the pricing architecture overview.