# A price is simple until the customer qualifies for it. **Author:** Ivan Misic **Published:** 2026-08-30 **URL:** https://ivanmisic.net/blog/product/pricing-is-rules-not-a-number **In plain English** Start with who the offer is for: a new customer, an existing customer, or both. A guest may see a generic price, then qualify for a different offer after login or customer selection. Commercial owns that rule. Product and engineering must make any change clear and keep the accepted price consistent through checkout, billing, and any later touchpoint. The hardest price to keep true is the one shown before you know who the customer is. A physical product with one SKU, a full upfront price, and optional equal instalments is the easy case. The amount can be split, displayed, and checked without asking much else. Many services, contracts, bundles, and promotions are not this polite. A guest can browse the website, compare an offer, and leave without buying. They may return after login, call another channel, or continue in a store. If the price changes later without explanation, the customer has little reason to trust what they saw. The number is only the result. Commercial should already have decided who gets it and under which conditions. ## Start with who the offer is for The first pricing question is not “how much?” It is “for whom?” A useful commercial split is Greenfield and Brownfield. Greenfield covers a new customer or a new relationship. Brownfield covers an existing relationship where contracts, products, tenure, or retention rules may affect the offer. That is one axis. Acquisition and retention are another. The first describes the customer relationship; the second describes the commercial motion. They are related, but not interchangeable. That distinction becomes messy on an open website. An existing customer can arrive as a guest and look like a new one. They can select an acquisition offer, identify themselves later, and expect the business to recognise the relationship they already have. They may also be an existing customer buying a genuinely new service, so login alone does not answer which journey applies. Before shaping the screen, I would settle four decisions: 1. Is the offer for new customers, existing customers, or both? 2. At which point can the journey know the difference? 3. What happens to an offer selected before that context is known? 4. What must the customer see if the offer or price changes? Without those answers, “personalised pricing” is mostly a polite name for surprising the customer later. ## The dangerous moment is when context arrives Take a guest who selects a plan and a device. The page shows a generic acquisition price. During pre-sales, the visitor logs in or provides enough information for the business to identify the relationship. Several outcomes are possible. The customer may qualify for a retention benefit and see the price go down. A selected offer may be replaced by one with different contract terms. The price may go up because the original promotion does not apply to the identified customer. The offer may disappear completely. A lower price sounds harmless, but it still needs an explanation. Otherwise the customer cannot tell whether they received a benefit, changed the product, or triggered an error. An increase is harder. It cannot arrive as a silent recalculation after the customer has already invested time in the journey. The guest price can still be valid. But you need to say when it may change and explain the change once you know who the customer is. ## A price has context The same offer can have several valid prices. Customer, journey, channel, contract, campaign, and time decide which one applies. I describe the price with its context, not only the amount: - the product or offer being priced - whether the journey is acquisition, retention, or another transaction - the customer context known at that moment - the sales channel - the contract or commitment term - active campaign and discount rules - the time at which eligibility was evaluated - the tax and billing treatment
![Pricing decision diagram showing customer, channel, offer, and time converging into one price](/images/blog/product/price-qualification-context.png)
The number is the output of a pricing context. Change an input and the valid price may change with it.
Someone in commercial needs to own every price shown to the customer. That does not mean the amount can never change. It means any change is intended, explainable, and applied before the customer accepts it. ## Commercial owns the rules The team shaping the proposition decides who gets the offer, how long it lasts, which benefits can combine, and what happens when the customer's context changes. These are commercial decisions with financial consequences. Product turns them into journey behaviour and acceptance criteria. Engineering builds the rule evaluation, passes the context, preserves the decision, and connects the systems that fulfil it. Neither product nor the backend should invent commercial policy because a rule was missing. I would not let an offer go live until the commercial owner can answer this table: | Question | Example decision | |---|---| | Who is the offer for? | new customers, existing customers, or both | | Can benefits combine? | campaign and relationship benefit may stack | | Which applies first? | fixed adjustment before percentage discount | | What takes priority? | an existing contract rule overrides a general acquisition campaign | | What happens after identification? | keep, replace, reprice, or withdraw the selected offer | | What happens on cancellation? | remove or recalculate a dependent bundle benefit | Engineering will build something either way. The question is whether it builds an agreed rule or has to guess. ## Show how long the price lasts A discounted price without a duration is incomplete. “€19.99 per month” can mean the ongoing charge, the first invoice, a promotional period, or an average constructed for comparison. Customers should not need to open the terms to discover that it becomes €34.99 after six months. For recurring services, the offer should answer three things near the price: - What will I pay now? - What will I pay regularly? - When and why can that amount change? The copy can stay short, but the data still needs start and end dates, recurring and one-time components, and the price after a temporary benefit ends. A single `amount` field cannot carry that meaning. This matters when several products are bundled. The total may look clear while the future price of each component is hidden. Cancellation, renewal, or a later plan change then exposes a rule the customer never saw. ## Keep the price true across the journey A truthful price is not always an identical number. New information can change eligibility. But every touchpoint should use the same commercial rule and explain the same result for the same context. That includes the product card, comparison page, basket, checkout, order confirmation, and bill. It also includes a handover from the website to an assisted channel. If the next touchpoint cannot recover the offer, context, and conditions the customer saw, it may calculate a different answer and ask the customer to start again. The system behind the price must carry enough information to say what was offered, to whom, under which conditions, and when. The customer does not need that full model on screen. The business does. ## Preserve the decision after acceptance Recalculating from the current catalogue at every step looks clean on a diagram. It can also change a price halfway through checkout when a campaign expires, the catalogue changes, or a customer attribute arrives late. The order needs to keep the price the customer accepted, together with the rules that produced it. Billing can still validate the order, but it should not have to guess what was promised from a product code and a total. I would keep one offer and one price decision in the integration layer. The adapters translate that into whatever the older billing and order systems expect. I described that pattern in [Build the API layer before replacing the billing system](/blog/digital-transformation/dont-replace-billing-system). The layer preserves the commercial decision. It does not invent a new one. ## Test transitions, not only amounts “Ten percent off 30 equals 27” proves arithmetic. It says little about the product behaviour. The useful tests follow the moments when context changes: - a guest who remains a new customer keeps the valid acquisition offer - an existing customer who identifies later moves to the correct retention or relationship offer - a lower price is explained as a benefit, not shown as a random cart change - a higher price requires a clear reason and renewed confirmation - an ineligible customer receives the agreed fallback without a leaked campaign message - a web-to-assisted handover produces the same answer for the same context - a price accepted before a campaign or catalogue change survives order completion - support can retrieve the components that produced the billed amount If a test can assert only the final number, the model is too thin. ## The number is the last step Start with who the offer is for. Decide what happens when a guest becomes a known customer. Give commercial ownership of the rule, then make product and engineering carry that decision across the journey. `19.99` can stay simple on screen. It should never be simple behind it.