History

Satisfaction utilisateur

(soit sondage, soit systématique)

voir http://www.glpi-project.org/forum/viewtopic.php?id=9356

DD (séminaire) :
  • Enquête visible après la cloture administrative suivant (délais / fréquence)
  • Enquête simple avec un indice de satisfaction global (prédéfini en dur : êtes vous satisfait?) avec système de notation de 1 à 5 (étoiles?) +zone de commentaire
  • Gestion de lien protocolé avec un outil externe (afficher celui là à la place du système interne)
  • Configuration
    • activation dans configuration générale + definition des liens externes + mode par défaut (ex : oui + enquete interne)
    • pour chaque entité + récursivité
      • oui / non pour l'utilisation
      • sélection du type d'enquête (interne ou lien)
      • délais pour l'envoi pour remplissage de la notification d'enquête
      • Fréquence : à chaque clôture, toutes les n clôtures par utilisateur
  • 1 retour par ticket, retour fait par celui qui clos la demande (lié cloture administrative)
    • si cloture auto ?
  • Système de notification (lien vers enquête de satisfaction si il y en a une dans le mail de la clôture administrative
  • Dans la liste des tickets clos, afficher le résultat de l'enquête (étoiles) ou le lien si l'enquête n'est pas remplie. Dans le cas de l'externe, ne rien afficher.
  • Indice et commentaire sont des caractéristiques du ticket donc enregistré dans la table tracking (donc utilisable dans le reporting du ticket)
  • Rajout d'une colonne dans les stats
  • Possibilité de rapport / stats plus poussées dans un plugin
  • Affichage du formulaire de l'enquête de satisfaction (notation + zone de commentaire) dans un onglet "satisfaction"

----
Analyse préalable

  • Rattachement avec la clôture administrative du ticket ?
    - yllen : la génération de l'enquête n'est faite que si le ticket est clos
  • Configuration :*
    - yllen : configuration de la génération des enquêtes par entité : taux, fréquence, type (interne, externe)
  • Activation : oui/non par entité
    - yllen : si taux = 0 => pas de génération d'enquête
  • Fréquence par entité : à chaque ticket, systématiquement toutes les n demandes ou hasard 1/n
    - yllen : taux paramétrable par entité (de 0% : pas d'enquête à 100% : tous les tickets)
    ainsi que délai de déclenchement (déclenchement après 0 jour (immédiatement) ou paramétrable entre 1 et 30 jours (au-delà je ne vois pas l'utilité d'une enquête)
  • Création de l'enquête :*
    - yllen : actuellement, c'est un cron qui déclenche la génération de l'enquête
    Doit-on autoriser la génération manuelle d'une enquête ?
    Si oui,
    - doit-on vérifier que l'enquête est bien activée avant l'affichage du bouton ?
    - qui a le droit de générer cette enquête ? - droit dans le profil ?
    - comment doivent être comptabilisé ces enquêtes ? (vu que les réponses seront en sus du taux demandé)
  • Rattachée à une entité / recursive, activable/desactivable ?
    - yllen : l'enquête est paramétrable par entité (avec héritage de l'entité parente possible).
    la désactivation se faisant par un taux de déclenchement à 0
  • Configuration de n questions ( une question un champs input)
    - yllen : une seule question : degré de satisfaction à exprimer sous forme d'étoiles de 1 à 5 (merci Julien pour les étoiles)
    + zone commentaire
  • Configuration de la notation (la même pour toutes les questions) : Gestion via 5 étoiles
    - yllen : aucune configuration par entité, c'est en dur dans le core

    - gportheault: Configuration de n questions de type QCM (une réponse au choix parmi une liste définie pour chaque question) ou de type commentaire libre
    - Moyo : comment gérer les langues multiples dans ce cas précis ?
    - JMD : Piste envisageable -> lors de la saisie d'une question l'utilisateur peut saisir plusieurs traductions de la question en l'associant à une langue (dropdown).
    L'affichage du formulaire se fera donc à partir de la langue de l'utilisateur et des traductions des questions fournies. Si pas de trad, on affiche la question par défaut.
    - JMD : pour la partie réponses, je pense qu'on peut tout de même se limiter à une notation de 1 à 5 , partir sur du commentaire libre etc.... ça revient à faire un outil de sondage et ça me semble pas vraiment l'objectif de GLPI. Attention à la dérive liste de noël...

  • Notification :*
  • Si notification par mail activée ?
    - yllen : paramétrer une notification par entité (notification déclenchée par la tâche automatique : createinquest)
    - si enquête interne : lien vers l'enquête dans GLPI
    - si enquête externe : lien protocolé indiqué dans le champ URL de la configuration de l'enquête

    - gportheault: -> vérification qu'une réponse n'a pas déjà été donnée par cette utilisateur sur le même questionnaire.Envoi d'un mail vers un choix de personnes (notifications) des qu'une réponse à une enquête est effectuée (réaction rapide d'une cellule qualité par exemple, en cas de critique).

  • Résultats :*
    - yllen : pas encore réfléchis précisément sur ce point (camembert ou pas)

    - indice par réponses et sur une période
    - gportheault: De type rapport avec droit de visu (tout le monde n'a pas le droit de voir les résultats d'une enquête):
    - camembert / question présentant les réponses sur une période, un technicien, ou un groupe technique (afin de pouvoir évaluer le travail des techniciens vu du client)
    - présentation des réponses brutes sur une période, un technicien, ou un groupe technique (top: cela peut être fait en cliquant sur le quartier représentatif du camembert du rapport précédent), cela permet de voir les réponses en commentaire libre.
    - JMD : et si on aime pas le camenbert ?

MoYo :
- pour moi quelquechose de simple : indice de satisfaction global (de 1 à 5).
- Etudier la possibilité de lié vers un outil externe si besoins plus poussés : ajout d'un texte + lien configurable (cf. mail template ?)