TAI046 Traiter un ticket d’incident dans un service d’assistance

TAI046 Traiter un ticket d’incident dans un service d’assistance

 

TAI046 Traiter un ticket d’incident dans un service d’assistance

TABLE DES MATIERES

1 ORGANISATION 3

1.1 Organisation générale d’un Service Desk 4

1.2 Principe de fonctionnement 4

2 Prise en charge de l’utilisateur et de son appel 5

2.1 Le contact 5

2.2 Identifier l’utilisateur et son environnement matériel 5

2.3 Identifier son problème 5

2.4 Ce qu'il ne faut pas dire 5

2.5 qualification de l’appel 6

2.5.1 Principe 6

2.5.2 Aide à la décision 6

2.5.2.1 L’impact 6

2.5.2.2 L’urgence 6

2.5.2.3 La priorité 6

2.5.2.4 Exemple de grilles d’analyse : 7

3 Que deviennent les appels qualifiés? 8

4 traitement d'un appel 9

4.1 Traitement en direct 9

4.2 Traitement différé 9

4.3 Mécanisme du traitement d'un appel au niveau 1 9

4.3.1 Documenter l'intervention 9

4.3.2 Respecter les contraintes de temps 9

4.3.3 Affecter l'appel à un niveau 2 10

4.3.4 Déclencher une intervention 11

4.4 Les problèmes 11

4.4.1 Signalement des problèmes 11

4.4.2 Gestion des problèmes 11

5 Cloture d'un appel 13

5.1 Quand clôturer un appel 13

5.2 qui clôture un appel 13

6 rendre compte de l'intervention 14

6.1 Le suivi d'un appel 14

6.2 Qui fait le compte rendu d'intervention 14

6.3 Quel est le support d'un compte rendu 14

6.4 Quand faire un compte rendu d'intervention ? 14

6.5 Les rubriques d'un compte rendu d'intervention 14

6.5.1 Les rubriques renseignées à la création du compte rendu 14

6.5.2 Les rubriques renseignées lors de l'intervention 15

1 ORGANISATION

Les modèles d'organisation pour traiter les appels clients sont très variés. Ils dépendent de la nature des prestations proposées, du contexte dans lequel ils se situent et de la culture d’entreprise.

L’organisation d’une « hotline » destinée à des particuliers ou des SOHO (Small Office / Home Office) sera différente de l’organisation d’un service desk à destination de grands parcs informatiques.

ITIL (Information Technology Infrastructure Library) fournit pour la gestion des services informatiques un recueil des meilleures pratiques issues d’un grand nombre d’entreprises anglo-saxonnes. Mais chaque structure de service desk sera unique et cela pour deux raisons :

 ITIL n’est pas une norme, juste un ensemble de recommandations qui doivent être adaptées sur le terrain

 En France, à la fin 2006, 13% des entreprises appliquaient la démarche ITIL et 60% déclaraient s’y intéresser. ITIL devient un standard de fait, de façon complémentaire aux  normes d’assurance qualité telles que ISO 9001 ou ISO 20000.

Dans ce support nous allons examiner le traitement d'un appel dans ses grands principes en conformité avec ITIL.

Dans une organisation Service Desk, le traitement d’un appel utilisateur va consister à :

 Ouverture d’un dossier lors de l’appel de l’utilisateur,

 Qualifier le type d’appel, cela va consister à identifier le type de prestation attendue par l’utilisateur et à affecter une priorité à l’appel.

 Traiter l’appel, on va soit résoudre le problème soit le transférer ou l’escalader.

 Clôturer l’appel

ITIL recommande qu’il y ait un point de contact unique entre les utilisateurs et le département informatique.

Dans ITIL ce point de contact s’appelle Centre de Services (Service Desk), il est responsable du traitement de tous les appels des utilisateurs qu’ils soient occasionnés par des dysfonctionnements ou que ce soient de simples demandes.

Il doit également enregistrer tous les incidents, afin de fournir une source centrale d’information pour le management du SI (Système d’Information).

Ainsi les incidents récurrents seront requalifiés en problèmes et génèreront des changements de configuration qui permettront d’améliorer le service rendu par le SI.

