Comment mettre en place une gestion des problèmes dans le cadre des SAV ?

Vous trouverez dans cet article un guide étape par étape pour la mise en place des problèmes dans votre instance Autotask afin de faire le traitement des demandes de SAV sur vos périphériques.

Parce que la vie d’un MSP n’est pas faite que de traitement de demandes ou d’incidents… ce sont parfois aussi des « problèmes ».

La notion de « Incident » ou « Problem » est définie dans la sémantique d’ITIL (Référentiel de Bonnes Pratiques) et norme ISO20000. La confusion entre incident et problème est récurrente, en voici donc une définition :

• Un incident est une dégradation ou une interruption imprévue du service ;
• Un problème est la source d’un ou de plusieurs incidents dont la cause fondamentale est inconnue.

Il arrive parfois qu’un ticket incident soit bloqué dans le traitement, car il nécessite l’intervention d’un tiers : Éditeurs ; SAV matériel, etc. Nous allons donc exploiter les tickets de type « Problem » dans Autotask pour répondre à cette demande.

Dans notre exemple, nous allons faire le test pour un seul fournisseur, mais rien n’empêche ensuite de généraliser le mode opératoire pour d’autres fournisseurs (Fabricant, Editeur, Opérateur internet etc.).

Configuration préalable / Périmètre du test

Afin de pouvoir faire la gestion des problèmes, nous allons devoir faire quelques configurations préalables. Dans notre exemple, nous allons avoir un incident « Problème-écran noir » que nous allons ensuite transformer en un problème dans le cadre d’un SAV chez le constructeur.

Les avantages de la mise en place « Incident vers Problème » :

• Les tickets d’incidents sont tous regroupés et rattachés à un seul ticket problème ;
• Une traçabilité de l’ensemble des tickets qui ont été ouverts sur company vendor (fournisseur) : Obtenir la liste de l’ensemble des tickets qui ont été ouverts en SAV chez DELL par exemple ;
• La mise à jour du ticket problème permet de mettre à jour les informations sur un ensemble de tickets incident (comme le changement de statut), et si souhaité, de notifier chacun des contacts des incidents.

Les inconvénients de la solution de la mise en place « Incident vers Problème » :

• Dans le cas d’un SAV Constructeur, la mise en place de cette solution « 1 pour 1 : Un ticket Incident = Un ticket problème » fait qu’on se retrouve avec deux tickets pour le même sujet, donc une certaine lourdeur de gestion.

L’analyse des données (statistiques) va pouvoir se faire ensuite à travers des Widgets.

Création d’une Company Category « Vendor »

Une première étape consiste à créer les différents « Vendor » (fournisseur) sur lesquels vous souhaitez appliquer une gestion de problèmes.

Dans menu Admin > Features & Settings > Company Categories, il y a plusieurs options :

• Vous avez déjà une Company Category Vendor/Fournisseur ? ;
• Vous utilisez un formulaire « Standard » ?

Si vous avez envie de créer un formulaire spécifique fournisseur, il faut dupliquer une Company Category déjà présente :

On renomme « Copy (1) of xxx » en « Fournisseur », on coche la case « Active »

Dans le « Header », on configure le Company Type en « Vendor » et dans « Available List Values », on ne laisse que « Vendor » de disponible.

Nous n’allons pas plus loin dans la configuration de la Company Page « Fournisseur », libre à vous de masquer ou de créer les champs que vous jugez nécessaires.

Nous allons ensuite dans la barre d’outils Autotask vers + > CRM > Company et faire la création de notre première company avec le formulaire « Fournisseur »

Nous allons choisir dans la liste déroulante « Company Category » « Fournisseur » puis remplir les informations obligatoires :

• Account Manager,
• Company Name,
• Status,
• Téléphone,
• Company Type.

Nous répétons cette opération pour avoir l’ensemble de nos fournisseurs : ou alors option automatisation, en faisant l’import en masse dans Autotask via le fichier CSV.

Nous allons ensuite créer à minima un contact « SAV DELL » associé à la company DELL :

