Also measure what never gets reported.
Ticket data is a record of what was reported — a selection, not a picture. Don't ask 'How did I help you?' but 'Where do you get stuck?'
SITS Netherlands 2026 · Jaarbeurs Utrecht · Tuesday 22 September
A better service desk starts upstream
Plenary session, open theatre on the exhibition floor · 16:00 · 40 minutes incl. Q&A
For whom
For people who own or run a service desk and are tired of solving the same thing every month.
In one line
A large share of what lands on your service desk is not a failure. It is friction — help requests that could have been prevented, and losses that should never have become a ticket at all. Both are caused upstream, in how IT is designed, deployed and adopted. That is where a service desk manager has to be. Not to do more work, but to stop work that never had to exist.
Build
Where it is designed.
Screens without tooltips, error messages that only say something went wrong, processes that need three screens for one approval. Nobody at the design table has ever answered the phone about it.
Run
Where it is deployed.
An update rolled out overnight that changes a menu by morning. Single sign-on that still asks for a password in two of eight applications. Training that is the same twenty minutes for everyone.
Use
Where it is experienced.
Live is not the same as in use. A system can be technically perfect and still never be adopted — and the gap between the two is where your tickets come from for the next three years.
Support
Where it all ends up.
The service desk is the clearing house for everything upstream got wrong. Availability is green, SLAs are met, and the tickets keep coming. That is not a ticket problem. It is an organisational problem showing up as ticket volume.
Ticket data is a record of what was reported — a selection, not a picture. Don't ask 'How did I help you?' but 'Where do you get stuck?'
A root cause does not have to be technical. Use the process you already own to remove structural friction, and prove that it worked.
Don't ask for a seat at the project table — state what must be in place before go-live. Backlog items, go-live criteria, evidence.
Leave your details (your email is enough) and you’ll get the full handout of this session straight away.
Leave your details — the handout (PDF) downloads straight away.
Thank you! 🎉
Your handout is downloading automatically. Not working? Download it here.
About the speaker
Jan Massier started on the service desk at Apple Computer in 1995 and has spent the years since on the part of IT that rarely makes the project plan: the people. Through implementation management at an international IT consultancy, IT communication management and adoption management he developed his own approach to change in IT environments.
He is ITIL- and XLA-qualified and works with MoC4IT™ — Management of Change for IT — a practical method built on Kotter, ADKAR® and ITIL. His work centres on three connected questions: why systems that work technically still go unused, where the friction sits that never gets reported, and how to make it measurable so something can be done about it.
The two instruments
BePresent (est. 2006) works as Digital Experience Improvers for organisations in healthcare, financial services, industry and the public sector. Two instruments support that work: the Adoptiekompas™, which uses short pulse measurements to show where adoption stalls — on must, want and can — and the DEX-kompas™, which measures digital friction across the domains where the work actually happens.
Fewer unnecessary tickets, users who get stuck less often, and room for the IT that keeps coming. Let's talk about where your friction sits.
Get in touch