Centre de services, gestion des incidents et gestion des problèmes

Le support commence par l’identification de ce qui s’est passé. Une pratique réunit les personnes, les informations, les outils, les partenaires et les méthodes de travail nécessaires pour atteindre un objectif. Les sept pratiques de support partagent des informations, mais leurs finalités diffèrent.

Classer la situation

Un incident n’implique pas nécessairement une interruption totale. Une page de notes de frais qui s’ouvre normalement en 2 secondes mais qui en prend désormais 40 a subi une réduction de qualité. La gestion des problèmes recherche les causes des incidents et les causes potentielles avant qu’elles ne perturbent le service. Un seul incident peut justifier ce travail ; de nombreux incidents peuvent avoir un même problème en commun.

Un événement concerne un état observé. Un avertissement concernant un disque peut permettre d’agir avant qu’un utilisateur ne perde le service. Si un événement montre que le service est interrompu ou dégradé, la gestion des incidents doit aussi intervenir. Les enregistrements de l’événement et de l’incident décrivent différents aspects d’une même situation.

Un élément de configuration, ou CI, est un composant qui doit être géré pour fournir un service. Les serveurs, bases de données, commutateurs réseau et licences logicielles peuvent être des éléments de configuration. Relier les enregistrements à ces éléments aide le personnel à voir quels service et composant sont concernés.

Distinguer la cause de l’atténuation

Une erreur connue est un problème qui a été analysé mais reste non résolu. L’analyse n’a pas nécessairement établi la cause sous-jacente et une solution de contournement peut ne pas encore exister. Une solution de contournement réduit ou élimine l’impact tant qu’une résolution complète n’est pas disponible ; certaines réduisent aussi la probabilité de nouveaux incidents.

Pour le problème de VPN, une reconnexion manuelle après la sortie de veille de l’ordinateur portable permet de continuer à travailler. Cette solution de contournement peut résoudre l’incident actuel d’un utilisateur alors que le problème reste ouvert. Qualifier le problème d’erreur connue indique qu’il a été analysé ; cela ne signifie pas qu’une solution définitive existe.

Choisir la pratique qui effectue le travail

Le centre de services recueille les demandes des utilisateurs. La gestion des incidents rétablit le service ; la gestion des problèmes gère les causes, les solutions de contournement et les erreurs connues. La gestion des demandes de service exécute les demandes prédéfinies. La surveillance et la gestion des événements observent les services et répondent aux changements qui présentent un intérêt. La gestion des niveaux de service convient d’objectifs fondés sur les besoins métiers et les vérifie. La gestion des relations développe les liens avec les parties prenantes qui soutiennent ces accords.

Classe la situation à l’origine du contact d’après les faits. Un mot de passe oublié donne généralement lieu à une demande de réinitialisation. Un serveur de connexion en panne crée des incidents. Enregistrer la commande d’un ordinateur portable pour une nouvelle recrue comme un incident gonfle le nombre de pannes et conduit à appliquer les mauvais objectifs, même si l’utilisateur l’a soumise au moyen du formulaire d’incident.

Le centre de services recueille les demandes de résolution d’incidents et les demandes de service. Il sert de point de contact unique entre les utilisateurs et le fournisseur de services. Les utilisateurs disposent d’un point clairement identifié pour demander de l’aide, même lorsque plusieurs équipes doivent contribuer au résultat.

Assurer la continuité des échanges

Chaque contact doit recevoir un accusé de réception, être classé, confié à un responsable et faire l’objet d’une action. Le centre résout ce qu’il peut et oriente le travail spécialisé vers les bonnes personnes. Il reste responsable du contact avec l’utilisateur pendant leur intervention : il communique les progrès, indique à quoi s’attendre et vérifie que le résultat convient à l’utilisateur.

Les utilisateurs peuvent contacter le centre par téléphone, portail, application mobile, courrier électronique, messagerie instantanée, agent conversationnel, accueil sur place, SMS, messagerie sur les réseaux sociaux ou forum communautaire. Un système d’enregistrement partagé conserve l’historique entre les canaux. Une personne qui passe de la messagerie instantanée à un appel ne devrait pas avoir à raconter de nouveau son histoire.

Organiser les équipes autour du service

Un transfert de prise en charge dans le cadre du support follow-the-sun nécessite un enregistrement exploitable : impact actuel, travail effectué, prochaine action et point d’information promis. L’équipe suivante peut poursuivre le travail et les échanges sans dépendre de la connexion de l’agent précédent.

À mesure que le libre-service prend en charge davantage de tâches simples, les agents consacrent plus de temps à aider les personnes dans leurs situations de travail. Une connaissance concrète de l’organisation les aide à comprendre pourquoi une tâche bloquée est importante. Un problème de paie à l’approche d’une échéance n’a pas la même urgence que le même symptôme pendant une période calme.

Le personnel a besoin d’empathie, d’une communication claire, d’intelligence émotionnelle et de compétences pour analyser les incidents et définir leur priorité. Tous les agents n’ont pas besoin d’être des experts techniques très spécialisés. Un point d’information efficace pourrait dire : « Je comprends que cela bloque ton rapport de fin de mois. L’équipe réseau travaille sur le problème et je t’appellerai au plus tard à 11 h 30 pour te tenir informé. » Il relie le travail de l’utilisateur à une action et à un prochain contact fiable.

Fournir des informations utiles aux agents

La téléphonie intelligente aide à gérer les appels et les rappels. Les outils de gestion des circuits de traitement orientent le travail et les escalades. Les articles de la base de connaissances permettent d’appliquer les solutions de manière reproductible ; les outils d’accès à distance aident les agents à assister les utilisateurs. L’enregistrement des appels et les contrôles qualité soutiennent l’accompagnement des agents. Les tableaux de bord et la surveillance montrent la situation actuelle, tandis que les informations de configuration révèlent les composants dont dépend un service.

Mesurer l’expérience autant que la rapidité

Le taux de résolution au premier contact est la part des contacts résolus dès le premier échange, sans transfert ni rappel. Pour 780 résolutions au premier contact sur 1 200 contacts :

Le délai moyen de réponse, le taux d’abandon et la satisfaction des utilisateurs apportent des éclairages différents. Le taux d’abandon compte les appelants qui raccrochent avant la réponse d’un agent. Une hausse du taux de résolution au premier contact peut masquer des solutions peu fiables si les utilisateurs reviennent rapidement pour le même problème ; examine donc aussi la qualité et les contacts répétés.

