In a small company IT tickets get handled by „going over to the IT guy". In a medium one — they don't. Somewhere between 20 and 40 employees every informal channel breaks down, and one morning three things fall through the cracks and the board asks „why has the printer been down for two weeks?". The answer is usually boring: because nobody wrote it down.
This isn't a laziness problem. It's an architecture problem. When the same person receives tickets through Slack, WhatsApp, email, phone and „hey, catch me when you're back from lunch", three out of five channels lose to physics. There's no single place that shows what's waiting, what's in progress and what got stuck. There's no history. There's no basis for the conversation with the board about why you need another half-time IT hire.
This post is about when to put such a system in place, what it actually changes, and how not to overengineer the tool.
When Slack stops being enough
Informal channels work as long as one person remembers everything. When IT is a one-person post and the company has 12 employees — Slack + a notebook is fine. When the company grows to 30–50 people, a second half-time person joins, a VP starts sending tickets by SMS directly, and the accountant prefers email. Chaos begins.
A few symptoms that in practice mean „it's time":
- A ticket disappeared because three others landed in the same Slack channel.
- An employee is asking the same thing for the third time because the first time it was „by tomorrow".
- A new hire in IT has no idea what to do in the first week, because nothing is written down.
- You can't answer the board's „how many tickets did we close last month".
- Outages keep repeating, because nobody connects today's issue to a similar one from a month ago.
If any of these describe your week — this isn't a problem more team dedication will solve. It's a problem a simple tool solves: one where every ticket has a number, an owner and a status.
What a helpdesk actually gives you
A helpdesk (or, more nicely, „service desk") isn't a magical app. It's two things: a single funnel every ticket falls into, and a history you can go back to. Everything else is a bonus.
The first benefit is obvious: you stop losing things. The second only shows up after a few months — suddenly it's easy to run a simple report and see that 40% of tickets are the same. That Chris from accounting reports „Comarch Optima freezes" seven times a month, always at 8:30, always on the same invoice. That the printer in the meeting room died eight times in a quarter, so maybe it's worth replacing instead of paying for service calls every month.
The third benefit is about the conversation with the board. „IT is overloaded" is a sentence the board won't buy. „In June we closed 187 tickets, the median resolution time is 6 hours, one person closes on average 12 tickets a day — and we have 43 in the backlog" is a sentence that ends the debate.
Fancy features don't matter. What matters is that everyone in the company knows where to report and knows the report won't disappear.
Choosing a tool — start simple
The helpdesk market is huge and full of tools designed for companies with 500+ employees. For an SME that's often a trap: you buy Jira Service Management, spend three months trying to configure it, and the team goes back to Slack anyway. The rule is simple — start with the simplest tool that solves 80% of the problem and add complexity only when you actually miss it.
A practical map for Polish SMEs with 20–50 people:
- Freshdesk (free plan up to 10 agents, then ~15 EUR/agent per month) — our first recommendation for a company that has never had a helpdesk. Simple form, user portal, mobile app. A week to roll out.
- Zoho Desk — similar price bracket, sensible if you're already inside the Zoho ecosystem.
- osTicket / GLPI (free, self-hosted) — good if you have the skills to run and maintain them. GLPI additionally tracks hardware assets, which is a nice bonus for an SME with 60 laptops.
- Jira Service Management — a good tool, but decidedly too big until you have an IT team of at least five and a process you've already written down.
- Microsoft 365 with Power Automate + SharePoint lists — works if you're already in M365 and want to stay in the ecosystem. Looks cheap, but maintaining a Power-Automate-based build can eat more hours than a Freshdesk licence costs.
Don't buy a system with 40 required fields on the ticket form. The team will still type „printer doesn't print". Buy a system where you can open a ticket from email, assign someone in one click and add a comment.
Rollout — what we see in practice
The technical rollout takes a few days. The human rollout takes months. People naturally return to the simplest channel that worked recently, and that's usually „ping me on Slack". If you don't change the habit, the tool turns into a graveyard.
A concrete example from a recent project. A 32-person electrical wholesaler, two locations, a one-person IT department plus external support from us. Tickets flowed through three channels: Slack (~60%), email to the IT guy (~25%), the rest „in the hallway". Average resolution time, measured manually from a sample: 2.5 days. The biggest issue — recurring incidents that nobody was seeing as recurring.
We deployed Freshdesk on the free plan. Configuration took four working days. Key decisions: a single it@ address forwarded to the Freshdesk mailbox, direct Slack to the IT guy turned off (the #it-help channel now redirects to the form), a short 30-minute team briefing, and a QR-code poster in every meeting room saying „if something's not working — scan me". After six weeks the median resolution time dropped to 6 hours, and 41% of closed tickets had one of three recurring keywords in the title: „Optima", „printer", „VPN". Three concrete investments in the following quarter (an Optima licence upgrade, one printer replacement, a VPN reconfiguration) removed roughly a third of the ticket volume.
There was no magic, no AI in this. There was one place where everything was visible and consistency over the first two months.
What not to do
A few things that in practice kill a rollout:
- Too many fields and categories up front. Start with three categories („hardware", „applications", „accounts and access") and a priority. Add the rest once you see something is missing.
- Running Slack and the helpdesk in parallel. There must be one entry channel. Slack can stay — but only with a bot saying „open a ticket here".
- Hard SLAs on day one. A „4-hour response" SLA makes sense after a month of observation. Before that it's fiction.
- Rolling out the helpdesk „while we're at it" during an M365 migration. Do one thing at a time. Package rollouts fall apart in three ways simultaneously.
- No single owner. Even if the tool is run by an external partner, someone has to own it. Without that, six months in nobody remembers who was supposed to update the categories.
If you're not sure which tool to start with — let's talk for half an hour. Usually we can tell in that time whether you need a free Freshdesk plan or you genuinely need Jira.
A helpdesk isn't about features. It's about every ticket having a number and every employee knowing it won't disappear.