Analyse d'un cas de communication avec un client "difficile"

Parfois, l'ingénieur du support technique doit faire un choix difficile : adopter le modèle de dialogue « Nous sommes pour une haute culture de service ! » ou « Appuie sur le bouton - tu obtiendras un résultat » ?

…En cassant une aile en coton,
Allongeons-nous dans les nuages, comme dans des cryptes.
Nous, poètes, sommes rarement saints,
Nous, poètes, sommes souvent aveugles.
(Oleg Ladyzhensky)

Travailler dans le Support Technique, ce n'est pas seulement des histoires amusantes sur le temps qui saute et les licornes GPS, ni même des énigmes de détective à la Hercule Poirot.

Le Support Technique, c'est avant tout de la communication, et la communication implique des gens, et parmi nos clients, il y a des personnages très différents :

• Un Allemand travaillant depuis un café en face de son bureau à Berlin, possédant une véritable endurance nordique, un calme parfait, un réseau soigneusement agencé, un vaste parc serveurs et des capacités cognitives pour tout configurer et maintenir à A+. Les demandes de sa part provoquent généralement la même réaction que le dernier ravioli dans une grande compagnie et une lumière éteinte au mauvais moment.
• Un Britannique, qui a changé deux entreprises au cours des cinq dernières années, mais pas son style de travail avec le support. Ses cas font soit fuir les gens, comme s'il s'agissait de la peste bubonique, soit les prennent, en présageant toute la « beauté » de travailler avec cette personne, car il peut sans avertissement prendre le contrôle d'une session à distance (pour vérifier son email, parfois personnel), mettre la pression sur les ingénieurs et la direction pour des choses insignifiantes, et enfin, fermer aussi soudainement des demandes avec le commentaire « DUPLICATA ».
• Un Indien avec un nom compliqué et imprononçable, défiant tous les mythes sur l'IT indien : poli, calme, compétent, lisant la documentation, écoutant les conseils de l'ingénieur et faisant toujours tout lui-même, arborant un magnifique turban (oui, nous l'avons trouvé sur Facebook) et une prononciation oxfordienne parfaite.

Chaque ingénieur peut se souvenir d’une poignée de ces clients « nommés » sans trop réfléchir. Certains effraient nos débutants (« si tu te comportes mal dans le labo, le bogeyman va venir et!.. »), d'autres nous rendent fiers (« et j'ai déjà clos 5 demandes de N. ! »). Et le plus souvent, nous nous souvenons et comprenons que les exemples positifs et négatifs ne sont que notre perception, qui découle de la communication, à la fois entre nous et les clients et vice versa.

Et cette communication peut être très variée.

Nous avons déjà parlé de les «démons» qui empêchent les ingénieurs de travailler avec les clients, et maintenant je veux montrer comment cela se passe, à travers un exemple concret.

Voici un bon exemple datant de deux ans : la réaction d'un client aux étapes de dépannage «traditionnelles» de l'ingénieur et celle de l'ingénieur face au style de communication du client.

Cas sur la fragmentation

Ainsi, le cas : un client très expérimenté et techniquement averti ouvre un ticket auprès du support technique et pose une question directe, fournissant de nombreux détails pour décrire la situation.

J'ai pris la liberté de réécrire la correspondance sous forme de dialogue, en préservant les caractéristiques stylistiques.

Client (C) : — Bonjour, Monsieur. Je m'appelle Marco Santino, nous avons suivi vos meilleures pratiques et installé la technologie la plus récente que vous recommandez, mais nous constatons que la performance du système devient critique en raison d'une forte fragmentation. Est-ce normal ?

Ingénieur (I) : — Bonjour, Marco ! Je m'appelle Ignat, et je suis là pour vous aider. Cela se manifeste-t-il toujours ? Avez-vous essayé de défragmenter ?

