A service catalog answers one question: what can IT do for you? If users have to email someone, guess at a ticket category, or describe their request from scratch every time, you do not have a service catalog. You have a suggestion box.
GLPI does not have a dedicated "service catalog" module with that label. Instead, a service catalog is built from ticket categories, ticket templates, and the self-service portal. Getting this right requires design decisions, not just configuration.
Start from what users actually request
The most common mistake is building a catalog from IT’s internal perspective. Teams list every service they technically provide, organized by technology stack. Users see categories like "Active Directory," "Network Infrastructure," or "Middleware" and have no idea where their request belongs.
Instead, pull your last 6 months of tickets. Group them by what users were actually asking for. You will find patterns: new employee setup, software installation, access requests, hardware replacement, VPN issues. These become your catalog items. Name them in language users understand, not in language that makes sense to the infrastructure team.
Structuring the catalog in GLPI
Category hierarchy
Under Setup > Dropdowns > Ticket categories, build a two-level tree. Top level: audience-based groups like "Employee services," "Hardware," "Access and accounts," "Software." Second level: specific items like "Request a new laptop," "Reset my password," "Install application." Keep it shallow. Three or more levels deep and users give up navigating.
One template per catalog item
Each catalog item should have an associated ticket template (Setup > Dropdowns > Ticket templates). The template pre-fills the ticket type (Request), assigns the correct category, sets the target group, and includes mandatory fields specific to that request. For a "New employee setup" request, the template should ask for start date, department, required applications, and manager for approval. For "Request a monitor," it might just need the office location.
Approval workflows
Some requests need manager approval before fulfillment. GLPI handles this through validation rules on the ticket. Configure approval requirements per category. A request for a standard mouse does not need sign-off. A request for admin access to a production server does. Set these rules in the business rules engine so they trigger automatically based on the category.
Service catalog vs. request catalog
There is a useful distinction between these two concepts. A service catalog describes what IT provides at a strategic level: email service, endpoint management, network connectivity. A request catalog is the operational menu: the specific things users can order. GLPI’s ticket category tree serves as the request catalog. The broader service catalog, if you need one, lives in documentation or a CMDB service object that maps to multiple request categories.
For most organizations under 500 employees, a well-structured request catalog in GLPI is sufficient. You do not need both unless your governance framework requires it.
Keeping it alive
A catalog that is not maintained becomes a graveyard of irrelevant options. Review it quarterly. Check which categories have zero tickets in the last 90 days. Retire them or merge them. Check which categories have the most "Other" or "General" selections, because that signals the catalog does not cover something users actually need.
Add new items when you see the same freetext request appear three or more times. If users keep typing "I need a second monitor" in miscellaneous tickets, that is a catalog item waiting to be created.
A good service catalog is a living document expressed through GLPI configuration. Treat it like a product, not a project.