The client everyone knows about
Ask your service desk which client is the busiest, and they will name one straight away. The accounting practice with forty users that raises tickets about printers every day. The one whose office manager emails the helpdesk for everything, including things that are not IT. Everyone knows. Nobody has the numbers.
The contract was priced two years ago on a per-user fee for a certain level of support. Since then, the client has added a second office, moved to a new line-of-business application and hired staff who need more help. The fee went up with the user count, but the effort went up faster. The account manager is about to discuss renewal with no evidence either way.
Why the numbers stay hidden in the PSA
Your PSA, whether ConnectWise PSA, Autotask, HaloPSA or another, holds every ticket and every time entry. The problem is that the reports that matter, effort per user, per client, over time, compared with the contract, need data from more than one place and a bit of cleaning.
- Seat counts come from contracts or billing, not from the ticket data.
- Tickets are logged against the wrong company or a catch-all account.
- Alert tickets from the RMM are mixed with user requests.
- Project work and out-of-contract work are logged alongside support.
- Time entries are incomplete, so ticket counts and hours tell different stories.
Company records add their own noise. Tickets raised by a client's staff from personal email addresses land on a catch-all company, and a client with two legal entities may be split across two PSA companies. A per-client figure built on that data is wrong before any analysis starts, so the clean-up has to be part of the work.
What an unseen imbalance costs
| Unseen pattern | Consequence |
|---|---|
| High-demand client on a standard tier | Engineers' time subsidises one account |
| Rising demand not noticed | The renewal is priced on out-of-date assumptions |
| Low-demand client not noticed | A client who may be under-served or ready to leave |
| Demand driven by one issue | A recurring fault treated as normal support |
| No evidence for the conversation | Account managers avoid the topic at renewal |
High demand is not always the client's fault. Often it points to an unresolved problem, an unsuitable setup or a training need. Seeing it is the start of fixing it.
The per-client demand view we build
- A nightly pull of tickets and time entries from your PSA through its API, with company, contact, board or queue, type and source.
- Seat and device counts per client from your contracts or billing, so demand is shown per user and per device.
- Filters that separate RMM alert tickets, project work and out-of-contract work from normal user support, using rules you agree.
- A comparison per client against the tier or assumption their contract was priced on, which you enter.
- Trend lines per client over months, and a flag when demand moves outside the range you choose.
- A drill-down by category and by user, so you can see if one person, one site or one application is driving it.
Where it helps, we add simple categorisation of ticket text using an AI model such as Anthropic Claude, so vague tickets are grouped by likely cause. Engineers can correct the category, and the correction is kept.
Account reviews after the change
The service manager opens the dashboard on Monday and sees three clients flagged: the accounting practice, whose tickets per user are well above its tier; a new client, still in its busy onboarding period; and a client whose tickets have almost stopped, which prompts a call. The drill-down shows the accounting practice's demand is mostly one application and two users, which becomes a proposal for training and a fix, not an argument about money.
When renewal comes up, the account manager goes in with a year of figures, broken down so the client can see them too.
Is this your service desk?
- Everyone knows your busiest client, but nobody can show the figures.
- Renewals are priced on seat count without looking at effort.
- RMM alerts and user requests are counted together.
- You have never compared tickets per user across clients.
- Clients with falling ticket volume go unnoticed until they leave.