(C) : — Cher Ignat ! Oui, cela se manifeste toujours. Nous avons essayé de défragmenter, mais, hélas, cela prend trop de temps avec l'arrêt complet du système, donc ce n'est pas possible.

(I) : — Écoutez, je ne trouve pas ces meilleures pratiques. Où les avez-vous trouvées ? Et peut-être devrions-nous procéder à la défragmentation, non ?

(C) : — Cher Ignat ! Comprenant que vous ne prenez pas notre problème au sérieux et en me retenant à grand-peine de donner une réponse franche, je vais tout de même essayer de vous répondre. Nous n'avons pas votre expérience (nous sommes dans l'IT seulement depuis 1960), et nous vous sommes très reconnaissants pour votre travail et vos efforts pour notre éducation. Les meilleures pratiques nous ont été transmises par vos chefs de produit lors d'un dîner à Barcelone, et je vous ai envoyé un lien à leur sujet. Vous, Ivan, nous vous demandons directement : cette situation est-elle normale ? Si vous n'êtes pas intéressé à parler avec nous, s'il vous plaît, trouvez quelqu'un qui peut nous aider.

(I) : — Marco, je n'ai pas trouvé ces meilleures pratiques. J'ai besoin des logs, et je vais transmettre le problème à un autre ingénieur. Laissez-moi vous dire ceci : si vous constatez une fragmentation et ne défragmentez pas — c'est stupide et irresponsable. Et en général, comment avez-vous pu confondre le noble nom “Ignat” et m'appeler Ivan ?

(K): — Assez ! Je ne suis pas votre frère, ni votre beau-frère, Ignat, pour que vous m'appeliez par mon prénom. Par conséquent, veuillez vous adresser à moi en tant que M. Santino ! Si vous ne pouvez pas trouver le document et que vous ne parvenez pas à gérer une tâche aussi simple, alors soit démissionnez, soit demandez à son auteur qui nous a remis ce document ! En ce qui concerne les journaux, nous ne pouvons pas vous les transmettre sans accord spécial, car nous travaillons avec des documents sensibles. Votre indignation concernant mon erreur montre votre ignorance et votre manque de décence. Je vous plains sincèrement. Et enfin : si nous disons que nous avons « essayé de défragmenter » et que c'est « impossible », cela signifie que nous avons essayé et que c'est impossible. Ignat, je vous en prie, cessez de dire des sottises et concentrez-vous sur votre travail — soit donnez-nous une réponse, soit trouvez celui qui le fera !

Après cela, la demande a été transférée à un niveau supérieur, où elle est morte — le client n'a toujours pas fourni les journaux, les tests à grande échelle n'ont rien donné et le problème n'a tout simplement pas pu être confirmé.

Question : que pouvait faire l'ingénieur pour éviter l'escalade et les conflits ?

(Essayez de répondre à cette question vous-même avant de lire la suite).

Une parenthèse technique lyrique
Pour les amateurs de mystères et ceux qui se demandent « qui est le coupable ? » : le problème s'est avéré bien plus sérieux : la fragmentation de ReFS n'affectait pas seulement les opérations de disque, mais dans certains cas, elle augmentait la consommation de CPU et de RAM jusqu'à dix fois, et pas seulement chez les clients de Veeam — tous les utilisateurs de ReFS pouvaient en souffrir.

Microsoft a mis plus d'un an, avec le soutien de nombreux fournisseurs, pour enfin corriger cette erreur (dans ce que nous voyons aussi notre mérite — de nombreuses têtes ont été brisées sur le support de ce géant à tous les niveaux).

En répondant à la question “que pouvait-on faire ?”, je veux poser une autre question éternelle : « Qui est le coupable ? »

Par solidarité professionnelle, j'ai très envie de dire : « Le client est coupable », — et commencer à protéger l'ingénieur. En tant que responsable, j'évalue constamment le travail de mes ingénieurs et je vois les erreurs commises par Ignat. Qui a raison ?

Examinons tout dans l'ordre