Création d’un Issue Type / Sub-Issue Type « SAV »

Afin de pouvoir qualifier au mieux les tickets, nous allons créer des types et sous-types pour refléter les demandes de SAV. Dans le menu Admin > Features & Settings > Service Desk (Tickets) > Issue & Sub-Issue Types, faire un clic sur « +New »

Faire la création d’un Issue Type Name « SAV » par exemple et créer plusieurs Issue Types avec le nom des fournisseurs.

Création d’une Ticket Catégorie « Problème »

Dans le menu Admin > Features & Settings > Service Desk (Tickets), nous allons créer un formulaire spécifique à la gestion des problèmes.

Vous pouvez partir d’une base existante en faisant un « Copy » d’un formulaire existant ou de faire un clic sur « + New » pour partir d’un modèle vierge.

Nous allons créer un modèle « Gestion SAV » :

Dans le Header, faire la configuration liée à la spécificité de formulaire problème. Nous allons définir « Problem » pour le ticket type en Default Value :

Cela va permettre de faire une personnalisation de notre formulaire pour la gestion des problèmes.

Création d’un Status de ticket « Attente fournisseur/SAV »

Dans le menu Admin > Features & Settings > Service Desk (Tickets) > Task & Ticket Statuses nous allons créer un statut « En attente fournisseur » qui valide le SLA Event « Waiting Customer » en faisant un clic sur « + New » en haut à gauche.

Nous sommes, dans cet exemple, très généraliste, nous pourrions avoir un statut pour définir une granularité « SAV Matériel » ; « SAV éditeur (Bugfix..) » ; etc.

Création de l’incident

Nous allons maintenant créer un Incident classique de type « Problème d’écran noir ».

Après une première qualification, un SAV est nécessaire. Le technicien passe donc le ticket avec un statut « En attente fournisseur » et change l’Issue Type et le Sub-Issue Type en « SAV – SAV DELL ».

Nous allons maintenant créer un ticket problème que nous allons créer et associer à ce ticket incident. Dans le menu du ticket, dans Tools > Association Incident With New Problem

Une nouvelle fenêtre s’ouvre avec un ticket type « Problem » qui est grisé. Un bandeau jaune indique que notre ticket incident va être associé à ce nouveau problème.

Nous allons modifier ici la Ticket Category pour choisir « Gestion SAV » que nous avons créé précédemment.

Nous allons ensuite faire la modification de ce ticket problème en remplissant les champs suivants :

• Titre du ticket : « SAV – Ecran Noir – ST CZC1148L3N » (ST = ServiceTag / Numéro de série)
• Company : DELL à la place de la company de votre utilisateur
• Contact : PRO SUPPORT qui est le contact de DELL
• Status : NEW
• Priority : Moyenne (peut être modifier)

Dans le bloc « Ticket Information »

• Issue Type / Sub-Issue Type : SAV / SAV DELL
• Due Date : +7 jours et l’heure du moment (peut être mis en automatique en valeur par défaut dans le formulaire).
• Queue : IT Support Niv 1 (une file de traitement spécifique peut être créée pour la gestion des SAV)
• Primary ressource : La ressource en charge des SAV.

Faire « Save », vous pouvez voir que votre ticket incident est associé à ce ticket problème dans un onglet « Incidents » du ticket problème :

Nous avons donc dans l’instance Autotask deux tickets pour le même sujet :

•  T20220117.0009 : Ticket d’incident créé par l’utilisateur
•  T20220117.0011 : Ticket problème créé par votre technicien pour la gestion du SAV

Pour connaitre les tickets problème en cours, il est possible de faire un Widget sur l’Entity Ticket, Sur un « Count of Ticket » avec deux filtres :

• Status not equal to Complete
• Ticket type equal to Problem

Ainsi on peut avoir un widget avec l’ensemble des tickets problèmes en cours :

En cliquant sur le chiffre, on retrouve notre ticket problème :

Comment faire le traitement de mes SAV ?

Même liés entre eux, le ticket incident et le ticket problème peuvent avoir un cycle de vie indépendant (création d’entrée de temps etc.).

