Every exception arrives with a good reason. The customer is large, or early, or a name you want on your website. The request is small. Saying no would lose the deal. Saying yes costs an afternoon.
So you say yes, and then yes again to the next customer, for an equally good reason. A few years on, the company sells one offer and delivers another. The second one sets your costs.
The problem is timing. An exception is judged once, at the sale, against the revenue it brings. Its costs arrive later, land on other people and combine with every exception already agreed.
Priced once, paid monthly
Whoever approves an exception sees all of the benefit: a signed contract, a logo, a quarter that closes. They see almost none of the cost, because the cost is not yet work. It becomes work later, for someone else.
Consider a startup that monitors heart-failure patients at home. Patients get a connected scale and blood-pressure cuff. The hospital’s care team sees the readings on a dashboard and gets an alert when a patient starts to deteriorate. Three hospitals sign in the same year, each with one request.
The largest wants patient data kept on its own servers. The second wants its own alert rule: flag a patient after a two-kilogram weight gain in three days. The third wants the app and devices in its own branding. Each request is reasonable, each contract is worth having, and the startup agrees to all three.
On the day each is approved, none looks expensive. A second server. A settings change. A new logo.
Exceptions do not add up. They collide.
The cost appears when the exceptions meet. Every software release now ships to two places: the startup’s own cloud and the hospital’s servers, which run a version behind. The custom alert rule has to be tested again with each release, because in medical software an alert that silently stops firing is a patient-safety failure. The branded app is a separate app-store listing with its own review, and it has to work with both hosting set-ups.
No single request was costly. The expense is that each one must work with the others, and someone has to keep all of them in mind. Collisions grow faster than exceptions: three can clash in three pairs, ten in forty-five. Stephen Wilson and Andrei Perumal, who study complexity costs, argue that these costs rise non-linearly as variety grows (Wilson & Perumal, 2009). In the efficiency equation, that growth lands in one term.
Network complexity (N) sits in the denominator. Every exception adds a coordination path, and each new path must be reconciled with those already there.
The Entrepreneurial Efficiency Equation (η) · Dr. Hafiz Muhammad Ali
Mark Gottfredson and Keith Aspinall at Bain called the balance point the innovation fulcrum: the number of products at which customer satisfaction and operating complexity are in balance (Gottfredson & Aspinall, 2005). Exceptions push a company past it without anyone launching a product.
The customers you cannot see losing money on
The damage is hard to see because companies record revenue by customer and cost by department. The second server sits in infrastructure, the re-testing in quality assurance, the app listing in product. No report adds them back to the hospitals that caused them.
When someone does, the result is uncomfortable. Robert Kaplan and V. G. Narayanan describe the pattern known as the whale curve: the most profitable fifth of customers typically generate 150 to 300 per cent of total profits, and the least profitable give much of it back (Kaplan & Narayanan, 2001).
Benson Shapiro and his colleagues had already shown that customers with similar revenue can differ widely in what they cost to serve (Shapiro et al., 1987). Exceptions are one of the quieter ways a customer becomes expensive to serve.
Not every exception is a mistake
None of this is an argument for refusing customers. Early exceptions are often how a startup learns what its market needs. The custom alert rule may show that every heart-failure team wants to set its own thresholds. That is not a favour to one hospital. It is a better product.
Frances Frei’s research on service businesses offers a useful frame. Customers bring variability: in when they arrive, what they ask for, what they can do themselves, how much effort they make and what they prefer. A company can accommodate that variability or reduce it. Done crudely, accommodation raises costs and reduction lowers service. Done well, either protects both (Frei, 2006). The mistake is accommodating by default, at full cost, without noticing that a choice was made.
So the useful question is not whether to grant an exception. It is what the exception leaves behind: knowledge about the market, a capability other customers could use, or an obligation that exists for one customer and lasts as long as they do.
Standardise, price or narrow
Each of the three points to a different decision.
Standardise when the exception leaves knowledge or a capability. Make alert thresholds configurable, validate the feature once and offer it to every hospital. The exception has become product.
Price it when the exception leaves an obligation the customer will pay for. Hosting on a hospital’s own servers can become an enterprise tier, with a set-up fee and an annual charge that covers the second environment.
Narrow when the obligation is one the customer will not pay for. A hospital that needs a fully branded app may need a white-label supplier, not you. Referring it elsewhere feels like losing revenue. It is often the cheapest decision in the company, and it is what an ICP built as an elimination rule is for.
Skip the sort, and the exception decides for you. It stays unpriced, has no owner and never ends, until it becomes part of how the company works.
What will this exception leave behind?
-
Who will carry it after the contract is signed?
Name the person, not the team. If the answer is you, the exception also runs through the founder.
-
What does it leave behind: knowledge, a capability or an obligation?
If you cannot name the knowledge or the capability, assume it is an obligation.
-
What else will it have to work with?
List the exceptions it touches. Three can clash in three pairs. Ten can clash in forty-five.
-
Would you offer it to the next ten customers at this price?
If yes, it belongs in the standard offer. If no, it needs a price of its own, or a polite referral.
-
When does it end?
An exception with no end date is a product decision you have not made.
The business you actually run
Every company has two business models. One is written down: the offer, the price, the customer you mean to serve. The other is everything you have agreed to do. Early on, the gap is small. As you grow, the second takes over, and it sets your costs, your hiring and what your team has time to build.
Say yes as often as the market asks. Then make every yes a product, a price or a boundary.
References
- Frei, F. X. (2006). Breaking the trade-off between efficiency and service. Harvard Business Review, 84(11), 92–101.
- Gottfredson, M., & Aspinall, K. (2005). Innovation versus complexity: What is too much of a good thing? Harvard Business Review, 83(11), 62–71.
- Kaplan, R. S., & Narayanan, V. G. (2001). Measuring and managing customer profitability. Journal of Cost Management, 15(5), 5–15.
- Shapiro, B. P., Rangan, V. K., Moriarty, R. T., & Ross, E. B. (1987). Manage customers for profits (not just sales). Harvard Business Review, 65(5), 101–108.
- Wilson, S. A., & Perumal, A. (2009). Waging war on complexity costs: Reshape your cost structure, free up cash flows and boost productivity by attacking process, product and organizational complexity. McGraw-Hill.