Les enregistrements du centre soutiennent également les autres pratiques. Les symptômes répétés aident à identifier les problèmes, les plaintes alimentent la gestion des relations et les données de réponse et de satisfaction soutiennent les revues des niveaux de service.

La surveillance et la gestion des événements observent systématiquement les services et les composants, enregistrent certains changements qui présentent un intérêt et déclenchent des réponses adaptées. Elles aident les équipes à agir face aux situations qui apparaissent comme aux défaillances qui ont déjà touché les utilisateurs.

De la mesure à l’événement

La surveillance peut observer la charge du processeur, l’utilisation de la mémoire, le délai de réponse d’un site web, les tâches planifiées ou la température d’un centre de données. La gestion des événements détermine quels changements présentent un intérêt, comment les enregistrer et quelle réponse leur apporter. Son périmètre comprend les événements liés à l’infrastructure, aux services, aux processus métiers et à la sécurité de l’information.

Une exception appelle une action, mais son effet sur le service doit encore être évalué. Un composant peut tomber en panne tandis que la redondance maintient le service en fonctionnement. Crée un incident lorsque l’événement révèle un service interrompu ou dégradé.

Calculer le temps disponible

Un disque de 500 Go a un seuil d’avertissement à 80 % et un seuil d’exception à 95 %. Calcule d’abord l’espace utilisé à chaque seuil :

L’espace restant entre les deux seuils est de 75 Go. Si le remplissage se poursuit à environ 10 Go par jour :

L’avertissement donne le temps d’agir. Cette estimation suppose que le rythme de remplissage reste le même ; les mesures actuelles restent donc utiles pendant que l’équipe prévoit de la capacité.

Réduire le bruit et révéler les causes communes

Choisis ce qu’il faut surveiller en fonction des objectifs de service et des risques. Définis des seuils, filtre les événements qui ne nécessitent pas d’attention et établis une corrélation entre les événements liés. Si la panne d’un commutateur réseau rend inaccessibles 40 serveurs connectés, la corrélation regroupe leurs alertes et attire l’attention sur le commutateur commun.

Déclencher une alerte pour chaque événement enregistré crée une fatigue liée aux alertes. Des messages fréquents qui ne conduisent à aucune action utile apprennent aux personnes à ignorer les alertes. Chaque alerte doit avoir un responsable et une action associée. Conserve les événements d’information habituels dans les journaux et examine les seuils qui demandent régulièrement de l’attention sans produire de travail utile.

Les réponses peuvent comprendre un redémarrage automatique, une notification, un enregistrement d’incident, un enregistrement de problème pour une situation récurrente ou une demande de changement pour augmenter la capacité. Certains événements restent simplement dans le journal pour une analyse ultérieure. Même automatisée, une réponse doit être accompagnée d’une règle claire précisant quand elle s’applique.

Vérifier ce que les utilisateurs peuvent réellement faire

Des composants dont les mesures sont normales peuvent coexister avec un service en panne. Un contrôle de bout en bout, comme une transaction synthétique qui se connecte et effectue un achat test toutes les 5 minutes, vérifie un résultat utilisateur à travers les composants. Les tendances de surveillance aident ensuite la gestion des problèmes à repérer des récurrences et la gestion des niveaux de service à rendre compte de la disponibilité et des performances.

La gestion des incidents réduit au minimum l’impact négatif des incidents en rétablissant le service normal aussi vite que possible. Chaque incident est enregistré et géré au regard d’attentes de résolution réalistes, convenues et communiquées. Les signalements peuvent venir des utilisateurs, de la surveillance, des fournisseurs ou du personnel.

Enregistrer assez d’informations pour permettre à une autre personne d’agir

Un enregistrement utile indique les personnes touchées et comment les joindre, le service et les éléments de configuration concernés, l’heure de détection et les symptômes. Il contient aussi la catégorie, l’impact, l’urgence, la priorité, le groupe auquel l’incident est affecté, les actions et la résolution. Des liens vers les changements, problèmes, erreurs connues et articles de la base de connaissances associés évitent de répéter les investigations.

Par exemple : « Depuis 9 h 40, les lecteurs de l’entrepôt du dépôt nord ne peuvent pas transmettre les confirmations de livraison ; environ 30 employés sont concernés. » L’agent suivant dispose ainsi de l’effet sur le service, du lieu, de l’heure et de l’ampleur du problème. Enregistre les découvertes et les actions ultérieures au fur et à mesure afin que l’historique reste exploitable.

La catégorisation regroupe les incidents par type, par exemple « Réseau > Wi-Fi » ou « Application > Paie ». Une catégorie correcte oriente le travail vers les personnes disposant des bonnes compétences et permet une analyse fiable des tendances. Un mauvais classement peut entraîner à la fois des retards immédiats et des données trompeuses pour l’analyse ultérieure des problèmes.

Décider de ce qui doit être traité en premier

L’impact décrit l’effet sur l’activité : utilisateurs touchés, importance du service et conséquences financières, juridiques ou sur la sécurité des personnes. L’urgence décrit la vitesse à laquelle le préjudice augmente ou le délai dans lequel le service doit être rétabli. La priorité combine les deux pour déterminer l’ordre de traitement.

Les organisations définissent leurs propres matrices. Voici un exemple courant à cinq niveaux :

Une panne du paiement en magasin qui touche tous les clients un jour de promotion a un impact élevé et une urgence élevée, ce qui donne la priorité 1 dans cette matrice. Un système de paie indisponible pour l’équipe des ressources humaines, avec un traitement prévu le lendemain, a un impact moyen et une urgence élevée, soit la priorité 2. Un second écran qui clignote et pour lequel un écran de remplacement est disponible a un impact faible et une urgence faible, soit la priorité 5.

Une personne haut placée qui appelle peut avoir un besoin métier urgent, mais son rang et le nombre de plaintes ne déterminent pas la priorité. Demande quel travail est bloqué et à quel moment les conséquences deviennent graves. Applique la matrice convenue à ces faits.

Distinguer la réponse du rétablissement

Pour un incident de priorité 2, supposons que les objectifs soient une réponse sous 30 minutes et une résolution sous 4 heures. Un enregistrement ouvert à 13 h 10 est pris en compte et affecté à 13 h 25 : la réponse prend 15 minutes. Le service est rétabli à 16 h 40, soit un délai de résolution de 3 heures et 30 minutes. Les deux objectifs sont atteints et mesurent des étapes différentes.

Les incidents à faible impact doivent être traités efficacement ; ceux à fort impact peuvent nécessiter davantage de personnel et d’attention de la direction. Un modèle d’incident fournit des étapes prédéfinies pour un type d’incident connu, comme une imprimante hors ligne, notamment les vérifications et l’affectation. Il fait gagner du temps sans décider de la priorité de chaque nouvelle situation.

