Plain-Language Pricing
A research inquiry into how service businesses explain what they charge, and whether a clearer explanation changes the conversation with customers.
Self-initiated example — not a client engagement.
Case 03 / 04
The artifact
A price reads as plain the moment its rule, its adjustment and its exception are all stated in the same place.
Inputs
- Scope
- Unit
- Customer type
- Cost / constraint
- Exception
Pricing logic
- Base rate follows the unit.
- Price adjusts by customer type.
- Price never drops below cost or the stated constraint.
- Exceptions need a named approver.
Quote language
For [scope], billed by [unit], the price follows the standard rate for [customer type] — adjusted only where a named approver signs off on an exception.
The structure starts with what actually varies: scope, unit, customer type, cost or constraint, and any named exception.
The base rate follows the unit, and price adjusts by customer type — the same two rules every time, not a fresh negotiation.
Price never drops below cost or the stated constraint, and any exception needs a named approver, so nothing is quietly discounted.
Those same rules generate the sentence a customer actually reads — plain language, no invented number.
What changes operationally
BeforeThe pricing page is technically complete and practically unreadable.
AfterThe first page someone reads states, in plain language, roughly what they would pay and why.
BeforeThe real pricing conversation moves to a later email thread.
AfterThe pricing conversation happens upfront, in the first message.
BeforeAn exception is buried in a footnote.
AfterAn exception is a named, visible rule, not a footnote.
Context and question
Service pricing is often written to protect the business from every edge case at once — tiers, add-ons, footnotes, “contact us for a quote” — rather than to answer the one question a prospective customer actually has: roughly what will this cost me, and why. The result is a pricing page that is technically complete and practically unreadable, which does not remove the hard pricing conversation, it only delays it to an email thread later, usually after both sides have already spent time on a call. The question here is narrower than “simplify your pricing”: what does a genuinely plain-language explanation of price look like for a service business, and does it change that later conversation at all.
Approach
The approach starts from real pricing pages and proposals, read the way an actual prospective customer would read them — cold, without the context the business has in its own head. Where the plain-language test comes back no, the gap between the actual pricing logic and its written explanation is the thing worth studying, not the pricing itself.
