Organigramme de remontée du support client (arbre de décision)

Organigramme de remontée du support client : un arbre de décision de huit tests acheminant un cas vers la première ligne, le niveau 2, l'ingénierie, le propriétaire du compte ou un responsable de service.

Utiliser ce modèle

Qu'est-ce que le processus organigramme de remontée du support client (arbre de décision) ?

Cette page est un arbre de décision, pas une cartographie des processus. Une cartographie des processus indique ce qui se passe ensuite et qui le fait, du ticket enregistré jusqu'à la clôture. Un arbre de décision répond à une question plus étroite et bien plus controversée qui se trouve à l’intérieur : étant donné le cas dont vous êtes saisi, reste-t-il en première ligne, et si ce n’est pas le cas, qui le prend ? Pour le flux de bout en bout, y compris la journalisation, la priorisation, la gestion et la clôture des incidents majeurs, utilisez l'organigramme du processus de gestion des incidents. En cas d'insatisfaction à l'égard du service plutôt que d'un défaut, utilisez l'organigramme du processus de réclamation client. Utilisez ce graphique lorsque l'argument porte sur le routage lui-même.

L’escalade va mal dans deux directions opposées et les deux coûtent cher. Si la situation s'intensifie trop facilement, le niveau 2 devient une deuxième file d'attente pour les cas qui auraient pu être fermés en première ligne, ce qui augmente le coût par ticket et allonge l'attente pour les cas qui nécessitent réellement une attention spécialisée. Trop rarement, un compte protégé par contrat apprend un engagement manqué de la part de ses propres utilisateurs. Aucun des deux échecs n’est résolu par davantage de supervision. Il est résolu par des tests écrits, huit d'entre eux ici, chacun répondant à partir du ticket et du relevé de compte plutôt que de l'impression de la conversation.

Les voies nomment les droits de décision, pas les départements. L'agent de première ligne décide de la portée et de l'efficacité d'un correctif documenté. Le chef de l’équipe d’assistance est responsable des tests d’exposition, de SLA et de défauts. Le titulaire du compte répond si le compte est stratégique ou protégé contractuellement. Le responsable de service répond à une seule question, à savoir si un compte critique est concerné, et seulement une fois l'exposition déjà établie. Exécuter les tests dans cet ordre signifie que le propriétaire de l'autorité la plus élevée gagne : un dossier juridiquement exposé ne peut pas se retrouver tranquillement dans un retard technique.

Ce que couvre cet organigramme

Dans ce modèle

  • Une porte de première ligne est envisagée avant toute escalade : « Dans le cadre de la première ligne ? » et « Un correctif documenté le résout ? » les deux doivent répondre Oui pour atteindre le résultat « Résolu en première ligne ». Soit Non, le dossier est envoyé à « Examen d'escalade par le chef d'équipe ».
  • L'exposition est testée en premier et non en dernier. « Exhibition de réputation ou d'ordre juridique ? » répondre Oui passe directement à « Compte critique affecté ? » dans la file du responsable de service, dont le Oui se termine par « Le responsable de service prend le commandement » et dont le Non se termine par « Le propriétaire du compte prend possession ».
  • « Cible SLA en danger ? » splits A risque from Dans la cible : A risque détourne le test du compte avant tout routage technique, Dans la cible passe directement à la question défaut.
  • « Compte stratégique ou protégé ? » se trouve dans la voie du propriétaire du compte. Oui se termine par « Le propriétaire du compte devient propriétaire » ; No rejoint le routage technique plutôt que d'ouvrir une seconde file d'attente parallèle.
  • Acheminement technique via « Défaut du produit confirmé ? » : Non se termine par « Transmis au support de niveau 2 », Oui passe à « Solution de contournement disponible ? », où Non se termine par « Transmis à l'ingénierie en tant que défaut ».
  • Un résultat délibéré sans escalade : lorsqu'une solution de contournement existe, l'agent la publie et le cas se termine par « Consigné comme un défaut, non remonté », de sorte que le bogue rejoint le retard d'ingénierie normal au lieu de consommer une escalade.