La personne qui enregistre un incident n’est pas forcément celle qui rétablit le service. Les utilisateurs, les agents du centre, les spécialistes, les fournisseurs et les équipes temporaires peuvent tous contribuer. Une responsabilité clairement attribuée et des transferts de prise en charge utiles font avancer le travail tout en donnant à l’utilisateur un interlocuteur fiable.

Faire intervenir les bonnes personnes

Le support par niveaux répartit le travail selon l’expertise. Une organisation courante place le centre de services au niveau 1, les spécialistes des réseaux ou des applications au niveau 2 et les experts très spécialisés, les développeurs ou les fournisseurs au niveau 3. Les organisations choisissent leur propre structure et leur propre numérotation.

Le swarming réduit les attentes et les transferts répétés lorsque la responsabilité n’est pas claire au départ. Invite les personnes concernées et libère-les lorsque leur contribution n’est plus nécessaire. L’effort total dépend de l’organisation du travail en groupe ; mobiliser de nombreuses personnes sur un incident simple leur fait perdre du temps.

Pendant l’investigation, utilise les articles de la base de connaissances, les erreurs connues, la surveillance et les enregistrements des changements récents. Un transfert utile indique le service touché, ce qui a déjà été essayé et le résultat obtenu. Réaffecter le ticket sans ces informations risque d’entraîner une répétition du travail. Un même responsable reste chargé de l’incident jusqu’à sa clôture, même lorsque le groupe technique affecté change.

Juger la résolution d’après le service

La résolution signifie que le service normal est rétabli. Elle peut résulter d’une solution définitive ou d’une solution de contournement. Supposons qu’un serveur d’impression en panne empêche l’impression des bulletins de paie. Le niveau 2 redirige les impressions vers un serveur de secours en 25 minutes. Les utilisateurs peuvent de nouveau imprimer : l’incident est donc résolu, tandis que la gestion des problèmes peut rechercher pourquoi le premier serveur est tombé en panne.

Un redémarrage qui laisse les utilisateurs dans l’impossibilité d’imprimer n’a pas résolu l’incident. Le marquer comme résolu pour atteindre un objectif ne produit que des rapports trompeurs et des tickets rouverts. Vérifie le résultat pour le service en demandant confirmation à l’utilisateur et en effectuant les contrôles pertinents.

Tenir les utilisateurs informés et clôturer l’enregistrement

Conviens d’intervalles pour les points d’information et utilise un langage simple. Par exemple : « Les impressions sont redirigées vers un autre serveur. Elles devraient fonctionner d’ici 14 h 30 et nous te le confirmerons. » Explique l’effet sur le service, l’action entreprise et le prochain point d’information sans demander aux utilisateurs d’interpréter les journaux techniques.

La clôture comprend la confirmation que le service convient à l’utilisateur, l’enregistrement de la résolution, la catégorie finale correcte et les liens vers les problèmes ou erreurs connues associés. Mets à jour les articles de la base de connaissances lorsque l’incident révèle une étape réutilisable. Certaines organisations clôturent un enregistrement résolu après un délai défini, par exemple 3 jours ouvrés, si l’utilisateur ne répond pas ; la règle de clôture fait partie du processus convenu.

Les soupçons de logiciel malveillant, les compromissions de compte ou les fuites de données peuvent être signalés au même centre. Enregistre le signalement et transmets-le au processus dédié de réponse aux incidents de sécurité de l’organisation. Les situations de sinistre déclenchent les plans de reprise après sinistre de l’organisation.

Un incident majeur a un impact sur l’activité suffisamment important pour nécessiter une réponse dédiée et coordonnée. L’organisation définit ses critères. Une interruption touchant de nombreux clients ou une panne du système de paiement peut y répondre, et les incidents majeurs correspondent généralement à la priorité la plus élevée.

Déclarer l’incident selon son impact et coordonner la réponse

N’attends pas de connaître la cause pour déclarer un incident majeur. La déclaration permet à l’organisation de réunir les bonnes personnes pendant que l’investigation se poursuit. Si des éléments ultérieurs montrent que l’impact est moindre, le niveau de l’incident peut être abaissé.

Un gestionnaire des incidents majeurs désigné coordonne les priorités, les actions et les décisions. Des spécialistes, des fournisseurs et des représentants métiers peuvent former une équipe d’intervention temporaire. C’est du swarming à plus grande échelle : l’équipe travaille ensemble au rétablissement, avec une responsabilité de coordination clairement attribuée.

La communication doit avoir son propre responsable. Informe les parties prenantes à intervalles réguliers, par exemple toutes les 30 minutes. Un bandeau sur le portail ou une page d’état montre que le problème est connu et réduit les appels concernant le même problème. Sépare les points d’information métiers de l’appel technique afin que les ingénieurs puissent se concentrer et que les parties prenantes reçoivent des informations claires.

Suivre l’interruption des paiements

À 9 h 12, la surveillance détecte que tous les paiements par carte aux caisses des magasins échouent. Le premier magasin appelle à 9 h 15. L’organisation déclare un incident majeur à 9 h 18 et réunit l’équipe à 9 h 20.

À 9 h 35, les parties prenantes reçoivent le premier point d’information. À 9 h 50, l’équipe identifie le renouvellement d’un certificat de la passerelle de paiement effectué à 9 h 00. À 10 h 05, le changement est annulé et les paiements fonctionnent à nouveau. Le rétablissement a pris 53 minutes depuis la détection :

La surveillance confirme que le service est stable à 10 h 20, au moment où le dernier point d’information est envoyé. Cette confirmation ultérieure est distincte du rétablissement à 10 h 05. Enregistrer les deux rend la chronologie et le calcul du niveau de service plus clairs.

Tirer des enseignements après le rétablissement

Une revue après incident examine ce qui s’est passé, le déroulement de la réponse et les améliorations à apporter. Une revue sans recherche de coupable cherche à comprendre quelles conditions techniques et organisationnelles ont permis la défaillance. Les personnes peuvent signaler plus librement les contrôles manquants et les décisions confuses lorsque la discussion cherche des améliorations plutôt qu’un coupable.

Attribue les actions d’amélioration à des responsables et prévois un moyen de vérifier leur réalisation. Un incident majeur est aussi un déclencheur important pour la gestion des problèmes, car sa répétition pourrait avoir un impact grave. L’investigation peut mener à une solution définitive par l’habilitation des changements. La gestion des niveaux de service rend compte de l’interruption au regard des objectifs convenus, et la gestion des relations explique son effet et le plan de prévention aux responsables métiers concernés.

