How to tell the difference between a support service that protects your business and one that profits from your problems.
There is a version of tech support that most businesses have experienced and nobody enjoys. You hit a problem. You raise a ticket. Someone you’ve never spoken to replies with a generic answer 48 hours later. The problem might get solved, it might not. Either way, the ticket is closed, the hours are logged, and at the end of the month you get an invoice that tells you how much support you used but nothing about why you needed it.
This is how most technical support works. It is reactive, anonymous, and transactional. And for the consultant providing it, there is very little incentive to make the problems go away — because the problems are what generate the revenue.
That might sound cynical. It isn’t. It’s a structural issue with how tech support is typically sold, and understanding it is the first step to demanding something better.
The business model you’re not supposed to notice
Most technical support contracts are sold on time. You buy a block of hours. Your team uses them when issues arise. When the hours run out, you buy more. The consultant reports how many hours were used and on what, and the implicit message is: your team has a lot of problems, you clearly need this support.
On the surface this looks reasonable. Underneath, it creates a dynamic where the consultant benefits from your problems persisting. Not necessarily deliberately — but structurally. If the same types of issues keep coming back month after month, the consultant gets paid month after month. There is no commercial pressure to investigate why those issues keep recurring and address the root cause. In fact, doing so would reduce the billable hours.
Some consultants go further. They use tech support time and statistics as leverage to sell additional services. The conversation sounds like this: “Look how much support your team is using — you clearly need a wider implementation programme, more training, a system overhaul.” The support data becomes a sales tool, not a diagnostic tool. And the business paying for it has no way to evaluate whether the volume of support reflects genuine complexity or problems that should have been fixed months ago.
This is not universal. There are excellent support providers who operate with integrity. But if you have never questioned the structure of your tech support arrangement, it is worth asking: is my consultant solving problems, or maintaining them?
What good tech support actually looks like
The purpose of technical support is to keep a business operating smoothly. That sounds obvious, but it has an important implication that most support models ignore: if the support is working, you should need less of it over time, not more.
Every technical environment — whether it’s design software, project management systems, information management platforms, or anything else — generates issues. That’s normal. Teams hit problems, workflows break, things don’t behave the way they’re supposed to. The question is what happens after the issue is resolved.
In a reactive support model, the answer is: nothing. The ticket is closed. The problem is addressed in isolation. If the same problem comes back next week for a different team member, it generates a new ticket and new billable time. The pattern is never examined because examining it isn’t part of the service.
In a proactive support model, every issue is resolved — but it’s also recorded, categorised, and monitored. Over time, patterns emerge. And those patterns are where the real value lives.
The normal distribution principle
Here is something that anyone who has provided technical support long enough comes to recognise: the majority of issues cluster around a small number of topics.
It looks random from the inside. Every day brings a different question, a different error, a different team member stuck on something. But when you step back and look at the data across weeks and months, the distribution is remarkably consistent. Out of all the issues raised, a significant majority will trace back to a handful of underlying causes — a misconfigured template, a gap in training on a specific workflow, a standard that wasn’t properly established at project setup, a process that the team adapted around rather than doing correctly.
This is a normal distribution. It means that if you fix the three or four root causes generating most of the support requests, the overall volume of support drops significantly. Not to zero — there will always be genuine one-off issues, edge cases, things that couldn’t have been anticipated. But the recurring problems, the ones that generate the bulk of the hours and the bulk of the cost, can be eliminated.
A consultant who operates this way will actively work to reduce your support bill. They will identify the clusters, propose fixes to the underlying issues — whether that’s a configuration change, targeted training, a process adjustment — and then monitor whether the fix worked. If it did, the support volume for that issue type drops, your costs go down, and your team operates more efficiently.
A consultant who doesn’t operate this way will simply keep answering the tickets.
Transparency is not optional
One of the simplest tests of whether your tech support is serving you or serving your consultant is this: can you see exactly what the support time is being spent on?
Not in a vague monthly summary. In detail. What issues were raised. How long each one took. What category they fall into. Whether this week’s issues are the same as last week’s or different. Whether the overall trend is going up, down, or staying flat.
This transparency matters for two reasons. First, it allows you to make informed decisions about your own business. If you can see that 60% of your support hours are being consumed by the same type of issue, you can authorise a fix and know exactly what it should save you. You’re managing your costs based on evidence, not based on what your consultant tells you that you need.
Second, it keeps the consultant honest. When the data is visible to both parties, it becomes very difficult to use inflated support statistics as a justification for selling additional services. The numbers speak for themselves. If the consultant is good at their job, the trend line goes down over time. If it doesn’t, you have the data to ask why.
Any consultant who resists providing this level of transparency is telling you something important about how they operate.
A benchmark worth knowing
Across a range of businesses and project environments, a reasonable baseline for ongoing technical support is around 30 minutes per day. That accounts for the day-to-day questions, the small issues, the things that naturally arise when a team is working in a live environment.
If your team consistently needs more than 30 minutes of support per day, that is not necessarily a problem — but it is a signal. It usually means that the issues are clustering around something structural. A process that isn’t working. A configuration that isn’t right. A gap in how the team was trained or how the project was set up. Something that, if addressed at the root, would bring the daily support need back down.
This is the point where a good consultant earns their value — not by logging the hours and invoicing for them, but by saying: “Your support volume is above baseline. Here’s why. Here’s what we recommend changing. And here’s what we expect the support volume to look like once we’ve made the change.”
That’s the difference between a support service and a consultancy. One answers your questions. The other asks why you’re asking them.
The reactive trap
There is a temptation — and it’s understandable — to use a tech support arrangement as a way to get broader work done. Training that should have been part of an implementation programme. Configuration that should have been scoped as a project. Modelling support that belongs in a production contract, not a support contract.
This isn’t inherently wrong, but it has a consequence: it makes all the support reactive. The consultant is constantly responding to whatever comes in, with no capacity to step back, analyse the patterns, and address the structural issues. The support stays busy. The problems don’t get solved. And the business accumulates risk — because reactive support means nobody is looking at the bigger picture.
The best approach is to separate the two. Use technical support for what it’s designed for — keeping the team moving on a daily basis. And when the support data reveals something bigger, address it as a planned piece of work with a clear scope and objective. That way the support stays focused, the underlying issues actually get fixed, and the business isn’t paying reactive rates for work that should have been planned and budgeted.
How to evaluate your current tech support
If you’re not sure whether your current support arrangement is working for you, here are the questions worth asking:
Can you see exactly where the support hours go each month? If not, ask for that breakdown. If your consultant can’t or won’t provide it, that tells you something.
Is the volume of support going down over time? If you’ve been on a support contract for six months or more and the monthly hours haven’t decreased, the recurring problems are not being addressed. The support is treating symptoms, not causes.
Has your consultant ever proactively recommended a change that would reduce your support costs? If the answer is no, consider what that means about their incentive structure.
Are you using support time for work that should be scoped separately? If your support hours are consistently high, some of that volume may be work that doesn’t belong in a support contract. Separating it out will give you a clearer picture of your actual support needs.
Does your consultant explain what they fixed and why it was broken? A closed ticket is not a resolution. A resolution includes what happened, why it happened, and what’s been done to stop it happening again.
Reducing risk, not maintaining it
Technical support exists to make a business more resilient, not more dependent. The test of a good support service is not how responsive it is — although responsiveness matters. The real test is whether the service is actively working to reduce the need for itself.
That means identifying the patterns. Fixing the root causes. Being transparent about where the time goes. And operating with the understanding that if support costs aren’t going down over time, something isn’t working — and it’s the consultant’s job to figure out what.
The businesses that benefit most from tech support are the ones that treat it as an intelligence source, not just a helpdesk. The data it generates tells you where your team is struggling, where your systems are weakest, and where a targeted investment would save you more than the support itself costs. That’s how tech support becomes a strategic asset instead of an overhead.
And if your current consultant doesn’t think about it that way, it might be worth finding one
who does.