L’enregistrement des incidents va également permettre de renseigner des indicateurs sur la qualité du service rendu : nombre d’appels, taux de résolution des incidents au 1er niveau, temps moyen de résolution…

Ces indicateurs permettront de chiffrer le service que vous rendez aux utilisateurs en quantité et en qualité, ce qui, au passage, justifie votre poste et votre rémunération.

Dans ce support nous emploierons le terme de Service Desk pour désigner ce point de contact, nous le préférons à Help Desk très employé jusqu’à présent mais plus restrictif.

1.1 Organisation générale d’un Service Desk

L’organisation générale d’un service desk est le plus souvent structurée en 3 niveaux.

Le niveau 1, composé de techniciens ayant une bonne connaissance des produits, dispose d'un temps limité pour répondre aux besoins des utilisateurs. C’est ce premier niveau, avec un n° d’appel unique, qui est le passage obligé de tout utilisateur ayant une demande d’assistance ou de dépannage.

Le service desk n’est pas une cellule d’accueil « boîte aux lettres », il doit résoudre la plupart des incidents dés le 1er niveau.

On considère qu’un service desk est performant quand le niveau 1 résout à peu près 80% des incidents.

Le niveau 2 est constitué de spécialistes qui disposent d'un temps plus long pour résoudre les incidents et qui ont rarement les utilisateurs en ligne.

Très souvent, le niveau 3 ne fait pas partie de la cellule Service Desk, il se trouve chez l'éditeur du logiciel ou le constructeur du matériel.

1.2 Principe de fonctionnement