La gestion des problèmes réduit la probabilité et l’impact des incidents en identifiant leurs causes réelles et potentielles et en gérant les solutions de contournement et les erreurs connues. Elle utilise les éléments issus du travail de support pour réduire la probabilité ou le coût des perturbations futures.

Poser une autre question

Les deux pratiques peuvent travailler simultanément sur le même problème. Le personnel chargé des incidents peut appliquer une solution de contournement pendant que le personnel chargé des problèmes examine les conditions à l’origine de la défaillance. Une solution de contournement efficace soulage les utilisateurs, mais son application répétée prend toujours du temps et laisse la cause en place.

La gestion des problèmes comporte trois phases : l’identification des problèmes, le contrôle des problèmes et le contrôle des erreurs. L’identification trouve une cause ou un risque qui mérite une investigation. Le contrôle des problèmes l’analyse et documente les solutions de contournement et les erreurs connues. Le contrôle des erreurs gère les erreurs connues non résolues et évalue les solutions durables.

Utiliser plusieurs sources d’information

Les tendances des incidents révèlent des symptômes récurrents. Les agents du centre et les utilisateurs peuvent remarquer des récurrences masquées par des descriptions différentes dans les tickets. Un incident majeur peut révéler un risque grave de récurrence après une seule perturbation. Les fournisseurs peuvent annoncer des défauts ; les développeurs, les testeurs et les équipes projet peuvent identifier des situations susceptibles de provoquer une défaillance lorsque le service sera utilisé plus largement.

La gestion réactive des problèmes part d’incidents qui se sont produits. Le travail proactif part de causes potentielles avant qu’un incident ne survienne. L’avertissement d’un fournisseur signalant une fuite de mémoire dans une version de micrologiciel peut justifier une investigation même si les utilisateurs locaux n’ont signalé aucune panne. Des événements d’avertissement répétés peuvent fournir un autre signal précoce.

Transformer une récurrence en enregistrement de problème

En 30 jours, le centre enregistre 14 incidents décrits ainsi : « Le VPN se déconnecte lorsque l’ordinateur portable sort de veille ». Chacun mobilise le centre pendant environ 25 minutes :

Cela représente environ 5,8 heures, sans compter le temps perdu par les utilisateurs. Relie les incidents à un enregistrement de problème afin que les personnes chargées de l’investigation puissent comparer les appareils concernés, les conditions et les moments concernés. Des incidents distincts continuent de consigner chaque perturbation ; le problème relie les éléments permettant d’identifier leur cause commune.

Un enregistrement de problème utile contient la description, les services et éléments de configuration concernés, les incidents associés, un responsable, l’état du problème, les résultats de l’analyse et une priorité fondée sur le risque. Prends en compte à la fois la probabilité de nouveaux incidents et l’importance de leur impact sur le service. Une panne rare d’un service critique peut mériter autant d’attention qu’une panne mineure fréquente.

Ouvrir un problème pour chaque incident crée un retard de traitement sans objectif d’investigation utile. Un incident isolé dont la cause est évidente et sans gravité peut ne pas nécessiter d’enregistrement de problème distinct. Une récurrence, un impact majeur ou une défaillance potentielle importante constituent des raisons plus solides d’enquêter.

Le contrôle des problèmes analyse les problèmes et documente les solutions de contournement et les erreurs connues. La priorité dépend du risque pour les services : l’effort d’investigation porte donc là où de nouveaux incidents sont les plus probables ou les plus préjudiciables.

Regarder au-delà du composant défaillant

Les quatre dimensions aident à élargir l’analyse : organisations et personnes, information et technologie, partenaires et fournisseurs, et flux de valeur et processus. Une défaillance technique peut être liée à une lacune dans un processus ou à un manque de connaissances. Par exemple, la configuration d’un ordinateur portable peut désactiver un paramètre d’alimentation nécessaire à un pilote réseau fourni par un fournisseur, sans que les tests de l’image système standard ne détectent cet effet.

Des techniques utiles examinent les éléments sous différents angles :

• La méthode des cinq pourquoi suit une chaîne d’explications vers des causes sur lesquelles les personnes peuvent agir. Son nom invite à approfondir, sans imposer de s’arrêter exactement à cinq questions.
• Un diagramme d’Ishikawa, aussi appelé diagramme de causes et effets, regroupe les causes possibles sous des rubriques telles que les personnes, les processus, la technologie et les fournisseurs.
• Une chronologie classe les changements et les défaillances dans le temps afin que l’équipe puisse examiner leurs liens.

Les causes possibles doivent être vérifiées à l’aide d’éléments concrets. Plusieurs conditions peuvent interagir : le résultat utile est donc une explication qui permet d’agir, même en l’absence d’une cause racine unique.

Suivre une chaîne de causes

Un export de paie échoue parce que son traitement par lots dépasse le délai autorisé. Pourquoi ? Une requête de base de données prend trois fois plus de temps que d’habitude. Pourquoi ? Un index manque après une mise à niveau. Pourquoi manque-t-il ? Le script de mise à niveau ne l’a pas recréé. Pourquoi le problème n’a-t-il pas été détecté ? La liste de vérification de la mise en production ne prévoit aucun contrôle des performances de la base de données.

Cette analyse indique qu’il faut intervenir techniquement sur l’index et le script, et améliorer le processus de vérification des mises en production. S’arrêter au dépassement du délai laisserait en place les conditions qui permettent sa répétition. S’arrêter à « erreur humaine » ferait aussi manquer les contrôles ou les procédures plus claires qui pourraient éviter une nouvelle erreur.

Rendre une solution partielle réutilisable

Lorsqu’aucune solution complète n’est disponible, documente une solution de contournement dans l’enregistrement de problème. Fournis au personnel assez de détails pour l’appliquer de manière cohérente et explique quand elle convient. Pour le problème de VPN sur ordinateur portable, l’action est la suivante : « Après la sortie de veille de l’ordinateur portable, ouvre l’application VPN et sélectionne Reconnecter ; cela prend environ 20 secondes. »

Une solution de contournement réduit l’effet du problème ; elle ne prouve pas que la cause a été éliminée. Partage-la dans une base de connaissances ou une base de données des erreurs connues afin que le personnel chargé des incidents puisse rétablir plus vite les services concernés, parfois dès le premier contact.

Un problème devient une erreur connue dès qu’il a été analysé et reste non résolu. La cause sous-jacente peut encore être incertaine et une solution de contournement peut toujours manquer. L’enregistrement consigne ce qui a été évalué et appris jusque-là. Exiger à la fois une cause démontrée et une solution de contournement avant de partager l’erreur connue retarderait la diffusion d’informations utiles.

