Most articles about centralized ticketing start with a cartoon of stressed workers buried in paper. Nobody is actually buried in paper anymore. The real baseline in a mid-size company is a mix of email threads to specific people, DMs in Teams, a couple of Slack channels that weren't supposed to be for IT but became IT, and a spreadsheet someone maintains by hand. That's the "chaos" — and the interesting question is what actually changes when every request has to go through one GLPI queue instead.
What the old setup actually looks like
In most places it's a few distinct problems glued together. Requests land on whoever the user knows personally, which means that person's inbox becomes the queue. When they're on holiday nothing moves. Urgent items jump the line because they arrived via Teams DM, not because they're genuinely urgent. Nobody can tell you how many open requests exist, because no one system has them all. And when someone leaves the company, whatever they were carrying in their head walks out of the building with them. None of this is a scandal — it's just how things end up when the tool for requests is "ask a colleague."
What changes on day one
When you send every request through a single GLPI queue, the visible changes are modest but important. Each request has an owner the moment it's created, not when someone happens to notice. The creator sees status and ETA without having to ask. The person assigned to work on it sees what they're responsible for without refreshing three apps. When someone is out, their manager can reassign without guessing what's sitting in their inbox. None of that is revolutionary — it's table stakes — but it replaces half the daily "have you seen this?" and "who's handling that?" conversations.
What changes after a month
The second wave is reporting. Once the data exists in one place, you can start asking questions the spreadsheet never answered: how many tickets does the printer category see per week, which category's SLA is slipping, which locations generate the most work, which users create the most duplicate requests. Some of the answers will surprise you, and that's the point. The first month of a real ticketing system is usually when an organization finally sees where the time actually goes — and it's rarely where people assumed it went.
What a tool doesn't fix
Two honest caveats. First, centralization exposes problems; it doesn't fix them. If tickets pile up because there aren't enough technicians, the queue will show the pile. A tool's job is to make the problem visible, not to make it disappear. Second, one queue only works if people use it. The hardest part of any rollout is not the GLPI install — it's convincing the finance director who has always pinged IT directly to submit a ticket like everyone else. Without management backing, the system quietly coexists with the old email threads and nothing changes.
Where to start
Two suggestions from the rollouts we've run. Start with one department, not the whole company — pick a team where the pain is worst and the manager is bought in. Get the categories, templates, and SLAs right for them, then point the next team at the same queue. And from day one, make "if it's not a ticket, it didn't happen" a real rule — friendly but consistent. Six weeks in you'll know whether the transition is sticking, and nobody still using it will want to go back.