Point important : La création d’une entrée de temps sur le ticket problème ne se matérialise pas par une entrée de temps sur les tickets incidents, mais par la création d’une note ; ce qui peut avoir un impact sur les modalités de décompte d’heures ou de facturation de vos contrats.

Dans notre exemple d’une relation 1 pour 1 (1 Incident = 1 Problème), nous allons traiter notre incident utilisateur uniquement à travers le prisme du ticket problème.

En consultant le ticket problème, le technicien a les informations nécessaires pour contacter le support constructeur/éditeur :

Le ticket est actuellement en « New ».

Le technicien va prendre contact avec le support et il va faire une entrée de temps. Dans notre exemple, nous sommes en attente de réception d'une pièce. Nous allons donc mettre le Status « En attente Matériel » puis mettre une Summary Notes :

En bas de l’internal notes, il y a possibilité de cocher la case « Create Not(e)s on this ticket’s 1 incident » afin que l’information dans la Summary Notes soit dupliquée également dans le ticket incident :

Cocher cette case avec prudence, si vous avez mis en place des Workflows de notification pour ne pas communiquer des informations trop techniques à votre client.

Après un cycle de vie sur le ticket problème, vous avez fait le remplacement de l’élément défectueux : vous avez donc la possibilité de faire la clôture du ticket Problème et Incident au cours de la même opération.

Au moment de l’entrée de temps, votre technicien va devoir faire deux actions au minimum :

• Passer le ticket sur un Status « Complete» et cocher dans la case « Update Status on 1 incidents » pour appliquer le Status à l’ensemble des tickets incidents associés aux problèmes.

• Il va également saisir une Summary Notes qu’il va appliquer sur le ticket problème et sur l’ensemble des tickets incidents associés aux problèmes en cochant ces trois cases :

Les Status des tickets sont synchronisés :

Comment faire des notifications à la clôture ?

Si vous avez mis en place un Workflow de notification standard sur le passage d’un ticket sur le Status « Complete » alors quelques ajustements vont être nécessaires.

En l’absence de modification de ce Worklflow standard :

• Le contact et contact additionnel de la Company Vendor vont être notifiés.
• Le contact et contact additionnel des tickets incidents vont être notifiés.

Dans ce premier cas, ce n’est pas forcément utile (mail de support automatique).

Dans le deuxième cas, c’est le fonctionnement attendu.

Si malgré tout vous voulez des notifications spécifiques, il est possible d’utiliser la condition dans le Workflow « Has Problem Ticket (Incident Only) » pour les tickets incidents liés à un problème.

Widget : Des statistiques !

Nous pouvons faire un :

• Widget avec la liste de l’ensemble des tickets pour le fournisseur DELL (ensemble des demandes de SAV) :

• Widget multi éditeur pour connaitre le nombre de tickets pour chacun d’entre eux. C’est un simple « Count Of Ticket » sur l’Entity Ticket avec un filtre Company Equal To {Company Vendor} :

• Widget incidentologie sur les Assets au niveau de leurs cartes mères :

• Widget incidentologie sur les Assets en fonction de leurs modèles :

👷‍ À vous de jouer ! 

• Faire la création des company VENDOR avec au moins un contact pour chacun ;
• Faire le remplissage des Sub-Issue types avec les différents type de SAV ;
• Faire l’optimisation de votre Ticket Category « Gestion SAV » pour n’avoir que les champs pertinents ;
• Faire la création des Widgets de contrôle.

Conclusion

L’inconvénient dans cet exemple est d’avoir autant de tickets problème d’éditeur avec lesquels on souhaite faire la gestion des incidents. En revanche, la fonctionnalité prend tout son sens dans le cas d’un incident Opérateur et l’ouverture de multiples tickets sur un panel d’utilisateurs de la société finale.

Les tickets incidents en cours de demande SAV restent des incidents et à ce titre peuvent toujours apparaitre dans les Widgets, sauf à mettre un filtre d’exclusion de type « Problem Ticket Number is not empty ».