Ask three people in a small company how they get IT help and you will get three answers. One pings the sysadmin on chat. One walks over and catches whoever looks least busy. One emails an address that forwards to someone who left two years ago. Everyone gets help eventually, which is exactly why the problem hides for so long. Nobody is furious, nothing is obviously broken, and the whole arrangement looks like it works.
Then a new hire asks the reasonable question — "How do I get IT help?" — and nobody can answer it in a sentence. That is the moment to build something, before the company grows past the point where remembering who to ask is still possible.
The appeal is obvious. Telling someone face to face takes ten seconds: no form, no queue, no ticket number. But those ten seconds belong to someone who was halfway through a backup check or a permission change, and the task with a person attached usually wins. A thirty-second interruption is rarely thirty seconds. It is a lost train of thought, a re-check of what was already checked, and a slightly higher chance that something gets missed.
The bigger cost is that nothing gets captured. If the same printer jams every Monday for six weeks, four friendly conversations never add up to a pattern. Nobody sees the sixth occurrence sitting next to the first five. If one request arrives through two channels, it can be done twice — or closed once while a second person keeps waiting. And when the person who fixes everything is away, there is no record of what they were holding.
The favour economy has one more flaw: it is invisible to whoever controls the budget. You cannot argue for another hire, a better backup tool, or replacing an aging laptop fleet with a recollection of how busy last month felt.
What a ticket buys you is not paperwork. It is a place for a request to live, a name attached to it, and a history you can read later.
Pick a single intake channel and make it the only one. A form is usually best, because it asks the same questions every time and produces something searchable. An email alias that creates tickets automatically works too. What matters is that chat messages and desk visits are redirected there consistently — every time, including the times it feels silly.
Redirecting is the hard part, and it has to come from the person doing the work. "I will absolutely forget that if you tell me here. Drop it in the form and I'll pick it up this morning" is the whole trick. Say it warmly, say it every time, and give people a two-week grace period before you stop quietly doing favours. Announcing the change in advance helps more than enforcing it does.
Keep it short enough to finish in under a minute. Do not ask people to pick a technical category, guess a severity level, or choose from a list of twelve issue types they do not understand. Sorting is your job. If a form takes longer to fill in than walking over to someone's desk, it will not survive contact with a busy Tuesday.
Every queue needs an order, and the order should be written down where everyone can see it. The usual failure is a priority system with five levels that nobody can tell apart. Three or four bands, described in terms of work rather than technology, is plenty.
Alongside priorities, give every ticket a small set of states: New, In progress, Waiting on you, Done. The third state matters more than it sounds. "Waiting on you" tells the requester that the ball is in their court, so a ticket that stalls does not simply look ignored.
Read the front door every morning. Even if you do nothing else, moving each new ticket into a state and leaving one short comment — "got it, looking at this after lunch" — does more for trust than any tool you could buy. A queue that gets acknowledged feels like a queue. A queue that stays silent feels like a hole.
Write the closing note for a human being. "Fixed" is not a closing note. "Replaced the network cable under your desk — it was failing intermittently, so let me know if it drops again this week" tells the requester what happened and what to watch for. Write it in the language they used when they filed the ticket, not in yours.
Then set a rule for the stalled ones. If you are waiting on the requester, give it a date and close it once that date passes, with a friendly note. If you are waiting on a vendor, keep it open and say so once a week. Tickets that sit in limbo for a month teach the whole company that the system does not work — and the hallway starts filling up again.
This is the step almost everyone skips, and it is where the real value lives. Twenty minutes a month is enough.
Done consistently, a ticket log stops being a chore and becomes a map of the company's weak spots. It shows you which laptop model keeps dying, which onboarding step always gets missed, which system people quietly need training on. That is the argument for change, made in numbers instead of anecdotes.
A ticket system exists to serve the people filing tickets, not to protect the people closing them. A few rules keep it that way. Never make someone file a ticket to report that they cannot file a ticket. Never let "no ticket, no fix" apply to a genuine emergency — fix the outage first and log it afterwards. And if the same person files the same ticket for the third time, that is not a discipline problem, it is a signal that something upstream is still broken.
The goal is not a tidy queue for its own sake. It is a company where a problem gets found, owned, fixed, and remembered — and where the next person with that same problem gets help faster than the last one did.
Photo: Yan Krukau / Pexels
Unassigned seats, duplicate subscriptions and forgotten renewal dates drain small IT budgets quietly. Here are ten...
Free antivirus covers basic malware blocking, but paid tiers add phishing defence, VPNs, parental controls, priority...
SSDs cut boot times and survive drops; hard drives still win on cost per terabyte. Here is how to match each drive...
Your trusted source for reliable IT solutions.
