Une enquête de satisfaction que personne ne remplit ne mesure rien. Le module Pending Survey de NexTool règle le problème frontalement : tant qu'il reste des enquêtes en attente, l'utilisateur ne peut pas ouvrir de nouveaux tickets via le catalogue de services. En maintenance de centres de services, nous avons appris que le taux de réponse ne monte pas avec plus de rappels par e-mail - il monte quand répondre cesse d'être optionnel pour continuer à utiliser le portail.
Le problème
GLPI propose une enquête de satisfaction native à la clôture des tickets, mais le taux de réponse est souvent décevant. Sans incitation, l'utilisateur ignore le lien envoyé par e-mail et ouvre le ticket suivant normalement. Résultat : des données insuffisantes pour mesurer la qualité. Les équipes qui ont besoin d'un NPS ou d'un CSAT fiable vivent la même boucle frustrante - l'outil a la fonction, mais les données n'arrivent jamais en masse.
L'approche classique d'envoyer des rappels par e-mail a un retour marginal. Ce qui change la donne, c'est de conditionner le prochain accès au catalogue à la complétion des enquêtes précédentes. C'est exactement ce que fait Pending Survey, sans toucher au flux de ceux qui ont déjà répondu.
Comment fonctionne Pending Survey
Le module intercepte l'accès au /ServiceCatalog de GLPI et vérifie combien d'enquêtes de satisfaction sont en attente pour l'utilisateur connecté. Le comportement est gradué en deux niveaux :
- 1 enquête en attente - alerte douce, avec option d'ignorer. L'utilisateur est rappelé mais ouvre quand même le ticket.
- 2 enquêtes en attente ou plus - blocage total. Le catalogue est remplacé par un écran avec des liens directs pour répondre à chaque enquête. Impossible d'ignorer.
Le module respecte le réglage natif d'expiration des enquêtes (max_closedate) : une enquête expirée ne compte pas comme en attente et ne bloque pas l'utilisateur pour rien. Il existe des exemptions automatiques pour les techniciens et super-admins, ainsi que des exemptions configurables par utilisateur et par groupe. Fonctions clés :
- Blocage conditionnel du catalogue - deux niveaux : alerte douce et blocage total.
- Liens directs vers les enquêtes - l'utilisateur voit exactement quoi remplir et y accède en un clic.
- Exemptions flexibles - techniciens, super-admins et groupes précis ne sont jamais bloqués.
- Interface responsive - l'écran de blocage fonctionne bien sur mobile.
- Seuil configurable - le nombre d'enquêtes qui déclenche le blocage total est ajustable.
Pending Survey face au rappel par e-mail (natif)
La différence n'est pas d'envoyer plus de rappels, c'est de choisir le moment de l'intervention :
| Critère | Rappel par e-mail (natif) | Pending Survey |
|---|---|---|
| Moment de l'intervention | Plus tard, dans la boîte | Au prochain accès au catalogue |
| Effet sur le taux de réponse | Marginal | Monte en conditionnant l'accès |
| Granularité | Activé ou désactivé | Alerte douce (1) et blocage (2+) |
| Exemptions | Sans objet | Techniciens, super-admins, groupes |
| Respecte l'expiration d'enquête | Sans objet | Oui, via max_closedate |
| Friction pour l'utilisateur | Faible mais ignorable | Graduée et réversible au niveau 1 |
Comment l'activer
- Installez le plugin NexTool dans GLPI.
- Allez dans Configuration > NexTool > Modules.
- Trouvez la carte Pending Survey et cliquez sur Installer, puis Activer.
- Dans les réglages, définissez le seuil, activez l'alerte douce et fixez les utilisateurs et groupes exemptés.
Avant de l'activer : mesurez qui serait bloqué
L'erreur la plus coûteuse est d'activer le blocage total sans mesurer le stock d'enquêtes en attente. Si la moitié de la base a deux enquêtes en attente ou plus, vous venez de bloquer la moitié de l'entreprise le jour du déploiement - et le téléphone sonne. Avant d'activer, lancez cette requête pour dimensionner l'impact (adaptez les noms à votre version de GLPI) :
-- Utilisateurs avec 2+ enquetes commencees et non repondues
SELECT u.name AS utilisateur, COUNT(*) AS en_attente
FROM glpi_ticketsatisfactions ts
JOIN glpi_tickets t ON t.id = ts.tickets_id
JOIN glpi_users u ON u.id = t.users_id_recipient
WHERE ts.date_answered IS NULL
AND ts.date_begin IS NOT NULL
GROUP BY u.id
HAVING en_attente >= 2
ORDER BY en_attente DESC;En maintenance, nous avons mesuré le même schéma chez plusieurs clients : les rappels d'enquête par e-mail rendent des pourcentages à un chiffre ; conditionner le catalogue fait monter le taux de réponse de façon constante. Mais l'autre erreur courante est traître : oublier l'exemption et bloquer sa propre équipe. Nous avons vu un analyste senior incapable d'ouvrir une demande interne à cause de vieilles enquêtes en attente. La règle est donc : exemptez techniciens et responsables avant de relever le seuil, et commencez par l'alerte douce une ou deux semaines avant d'activer le blocage total.
Pour qui (et quand ne pas l'utiliser)
Le module est recommandé pour les centres de services qui doivent relever le taux de réponse aux enquêtes, les responsables qui dépendent d'un NPS ou CSAT à valeur statistique, et les organisations soumises à des audits qualité exigeant des indicateurs de satisfaction constants.
Quand ne pas l'utiliser : si le catalogue est le seul canal d'ouverture et qu'il existe un SLA de délai pour ouvrir un ticket, le blocage total peut devenir une violation de SLA - dans ce cas, restez sur l'alerte douce seule. Et dans les cultures où bloquer l'utilisateur final est politiquement intenable, utilisez le niveau 1 comme rappel permanent et ne déclenchez pas le blocage. Le but est la donnée de satisfaction, pas la guerre avec ceux qui ouvrent des tickets.
Compatibilité
- GLPI : 10.x et 11.x
- Offre : Sous licence
- Plugin : NexTool 3.x+
Étape suivante
Pending Survey fait partie de NexTool, le plugin modulaire pour GLPI. Découvrez tous les modules ou parlez à l'équipe.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.