Les enregistrements d’incidents fournissent une grande partie des éléments d’analyse. Des catégories, symptômes, actions et résultats cohérents aident les analystes à comparer les cas. Le contrôle des problèmes fournit en retour de meilleures connaissances pour le prochain incident.

Le contrôle des erreurs gère les erreurs connues et identifie des solutions définitives possibles. Il maintient visibles le coût et l’effet des problèmes non résolus, afin que les décisions de correction reposent sur des éléments à jour.

Comparer l’effort au bénéfice

Une solution doit être justifiée au regard de son coût, de ses risques et de ses bénéfices. Inclus l’effort de test et de déploiement, l’impact de l’application répétée de la solution de contournement et le temps perdu par les utilisateurs. Une correction technique rapide peut tout de même présenter un risque pour le service ; une réparation plus longue peut être justifiée si elle élimine des perturbations fréquentes.

L’erreur connue du VPN provoque environ 14 incidents par mois, chacun mobilisant le centre pendant environ 25 minutes. Le test et le déploiement du pilote mis à jour sur 600 ordinateurs portables nécessitent 16 heures.

1. L’effort mensuel du centre est de $14\times 25=350\text{ minutes}$.
2. L’effort prévu pour la correction est de $16\times 60=960\text{ minutes}$.
3. Le délai de récupération en temps de travail du centre est de $960÷350\approx \mathrm{2,7}\text{ mois}$.

Cette estimation compare l’effort ponctuel de correction à l’effort récurrent du centre. Le temps gagné par les utilisateurs apporte un bénéfice supplémentaire. L’estimation aide à justifier le changement, dont le risque de mise en œuvre doit néanmoins être évalué.

Continuer à examiner les erreurs acceptées

Une organisation peut accepter une erreur connue lorsqu’une solution définitive coûte plus que le bénéfice attendu. Prenons un défaut d’affichage mineur dans un ancien système dont le retrait est prévu dans 4 mois. Si la solution de contournement est simple, la décision peut être de la conserver jusqu’au retrait.

L’acceptation nécessite une erreur documentée, une solution de contournement utilisable et un réexamen de la décision de la maintenir. Si le retrait est retardé ou si l’effet sur les utilisateurs augmente, l’équilibre change. Le contrôle des erreurs réévalue l’impact sur les clients, la disponibilité et le coût des solutions, ainsi que l’efficacité des solutions de contournement. Améliorer ou automatiser une solution de contournement répétée peut réduire l’effort tant que l’erreur subsiste.

Autoriser la mise en œuvre et vérifier la réussite

La gestion des problèmes identifie et justifie la solution. L’habilitation des changements évalue le risque et autorise un changement avant sa mise en œuvre par les équipes responsables. Un enregistrement de problème n’autorise pas à lui seul un déploiement en production.

Après la mise en œuvre, vérifie si la cause ou son effet a réellement été éliminé. Par exemple, examine la surveillance et les incidents correspondants sur une période de 30 jours. Un message confirmant la réussite du déploiement montre qu’une action a été réalisée ; les tendances des incidents montrent si elle a résolu le problème.

Dès que les éléments confirment le résultat, clôture le problème et l’erreur connue, puis mets à jour ou retire les articles associés. Si les incidents continuent, utilise les nouveaux éléments pour réévaluer l’analyse ou la solution. La gestion des problèmes alimente aussi l’amélioration continue lorsque l’investigation révèle des lacunes dans un processus, les compétences du personnel ou les accords avec les fournisseurs.

La gestion des demandes de service traite efficacement et de manière conviviale les demandes prédéfinies formulées par les utilisateurs afin de soutenir la qualité de service convenue. Les demandes font normalement partie de la fourniture du service, même lorsque leur exécution nécessite plusieurs personnes ou approbations.

Identifier les types de demandes courants

Un ordinateur portable en panne correspond à un incident, car un service existant a cessé de fonctionner. Une commande convenue d’ordinateur portable est une demande. Ce n’est pas le canal ni la formulation qui détermine le type, mais la situation du service.

Les organisations publient généralement les types de demandes dans un catalogue de services sur un portail en libre-service. Chaque formulaire recueille les informations nécessaires à l’exécution, telles que l’utilisateur, la date de début, le centre de coûts et le responsable chargé de l’approbation. Demander les détails pertinents dès la soumission évite des échanges répétés qui allongent l’attente.

Distinguer la demande du changement

Certaines demandes nécessitent un changement apporté à un service ou à un élément de configuration. Un changement standard présente un faible risque, est préautorisé, bien compris et entièrement documenté. Il suit sa procédure approuvée sans nouvelle autorisation pour chaque utilisation. L’ajout d’un utilisateur à une liste de diffusion est un exemple courant.

Le statut de la demande et l’autorisation du changement répondent à des questions différentes. Une demande prédéfinie du catalogue reste une demande de service lorsque son exécution nécessite un changement qui demande une évaluation individuelle. Conserve l’enregistrement de la demande et relie-le au travail d’habilitation des changements nécessaire à son exécution.

Par exemple, un catalogue propose des serveurs virtuels. Un utilisateur demande un serveur dont la taille dépasse la plage autorisée par le changement standard. La demande reste une demande de service ; la création passe par l’habilitation des changements avant son exécution. La présence dans un catalogue ne préautorise pas toutes les créations possibles.

Une demande portant sur quelque chose qui n’est pas prédéfini suit un autre circuit. « Créez-nous un nouveau portail client » est une nouvelle demande qui appelle une décision de produit ou de projet. Une proposition d’installer un logiciel de contrôle à distance inconnu sur tous les ordinateurs du bureau nécessite une évaluation du changement. L’appeler une demande dans le langage courant n’en fait pas une demande de service prédéfinie.

Agir sur les retours d’information et les demandes fréquentes

Une plainte reçue par le circuit des demandes doit être confiée à une personne capable d’agir. Des plaintes répétées sur les délais de réponse peuvent parvenir à la gestion des niveaux de service, tandis qu’une perte de confiance plus générale peut nécessiter l’intervention de la gestion des relations. Enregistrer le retour d’information marque le début de l’action, pas son achèvement.

Compte les types de demandes pour trouver où la standardisation sera la plus utile. Les demandes d’accès, les réinitialisations de mot de passe et les commandes de matériel représentent souvent une grande part du volume. Réutiliser une procédure définie pour ces types fréquents évite aux utilisateurs et au personnel de devoir concevoir un nouveau traitement à chaque fois.