Le service desk est le niveau 1. Il reçoit les appels, pour traiter les appels, il dispose d'un temps limité. S'il parvient à traiter l'appel, celui-ci est clôturé. S'il n'y parvient pas, il a deux possibilités : 

 déclencher une intervention sur place ou faire intervenir un fournisseur tiers (dans le cas d'une garantie, par exemple)

 Soumettre l’incident au niveau 2 si ce dernier dépasse ses compétences.

Dans tous les cas de figure, il devra ouvrir le dossier d’appel, suivre le déroulement de l'intervention, tenir informé l’utilisateur et déterminer si l'appel peut être clôturé.

Le niveau 2 va intervenir sur les cas qui nécessitent une connaissance plus pointue d'un domaine. Il dispose d'un délai plus long pour résoudre les incidents, le délai dépend des contrats de services passés avec l'utilisateur. 

Dans le cas où il ne pourrait traiter l’incident, il remonte ce dernier au niveau 3.

Le niveau 3 est le niveau « expert », très souvent il s’agit des éditeurs et constructeurs.

2 Prise en charge de l’utilisateur et de son appel

Lorsqu'un utilisateur vous appelle, ce qu'il attend de vous, ce n'est pas forcément une réponse immédiate, mais que vous preniez en charge son incident et que vous ne le laissiez pas tomber. 

Si quelques prestataires font correctement leur travail, avec les autres, deux cas de figures peuvent se produire :

 on dit que l'on va vous rappeler et on vous oublie

 on ne répond pas à votre question, mais à une autre

Le premier cas de figures peut être résolu en suivant la demande d'intervention depuis l'appel de l’utilisateur jusque sa résolution (il s'agit donc d'un problème d'organisation et de méthode résolue si l’on suit les recommandations d’ITIL) et pour le deuxième cas de figure, c'est avant tout un problème de communication.

2.1 Le contact

Le technicien de service desk doit dans un premier temps s'identifier formellement, rassurer son utilisateur et parfois même le calmer. 

Il n'est pas à exclure que ce dernier vous passe un savon, prenez-le avec bonne humeur et laissez passer l'orage ou alors changez de métier…

2.2 Identifier l’utilisateur et son environnement matériel

L'identification est très importante, car elle permet de connaître la nature de la prestation que vous êtes tenu de lui offrir.

Vous devez également identifier le matériel sur lequel il travaille : marque et modèle du PC ou du périphérique, type de réseau, système d'exploitation et logiciels.

2.3 Identifier son problème

Pour identifier le problème de l’utilisateur, vous disposez de 3 à 5 minutes environ. Avant de chercher à le résoudre, il faut d'abord l'écouter et surtout s'assurer que l'on a compris. Pour cela vous utiliserez toutes les techniques de l'entretien de recueil d'informations à savoir : écoute, reformulation, relance, synthèse partielle et synthèse finale.

2.4 Ce qu'il ne faut pas dire

Beaucoup d’utilisateurs risquent de vous demander quand le technicien va intervenir et combien de temps cela va durer. Pour la première question, vous n'apporterez de réponse que si vous êtes en mesure de planifier dans l'immédiat l'intervention. Si ce n'est pas vous qui planifiez, vous ne devez pas apporter de réponse, vous risqueriez de mettre votre technicien dans l'embarras et de nuire à l'image de marque de votre service. Il sera préférable de rassurer l’utilisateur en lui assurant le meilleur service dans les délais prévus contractuellement.

De même pour la durée d'une intervention, si cela sort du cadre de votre compétence, vous ne devez avancer aucun chiffre. Si vous annoncez une heure et que trois heures sont facturées, l’utilisateur n'aura pas oublié ce que vous avez avancé.

2.5 qualification de l’appel

2.5.1 Principe

Face à une demande d'intervention, le technicien de service desk de 1er niveau se trouve confronté à l'alternative suivante : traiter la demande dans l'immédiat, faire appel à un spécialiste et différer l'intervention. Il doit affecter une priorité à l’appel, c’est ce qu’on appelle la qualification de l’appel. S’il prend la décision de faire appel à un spécialiste il effectue ce que l’on appelle un transfert.

   Le transfert ne doit pas être confondu avec l’escalade. On appelle .escalade l’action qui consiste à transmettre au spécialiste un incident que le technicien de service desk aurait dû résoudre lui-même. 

Beaucoup de techniciens de service desk de 1er niveau en herbe, ont la mauvaise habitude de vouloir traiter tous les incidents eux-mêmes en direct. Ce choix peut être mauvais et ce pour plusieurs raisons :

 La durée de l'intervention au téléphone ou avec un autre moyen de communication monopolise le technicien de service desk de 1er niveau qui ne peut prendre d'autres appels.

 Un spécialiste interviendra plus rapidement et plus efficacement.

 Agir dans la précipitation n'est pas forcément le meilleur service à rendre.

   La durée d'une intervention faite par un technicien de service desk de 1er niveau ne doit pas excéder, en général  plus de 10 minutes, au-delà il faut passer la main à un spécialiste.  

2.5.2 Aide à la décision

Trois paramètres vont vous permettre de qualifier un appel, ce sont :

 L’impact (ou sévérité)

 L’urgence

 La priorité

2.5.2.1 L’impact

Permet de mesurer le volume et l’ampleur d’un incident : toute l’entreprise, un service, un VIP, un utilisateur.

Ainsi un incident sur un serveur aura un impact plus important qu’un incident sur un poste de travail.

2.5.2.2 L’urgence

Ce paramètre permet de mesurer la criticité d’un incident par rapport à l’activité de l’utilisateur : bloqué, ralenti, peut vivre avec.

2.5.2.3 La priorité

C’est la vitesse à laquelle l’incident doit être résolu en fonction de l’impact et de l’urgence.

Ce paramètre est en général associé à un délai de résolution contractuel.

2.5.2.4 Exemple de grilles d’analyse :

Détermination des priorités

 IMPACT 

URGENCE Toute l’entreprise Un service, un VIP Un utilisateur 

Bloqué 1 2 3 

Ralenti 2 3 4 

Peut vivre avec 4 4 4 

Indicateurs de traitement des priorités

  1 2 3 4 

Temps de détection 1 mn 5 mn 10 mn 30 mn 

Taux de réussite 99% 98% 97% 95% 

Temps de résolution 10 mn 30 mn 1 h 24 h 

Taux de réussite 98% 97% 95% 90% 

Délais maximum 1 h 2 h 4 h 5 jours 

3 Que deviennent les appels qualifiés?

La qualification des appels revient à classer les appels de vos utilisateurs par priorité.

L'activité de qualification d'appel n'est pas plus simple que celle qui consiste à faire des interventions de premier niveau. 

Une erreur à ce niveau peut être lourde de conséquences. Si vous qualifiez mal une panne bloquante d'un serveur, votre entreprise ou votre client peuvent avoir une perte de chiffre d’affaire …ou plus grave encore…

4 traitement d'un appel

4.1 Traitement en direct

Un appel est traité en direct lorsque c'est le technicien qui a qualifié l'appel qui le prend en charge. Il n'y a donc pas de rupture entre le moment où le client appelle et le moment où l'on traite son appel.

   Le temps alloué pour traiter un appel au premier niveau est généralement limité. Si l'intervention est trop lourde ou trop compliquée, il ne faudra pas la traiter à ce niveau. Par contre, il faudra que la majorité des incidents soient résolus à ce niveau, c’est la toute la difficulté du système ! 

4.2 Traitement différé

Lorsque le technicien qui qualifie l'appel l'affecte à un autre intervenant, cet appel sera traité en différé. Dans ce cas c'est l’utilisateur qui sera rappelé.

En fonction de la qualification de l'appel, le traitement différé sera de niveau 1 ou 2. Si l'appel est transféré à un spécialiste il s’agira de niveau 2 (on parlera alors de transfert). Si une intervention sur site est déclenchée, cela pourra être des niveaux 1 ou 2 selon la nature de l’intervention.

4.3 Mécanisme du traitement d'un appel au niveau 1

4.3.1 Documenter l'intervention

Quel que soit le cas de figure, il y aura toujours un suivi de l'intervention. Le technicien devra toujours laisser une trace de son diagnostic et de ce qu'il a fait. Il y a deux raisons à cela :

 Avoir un historique des interventions chez le client

 Informer de ce qui se passe et de ce qui a été fait pour le cas où vous affecteriez l'appel à un spécialiste. 

4.3.2 Respecter les contraintes de temps

Selon les organisations, le temps alloué pour résoudre l'appel peut varier. Dans les hotlines grand public, cette durée est de l'ordre de 10mn. Toutefois en fonction de la file des appels en attente, cette durée peut être allongée ou, au contraire, aux heures de forte affluence elle peut être réduite.

Les contraintes de temps se justifient par le fait que si vous passez trop de temps avec un utilisateur, la file d'attente s'allonge et vos utilisateurs en file d'attente vont raccrocher. Cela va générer du mécontentement et ces utilisateurs vont rappeler ultérieurement ce qui va à nouveau encombrer la file d'attente. De plus lorsque l’utilisateur arrivera à avoir un technicien, il sera quelque peu énervé…

   Dans le jargon officiel les utilisateurs qui raccrochent sont appelés des … "Raccrochés". Il fallait y penser.  

4.3.3 Affecter l'appel à un niveau 2

Plusieurs cas de figures peuvent amener le technicien de niveau 1 à affecter un appel au niveau 2.

 Il n'a pas assez de temps

 Il n'a pas les compétences suffisantes pour traiter le problème

 Il a pris en charge l'appel et il n'arrive pas à le résoudre…

Le technicien manque de temps

Lorsque le technicien, bien qu'il soit compétent pour le faire, s'aperçoit que le problème à résoudre ne pourra pas l'être dans le temps imparti, il va affecter l'appel au niveau 2.

De même, lorsque le technicien a commencé à traiter l'appel et qu'il s'aperçoit qu'il approche du temps limite et qu'il est loin de la solution, il va affecter l'appel au niveau 2.

Dans ces deux cas de figure, il aurait pu traiter l'appel, c'est le manque de temps qui l'en a empêché. L'action qui consiste à affecter l'appel au niveau 2 s'appelle une escalade.

   Inutile de dire qu'il est préférable de s'apercevoir rapidement qu'on ne pourra traiter un problème…  

Le problème dépasse ses compétences

Dans ce cas de figure, le technicien va affecter l'appel à un spécialiste, cette action se nomme un transfert.

   La distinction entre transfert et escalade n’est pas pratiquée partout et ne figure pas dans ITIL 

Le technicien ne parvient pas à résoudre le problème

Deus cas de figure peuvent générer cette situation. L'un va générer un transfert, l'autre une escalade.

Imaginons que le technicien dispose d'une procédure de dépannage qu'il doit suivre pas à pas. Si le problème n'est pas résolu à l’issue du déroulement de la procédure, cela signifie que cela dépasse ses compétences. Il va donc effectuer un transfert.

Imaginons maintenant, que le technicien qui fait de l'assistance bureautique ne parvienne pas à résoudre un problème d'utilisation courante (générer une table des matières sous Word par exemple), il va faire appel au niveau 2 afin de  résoudre le problème du client. Nous sommes dans le cas de figure où, malgré que le problème soit de niveau 1, on a dû faire appel au niveau 2. C'est donc une escalade.

   Les pratiques varient considérablement d’une organisation de service desk à l’autre.

Chez certains, la distinction entre transfert et escalade n’existe pas, chez d’autres au contraire on va faire la chasse aux escalades et aux raccrochés, vous rencontrerez aussi des Service Desk où le niveau 2 n’existe pas.  

4.3.4 Déclencher une intervention

Lorsque de toute évidence le problème est matériel, le technicien ne pourra faire l'intervention à distance. Dans ce cas de figure il peut déclencher une intervention sur le site de l’utilisateur.

   N'oubliez pas qu'à ce stade, l'appel à été qualifié et que le technicien sait ce à quoi peut prétendre l’utilisateur en termes d'intervention. 

Pour déclencher l'intervention, le technicien devra pouvoir remplir une demande d'intervention. Sur cette demande, on trouvera, bien entendu les coordonnées de l’utilisateur ainsi que l'identification de l'équipement concerné.

Le cas échéant on indiquera le délai d'intervention. Mais il faudra surtout faire un diagnostic précis du problème rencontré pour ne pas envoyer le technicien dans l'inconnu.

Si le technicien n'est pas en mesure de réaliser ce diagnostic, il n'a pas forcément les compétences, il ne déclenchera pas l'intervention, il la transférera au niveau 2 et c'est ce dernier qui déclenchera ou non l'intervention.

4.4 Les problèmes

Quand la cause d’un incident ne peut pas être identifiée, cet incident pour ITIL est requalifié en « problème ».

Quand la cause est trouvée le problème est requalifié en « erreur connue ».

Ce processus de transformation des problèmes en erreurs connues pousse l’entreprise au changement.

4.4.1 Signalement des problèmes

Il appartient au technicien de Service Desk, c'est-à-dire vous, d’enregistrer les problèmes.

La forme de cet enregistrement variera selon l’organisation du Service Desk auquel il appartient, on peut dire schématiquement que le problème sera enregistré dans une base de données (la même que celle où sont enregistrés tous les incidents).

4.4.2 Gestion des problèmes

Un problème est la cause sous-jacente inconnue d’un ou plusieurs incidents. Il devient une erreur connue lorsque la cause à l’origine de ce problème est connue et une solution de contournement provisoire ou permanente a été identifiée.

Qui va gérer les problèmes ?

C’est au technicien de Service Desk de signaler les problèmes.

Pour le travail de recherche des causes d’incidents, cela varie selon les organisations : cela peut être le travail du niveau 2 ou bien le travail de groupes avec une spécialité technique au niveau 1 (groupe bureautique, groupe réseau, groupe poste de travail…).

La tendance actuelle va vers le niveau 1 à qui l’on demande de plus en plus de compétences techniques et d’autonomie.

Quand la cause est identifiée le problème devient une erreur connue, qui doit être enregistrée dans la base de données.

Dans ITIL cette base de données s’appelle la CMDB : Configuration Management Database.

Cette base de données sera à la disposition des techniciens Service Desk, mais pourra aussi être à la disposition des utilisateurs de différentes manières (à travers des FAQ par exemple).

Cela aura pour effet :

1. d’améliorer l’efficacité du support,

2. d’identifier des incidents récurrents,

3. de supprimer la cause du problème en améliorant l’existant (formation des utilisateurs, modification de configuration matérielle, application de services packs ou changement de version de logiciels, amélioration du réseau, amélioration des procédures de sécurité…).

5 Cloture d'un appel

Une règle d'or en assistance informatique : tous les appels doivent être clôturés.

La clôture d'un appel, comme toutes actions en Service Desk, obéit à certaines règles. Il faut savoir quand clôturer un appel et savoir qui peut le clôturer.

5.1 Quand clôturer un appel

Un appel ne peut être clôturé que lorsqu'une solution définitive qui permet de résoudre l’incident a été apportée.

Une solution définitive est une solution qui résout complètement l’incident. Selon le contexte une même solution peut être temporaire ou définitive.

Prenons le cas d'un appel consécutif à une panne d'imprimante. La solution qui consiste à mettre en place une nouvelle imprimante peut être considérée comme une solution temporaire, il s'agit alors d'un prêt. Elle peut être également considérée comme définitive, il s'agit alors d'un remplacement.

   C'est le contrat passé avec le client qui, généralement, détermine s’il s'agit d'un prêt ou d'un remplacement. 

Dans le cas de figure où il s'agit d'un prêt, l'appel ne peut être clôturé. S’il s'agit d'un remplacement l'appel peut être clôturé.

5.2 qui clôture un appel

Dans la mesure où une seule personne doit suivre un appel, il ne peut s'agir que de la personne qui a ouvert le dossier d'appel. Cette personne doit en assurer le suivi et ce, jusqu’à la clôture du dossier d'appel.

C’est donc le technicien de niveau 1 du Service Desk qui a ouvert le dossier d’appel et qui en a effectué le suivi, qui devra clôturer l’appel.

6 rendre compte de l'intervention

Pour que la décision de clôturer un appel soit prise, il est nécessaire de connaître dans le détail la ou les interventions qui ont été déclenchées suite à cet appel.

6.1 Le suivi d'un appel

De multiples événements peuvent se produire pendant la prise en charge d'un appel.

Le cas le plus simple est le suivant :

1. Un technicien du niveau 1 prend l'appel

2. Ce dernier réalise l'intervention et remplit un compte rendu d'intervention

3. Le technicien du niveau 1 clôture l'appel.

Si les étape 1et 3 sont toujours les mêmes, il en va tout autrement pour l'étape 2.

En effet, le technicien de niveau 1 n'est pas toujours en mesure de réaliser l'intervention.

Il peut soit l'escalader, soit la transférer... et dans ce cas un autre technicien va réaliser une intervention qui donnera lieu à un autre compte rendu d'intervention… etc.

Afin de pouvoir, à tout instant, suivre un appel, il est impératif que chaque intervenant informe l’initiateur de l'appel qu'il prend en charge cet appel et qu'il rédige systématiquement un compte rendu d'intervention.

Vous voyez que tout cela peut devenir très compliqué et qu'il convient d'examiner plus en détail la création et la rédaction des comptes rendus d'intervention.

6.2 Qui fait le compte rendu d'intervention

La règle dans ce domaine est simple, c'est la personne qui réalise l'intervention qui réalise le compte rendu.

6.3 Quel est le support d'un compte rendu

Le support d'un compte rendu peut être sous deux formes: une forme électronique ou une forme papier.

6.4 Quand faire un compte rendu d'intervention ?

Un compte rendu devra systématiquement être fait à chaque intervention.

6.5 Les rubriques d'un compte rendu d'intervention

6.5.1 Les rubriques renseignées à la création du compte rendu

A la création les rubriques renseignées seront :

 Un numéro d'intervention

 Les coordonnées de l’utilisateur

 Le numéro de contrat du client

 Le montant de l'intervention dans le cadre d'une intervention non contractuelle

 L'identification du ou des matériels concernés

 Le descriptif de l’incident

 La nature de l'intervention à réaliser

6.5.2 Les rubriques renseignées lors de l'intervention

 L'identification des pièces fournies ou échangées

 Le temps passé

 L'heure de début et de fin

 Le descriptif de l'intervention

 Une information sur la fin de l'intervention ou sur la suite à donner

 La signature du technicien et de l’utilisateur (et son identification : nom et fonction).

   Toutes les personnes ne sont pas habilitées  à signer un document. Une signature non habilitée n'engage pas la société de cette dernière.