Count support cost per sale instead of overhead

Support belongs in the cost of sale. Booked as one general overhead line, all the business ever sees is a single number that gets bigger every year, and nobody can say whether the money is well spent or what’s driving it. Put support against each sale instead and you get a number that actually means something: the support cost per sale.

As overhead, a founder or a CFO sees a cost and that’s it. It isn’t linked to the scale of the need, meaning how much you actually sold, or to the upstream costs that create the contacts in the first place, like an unclear instruction or a page nobody can find. So the only lever anyone can see is the cost itself, and the only question anyone asks is how to make it smaller. The real value is in bringing down the cost per sale and the number of requests per item sold, and that starts with how support is booked.

Booked as overhead, support is a cost nobody can explain

The problem with overhead is more what people think they see. A line in the accounts, a bit bigger than last year, with no link to how much was sold or what caused the contacts. When that line grows, it looks like support got more expensive. Maybe it did. Or maybe you sold twice as many units and support held up perfectly well. Overhead can’t tell you which.

So book it as a cost of sale. Take the total cost of delivering support and divide it by the number of items sold over the same period. That’s your support cost per sale.

Then track a second number next to it, tickets per item sold. Same sales figure underneath, but this time you’re dividing the number of tickets handled.

I’d keep the two apart, because they answer different questions. Cost per sale shows what support really costs the business for each thing you sell, and because it moves with sales it stops sitting there as a lump. Tickets per item sold is about the product. It shows how much need the product is creating.

They’re connected, and that’s the useful part. As you invest in improvements and the tickets per sale come down, the support cost per sale comes down with them. Support now has a number the CFO can read like any other cost of sale, and a way to improve it that doesn’t start with cutting people.

This sits next to the two measures I care about most, total case time and experienced quality. It doesn’t replace them. Those tell you how the customer got on, and this one tells the business what that cost.

Support cost per sale should fall as you grow even while the total rises

As volume grows, the total will climb. That’s fine. More customers means more people who’ll need help at some point, and nobody sensible expects support to cost the same at ten times the size. What should happen is that the support cost per sale comes down.

The difference is in where the support leader spends their time. At ten times the volume I’d expect them to be working much more on the proactive side, looking for areas to improve and invest in, and much less on firefighting. If a team at that size is still mostly reactive, it means not enough was invested earlier, and every week spent putting out the same fires is a week nobody’s working on stopping them.

That’s also where the number creeps back up. The queue grows, more people get added to keep up, and the improvement work slides to next quarter because everyone’s busy. The headcount grows to fit the friction, and the cost per sale goes up with it. Support tends to get worse as companies grow because of structure and cost control, not because anyone cares less, and this is one of the ways it happens.

A falling number only counts if the customer still feels looked after, though. You can push support cost per sale down very quickly by making it hard to get in touch, and it’ll look great in a spreadsheet.

So watch the online comments, the reviews and the CSAT score alongside it. If those start to drop while cost per sale falls, the team is being pushed too hard and the improvements aren’t real. People still need help, they’ve just stopped bothering to ask.

The most common contacts are often about how the product is used

Once you’ve got tickets per item sold as a number, the next question is which tickets to go after first. I’d start with the most common ones, and I’d look at them expecting to find something other than a fault.

I’d expect a good share of the biggest contact reasons to have nothing to do with the product failing. They’ll be a use problem, or an understanding problem. The customer didn’t know a setting existed, or read an instruction one way when it meant another, or couldn’t find the answer on the website and picked up the phone. Each of those is a real ticket with a real cost, and the product is doing exactly what it was designed to do.

So the question for each one is how we stop them needing to come in. Maybe better information at the moment they need it. Maybe a new instruction. Maybe a better website. None of that sits in support’s budget, which is part of why it doesn’t get done while support is booked as overhead. Using support data to find the causes is the first half of the job, and the support cost per sale is what gets someone to pay for the second half.

Only then would I bring in automation and AI for the general, repetitive questions. That lets you handle them well and cheaply until they can be designed out, but it won’t design them out for you. If a bot is answering the same question all day, every day, the bot is doing a fine job and the page is still broken.

So let AI take the pressure off the repetitive end of the queue. Just don’t expect it to tell you why the question keeps coming in, or to rewrite the instruction. Somebody has to.

On an ordinary day that’s fairly plain. An agent answers the same question for the fifth time before lunch and flags it, someone checks the volume, and whoever owns the page owns the fix. Then you measure that contact reason before and after. If the number doesn’t drop, the fix didn’t go deep enough.

Other teams act when you show them what carrying on will cost

The fix usually sits outside support, with product, web or sales. They have their own priorities, and a support leader saying customers are confused doesn’t move many roadmaps.

Numbers do. Support can build a clean and simple business case from its own data. Pull the ticket numbers for the issue. This is how many tickets we had for it, this is our prediction going forward if nothing changes, and this is what we can save if it’s fixed. In cost per sale terms, that’s a conversation a CFO already knows how to have.

When the other team says no, or not this quarter, don’t argue about their priorities. Show them what it will cost if we carry on, and ask whether they’re willing to take that cost. Sometimes they are, and that’s a fair decision. At least now somebody has made it with the numbers in front of them.

It gets sharper when an unusable unit costs the customer money every day, like a rental fleet, a car-sharing service or construction equipment. I’d still count support as a cost of sale, but I’d add the downtime cost on top. That can be a real number you know you aren’t earning from the vehicle while it’s standing still. Or it can include the cost of the person affected by the downtime, the one who can’t do their job until it’s sorted. Either way the ticket is the smaller part of what the problem costs, and the business case gets a lot easier to make.

If support is run by an outsourced support provider, the pricing has to point the same way. Paying per ticket with nothing else in the terms means the provider earns more the more tickets come in, which is the opposite of what you want. It can be as easy as this: if you bring the number of support tickets down by X, we’ll increase what we pay you per ticket by Y. Now it’s in their favour to bring tickets down, and a good support partner will start pressuring you to make the improvements, because they get paid when you do. That’s what I mean by ownership with consequence going both ways, and the commercial terms are where it has to be written.

This week, pull last quarter’s tickets for your single most common contact. Work out what they cost and divide that by items sold. Then write down, in one line, what it will cost to carry on as is. Take that line to whoever owns the fix.