Most ticket systems count tickets. This one also asks whether the person got their answer the first time, and how much effort it cost them to get it. Those two measures say more about a support desk than a queue length ever will.
Start a free trial Book a demoA list to work through, three taxonomies you define yourself, and a questionnaire that goes out when the ticket closes.
Everything raised, filterable by status, priority and issue type. Each row carries who reported it, how to reach them, and who it is with now.
All three are lists you maintain, not a fixed set somebody else chose. A desk that cannot name its own categories ends up filing everything under other.
Questionnaires built from templates, question groups and questions, so different kinds of ticket can ask different things when they close.
Both sit at the top of the ticket screen, in view while the queue is being worked rather than in a monthly report nobody opens.
The two measures across the top of the ticket screen, and the two columns people actually act on. Pick a numbered point.
Four points on this screen.
Every ticket that is not resolved first time comes back. Set your own numbers.
Assumes a ticket that is not resolved first time takes one further round. In practice some take several, so this is the optimistic version.
An illustration from the figures you entered, not a measured result. It says nothing about the tickets that are never raised because somebody gave up, which are usually the expensive ones.
The parts either side of the queue.
Somebody raises it themselves through a link you can copy and send, or you book it on their behalf while you are on the phone to them.
The second matters more than it sounds. A support desk that only accepts tickets through a form quietly loses every issue raised in conversation, and those are usually the ones from the people who matter most.
Statuses, issue types and priorities are maintained lists. The reason is not flexibility for its own sake: categories somebody else chose get ignored, and a queue where everything is filed under other tells you nothing about where the work is coming from.
Changing them is an administrative action, not a deploy, so the taxonomy can follow what you learn rather than the other way round.
A questionnaire goes out when the ticket closes, built from a template so different kinds of ticket can ask different things. A bug fix and an onboarding call are not the same conversation.
Question groups are ordered, which sounds trivial and is not: a form that asks the hard question first gets abandoned.
The chart runs from very difficult to very simple. The average hides the shape, and the shape is the point: a desk with most answers at very simple and a small tail at very difficult has a specific problem to go and find.
That is a different conversation from a desk whose answers cluster in the middle, which usually means the process is tolerable and nothing more.
Because tickets sit in the same system as the clients and the jobs, a support history is part of the client record rather than a separate account somebody has to be told about.
Time spent on a ticket can be recorded the same way any other time is, so support stops being invisible in the utilisation figures.
Nothing here is a separate system. The same job, the same people and the same numbers run through all of it.
A free trial takes a few minutes to set up, and no card. Or let us walk you through it against the way your practice actually handles support.
Start a free trial Book a demo