Un circuit de traitement des demandes définit le parcours de la soumission à l’exécution : étapes, approbations, responsabilités et résultat reçu par l’utilisateur. Des types de demandes similaires peuvent souvent réutiliser un modèle de circuit avec de légères modifications.

Placer les approbations là où elles apportent un contrôle

Les règles d’approbation dépendent de la demande. Une réinitialisation de mot de passe peut être effectuée après vérification de l’identité, sans approbation d’un responsable. L’achat d’un ordinateur portable peut nécessiter une approbation financière. L’accès aux données de paie peut nécessiter l’approbation du service de sécurité de l’information ou du responsable des données.

Les politiques définissent quelles demandes nécessitent ces décisions et lesquelles peuvent être exécutées avec peu ou pas d’approbations. Envoyer chaque action habituelle à un responsable ajoute de l’attente sans appliquer les exigences de contrôle propres à la demande. Supprimer une approbation d’accès obligatoire pour gagner du temps crée une autre défaillance. Précise la politique avant d’automatiser le circuit.

Suivre la demande pour une nouvelle recrue

Un responsable du recrutement soumet une demande 10 jours ouvrés avant la date d’arrivée. Le formulaire recueille le rôle de la personne recrutée, sa date d’arrivée et ses besoins en matériel et en accès.

• Le jour 1, les ressources humaines confirment la date d’arrivée et la création des comptes s’effectue automatiquement.
• Les jours 2 à 3, les responsables des données approuvent l’accès aux systèmes du service.
• Les jours 2 à 4, l’équipe de support prélève un ordinateur portable dans le stock et le configure.
• Avant la date d’arrivée, le matériel et les accès sont fournis et vérifiés.

Certaines activités se déroulent en parallèle. Le circuit indique néanmoins leurs responsables respectifs et leurs dépendances. Le responsable suit l’état global à partir d’une seule demande, y compris toute étape en attente d’approbation.

Rendre les délais prévisibles

Publie des délais d’exécution que l’organisation peut respecter, par exemple : « Ordinateur portable standard : 3 jours ouvrés ; ordinateur portable non standard : 10 jours ouvrés. » Si une étape est en attente, indique quelle décision ou information est nécessaire et qui en est responsable. Une attente visible fournit à l’utilisateur une explication utile sur l’avancement.

La gestion des niveaux de service convient des objectifs ; le centre se charge souvent de la réception. Les mesures utiles comprennent le respect des objectifs d’exécution, la part des demandes exécutées automatiquement, les demandes renvoyées pour informations manquantes et la satisfaction. De nombreux formulaires renvoyés peuvent indiquer que les questions initiales manquent de clarté, tandis que des approbations lentes peuvent appeler un changement de politique ou d’orientation.

Automatiser un processus fiable

Supposons que 400 appels mensuels de réinitialisation de mot de passe prennent chacun environ 8 minutes. Une réinitialisation sécurisée en libre-service avec vérification multifacteur peut économiser :

Cela représente environ 53 heures de travail des agents par mois si tous ces appels sont évités. Les utilisateurs peuvent aussi effectuer l’action à toute heure. Standardise les étapes et la vérification requise avant l’automatisation afin qu’elle reproduise une procédure fiable.

Certains utilisateurs soumettent des demandes comme incidents dans l’espoir d’obtenir un service plus rapide. Réoriente l’enregistrement avec une courte explication et indique le délai d’exécution approprié. Les politiques et les circuits réorientent aussi les demandes qui sont en réalité des incidents ou des changements. Améliorer le circuit des demandes réduit l’incitation à choisir le mauvais formulaire et préserve l’utilité des rapports d’incidents.

La gestion des niveaux de service définit des objectifs clairs fondés sur les besoins métiers et veille à ce que la fourniture soit évaluée, surveillée et gérée au regard de ces objectifs. Un niveau de service décrit la qualité attendue ou atteinte au moyen d’un ou plusieurs indicateurs. Un accord de niveau de service (SLA) documente les services requis et le niveau de service attendu convenus par le fournisseur et le client.

Partir du travail du client

Un accord de niveau de service utile porte sur un service défini dans le catalogue et sur des résultats définis. Il consigne un véritable accord obtenu par la discussion et utilise un langage compréhensible pour les deux parties. La seule durée de fonctionnement d’un serveur peut masquer le fait que les clients ne peuvent pas finaliser leurs commandes pendant les heures d’ouverture.

L’accord comprend généralement le périmètre et les horaires du service, la disponibilité, les objectifs de réponse et de résolution des incidents, les délais d’exécution des demandes, les contacts du support, les responsabilités des deux parties, les mesures et les comptes rendus, ainsi que la fréquence des revues. Conviens de la manière de calculer chaque mesure afin que les rapports utilisent la même base que l’engagement.

Calculer l’indisponibilité autorisée

Utilise la plage de service convenue comme dénominateur. Pour un service assuré 24/7 pendant un mois de 30 jours :

Un objectif de disponibilité de 99,9 % autorise 0,1 % d’indisponibilité :

La disponibilité est la part du temps convenu pendant laquelle le service est disponible :

Avec 50 minutes d’interruption, la disponibilité est d’environ 99,88 % : l’objectif n’est donc pas atteint. Utilise le résultat non arrondi pour le comparer à un objectif proche de la valeur atteinte.

Pour des horaires de service du lundi au vendredi, de 8 h à 18 h, sur 22 jours ouvrés, le temps convenu est de 220 heures ou 13 200 minutes. À 99,5 %, l’indisponibilité autorisée est de 66 minutes. Une interruption de 90 minutes à 2 h le dimanche se situe hors de ces horaires convenus et n’est pas comptabilisée pour cet objectif. Une interruption de 40 minutes pendant les horaires de service du mardi donne environ 99,70 %, ce qui respecte l’objectif.

Soutenir l’engagement en interne et avec les fournisseurs

Une promesse de rétablissement sous 4 heures nécessite des dispositions de support capables de produire ce résultat. Un fournisseur qui promet seulement la présence d’un technicien sur site sous 8 heures ne peut pas, par cette seule promesse, soutenir un objectif de rétablissement sous 4 heures.

Les organisations peuvent utiliser un accord de niveau de service par service pour un service et tous ses clients, par client pour les services d’un groupe de clients, ou une structure à plusieurs niveaux avec des conditions propres à l’organisation, au client et au service.

Les comptes rendus sur les niveaux de service nécessitent une vue d’ensemble de la fourniture. Les mesures opérationnelles montrent ce que le fournisseur a fait ; les mesures métiers et les retours d’information montrent comment le service a soutenu le travail du client.

