Que mettre dans un ticket
Les quelques informations qui transforment trois allers-retours en une seule réponse.
Un bon ticket n'est pas un ticket long. C'est un ticket qui contient les éléments permettant de reproduire ou de localiser le problème sans avoir à vous les demander.
Les cinq éléments utiles
- Ce que vous attendiez et ce qui s'est passé à la place. Les deux, pas seulement le second.
- Où : l'écran du portail concerné, ou l'appareil concerné.
- Quand : date et heure approximatives, avec le fuseau si vos sites sont répartis. Voir Fuseaux horaires.
- Sur combien d'appareils : un seul, ou tout le parc. C'est souvent l'information la plus discriminante.
- Le message d'erreur exact, recopié ou en capture d'écran.
Les identifiants à citer selon le sujet
| Sujet | À citer |
|---|---|
| Facturation, provisionnement | Le numéro de facture (INV-AAAA-NNNNN). |
| Licence, activation | Le pool concerné et le numéro de série de l'appareil. |
| Configuration kiosque | Le nom de la configuration et son numéro de version. |
| Analytics | L'appareil et la journée concernée. |
| API | Le préfixe de huit caractères de la clé — jamais la clé complète. |
Ce qui aide vraiment
Si le problème est visible à l'écran, une capture d'écran vaut mieux qu'une description. Si le problème concerne un appareil, la date de son dernier rapport dans Analytics est souvent l'information qui permet de trancher entre « l'appareil est muet » et « l'appareil va bien mais le réglage n'est pas passé ».
Et si vous avez déjà tenté quelque chose, dites-le : cela évite qu'on vous propose la manipulation que vous venez de faire.
This page did not answer your question?
Open a ticket