On the 10th of August, one of our clients couldn’t see her usual companies in Sage. An engineer made some changes, then called back the next morning to make sure it had held. It had. Ticket closed.
A week later, a different Sage problem. This time it was fixed with a connectivity change.
Two days after that, their Sage wouldn’t open properly. An engineer restarted the services, converted several of the client’s companies to match the same Sage version, and tested each one individually before signing off.
The next day, one company file still wouldn’t load. A server path needed remapping for three of the companies. Each was tested and confirmed working.
Six days later, the same client was locked out of Sage again.
Each of those five tickets was handled properly. Each engineer did real, specific work, tested it, and confirmed it with the client before closing. None of that shows up as wasted effort; it’s exactly what good support looks like, one ticket at a time.
What none of those five tickets could show, on their own, was what only became visible once someone read all five together: the versions of Sage running across that client’s machines didn’t match. That’s not something a single visit was ever going to catch. It’s something only the pattern could show.
That’s the argument of this post. A support ticket is usually a small, specific thing, done well. But a few hundred of them over six months can describe something no single ticket ever could: how your business actually runs, where the same fault keeps resurfacing in different clothes, and where good fixes are quietly covering for a cause nobody’s connected yet. If you run an accountancy practice, a run of Sage trouble in the middle of a busy period will sound familiar; a quick fix is still a morning lost each time, however well it’s handled.
Volume Tells You Very Little
Take two companies, each with 50 staff.
The first raises around 100 tickets a month. That sounds like a lot, until you look at what’s in it: new starter accounts, leaver access removal, equipment requests, software installs, permission changes, questions about a new system. It’s a business that’s hiring, changing and using its support desk as it should.
The second raises 30. Better, surely? But look at the list and the same things keep coming back. Someone loses access to an application every few weeks, a shared mailbox stops working again, a printer fault is on its fourth visit. That’s a business with fewer tickets and more friction.
Most tickets exist because something changed. You hired 30 people, opened a second office, moved to a new accounting system, or reorganised a department. More laptop requests, licence requests and access requests are what you’d expect after that, and they don’t mean your IT is unhealthy.
The useful question is whether the way you handle those requests has kept up. If every new starter means three people working out from scratch which systems they need, who approves what and what permissions to give, the ticket count isn’t the problem. The process behind it is.
So when someone shows you a report saying “87 tickets this quarter”, the honest reaction is “so what?”. The number is the least interesting thing about it. What matters is what the tickets are for, who’s raising them, what keeps returning and what changed in the business beforehand.
The Fifth Identical Ticket
That’s what the Sage tickets discussed above actually show. Every one of those five fixes was correct for the problem sitting in front of it that day. Nobody was cutting corners or guessing. The version mismatch across their machines was never visible in any single ticket, however carefully it was worked; it only showed up once the five were read side by side.
That’s the case for treating ticket history as its own source of information, not just a queue to clear. The first time a client has trouble in Sage, “how do we fix this?” is the right question, and a good engineer will answer it properly, as happened here. By the fourth or fifth time, a second question is worth asking alongside it: is this the same fault as last time, just dressed differently? The tickets won’t answer that question on their own. Somebody has to read them together to even know to ask it.
When The Tickets Aren’t Really IT Support Tickets
Some of the requests we see are more like these:
- “Who needs to approve this?”
- “Where do I find that document?”
- “Which version of the form should I be using?”
Our engineers can usually answer all of them. The question is whether they should have to. If IT is the place people go because nobody has written down the process, or because responsibility is unclear, or because the process changed six months ago and the documentation didn’t, then the helpdesk has become the business’s memory. It’s worth knowing that, because the fix is a clearer process, and no amount of faster ticket handling will provide one.
The same goes for who is raising the tickets. If almost everything comes through one office manager, that might just be sensible, since they’re the designated contact.
But it might also mean everyone has got into the habit of asking one person to sort things out. And if a department barely raises anything, it may simply have simple needs. It may also have a manager quietly fixing things themselves, or staff who’ve stopped reporting problems because they don’t expect anything to change. Silence isn’t the same as everything working, and the data can’t tell you which one you’re looking at. It can only tell you where to start asking, to avoid seeing any of those niggly signs of poor IT support.
Don’t Chase Zero
It’s tempting to think a good IT environment is one with almost no tickets. It isn’t. A growing business should generate requests, because people join and leave, offices move and software changes. A spike after a major system rollout is normal.
What should worry you is different: a steady flow of emergencies because nobody knows what will break next, dozens of tickets from one unresolved fault, or staff repeatedly asking things a simple process should answer. The aim isn’t fewer IT support tickets. It’s fewer unnecessary problems and a proper understanding of the ones that remain.
Your ticket profile should also move as the business does. If a 40-person firm grows to 120 and its tickets look the same two years later, that might mean people have got better at solving things themselves. Equally, they may have stopped reporting the small stuff. Neither is a reason to celebrate until you’ve asked. What changed, and why?
Spotting the Signs of Poor IT Support in Your Own Ticket History
Ticket data can’t diagnose a business by itself, and anyone who says otherwise is overselling it. What it can do is give you better conversations. Compare “You had 87 tickets this quarter” with:
“A lot of your requests are coming from new starters, and you’ve grown by a quarter this year. Is onboarding working as well as you’d like?”
or
“We’ve fixed this same fault four times since June. We’d like to find out why it keeps happening.”
The first is a statistic and the second is someone paying attention to your business.
A Ticket Health Check You Can Do This Week
Pull the last six months of tickets and ask:
- What keeps coming back? If the same fix has been applied several times, has anyone looked for the cause?
- Where are the requests coming from? Do some departments have genuinely different needs, or is something else going on?
- How many tickets trace back to a business change? New starters, leavers, office moves, new software, restructures.
- Are people asking questions that should have an obvious answer? Approvals, access and where documents live are common ones.
- Is one person acting as an unofficial helpdesk?
- Has your ticket profile changed as your business has? If not, why not?
- Has your IT provider ever explained the pattern behind the numbers? If they only report the figures, there’s probably more to get out of them.
Would you like a second set of eyes to prevent experiencing signs of poor IT support?
Our FREE Partnership Review Call is a straightforward conversation about what your tickets, systems and support are telling us and what we’d change. No obligation, just an explanation of your IT in plain English.
Call: 01707 378455
Email: hello@tristartechsolutions.co.uk
Frequently Asked Questions
What can IT support tickets tell you about a business? They can reveal recurring technical faults, unclear processes, training gaps, the effects of business change, and the areas where staff are experiencing friction.
Does a high number of IT tickets mean poor IT? Not necessarily. A growing or changing business will naturally raise more. The type, frequency and recurrence of tickets matter more than the total.
Why are recurring tickets a concern? Fixing the same problem repeatedly usually treats a symptom rather than the cause. A fault that returns is an opportunity to find out why you’re experiencing signs of poor IT support.
Can IT tickets reveal problems that aren’t technical? Yes. Repeated questions about approvals, documents or access often point to gaps in documentation, communication or responsibility, not technology.
How should an MSP use ticket data? To spot patterns, investigate recurring problems and connect IT activity to changes in your business; not just to close tickets faster.
