Most articles about the GLPI self-service portal describe what it looks like. The more useful question is what an end user can finish without ever writing to IT — because that's the metric the portal is judged by. A portal that looks clean but routes every interaction through to an agent has solved nothing. Here's the honest inventory of what the standard GLPI portal supports, and what takes a bit of configuration to become genuinely useful.
Submitting a ticket the right way
The portal's primary job is ticket submission. GLPI renders a simplified form — category, title, description, location, optional urgency — scoped to the user's profile. The piece that matters most is ticket templates. A template bound to a category pre-fills fields and marks some as mandatory: "Printer not working" as a category should require a printer asset, a floor, and a short description. Without that, the agent's first reply is always "which printer?", which is half the reason users stop using self-service and start pinging people on Teams. Fix the template, fix half the complaints about the portal.
Tracking and commenting on existing tickets
Once a ticket exists, the user can watch it: current status, assigned technician, SLA clock, every follow-up the technician adds. They can post their own follow-ups, upload additional screenshots, and approve the solution before the ticket closes. The "approve the solution" gate is worth enabling — it means the ticket stays on the user's side until they've actually confirmed the problem is gone, not when the technician thinks it is. Tickets close more slowly but they close correctly, and reopened-within-a-day counts drop noticeably.
Browsing the knowledge base
GLPI has a KB feature that's often underused. Articles can be marked as visible to end users, and the portal lists them in a searchable catalogue. If an article is linked to a ticket category, it'll surface when the user is about to submit a ticket in that category — a "before you submit, have you tried this?" nudge that closes the loop without ever involving the help desk. Whether this actually reduces ticket volume depends entirely on whether the KB has real, tested content. If the articles were generated in a panic the day before launch, users will ignore them by week two.
Seeing their own assets
If the GLPI inventory links assets to users, the portal can show each user their assigned computer, phone, monitor, and software. This sounds cosmetic but it has a concrete payoff: when a user opens a ticket, they can pick the exact asset it relates to, so the technician isn't guessing which of three laptops in the CMDB has the broken speaker. It also cuts the "what's my asset tag?" conversation that happens on every service desk at least once a day.
Approving requests
For organizations using GLPI for requests (software licenses, hardware orders, access requests), the portal is also where managers approve or reject requests assigned to them. One screen, one click, an audit trail written to the ticket. This is typically the first non-IT use of the portal to actually stick, because it replaces an email chain with something that logs who approved what and when — exactly what internal audit will ask for later.
What to configure first
A portal running on defaults helps nobody. The minimum configuration worth doing before real users get access: decide which ticket categories are visible to end users (hide internal ones — change management, problem records, anything with sensitive fields), create templates for the top five categories with mandatory fields, curate five to ten KB articles for the most common tickets, and turn on "approve solution." Everything else can wait until users tell you what's missing. The portal doesn't need to be complete — it needs to remove the first few reasons someone would bypass it.