Quand utiliser ce modèle

  • L'escalade au sein de votre équipe est décidée par le tempérament individuel, et deux agents traitent le même cas différemment.
  • Le niveau 2 ou l'ingénierie s'oppose à la qualité des escalades et vous avez besoin de critères d'entrée convenus plutôt que d'un ton plus strict.
  • Les responsables de comptes entendent constamment parler de cas graves de la part des clients avant d'en entendre parler en interne.
  • Vous rédigez ou révisez une politique d’escalade et souhaitez que les tests et les droits de décision soient convenus avant que quiconque ne rédige la prose.
  • Vous recrutez un nouveau personnel d'assistance et avez besoin d'une page indiquant quand transmettre la situation et à qui, ainsi qu'une cartographie des processus de bout en bout.

Comment cela fonctionne

  1. Nommez les quatre décideurs

    Remplacez l'agent de première ligne, le chef d'équipe d'assistance, le propriétaire de compte et le responsable de service par les rôles qui existent dans votre organisation. Les petites équipes fusionnent souvent le propriétaire du compte avec le chef d'équipe ; les organisations avec une couverture en dehors des heures d'ouverture gardent généralement le responsable de service séparé car ce rôle change par rotation. Chaque voie doit être une personne joignable et autorisée à passer l'appel, et non un nom de service.

  2. Notez ce que signifie la portée de première ligne

    « Dans le cadre de la première ligne ? est le test qui décide dans quelle mesure votre volume n'augmente jamais, il mérite donc une définition écrite. Étendez-le par capacité plutôt que par effort : un article publié, un changement de configuration documenté ou une action de compte standard est concerné ; tout ce qui nécessite du code, un accès aux données de production ou une concession contractuelle est hors de portée par définition, quelle que soit la volonté de l'agent d'essayer.

  3. Définir le déclencheur de risque SLA avant la date limite

    Décidez quelle proportion du temps de réponse ou de résolution restant déclenche la « cible SLA à risque ? » et acceptez-la à l'avance afin que l'outil puisse la déclencher automatiquement. Toute la valeur de la branche est qu’elle fonctionne alors que l’objectif peut encore être atteint. Un déclencheur défini à la date limite elle-même vous indique seulement que l'engagement a déjà été manqué.

  4. Définir à l'avance la liste des comptes protégés

    « Compte stratégique ou protégé ? » doit être responsable depuis le CRM en quelques secondes. Tenez une liste explicite et enregistrez ce qui protège un compte : un statut stratégique nommé ou des engagements de réponse et de résolution écrits dans l'accord. Décider au cas par cas est ce qui permet au client le plus bruyant, plutôt qu'au plus important, de bénéficier d'un traitement prioritaire.

  5. Convenez des déclencheurs d’exposition avec les autorités juridiques

    « Exhibition de réputation ou d'ordre juridique ? » est la branche qui prime sur tous les autres tests, ses critères doivent donc être approuvés par un support extérieur : données personnelles exposées, régulateur ou auditeur impliqué, risque pour la sécurité, publication publique ou enquête de presse, ou pénalité contractuelle en jeu. Gardez la liste suffisamment courte pour pouvoir être rappelée sous pression et faites en sorte que n’importe quel déclencheur soit suffisant.

  6. Convenez de ce qui compte comme un défaut confirmé et d'une solution de contournement acceptable

    Définissez une barre de preuves pour « Défaut de produit confirmé ? », par exemple reproduit sur une version prise en charge avec des étapes qu'un autre ingénieur peut suivre, de sorte que les rapports non reproduits soient transmis au niveau 2 pour le diagnostic plutôt qu'à l'ingénierie. Décidez ensuite qui juge la solution de contournement acceptable. Si ce jugement n'est valable qu'avec support, le résultat « Consigné comme un défaut, non signalé » sera contesté par les clients qui ne l'ont jamais accepté.

Questions fréquentes

En quoi est-ce différent d'un organigramme du processus de remontée d'informations du support client ?

