What GLPI satisfaction surveys measure after a ticket closes
A service desk manager who wants feedback from requesters once work is finished needs a post-closure satisfaction survey: a short questionnaire GLPI sends to the requester after a ticket is closed, so the answer reflects the outcome of the work rather than the mid-stream experience. The result is a rating attached to each ticket, which GLPI can then aggregate. The business value depends on splitting those ratings by entity, because a score blended across a bank's retail branches, a hospital's wards or a public body's departments tells the manager very little about which team needs help. Survey configuration in GLPI is handled per entity, so the manager should decide early which entities need their own survey behavior and which can share one.
Teams usually turn surveys on when they want a steady feedback signal to set against SLA compliance, or when a service owner needs evidence of requester experience for a review. The survey does not measure whether the SLA was met. It measures whether the requester felt the result was acceptable, so the two should be read together. Before rollout, the team should confirm the exact settings in the GLPI documentation for the version it runs, including how the survey delay is defined, which rating scale is offered, what the notification contains and how survey links behave for requesters who are not logged in. These details changed across GLPI releases, and a plan built on a remembered default will fail at the first test ticket.
The output that matters is the statistics view, where ratings can be read by entity and period. Before any target is set, the manager should run a test ticket in each entity, check that the notification arrives with a working link, and confirm that the response appears where the report expects it. A low response count is a finding in itself, so the team should agree in advance how many responses it needs before a rating means anything. Ask your GLPI integrator to document the survey configuration per entity as part of the handover, so the next administrator can reproduce it after an upgrade.
Survey options per entity and when each one fits
This table lists the settings a team configures for each GLPI entity when it turns on post-closure surveys, with the situation each choice suits and what to verify in the installed version. Read each row as a question to answer for every entity before enabling surveys. The main takeaway is that survey behavior is set entity by entity, so a shared instance can serve different service levels only if each entity's settings are reviewed separately.
| Setting | What it controls | When it fits | What to confirm in the installed version |
|---|---|---|---|
| Closure delay | How long after a ticket closes before the survey request is sent | Long-running requests where the requester needs time to confirm the fix; short delays suit fast-closing service desks | Where the delay is set (entity or satisfaction configuration), its unit, and whether it applies to tickets closed by automatic actions |
| Rating scale or question set | The answer format the requester sees and the values stored in statistics | Teams that want comparable scores across entities should keep one scale; entities with different service models may need their own wording | Which scale options exist in your version, whether questions can differ per entity, and how scores are aggregated in reports |
| Notification template | The message that carries the survey link and its wording for the requester | Internal staff and external customers usually need different tone, language and sign-off, so each audience may need its own template | Which template events trigger the survey notice, how the link is inserted, and whether the link is tied to a single ticket |
| Recipients | Who receives the survey request (the requester, the requester group or another contact) | Internal requesters on shared support queues fit requester-level surveys; external customers with named contacts may need a defined contact | Whether the requester, observer or assigned group is notified, and how multiple requesters on one ticket are handled |
| Entity enablement | Whether surveys run for a given entity at all | Pilot one entity first, or keep surveys off for entities where closure messages already go to a different channel | Inheritance rules from parent entities and whether child entities override the parent setting |
| Notification delivery | How the survey notice leaves GLPI and whether it reaches the requester | Environments with strict mail relay rules or external recipients need checks before rollout | Mail configuration, the notification queue and whether the sending account is allowed to reach external addresses |
| Reporting scope | Which entities and periods appear in survey statistics | Managers comparing service levels need results grouped by entity; per-team reviews need filters by group | Available filters in statistics, how survey data is retained, and who can view results under your profiles |
Setting up surveys entity by entity
This sequence turns post-closure surveys on only where they belong, with settings, notifications and links checked in a test before any real requester receives one. It ends with responses confirmed in statistics, so each entity's results can be read on their own.
Confirm version and survey availability
The GLPI administrator records the exact version in use, such as the 11.0 or 12.0 line, and checks the official documentation for that version to confirm how the satisfaction survey feature is configured. Confirm the menu paths and notification tags in your own instance, because they can differ between releases. The step is complete when the team has a written note of the version, the documentation page used and the settings that page describes.
Map entities and choose survey scope
The service desk owner and the GLPI administrator list every entity, then mark which ones need a survey, which can inherit settings and which should stay silent, such as internal test or decommissioned entities. Agree who owns the results for each entity. The step is complete when the list is signed off, and each entity has a named owner and a yes or no decision for surveys.
Configure survey settings for each entity
The administrator opens the entity configuration for each entity marked yes and sets the survey options that the version provides, including when the survey is sent after closure, the rating scale and whether the survey is enabled. Record each value in a shared table so entities can be compared later. The step is complete when a second person has reviewed the table against the scope decision from the previous step.
Build the survey notification template
The administrator creates or adapts the notification template that sends the survey link to the requester, using the link tag the version documents and a short, clear subject and body. Keep the template scoped to the entities that use it, so one entity's wording does not reach another. The step is complete when the template is saved, active and visible in the notification list for the right event.
Test on a closed test ticket
A tester creates a test ticket in one configured entity with a test requester account, assigns it, solves it and closes it so the survey event fires. Check that the survey is queued and that the notification arrives with a working link. Do this in each entity type your structure uses. The step is complete when the test ticket produces exactly one survey notification and the tester has logged the queue entry and the delivery.
Confirm the link opens for the requester only
The tester opens the survey link from the test notification while signed out and again while signed in as a different user, then as the requester. The link should be usable by the requester and should not reveal the ticket to others. Confirm the link cannot be reused in a way the version does not allow, and document what happens. The step is complete when the outcomes match the documented behavior and the security reviewer has accepted them.
Check responses in statistics
The tester submits a response through the test link, then opens the statistics views for the test entity to confirm the response is counted under the right entity and period. Repeat for one entity from each configured group. Check that responses from one entity do not appear under another. The step is complete when each entity's test response appears in its own statistics, and the team has a written record ready for the handover to operations.
Reading survey results in statistics without over-reading them
Satisfaction scores look precise, but they rest on small samples, mixed request types and uneven workloads. The cards below cover the decisions and misreadings that most often distort what GLPI satisfaction survey statistics tell a service desk.
Small response counts per entity
A handful of responses from one entity can swing its average sharply after a single bad ticket. Before comparing entities, check how many surveys each one actually returned in the period. Treat thin results as a prompt to ask questions, not as a verdict. Agree a minimum response count with the service owners before you publish any ranking, and show the count next to every average so readers can judge the weight of each score.
Mixing different ticket types
A password reset and a major incident rarely produce comparable feedback, yet a blended average hides that difference. Break results down by category or request type before drawing conclusions, and keep incidents and service requests in separate views. If a single headline score is required for reporting, state which ticket types it covers so the number is not read as a measure of the whole service.
Blaming a single agent for a low rating
A low rating on one ticket often reflects the wait before the agent touched it, a fault outside the desk, or an expectation the requester never had explained. Before attributing a score to an individual, open the ticket, read the comment and check the timeline, pending periods and any reassignments. Use survey data to start a coaching conversation, and keep individual comparisons out of formal performance reviews unless your own HR process supports that use.
Comparing entities with different request mixes
Two entities can both score 4 out of 5 while one handles mostly password resets and the other handles complex network changes. Entities with different request mixes, user populations or service hours are not directly comparable on raw averages. Compare each entity against its own history for the same categories, and ask the service owner which request types drive the difference before you conclude that one team performs better.
Confusing satisfaction with SLA compliance
A ticket can meet its time-to-resolve target and still earn a poor rating, because the requester wanted a different fix or a clearer explanation. Equally, a missed deadline can coexist with a good survey if the requester was kept informed. Read survey results next to SLA and OLA compliance from ticket statistics, not as a substitute for them, and look for tickets where the two signals disagree. Those tickets usually reveal the most about process gaps.
Ignoring who answered and when
Surveys sent at closure capture the requester's mood at that moment, and response rates often differ by user group, language or time of day. A low response rate from one population can make the sample unrepresentative even when the count looks adequate. Check which requesters respond and compare response rates across groups. Note the survey delay and any changes to the survey setup within the reporting period, since either can shift results without any change in service quality.
Who the survey scope should serve
You decide which entities send surveys and which closed tickets qualify. This is a scope decision before it is a configuration task. A survey sent to every entity produces results that are hard to compare, while a narrow scope can miss problems in areas that were never included. Settle the scope before the first qualifying ticket closes so the results describe a consistent population.
- Entity coverage: list which entities, such as business units, customers or internal departments, receive surveys and which are excluded, with the reason written down.
- Ticket types: decide whether incidents, service requests and changes all trigger a survey, or only the request types you want to measure.
- Survey timing: agree how long after closure the survey goes out, so requesters have had time to confirm the fix works.
- Ownership: name who reviews low scores and how quickly they respond.
Confirm with your GLPI administrator which survey settings are configured per entity and whether a scope change applies only to tickets closed after the change.
The requester receives a notification with a link and a rating question, and decides within seconds whether to respond. They need a message that identifies the ticket clearly, asks a question they can answer quickly, and does not send them through a second sign-in. Their experience depends on the notification template and on the email address the link is sent to.
- Clear subject line: the notification should name the ticket number and the closed request so the requester recognizes it at a glance.
- Link behavior: check that the survey link opens for the requester without an unexpected login prompt, especially where single sign-on is in place.
- Comment path: confirm whether the requester can add a free-text comment and where that comment appears for the service desk.
- Mailbox routing: requesters who answer from shared mailboxes or aliases may not match their GLPI user record, so test that case directly.
Test the flow with a requester account for each sign-in method your users rely on, and have your administrator confirm the notification template before go-live.
The entity administrator reads results for one business unit or customer and acts on them. They need to see responses for their own entity without seeing other entities' ratings or requester details. What they can see is shaped by the entity structure and the profile rights assigned to them, so the survey design and the access model have to be checked together.
- Entity boundaries: confirm that results are filtered to the entity and, where intended, its child entities.
- Profile rights: check which profile can open survey statistics and whether that profile can also open individual ticket content behind a rating.
- Comment handling: agree whether low-score comments go to the entity lead, the service desk manager or both.
- Review cadence: decide how often the entity reviews statistics and which patterns matter, such as repeated low ratings in the same category.
Ask your GLPI administrator to demonstrate the statistics view using an account that has only the entity administrator profile, and compare what that account can open with what a requester can see.
The reviewer asks where requester names, email addresses, ratings and free-text comments are stored, who can read them, how long they remain, and how they are removed. Survey responses are tied to tickets, so they follow the handling rules of ticket data and the database that holds it. Answers should come from the running instance, based on what the administrator can show you there.
- Storage location: confirm which database and file storage hold ticket and survey data, including backups and any replicas.
- Access: list the profiles and groups that can read responses and state whether exports are allowed and who can run them.
- Retention: ask how long tickets and survey records are kept and whether a documented purge process exists.
- Personal data in comments: determine whether free-text comments may contain personal data and how that content is redacted or deleted on request.
Ask your GLPI administrator for a written data map covering the survey feature, and review it with your privacy officer before extending surveys to regulated entities.
Security and privacy considerations for survey links and responses
Satisfaction surveys put a link in front of requesters and store their answers next to ticket data. The cards below cover the places where that combination creates exposure in a self-hosted GLPI, from the email link itself to the backups that keep survey rows after a ticket is purged.
Survey links sent by email
The survey notification carries a link that a requester can open without signing in to GLPI, so the link itself is the access control. Treat it like a one-time form URL: confirm which ticket and survey it identifies, whether it can be reused after a response is submitted, and whether it expires. Check the link in a test notification before enabling the rule for production entities, and confirm the behavior with your GLPI version.
Who can read responses
Survey results are visible to GLPI users according to their profile rights and entity access, not to every technician. Map which profiles can open the satisfaction data and the statistics views for each entity, and test with a technician account from a child entity to confirm that responses from another customer do not appear. Review this after any change to profiles or entity assignments.
Retention alongside ticket data
Survey responses are linked to tickets, so they usually follow the ticket lifecycle when tickets are purged. Decide how long you keep ratings and free-text comments, whether comments can contain personal data, and whether anonymized aggregates should outlive the raw rows. Write the decision into your records policy and confirm how purge actions treat survey rows in your installed version.
Exposing GLPI to the internet
If requesters reach GLPI from the internet, survey pages are part of the public surface, and the login page and the self-service area share the same web server. Confirm which URL paths are reachable without authentication, restrict the survey endpoints as far as your web server layout allows, and verify that requester sessions cannot reach other tickets or entities.
Logs and session activity
Web server access logs record survey link requests, and GLPI logs record the changes that administrators make to survey configuration. Decide who reviews these logs, where they are stored, and how long they are kept, because they can reveal ticket identifiers and requester addresses. Confirm the log locations and rotation settings in your own deployment before go-live.
Backup and restore of survey tables
Survey data lives in the GLPI database, so it is covered by the same database and file backups as tickets, and it is restored with them. Test a restore into a non-production copy and check that survey rows still match their tickets and entities. Remember that a restore can bring back responses a requester asked to have removed, so record how deletions are handled across backup copies.
Questions buyers ask about GLPI satisfaction surveys
Can GLPI satisfaction surveys be set up differently for each entity?
Yes, survey behavior is configured per entity in GLPI, so each business unit, customer or region can have its own survey delay, rating scale and notification setup. The practical question is how many entities need different settings and whether they share one notification template. Where entities share the same rules, one configuration can serve many of them. Where each entity expects its own wording, language or follow-up process, the configuration and testing grow with every entity. Confirm the entity hierarchy and the survey settings each entity needs before the work is scoped, since that map determines most of the configuration effort.
What drives the effort of a GLPI survey project?
Four factors shape the effort most. The first is the number of entities and how many of them need distinct settings. The second is the number of notification templates, including translations and any link text that must match each audience. The third is reporting: whether results only need to be viewed in statistics or must be exported and reviewed against service targets. The fourth is how closely surveys must follow ticket closure rules, such as ticket categories or requester types that should or should not receive a survey. Each added entity, template or reporting need adds configuration, review and test work, and a quote should list each of them separately.
Can our team configure GLPI surveys without outside help?
A team with GLPI administration experience can usually configure surveys in-house for a small, uniform setup. The work is mostly settings in the entity and notification areas, plus test tickets to confirm that a survey is sent after closure and that the link works. The effort rises when several entities need different rules, when templates must be translated, or when results must feed a reporting process. Ask whether the people doing the work have time to test each entity, and whether someone will own the results after go-live. A partner is most useful when the scope is wide or the team wants the configuration checked against its own environment.
What does the work need from our side?
Three inputs make the work predictable. First, an entity map that lists each entity, its parent, its requesters and the survey rules it should follow. Second, a set of test tickets in each entity, closed in the ways your team really closes them, so the survey behavior can be checked end to end. Third, a named owner for survey results who will read statistics, decide what counts as a problem and act on low scores. Without an owner, surveys are sent but results are not used. Access to a test environment and an agreed list of notification wording are also helpful, and they should be part of the written scope.
How long does a GLPI survey setup take?
Duration depends on scope, and no fixed figure applies to every organization. A single entity with one notification template and a simple review process is a short task. Multiple entities with different delays, translated templates and a reporting routine take longer, mainly because each entity needs configuration, test tickets and sign-off. Ask any provider to break the timeline into entity setup, notification testing, reporting review and handover, and to state which items depend on your team's availability. A fixed-scope agreement records the agreed timeline in writing before work begins, which makes the duration easier to check.
Can DeployOpen confirm how survey behavior works in our GLPI version?
Yes, DeployOpen can check survey behavior in the GLPI version you run, because the behavior can differ between releases and between installations. The check is done in your environment or a representative copy of it, using test tickets for each entity. It covers when the survey is created, when the notification is sent, whether the survey link works and where the results appear in statistics. Before the work starts, confirm which GLPI version is in use, since the current releases include GLPI 11.0.11 and GLPI 12.0.0 according to the GLPI releases page, and ask for the test results to be documented as part of the handover.
Do survey results need to be reviewed by a compliance team?
Survey results are normally an operational quality measure, not compliance evidence in themselves. If your service agreements or internal reviews refer to customer satisfaction, ask who will own the figures, how they will be retained and how they will be reported. Configuration records, such as entity settings and notification templates, are easier to review when they are documented as part of the handover. Confirm the reporting requirements with the teams that use the results before the setup is scoped.
Limits to confirm in your environment before you commit
Survey behavior in GLPI depends on the exact version, the plugins you enable and how your mail and notification setup runs. Confirm each item below against the documentation for your version or with a test on a non-production instance before you commit to a design.
Version and plugin behavior
Confirm that your installed GLPI version and any enabled plugins provide the survey behavior your team expects, including delays, rating scales and per-entity settings. Survey features have changed across releases, and a plugin can add or replace behavior that the core product provides. Check the release notes for your exact version and run one closed ticket through the full flow on a staging copy before you rely on it.
Email delivery through the notification queue
Survey links reach requesters through GLPI notifications, so they depend on the notification queue and your mail transport. Test that a survey email is queued, sent and received by requesters in each entity, including those whose addresses are on external domains. Check how failed sends appear in the queue and who is alerted when they fail.
Responses on reopened tickets
Decide what happens to a survey response when a ticket is closed, surveyed, then reopened and closed again. Confirm whether the earlier response is kept, overwritten or duplicated, and whether a second survey is sent. This affects how satisfaction trends are read, so write the rule down and test it with a reopened ticket before launch.
Customizing survey questions
Confirm whether your installed version lets administrators change the survey questions, scale labels and wording, or whether the questions are fixed. If you need extra questions for a specific entity or request type, ask whether this needs a plugin, a template change or custom development, and who maintains it through upgrades.
Language and accessibility of the survey page
Check that the survey page is translated into every language your requesters use and that the text follows the translation settings of the user's profile. Test the page with keyboard navigation and a screen reader, since requesters often respond from mobile devices or corporate mail clients that alter links. Ask whether the survey page changed in the version you plan to run.
Exporting results for reporting
Confirm how survey results leave GLPI for reporting: whether the statistics screens are enough, whether results can be exported in a usable format, and whether exports include the entity, ticket category and responder fields you need. Run an export on test data and reconcile the counts against the tickets that were closed in the same period.
How DeployOpen works on this
DeployOpen plans, implements, customizes, documents and supports self-hosted GLPI inside your own infrastructure, including the survey configuration described on this page. We agree the scope in writing before work starts, so the entities, survey rules and reporting expectations are settled before anyone changes a production instance.
How we scope
- Inventory which entities and ticket categories should send surveys, and which should stay silent.
- Agree the delay, rating scale and notification wording for each entity in the written scope.
- Confirm who receives survey results and which statistics views managers will use each month.
How we build
- Configure survey settings per entity in a test instance copied from your production data.
- Test the notification templates with real survey links and check that each link opens the correct ticket.
- Check the notification queue and automatic actions so surveys send on schedule without duplicates.
How we hand over
- Document each entity's survey settings, delays and template changes in a runbook your team can maintain.
- Walk your administrators through reading survey results in the statistics views and exporting them.
- Record the configuration in a change log so later edits can be reviewed and rolled back.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and testing are available as a retainer.
- Review survey configuration again when you upgrade GLPI, since plugin and template behavior can change between versions.
- Confirm with your team how often survey settings are reviewed and who approves changes after go-live.