Ce cas est très difficile, avec plus de questions que de réponses.

Formellement, Ignat a bien fait :

• il a suivi l'une des valeurs fondamentales de Veeam : Conversation from the heart;
• s'adresser au client par son nom;
• clarifier la situation avant de proposer une solution.

Aurait-il pu éviter un tel emportement?

Oui : remarquer comment M. Santino communique (uniquement en utilisant le vouvoiement et le nom de famille), éviter les « questions de base », montrer son intérêt pour le problème et promettre de comprendre si ce comportement est normal.

Des étapes minimales, sans entrer dans les détails techniques - et elles auraient déjà pu aider à "éteindre" la situation. Mais même si cela a été négligé - le fait de "ne rien faire" aurait aussi un peu aidé.

Cela semble évident : ne pas prendre une faute de frappe personnellement, ne pas se vexer face à un client sarcastique (même si tout indique un ego surdimensionné), ne pas faire dévier la conversation sur des attaques personnelles, ne pas céder aux provocations… Voilà tous ces "ne pas", tous importants, et tous concernant la communication.

Et qu'en est-il du client ? Les lettres sont rédigées dans un « style élevé », avec des références constantes à ses relations au plus haut niveau, des insultes voilées et une indignation due à un apparent manque de respect ? Oui, nous pouvons le lire de cette manière. Et d'un autre côté - M. Santino a-t-il vraiment tort dans sa colère?

Et pourtant, que pouvait-on faire des deux côtés ? Voici comment je le vois :

Du côté de l'ingénieur :

• évaluer le degré de formalité du client;
• moins suivre l'« isolation de base »;
• (ceci va être subjectif) lire plus attentivement les lettres;
• répondre aux questions, au lieu de les éviter;
• et enfin, ne pas céder aux provocations et ne pas faire de remarques personnelles.

Du côté du client :

• définir clairement la question dans le premier email, sans la dissimuler dans les détails techniques (cela ne découle pas directement du dialogue, mais croyez-moi, la précision était impressionnante);
• être un peu plus tolérant face aux questions - tout le monde ne pense pas de la même manière, et il faut parfois poser beaucoup de questions pour comprendre la nature même du problème;
• peut-être contenir le désir de montrer sa propre importance et ses relations "au plus haut niveau";
• et, tout comme pour Ignat - éviter les attaques personnelles.

Je répète - c'est juste ma vision, mon évaluation, qui n'est en aucun cas des recommandations ou un guide sur "comment vivre et travailler". C'est une des façons de voir la situation, et je serai ravi si vous proposez les vôtres.

Je ne défends pas l'ingénieur – il est un Buratino maléfique par lui-même. Je ne blâme pas le client – il a le droit de s'exprimer comme il l'entend, même si cette communication est souvent dissimulée dans un élégant entrelacs d'insulte polie presque délicate (un bon exemple d'idalgo moderne, exerçant non pas par mercenariat ou guerre, mais en IT – quoi qu'il en soit…).

« La faux a trouvé une pierre » — c'est exactement ainsi que je pourrais résumer cette correspondance, ou même l'exprimer autrement, en vérité que je crois sincèrement: « dans tout conflit, il y a généralement deux coupables ».

On peut dire avec les mots de notre coach professionnel : « l'expérience passée, les habitudes de communication et les différentes visions du monde entravent une communication réussie ». On peut se rappeler la règle d'or de la moralité : « Agis envers les autres comme tu souhaiterais qu'ils agissent envers toi ».

Ou on peut simplement dire : dans toute communication, il y a toujours deux personnes impliquées, et de l'autre côté du téléphone ou de l'écran, il y a un être humain, qui ressent aussi de la peur, de la joie, de la tristesse ou autre chose. Oui, on dit que les émotions et les affaires ne font pas bon ménage, mais que pouvons-nous faire face aux émotions ? Elles ont existé, existent et existeront, et même si nous sommes le Support Technique et que nous résolvons des tâches très spécifiques, notre travail principal est défini précisément par le deuxième mot : « soutien ».