Choisir les mesures ensemble

L’engagement client permet de découvrir les besoins par la discussion. Demande : « Quel travail la technologie soutient-elle ? », « Quels sont les moments clés de ton activité ? » et « Comment mesures-tu la réussite ? » Les retours d’information des clients apportent les résultats d’enquêtes et les commentaires recueillis après des incidents, des demandes et des périodes de service plus longues.

Les indicateurs opérationnels comprennent le nombre d’incidents, les délais de réponse et la disponibilité. Les indicateurs métiers peuvent comprendre le nombre de commandes traitées par heure. Leur combinaison peut révéler un écart entre les performances techniques et un service utilisable.

L’effet pastèque décrit des rapports verts accompagnés d’une expérience client rouge. Par exemple, tous les objectifs de résolution et une disponibilité de 99,95 % sont atteints, mais le système client met 12 secondes par écran en fin de trimestre et la satisfaction tombe à 2,1 sur 5. L’accord ne tient pas compte d’une condition importante pour que le service soit utile. Discute de la lenteur de la tâche métier et révise les indicateurs et les objectifs autour de ce besoin.

Calculer le taux de respect des objectifs

Sur 200 incidents de priorité 3, 184 respectent un objectif de résolution de 8 heures ouvrées :

Si le taux de respect requis est de 95 %, le nombre d’incidents qui devaient respecter l’objectif est de :

Il manque 6 incidents pour atteindre l’objectif. Le taux de respect mesure le nombre de cas ayant atteint leur objectif individuel, tandis que la disponibilité mesure le temps de service. Leurs dénominateurs sont différents et doivent être indiqués clairement.

Appliquer les règles de décompte convenues

Un accord de niveau de service précise si le temps est compté en heures ouvrées ou en heures calendaires et si certaines attentes suspendent le décompte. N’invente pas de suspension parce qu’un ticket attend une réponse de l’utilisateur ; applique la règle convenue.

Supposons que les horaires de service soient du lundi au vendredi, de 8 h à 18 h, et que le délai de résolution autorisé soit de 8 heures ouvrées. Un incident enregistré le vendredi à 16 h utilise 2 heures avant la fermeture. Les 6 heures restantes commencent le lundi à 8 h, ce qui donne une échéance le lundi à 14 h. Le week-end ajoute du temps calendaire mais ne consomme aucune heure ouvrée du délai autorisé.

Examiner les comportements et les améliorations

Une mesure unique peut encourager les raccourcis. Si la rapidité est le seul objectif, le personnel peut clôturer des tickets non résolus. Le taux de réouverture et la satisfaction aident à déterminer si une clôture rapide correspondait à un véritable rétablissement. Examine les mesures ensemble avant de conclure qu’un processus s’est amélioré.

Une revue de service réunit le fournisseur et le client, souvent chaque mois ou chaque trimestre, pour examiner les performances, les tendances, les changements à venir et les actions d’amélioration. Présente le contexte à côté des résultats indiquant si les objectifs sont atteints : disponibilité, volumes de commandes, satisfaction et explication des objectifs manqués. Attribue les actions et utilise la revue pour mettre à jour l’accord de niveau de service lorsque les besoins métiers ont changé. Les conclusions alimentent aussi l’amélioration continue.

La gestion des relations établit et développe les liens entre l’organisation et ses parties prenantes aux niveaux stratégique et tactique. Elle identifie et analyse les relations, surveille leur fonctionnement et les améliore au fil du temps.

Comprendre les besoins de chacun

Une personne peut tenir plusieurs rôles, mais les intérêts doivent tout de même être examinés. Identifie les besoins, les priorités et l’influence. Un sponsor peut privilégier le coût tandis que les utilisateurs demandent des horaires de support élargis. Comprendre les deux besoins donne au fournisseur une base pour discuter des compromis.

Les activités relationnelles comprennent la résolution des exigences contradictoires, le suivi de la satisfaction, le traitement des plaintes et des escalades, et l’aide aux parties prenantes pour comprendre comment tirer de la valeur des services. Elles contribuent aussi à définir les priorités des produits et services selon les besoins métiers.

Partager les projets avant qu’ils ne deviennent urgents

Un gestionnaire des relations métiers est souvent l’interlocuteur de haut niveau d’une grande unité métier. Il comprend les projets de cette unité, représente ses besoins auprès du fournisseur et explique les capacités et les contraintes de ce dernier.

Lors d’un échange trimestriel, le marketing indique qu’une campagne prévue dans deux mois devrait attirer cinq fois le trafic habituel sur le site web. Le gestionnaire des relations transmet cette information aux équipes chargées de la capacité et à la gestion des niveaux de service. Le fournisseur peut préparer une capacité supplémentaire et discuter des attentes concernant le service avant le début de la campagne.

L’information utile ne se limite pas à une prévision chiffrée. Elle comprend le moment où la demande se produira et son importance. Le travail technique et les discussions sur les objectifs peuvent ainsi soutenir le même événement métier. Attendre le jour du lancement transforme un besoin prévisible en problème urgent.

Relier la confiance à des engagements mesurables

La gestion des relations veille au partenariat global, à la confiance et à l’orientation stratégique. La gestion des niveaux de service s’occupe des objectifs de service précis et de leur mesure. Un échange régulier peut révéler un besoin ; le travail sur les niveaux de service peut le transformer en engagement convenu avec des mesures adaptées.

Une bonne relation permet de discuter honnêtement des limites et des coûts du service. Une fourniture fiable renforce cette confiance. Les deux parties contribuent : le client partage ses projets à temps et le fournisseur explique les ressources nécessaires au niveau de service proposé. C’est la cocréation de valeur dans le travail de support concret.

Ne contacter les interlocuteurs métiers que pendant les interruptions laisse des projets et des préoccupations inconnus. Maintiens aussi des contacts planifiés lorsque le service fonctionne bien. Les plaintes qui révèlent une relation dégradée nécessitent une discussion et un suivi, tandis que leurs détails sur les performances peuvent aussi alimenter la prochaine revue de service.

Un flux de valeur est une série d’étapes par lesquelles une organisation crée et fournit des produits et des services aux consommateurs. Un flux de valeur de support combine des pratiques autour d’un résultat, comme le rétablissement du service d’un utilisateur. Il peut faire intervenir les activités de la chaîne de valeur « impliquer », « fournir et soutenir » et « améliorer ».

Détecter, coordonner et rétablir