Un organigramme de processus est une séquence : enregistrer le ticket, le trier, le traiter, le résoudre, le clôturer, avec des lignes indiquant qui effectue chaque étape. Ce graphique est un arbre de décision, donc sa colonne vertébrale est une chaîne de questions plutôt qu'une chaîne de tâches, et ses branches se terminent par cinq résultats nommés différents au lieu de converger vers une seule étape de clôture. Utilisez la cartographie des processus pour voir l'ensemble du cycle de vie d'un dossier et utilisez cette arborescence au seul moment de ce cycle de vie où quelqu'un doit choisir un itinéraire. Les deux sont complémentaires : l'organigramme du processus de gestion des incidents montre où se situe la décision d'escalade, et ce diagramme montre comment la prendre.

Quand une demande d’assistance doit-elle être transmise ?

Lorsque l'un des rares tests écrits répond oui, pas lorsque le dossier est simplement ouvert depuis longtemps. Cinq des huit tests de ce tableau décident s'il faut escalader le problème : le cas dépasse les capacités de première ligne, aucun correctif documenté ne le résout, l'objectif du SLA est en danger, le compte est stratégique ou protégé contractuellement, ou il existe une exposition à la réputation ou au droit. Les trois autres décident où il va. Le temps écoulé est un déclencheur utile pour examiner un cas, mais un mauvais déclencheur pour le faire remonter à lui seul, car il déplace le travail sans ajouter aucune fonctionnalité dont le cas avait réellement besoin.

Quelle est la différence entre passer au niveau 2 et passer à un manager ?

Ils résolvent différents problèmes et ITIL les sépare en escalade fonctionnelle et hiérarchique. L'escalade fonctionnelle transfère un cas vers des personnes possédant des compétences plus spécialisées ou un accès plus approfondi au système, ce que représentent ici « Transféré au support de niveau 2 » et « Transmis à l'ingénierie en tant que défaut ». L'escalade hiérarchique implique une personne disposant de plus d'autorité, pour réinitialiser les attentes des clients, autoriser une exception ou engager des ressources, ce que représentent les résultats du propriétaire du compte et du responsable de service. Une affaire peut avoir besoin des deux. Envoyer un dossier à la ligne de gestion alors qu'il a réellement besoin d'un spécialiste fait perdre du temps au gestionnaire et ne fait pas avancer le ticket.

Chaque défaut confirmé d’un produit doit-il être signalé à l’ingénierie ?

Non, et traiter chaque défaut comme une escalade est la façon dont l’escalade perd son sens. Ce graphique est divisé en « Solution de contournement disponible ? ». En l'absence de solution de contournement acceptable, le client est bloqué. Le cas se termine donc par « Transmis à l'ingénierie en tant que défaut » et a la priorité affectant le service. Avec une solution de contournement, l'agent l'émet et le cas se termine par « Enregistré comme un défaut, non signalé » : le bogue parvient toujours à l'ingénierie via la voie normale d'admission et de priorisation des défauts, il n'interrompt tout simplement personne. Ce deuxième résultat est volontairement un terminateur de rejet, car décider de ne pas faire remonter le problème est un résultat légitime de l'évaluation et doit être enregistré comme tel.

Qui est autorisé à dire non à une escalade ?

Celui qui possède le test qui a échoué, c'est pourquoi les voies de ce tableau sont des droits de décision plutôt que des départements. Le chef d'équipe peut refuser un dossier qui échoue aux tests d'exposition, de SLA et de défaut et le renvoyer à la première ligne. Le propriétaire du compte, et non l'assistance, décide si un compte est protégé. Le responsable de service décide si un compte est critique et n'est interrogé qu'une fois l'exposition déjà établie, ce qui conserve ce rôle pour de véritables situations de commandement. Les escalades refusées sans raison enregistrée sont celles qui reviennent, alors identifiez quel test a échoué dans le cas.

Fait partie de

Fonctionnalités QueryChart pour ce processus

Utiliser ce modèle

Browse all Modèles de support client