Le soutien, c'est une affaire de personnes.

***

Vous vous souvenez, j'ai déjà écrit deux fois que deux personnes sont en cause ? Eh bien, en réalité, au-delà de cela – dans cette situation, les trois sont responsables. Pourquoi ? Tout simplement parce que l'ingénieur n'est pas un élément isolé, mais fait partie du support technique, et c'est notre travail et notre responsabilité d'apprendre à notre personnel à gérer des situations similaires. Nous essayons d'apprendre de nos erreurs – et d'aider nos employés à les éviter.

Peut-on toujours éviter de telles situations ? Pas toujours. Peu importe à quel point l'ingénieur hypothétique Ignat est bon, il peut y avoir quelqu'un de l'autre côté qui fera tout pour envenimer la situation.

Mais la beauté du travail chez Veeam Support, l'une des valeurs dont nous sommes fiers - c'est le travail en équipe. Il est très important de se rappeler : « Tu n'es pas seul » - et nous faisons tout pour que cela soit vrai.

Peut-on apprendre à vivre et travailler dans de telles situations ? Oui, c'est possible.

Nous savons, aimons et pratiquons — c'est pour cela que nous avons construit notre formation interne et que nous continuons à l'ajuster et à la peaufiner. En deux ans et demi, qui se sont écoulés depuis la situation décrite, nous avons sérieusement travaillé sur notre programme de formation — et maintenant nous utilisons activement des études de cas, modélisons des situations, accumulons et revenons sans cesse sur nos erreurs pour analyser les subtilités de la communication.

Nous croyons que nos équipes sont désormais beaucoup mieux préparées à toute situation, et si quelque chose surgit qu'ils ne sont pas prêts à affronter — nous sommes là pour aider, et ensuite nous compléterons nos cours avec de nouveaux exemples.

Et cela en vaut la peine. Voici, par exemple, le retour d'un de nos clients sur notre travail :

« Nous travaillons dans l'industrie informatique depuis plus de 20 ans, et nous sommes tous d'accord pour dire qu'aucun fournisseur n'offre le niveau de support technique que Veeam propose. C'est un plaisir de parler au personnel technique de Veeam car ils sont compétents et résolvent les problèmes rapidement. Le support ne doit jamais être sous-estimé. C'est une mesure de l'engagement et du succès d'une entreprise. Veeam est le numéro 1 pour le support. »

« Nous travaillons dans l'industrie informatique depuis plus de 20 ans, et nous affirmons qu'aucun autre fournisseur ne propose un niveau de support technique comme Veeam. C'est très agréable de travailler avec les ingénieurs de Veeam car ils sont compétents et peuvent résoudre les problèmes rapidement. Le support technique ne doit jamais être sous-estimé. C'est une mesure de la responsabilité et du succès d'une entreprise. Veeam a le meilleur support technique. »

***

Toute communication est un terrain d'expérimentation, qu'on le veuille ou non. À mon avis, faire des erreurs est normal ; de plus, mon exhortation est : faites des erreurs ! Ce n'est pas la chute qui compte, mais ce que vous apprenez à poser avec assurance ensuite.

Il est parfois difficile de se rappeler toutes les instructions et recettes que partagent généreusement les « gourous » de la communication avec les clients ou les collègues expérimentés. Il est souvent plus simple de se rappeler : « je parle avec une personne ».

***

Je ne prétends pas détenir le savoir suprême ou un standard de qualité particulier en communication avec les clients. Une liste de mes erreurs suffirait à remplir un manuel entier.

L'objectif que je me suis fixé : montrer comment cela peut être dans le support technique et lancer une discussion sur ce qui peut être considéré comme acceptable dans de tels cas, et ce qui ne l'est pas.

Qu'en pensez-vous ?

Source : habr.com