Most slow helpdesks aren't slow because the agents are slow. They're slow because two-thirds of incoming tickets say something like "the email doesn't work" with no application name, no error message, no affected user count. The agent reads it, replies "could you give me more details," waits two hours for the user to come back, and only then can start on the actual problem. Fix the intake and you compress that loop from days to minutes. GLPI has two complementary mechanisms for this: ticket templates and the Form Creator plugin.
Ticket templates: making fields mandatory
A ticket template in GLPI lets you say: for this category of ticket, these fields must be filled before the ticket can be submitted, and these other fields will be pre-filled with defaults. Open Setup > Templates > Ticket templates. Create one called Software incident. In the Mandatory fields tab, mark Title, Description, Category, Associated element (the affected asset), and Impact as required. In Predefined fields, set Type to Incident and Source to Self-service portal.
Now attach the template to your software-related categories (Setup > Dropdowns > ITIL categories, edit each category, set the Ticket template field). Anyone creating a ticket in those categories — agent or end user — gets the validated form. The "the email doesn't work" submission won't go through because no asset was picked.
Different templates per category, not one mega-template
A common mistake: one giant template that asks for everything because someone, somewhere, might need it. The result is a form so heavy that users abandon it or paste lies into mandatory fields just to submit. Instead, scope the template to the category. Software incident needs application name and version. Hardware request needs location and approver. Access request needs target system and justification. Each form short, each form complete for its purpose. The category selector at the top of the new-ticket form drives which template loads — users only see fields relevant to their issue.
Form Creator for non-technical end users
The standard GLPI ticket form is designed for technicians. End users find dropdowns like Impact / Urgency / Category meaningless and pick at random. The Form Creator plugin (the most-installed GLPI plugin for a reason) lets you build category-specific forms in plain language: instead of Urgency, you ask "How many people are affected? (a) Just me (b) My team (c) The whole department". Behind the scenes, those answers map to GLPI fields and create a proper ticket with priority already calculated.
The plugin also supports conditional logic — show the "Specify other system" text box only when the user picks "Other" in the system dropdown. And approval chains — a hardware request over €1000 routes to the cost-center owner before becoming a ticket. The end-user portal is no longer a confusing ticket form; it's a service catalog of recognizable requests.
Default watchers and groups
The other intake trick: automatically add the right watchers as the ticket is created. In the ticket template, set Default actors: requester is whoever submits, and a watcher group like Service-desk-leads is added automatically. The lead sees every new ticket in their list without explicit assignment, which is the difference between "the queue is being watched" and "the queue gets looked at when someone has time."
What to mandate, what to leave optional
Make mandatory only the fields the agent genuinely needs before they can start work. Title, Description, Category, and usually Affected asset or Affected system. Impact if your priority matrix uses it. Resist the urge to mandate everything — every extra required field is a reason for the user to fake the answer or call a colleague instead. The goal is enough information to start work, not a complete change-management record.