Most of the GLPI projects we get called into to rescue share the same four mistakes, and we don't think that's a coincidence — they're the obvious mistakes, the ones you'd make if you'd never run an implementation before. The interesting thing is that none of them are technical. GLPI itself is rarely the problem. The problem is usually what someone tried to configure on top of it in the first week.
Failure mode 1: eighty categories on day one
Someone in planning builds a tidy category tree: Hardware > Desktops > Dell > Monitor > Brightness. Twelve of these chains. The result is a portal where users genuinely can't find where to submit a ticket, so they stop trying and send emails instead. Categories should be built from real traffic, not from a taxonomy someone drew on a whiteboard. Start with eight to twelve top-level categories, watch what users actually submit, and add subcategories only when you have repeat evidence they're needed. A shallow tree with a high re-classification rate is healthier than a deep tree nobody can navigate.
Failure mode 2: business rules before traffic
The rule engine is tempting. It's where "automation" lives in the UI, so people configure rules before they've seen a single real ticket. Two months later there are forty rules, half of them contradict each other, and nobody remembers why the third one was added. Rules should come from observed patterns — "every ticket of this category from this entity always gets routed the same way" — not from guesses. Start with zero rules and add them one at a time, each justified by a pattern you can see in the data. An empty rule engine after four weeks is a sign of discipline, not neglect.
Failure mode 3: no exec backing for the "one queue" rule
A ticketing system only works if people actually use it. The hardest single thing in any rollout is convincing the finance director or the plant manager — the person who has always emailed the IT lead directly — to submit a ticket like everyone else. Without an exec who will publicly say "from now on, if it's not a ticket, it didn't happen," the system quietly coexists with the old email threads and the data is incomplete forever. We've seen technically excellent implementations fail on this single point. It's not a technical problem and there's no technical fix.
Failure mode 4: rolling out to the whole company at once
Big-bang rollouts produce big-bang failures. When ten departments go live simultaneously, nothing is configured for any of them specifically, training can't keep up, and the first week's bug reports overwhelm the admin team. Every implementation that worked in our experience started narrow: one or two departments, six to eight weeks of real traffic, fix whatever's wrong, then add the next team. The boring path is also the one that actually ships.
What year one should actually look like
If you do nothing fancy in year one but get these four things right, you'll be ahead of 80% of the installs we audit: a small category tree that matches real traffic, three to five templates on your highest-volume categories, one SLA policy that everyone understands, and management visibly using the portal themselves. The advanced features — Cascade workflows, complex reporting, cross-system integrations, AI classification — can wait. They're valuable additions on top of a working foundation, and they're expensive time sinks layered on top of a broken one.
When to bring in help
If your install is already in one of the four failure modes above and you're not sure how to untangle it, that's when an outside pair of eyes is usually cheaper than continuing to iterate internally. We run GLPI audits specifically for this — a half-day review, a short written report, and concrete advice on what to stop doing, what to simplify, and what to keep. Most of the recovery work is removal, not addition.