Cost to Serve: Why Two Identical Customers Earn You Different Money
Client and segment profitability is the question every business has and almost none can answer.
Summary
- Two customers paying the same price can cost very different amounts to serve. Implementation, support, customer success, custom work and slow payment vary by account, not by plan.
- A cost to serve analysis needs four or five cost pools, one driver and one rate per pool, and a count of activity per customer. Revenue minus direct delivery cost minus cost to serve is contribution per customer.
- Ranked, customers almost always form a whale curve: a few earn most of the profit and a minority lose money, often including large, prized accounts.
- Fix a loss-making customer by changing how they consume, charging for what costs, moving them to another tier or raising the price. Exit comes last.
Two accounts on the same SaaS plan. Both paying ₹18 lakh a year. Both on the same contract.
Account A onboarded themselves in a fortnight, raises four support tickets a year, uses standard integrations, and pays by standing instruction on the due date.
Account B took nine weeks of implementation with two of your engineers. It has a weekly call with customer success and requested three custom integrations. It raises around forty tickets a year, insists on a quarterly business review with a deck, and pays in 80 days.
Your revenue report says these two are identical. They are not close.
Put rough numbers on what each one consumes. The rates are the ones in our worked margin example. They are ₹550 a support ticket, a customer success manager at ₹18 lakh loaded, money at 14% a year, and implementation spread over a three-year customer life. Four assumptions are added here. An engineer costs ₹50,000 a week loaded (₹26 lakh a year). Direct delivery is a quarter of the price for both accounts. B's weekly call and four review decks take about a tenth of one manager's year against a fiftieth for A. And A pays on the invoice date, so all 80 of B's days are extra.
Two accounts at the same price, costed by what each one consumes
| ₹ per year | Account A | Account B |
|---|---|---|
| Price | 18,00,000 | 18,00,000 |
| Direct delivery cost (25% of price) | (4,50,000) | (4,50,000) |
| Implementation: 2 engineers × 9 weeks × ₹50,000 = ₹9,00,000, over 3 years | 0 | (3,00,000) |
| Support: 4 and 40 tickets × ₹550 | (2,200) | (22,000) |
| Customer success: 0.02 and 0.10 of ₹18,00,000 | (36,000) | (1,80,000) |
| Financing: B pays 80 days later than A; ₹18,00,000 × 14% × 80 ÷ 365 | 0 | (55,233) |
| Contribution | 13,11,800 | 7,92,767 |
| Contribution as % of price | 72.9% | 44.0% |
Spread over three years, Account B earns about 60% of what Account A does: ₹7,92,767 against ₹13,11,800. In the year the implementation actually happens, all ₹9,00,000 of it lands at once. That year, B's contribution falls to ₹1,92,767 (₹13,50,000 − ₹9,00,000 − ₹22,000 − ₹1,80,000 − ₹55,233), under a sixth of A's. The upkeep of three custom integrations is not even in these numbers.
Customer profitability is the question, not a side question
For a manufacturer, product cost is the dominant question. What does this part cost to make.
For almost every other business, from software and services to healthcare, diagnostics, D2C and distribution, the dominant question is which client, account, payer or channel actually makes money. Product or unit cost is one input to that, not the answer.
That matters because most costing effort goes into the wrong half. Companies build detailed unit costs and then apply a single average service cost to every customer, which guarantees that the variation, which is where the money is, stays invisible.
What drives cost to serve in each kind of business
The principle is identical everywhere. The activities differ.
What drives cost to serve, by business
| Business | What actually drives cost to serve |
|---|---|
| SaaS | Implementation and onboarding effort, support tickets, customer success hours, custom work, compute and storage consumed, payment behaviour |
| IT / tech services | Scope creep, revision rounds, client-side delay and rework, governance meetings, travel, seniority demanded, invoice disputes |
| Hospitals | Payer mix, claim submission and resubmission effort, disallowance rate, length of stay, documentation burden, credit period |
| Diagnostics | Sample collection logistics, turnaround demands, report customisation, B2B credit period, repeat testing |
| D2C / ecommerce | Returns and rto, cod handling, delivery drops, support contacts, acquisition channel cost, coupon stacking |
| Manufacturing / distribution | Order frequency, part loads, delivery drops, custom packaging, order amendments, payment behaviour |
| Pharma | Tender administration, cold chain, market-specific regulatory variation, distributor schemes |
Read your own row and you will probably recognise two or three items you have never costed by customer. These are the activities that cause the cost. Which basis to spread a shared cost on is a separate choice, set out in cost apportionment.
Six steps to contribution per customer
You do not need a costing system. You need an afternoon and a willingness to estimate.
- Take the pools. Total annual cost of the service activities. For SaaS that is implementation, support, customer success, and attributable infrastructure. For services it is delivery management, governance and rework. For a hospital it is billing, claims and documentation effort. Four or five numbers from your P&L.
- Pick a driver for each. Support cost per ticket. Customer success cost per hour. Implementation cost per project. Claims cost per claim submitted. Logistics cost per drop.
- Divide to get a rate. Total support cost ÷ total tickets = cost per ticket. Crude. Useful.
- Count the activity per customer. How many tickets, hours, claims, drops, amendments. Most of this already sits in your systems (a helpdesk, a timesheet, a claims log), and nobody has ever summed it by customer.
- Multiply and subtract. Revenue − direct delivery cost − cost to serve = contribution per customer.
- Rank them, low to high.
The whale curve, and who sits at the bottom of it
Almost always the same shape.
A small group produces most of the profit. A long tail produces very little. And a meaningful group actively loses money.
Kaplan and Cooper described this as the whale curve. Plot cumulative profit against customers ranked by profitability and it climbs well above 100%, then falls back as the loss-makers drag it down. In Kaplan's often-quoted version, roughly the least profitable tenth of customers lose money; other studies put the share higher. Treat 10% to 25% as a typical range, not a measurement of ours or a prediction of yours.
The uncomfortable part is who sits in the losing group. Taken as a segment, small accounts are often the worst on average. An SMB customer commonly raises five to ten times the tickets of a larger one, at a lower price. But the single biggest loss-makers are frequently large, visible clients everybody is proud of. They were won on a deep discount and are serviced generously to keep them happy. They pay slowly because they can, and consume support out of all proportion.
Nobody has ever added it up, because adding it up means saying something awkward about an important relationship. Ranking customers on contribution is also the first cut of an ABC analysis, which turns the ranking into a policy for each class.
Four fixes for a loss-making customer, then exit
Four options come first, and exit comes after all of them.
- Change how they consume. Minimum order quantity. Consolidated delivery. Support through a defined channel rather than direct lines to engineers. Quarterly reviews instead of weekly. The pattern is often negotiable, because nobody has ever asked.
- Charge for what costs. Implementation as a fee rather than a giveaway. Premium support as a paid tier. Delivery below a threshold. Payment terms priced rather than conceded. If a client values a weekly call, a weekly call can be part of a higher tier.
- Move them to a different channel or tier. A high-touch account at a low value belongs on self-serve, through a partner, or on a standard package rather than a managed one.
- Raise the price. Legitimate, and the hardest conversation, but much easier when you can show the service pattern rather than just asserting that costs have risen.
Most of the cost is in the pattern, not the customer.
Then, and only then, exit. Sometimes right, particularly where an account is both unprofitable and difficult. Fifth option, not first.
Two cautions before acting on the ranking
Idle capacity changes the answer, within limits. A client who contributes little but fills capacity you would otherwise leave idle is not the same as one displacing a better client. Keeping them is fine provided they cover their variable cost to serve: the delivery, support, success time and financing they actually consume. Below that line they are not filling capacity, they are paying you to lose money on it. There is a second cost too. The low price becomes that account's anchor, and filling a calendar at a loss hides a demand problem instead of solving it. So ask whether the alternative is a better customer or an empty seat, and whether this customer covers what they consume.
Don't over-build it. Five pools and five drivers gets you most of the way. Thirty activities traced precisely gets you abandoned in month three. The point is to find the outliers, not to produce a perfect number for every account.
Cost to serve makes the pricing floor segment-specific
This is why cost to serve sits in the pricing practice rather than in operations. A floor built on delivery cost alone puts two customers at the same price on the same side of it when they may sit on opposite sides. The floor in the margin piece only works once cost to serve is in it, segment by segment. And a request for 12% off from an account already consuming twice the average service is a very different conversation when you can say so with a number.
Start with your ten largest customers by revenue. Count their tickets, hours, claims or drops for the last twelve months. Put that next to what they pay you. One afternoon, and you will almost certainly find a surprise in the top ten.
To see where cost to serve sits among your other pricing gaps, take the Pricing Maturity Assessment.
Frequently asked questions
What is a cost to serve analysis?
It works out what each customer, account, payer or channel costs you beyond the product itself. That covers onboarding, support, account management, custom work, delivery and the cost of waiting to be paid. Subtract that and the direct delivery cost from revenue and you have contribution per customer, which can then be ranked.
How is customer profitability analysis different from gross margin by customer?
Gross margin by customer subtracts only the direct cost of delivery, which is usually similar across customers on the same plan. Customer profitability analysis adds the cost to serve, which is where customers differ most, so it is the version that separates the accounts that pay from the ones that cost.
What does a whale curve show?
Cumulative profit plotted against customers ranked from most to least profitable. It rises above 100% of total profit as the best customers are added, then falls back to 100% as the loss-making ones are counted. The height of the hump above 100% is the profit the loss-makers are giving away.
Should a business drop customers that lose money?
Not first. Changing how they consume, charging for the costly parts, moving them to a lighter tier and raising the price all come before exit. Check capacity as well: a customer filling otherwise idle time may be worth keeping, provided they cover their variable cost to serve.
How useful was this article?
One tap. It tells us what to write more of.
About the author
SRF Capital Studio
The next one
Get what we publish next, by email.
Working notes on raising, borrowing, protecting, growing and structuring capital in India. One email a week at most, and you can leave any time.
We use your address only to send this. See our privacy policy.
We store your address to send you these emails and nothing else. See our privacy policy.
Related reading