À 8 h 55, la surveillance avertit que la file d’attente des messages sortants augmente. À 9 h 05, elle franchit le seuil d’exception et un incident est créé. De 9 h 10 à 9 h 30, le centre reçoit 25 appels, associe les contacts à l’incident et publie un bandeau sur le portail.

L’équipe de messagerie achemine les messages par une passerelle de secours à 9 h 40. Le service normal de messagerie est rétabli : l’incident est donc résolu après 35 minutes. La solution de contournement rétablit l’acheminement tout en laissant la gestion des problèmes examiner la cause.

Relier de nombreux signalements d’utilisateurs à un incident parent permet de garder l’impact visible sans créer 25 interventions de rétablissement distinctes. Chaque utilisateur peut recevoir des informations sur l’avancement grâce aux enregistrements liés. Les rapports d’incidents peuvent montrer une perturbation de service et de nombreux utilisateurs touchés, tandis que le nombre de contacts continue de décrire la charge de travail du centre.

Enquêter et prévenir la récurrence

Un enregistrement de problème rassemble les éléments relatifs à l’incident. L’analyse révèle que le renouvellement automatique d’un certificat de sécurité a échoué sans qu’aucune alerte le détecte. Le problème analysé et non résolu est enregistré comme erreur connue avec la passerelle de secours comme solution de contournement.

Une tâche de renouvellement corrigée et la surveillance du renouvellement constituent la solution définitive proposée. Le changement passe par l’habilitation des changements avant sa mise en œuvre, puis le résultat est vérifié. La gestion des incidents fournit les éléments sur la perturbation ; la gestion des problèmes apporte l’analyse et le travail de prévention.

Rendre compte de l’effet sur le service et l’expliquer

Pour un service assuré 24/7 pendant un mois de 30 jours, la période convenue est de 43 200 minutes. Avec 35 minutes d’indisponibilité :

L’objectif de disponibilité de 99,9 % est atteint. Ce résultat indique le respect de la mesure convenue, mais le gestionnaire des relations explique tout de même la perturbation et le plan de prévention au directeur financier. Atteindre un objectif mensuel ne supprime pas la nécessité de traiter l’effet d’une interruption particulière sur l’activité.

Une demande de nouvelle boîte aux lettres partagée reçue le même matin reste dans son circuit de traitement des demandes de service. La séparation évite que l’interruption fausse le nombre de demandes ou transforme une demande habituelle en travail sur incident.

Relier le travail lors des transferts

Un événement appelle la gestion des incidents lorsque le service est affecté. Un incident récurrent ou majeur peut déclencher un travail sur un problème. Une solution définitive justifiée peut nécessiter une demande de changement. Une demande de service prédéfinie peut aussi nécessiter un changement associé lorsque son exécution exige une autorisation individuelle. Les plaintes peuvent parvenir à la gestion des niveaux de service ou à la gestion des relations.

Une pratique est un ensemble de ressources et de capacités, et non un service de l’organisation. Un même agent peut enregistrer un incident, exécuter une demande et repérer une récurrence. Des catégories correctes, des liens entre les enregistrements et des responsables clairement désignés permettent à ces activités de contribuer au même résultat pour l’utilisateur.

Un bon support permet de trouver facilement une solution éprouvée et de l’appliquer à nouveau en toute sécurité. Les connaissances, le libre-service et l’automatisation rapprochent le travail adapté de l’utilisateur et donnent au personnel plus de temps pour les cas complexes.

Garder les connaissances utilisables

Une base de connaissances contient des articles pratiques, des étapes de résolution standard et des solutions de contournement. Un article utile est court, emploie les mots de l’utilisateur et comporte un responsable et une date de révision. Par exemple, « Le VPN se déconnecte après la sortie de veille de ton ordinateur portable : solution rapide » nomme le symptôme qu’un utilisateur est susceptible de rechercher. Mets les articles à jour après utilisation afin que le lecteur suivant bénéficie des enseignements tirés.

Le libre-service permet aux utilisateurs de rechercher des informations dans la base de connaissances, de soumettre des demandes du catalogue et de suivre l’état de leurs tickets. Les agents conversationnels et virtuels peuvent répondre aux questions fréquentes ou exécuter des circuits simples. Un moyen clair de joindre une personne reste disponible lorsque le parcours automatisé ne peut pas aider.

Le shift left rapproche de l’utilisateur les résolutions qui s’y prêtent, par exemple en les transférant du niveau 2 au niveau 1 ou du centre au libre-service. Transfère une solution lorsqu’elle est suffisamment simple et sûre pour être utilisée à cet endroit, avec les connaissances et les contrôles nécessaires. Le bénéfice vient de la réduction de l’attente et de l’effort de support.

Automatiser le travail qui s’y prête

L’automatisation peut classer et orienter les enregistrements, créer des incidents à partir d’événements, exécuter des réponses définies, traiter des demandes standards et envoyer des points d’information. Simplifie et standardise d’abord le processus. Si les règles d’orientation sont erronées, leur automatisation envoie plus rapidement davantage d’enregistrements au mauvais endroit.

Les outils d’IA peuvent suggérer des catégories, rédiger des projets de réponse, résumer de longs historiques et repérer des groupes d’incidents similaires. Les personnes restent responsables des priorités, des approbations et des messages aux utilisateurs ; le personnel vérifie donc les suggestions avant d’agir. Les tickets peuvent contenir des données personnelles : utilise ces outils conformément aux règles de protection des données de l’organisation.

Calculer l’évolution de la demande adressée au centre

Un centre reçoit 2 000 contacts par mois, dont 600 concernent des réinitialisations de mot de passe et des questions pratiques simples. Un portail et un agent conversationnel en résolvent 450 sans contact avec le centre. Il reste :

La réduction de la demande totale adressée au centre est de :

Utiliser 600 comme dénominateur donnerait la part de ces contacts simples sélectionnés traitée en libre-service, une mesure différente. Le personnel peut consacrer le temps libéré aux incidents complexes et à l’identification des tendances.

Vérifier la réussite au-delà du trafic du portail

Un portail très fréquenté peut refléter une auto-assistance efficace ou des recherches répétées sans succès. Examine la part des sessions en libre-service après lesquelles l’utilisateur n’a pas eu besoin de contacter le centre pour le même problème. Combine ce résultat avec les retours d’information des utilisateurs et la qualité des résultats obtenus.

Un agent conversationnel qui bloque l’accès à une personne peut réduire le nombre d’appels enregistrés tout en laissant l’utilisateur dans une impasse. Un parcours automatisé utile fournit un résultat et transmet le contexte lorsqu’une aide humaine est nécessaire.