Templates in GLPI look like a cosmetic feature: a nicer form, a few pre-filled defaults, maybe some reordering. That framing undersells them. A well-written template is what makes the difference between a ticket that's actionable the moment it's submitted and one the technician has to push back with "which printer?" before they can even start. Most of the value isn't in the convenience — it's in the fact that the template decides what the user cannot skip.
What a template actually is
Under the hood, a GLPI ticket template is a set of per-field rules tied to a category: for each field on the form, you decide whether it's hidden, visible but optional, visible and mandatory, or pre-filled with a specific value. That's it. There's no code and no branching. What turns it into a powerful tool is that you can do this per category — so "Printer broken" looks completely different from "Network outage" without needing different ticket types or any plugin.
Mandatory fields are the point
If you take one thing away: the category "Printer broken" should make the specific printer a mandatory field. Not a nice-to-have, not suggested in the description box, not "please include the asset tag if you can" — mandatory. The moment you do that, every printer ticket arrives with the printer attached, the technician clicks through to its location and model, and the first-response time on that category drops visibly. The same logic applies to "Access request" (which system? which role?), "New hire setup" (start date? manager?), and "Software install" (which software? which machine?). Every category you run has two or three questions the user always has to answer eventually, and the template's job is to make them answer up front instead of in a ten-message back-and-forth.
Pre-fills that remove thinking
The second layer is sensible defaults. Most users don't know which SLA applies to their ticket, which group owns it, or what urgency they should pick — and they shouldn't have to. A template lets you set all of this invisibly: category determines group, entity determines location, requester type determines urgency. The user writes one sentence about what's wrong and submits. Everything else is already correct. This is the part that feels cosmetic but isn't: it's the difference between a service desk where users guess at fields and one where they just describe their problem.
Hiding fields users shouldn't touch
The third layer is the one people forget. A standard GLPI ticket form has more than twenty fields — half of them don't apply to most user submissions. Hide the ones that don't: impact, TCO, validation type, associated tasks, related tickets. The portal view should have five to eight visible fields, not twenty-two. Every hidden field is one less thing the user can get wrong, one less thing they have to scroll past, and one less reason to close the tab and write an email instead.
Where templates don't help
Templates won't fix a user who refuses to use the portal at all. If the finance director keeps emailing the IT lead directly, the nicest template in the world doesn't help. They won't fix a broken category structure either — if you have one template for "IT problem," you've just made a longer form, not a sharper one. Templates rely on categories being specific enough to have their own questions. That's usually the real work.
Where to start
Take your busiest three categories. For each, answer in writing: what two or three fields must be on every ticket for that category to be actionable without a follow-up? Make those mandatory in the template. Set sensible defaults for everything else. Hide the fields that don't apply. Then leave the other forty categories alone — those three templates will handle 60-70% of your ticket volume, and the rest you can template later if you see repeat patterns. Start narrow, expand only when there's an actual reason.