Une fois, le département Business Support de Social Discovery Group a dû relever le défi de taille de résoudre un arriéré de 1 500 tickets qui s'étaient accumulés sur quatre ans. La gestion d'un tel volume de problèmes était une entreprise sérieuse, et nous nous trouvions constamment en difficulté pour suivre les KPI. Malgré tous nos efforts, les billets n'arrêtaient pas d'être mélangés d'un sprint à l'autre, laissant les clients frustrés et nous nous sentions dépassés. Dans cet article, nous aimerions partager notre expérience de la réalisation de cette tâche apparemment impossible, en nous rappelant le légendaire sixième travail d'Hercule. Nous vous expliquerons les défis auxquels l'équipe SDGroup a été confrontée et les étapes que nous avons suivies pour reconstruire les processus de notre département. Nous avons adopté l'approche STATIK, qui s'est avérée incroyablement efficace pour nous aider à éliminer l'arriéré et à apporter un soulagement bien nécessaire à notre équipe. Donc, si vous cherchez des informations pratiques sur la façon de traiter un arriéré de tickets, continuez à lire ! Comment nous nous sommes retrouvés avec la file d'attente de 1 500 billets En tant que service d'assistance aux entreprises, nous sommes responsables du traitement des tickets contenant des plaintes et des suggestions de clients concernant nos services. Par exemple, si un client rencontre des difficultés avec le système de paiement sur notre site Web, il peut soulever un problème avec l'équipe d'assistance technique de SDG. Les collègues rassemblent toutes les informations pertinentes, y compris les étapes de reproduction des problèmes et les captures d'écran, et créent un ticket dans Jira, en l'attribuant à notre service. Nous effectuons ensuite des tests supplémentaires pour nous assurer que le problème n'est pas un problème client temporaire, mais un problème réel de notre côté. S'il est confirmé, nous créons un rapport de bogue, le hiérarchisons et le transmettons à l'équipe de développement pour résolution. En moyenne, nous recevions 20 à 30 billets par jour. Nous avons passé 2 à 3 heures à reproduire le problème, mais chaque fois que nous avions besoin de l'aide d'autres départements, tels que des détails de cas, des redémarrages de service, des données de la base de données ou des analyses de l'équipe de développement, nos tâches avaient tendance à rester bloquées. Nos collègues étaient souvent incapables de répondre rapidement et aucune équipe de développeurs distincte n'était affectée à nos rapports de bogues. De plus, nos tickets de développement avaient une priorité moindre par rapport aux tâches métier. En conséquence, même les tickets hautement prioritaires pouvaient rester non résolus pendant quelques mois, tandis que les tâches moins prioritaires restaient sur le tableau pendant des années. Comme vous pouvez le voir, ce flux a entraîné trop d'incertitude dans le respect des délais, ce qui a causé de l'insatisfaction tant pour nous que pour nos clients. La situation a entraîné plusieurs problèmes : Les clients étaient stressés et frustrés lorsque leurs problèmes n'étaient pas résolus assez rapidement, et nous n'étions pas en mesure de fournir un échéancier clair. Notre équipe d'assistance était frustrée, car les clients demandaient des mises à jour pour les problèmes non résolus presque tous les jours. L'équipe d'assistance nous a écrit et a reçu la même réponse : "Le problème n'est pas encore résolu." Notre équipe était surchargée et incapable de reprendre les anciennes tâches et de les lier en tant que cas récurrents. Nous étions désespérés face au nombre impressionnant de 1 500 tâches non résolues sur notre tableau. Nous savions que nous devions changer notre approche pour progresser. Voici à quoi ressemblait le cycle de vie du ticket pendant cette période. Examinons quelques-uns des problèmes que nous avons rencontrés lors de la gestion du backlog des problèmes : L'équipe d'assistance manquait de scripts pour documenter et filtrer rapidement les problèmes. Les tâches au statut "Nouveau" sont souvent restées bloquées dans les limbes. Lorsque nous n'avions pas suffisamment d'informations ou d'accès pour résoudre le problème, il passait au statut "Escaladé" et nous recherchions l'aide de collègues d'autres départements. Malheureusement, cela pourrait prendre des semaines voire des mois pour qu'ils répondent. Et parfois, nous avons manqué des commentaires en raison du volume écrasant de tâches entrantes. Une fois que nous avons finalement vérifié le problème, nous l'avons déplacé vers le statut "En attente de correctif". En raison d'une pénurie chronique de ressources de développement, ces tickets pourraient rester non résolus pendant des années. Les clients n'ont pas fermé les tickets, espérant que nous recevrons plus de ressources à l'avenir. L'important arriéré de tâches a entraîné des doublons. Il était difficile de les fusionner et de les fermer car nous avions souvent du mal à nous rappeler quelles tâches avaient été commencées les années précédentes. Cette approche mal organisée a entraîné un arriéré de . 1 500 tickets non résolus sur quatre ans L'approche STATIK et le sixième travail d'Hercule Nous avons réalisé que notre département était trop concentré sur le traitement des tickets plutôt que sur l'objectif principal de résoudre les problèmes des clients : améliorer leur fidélité envers les produits de Social Discovery Group et détecter les vulnérabilités de nos services et de nos sites Web. Vous vous demandez peut-être : « Pourquoi ne pas embaucher plus de personnel si vous ne pouvez pas gérer la charge de travail ? » Cependant, l'expérience a montré qu'en mettant en place des processus efficaces, on peut se passer de ressources supplémentaires. De même, Hercule acheva seul son œuvre en redirigeant le cours du fleuve vers les écuries d'Augias, qui les déblayèrent en une seule journée. Pour rationaliser notre billetterie, nous nous sommes référés au livre de Mike Burrows et avons mis en place l'approche STATIK, une stratégie systématique d'exécution de la méthode Kanban. "Kanban from the Inside" Lors de la mise en œuvre de l'approche STATIK, nous avons suivi ces : cinq étapes et conclu que les clients doivent être satisfaits de l'assistance fournie. Pour ce faire, nous devons nous assurer de ce qui suit : 1. Nous avons identifié les attentes des clients vis-à-vis de notre service d'assistance commerciale La transparence dans notre travail sur la tâche permet aux clients de comprendre ce qui se passe avec leurs demandes à tout moment. Rapidité de notre travail sur les tâches, fournissant un moment définitif pour les commentaires dans n'importe quel état du problème. La source interne est ce qui nous a gêné et a causé de la frustration dans notre propre travail. 2. Nous avons défini les sources internes et externes d'insatisfaction. La source externe est ce qui a causé de la frustration chez nos clients et entravé leur expérience. Nous avons examiné les tickets soumis à notre service et les avons classés selon les services d'où ils provenaient, leur fréquence et les attentes des clients en matière de temps de réponse et de solutions. 3. Nous avons analysé les sources et la nature de notre charge de travail. À ce stade, nous avons évalué l'efficacité avec laquelle nous traitions les tickets et déterminé le nombre de tâches que nous pouvions gérer de manière réaliste en une semaine. 4. Nous avons évalué nos capacités actuelles. De plus, nous avons calculé le temps moyen qu'il a fallu pour passer de l'initiation du ticket à la publication de la correction des bogues en production. 5. Nous avons reconstruit le cycle de vie des tickets et créé un nouveau processus. Notre cycle de vie initial des tickets En utilisant les connaissances acquises, nous avons développé un nouveau cycle de vie des tâches. Ensuite, nous avons mis en place une approche globale pour résoudre tous les problèmes mentionnés précédemment. Nous avons suivi les étapes suivantes : Nous avons créé des scripts pour notre équipe d'assistance afin de filtrer les tâches au niveau initial. Nous avons introduit un statut temporaire "Retour au rapporteur" pour les tâches qui nécessitaient l'intervention du client pour enquêter sur le problème. Si les informations nécessaires n'étaient pas fournies dans les trois jours, la tâche serait automatiquement clôturée. Nous avons supprimé le statut "Escalade" et l'avons remplacé par un statut plus spécifique "Confirmation du problème". Nous avons passé plus de deux mois à examiner et à fermer les tâches en double, nous laissant avec seulement 800 tickets uniques sur les 1 500 avec lesquels nous avons commencé. Nous avons mis en place des accords de niveau de service (SLA) et défini des minuteries pour chaque statut. Le statut "Confirmation du problème" avait une minuterie de 7 jours, tandis que le statut "Développement" avait une minuterie de 30 jours. Le fait d'avoir des tâches dans le statut "Confirmation du problème" nous a motivés à envoyer un ping à nos collègues pour obtenir une réponse. Nous avons changé notre approche de communication, en utilisant des messages privés ou des threads Slack au lieu de commenter dans Jira. Cela a réduit le temps de réponse à un jour par rapport aux semaines qu'il fallait auparavant. Bien que nous n'ayons pas mis de minuterie sur le statut "En attente de correctif", nous avons alloué plus de temps pour la communication et la discussion avec les clients. Si une tâche était jugée irréalisable, nous en informions le client et priorisions les tâches les plus importantes. Cela a conduit à une réduction de 50 % des tâches en attente. De plus, nous avons commencé à organiser des réunions où les clients pouvaient expliquer l'importance d'une tâche, nous aidant à mieux hiérarchiser notre charge de travail. Pour le statut "Développement", nous avons défini un timer de 30 jours et limité le nombre de tâches dans ce statut à quatre. Cela nous a aidés à nous concentrer sur la correction du bogue dans le délai imparti et à éviter d'être submergés par le bruit visuel inutile de 20 à 40 tâches dans l'état "Développement" sur le tableau. Pour nous assurer que nos pratiques sont durables, nous avons introduit le principe du 90e centile, ce qui signifie que 90 % des tâches devaient être terminées à temps, comme déterminé par les minuteries pour chaque statut. Nous avons surveillé cela à l'aide du tableau de contrôle de Jira et du plug-in Jira-helper pour créer le 90e centile. Enfin, nous avons introduit une motivation supplémentaire pour l'équipe, en promettant une prime si le principe du 90e centile était respecté, tout comme Augeas a promis à Hercule un dixième de ses chevaux en prime. En implantant cette nouvelle approche et en reconstruisant les processus de notre service, nous avons enfin pu nous attaquer à un problème qui nous tourmentait depuis quatre longues années. La solution n'a pas nécessité de temps, d'effort ou de budget supplémentaire, mais nous avons considérablement réduit le nombre de tâches à empiler. En seulement cinq mois, avec une équipe de seulement deux employés intelligents, nous avons réussi à réduire la file d'attente de 1 500 billets à seulement 150. Cette expérience nous a appris l'importance d'identifier la cause profonde d'un problème pour y remédier efficacement. Cela a également souligné l'importance de disposer de processus bien conçus, car des processus médiocres entraîneront inévitablement une accumulation de problèmes, comme nous l'avons découvert de première main. Écrit par Dimitri Andrews, ingénieur en test logiciel chez Social Discovery Group

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Developers: Build Less. Deliver More. [Learn how]	

S'attaquer aux écuries d'Augias du support client : notre réussite

Trop long; Pour lire

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

S'attaquer aux écuries d'Augias du support client : notre réussite

Trop long; Pour lire

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES