The question that reframed the design
Not "how do we get people to use the ticket system" but "why is sending a message easier". Once the second question is asked honestly, the answer is usually obvious and slightly embarrassing: because it is.
Designing an employee IT support system people actually use
01
Context
Every internal IT team runs two queues. There is the official one, in whatever system was chosen, and there is the real one: messages, corridor conversations, and requests to whoever is nearest and looks least busy.
02
Problem
The shadow queue gets the work done and destroys everything else. The team looks less loaded than it is, recurring problems never surface as patterns, nothing can be planned or staffed properly, and the person who is most approachable absorbs the most interruptions.
03
Constraints
- Friction decides the outcome
- If raising a ticket takes longer than sending a message, the message wins. No policy or reminder changes that.
- Occasional users, not power users
- Most employees raise a handful of tickets a year. The interface cannot assume familiarity with internal categories.
- The team needs structure the user cannot provide
- IT wants classification. The employee wants to describe a problem. Those pull in opposite directions.
01
02
03
04
Approach
I attacked the friction rather than the behaviour. I made submission genuinely short, did not require the user to classify their own problem into a taxonomy they have never seen, and let the team add structure on receipt where they have the context to do it correctly.
05
Architecture
Employee submissionShort, low-friction, no internal jargon required.
TriageClassification added by the team, who have the context to do it right.
Operational visibilityLoad, recurrence and time distribution become visible once requests arrive through one channel.
06
Solution
A ticketing system designed around the occasional user rather than the IT team's taxonomy, with classification pushed to triage. Once requests consistently arrive through one path, operational visibility follows for free.
07
Lessons
- 01Design against the real alternative. The competitor is a WhatsApp message, and that sets the bar for how short the submission path has to be.
- 02Do not ask users to classify their own problem. Correct classification requires knowing the answer, which is the thing they are asking about.
- 03Visibility is the by-product of adoption, not a feature. You cannot report your way out of a shadow queue.
- 04Adoption numbers are not published here because they have not been measured in a way worth publishing.
Stack
What it runs on