Fallstudie über die Kommunikation mit einem „schwierigen“ Kunden

Manchmal steht der Ingenieur im technischen Support vor einer schwierigen Wahl: Wende ich das Dialogmodell „Wir setzen auf hohe Servicequalität!“ oder „Drücken Sie den Knopf – und Sie erhalten das Ergebnis“ an?

…Das gebrochene Flügelchen aus Watte,
Lassen Sie uns in die Wolken sinken, wie in Gruften.
Wir, die Poeten, sind selten heilig,
Wir, die Poeten, sind oft blind.
(Oleg Ladyzhensky)

Die Arbeit im Support ist nicht nur eine Sammlung lustiger Geschichten über selbstsprungende Zeit und GPS-Einhörner, und auch nicht nur kriminalistische Rätsel im Stil von Hercule Poirot.

Technischer Support ist in erster Linie Kommunikation, und Kommunikation bedeutet Menschen, und unter unseren Kunden gibt es sehr verschiedene Charaktere:

• Ein Deutscher, der aus einem Café gegenüber seinem Büro in Berlin arbeitet, ausgestattet mit wahrhaft skandinavischer Gelassenheit, perfektem Ruhebewusstsein, einem sorgfältig abgestimmten Netzwerk und umfanglichen Fähigkeiten, all dies auf A+ Niveaus einzurichten und zu pflegen. Server Anfragen von ihm lösen in der Regel die gleiche Reaktion aus wie die letzte Pelmeni auf einem großen Tisch und das nicht rechtzeitig abgedrehte Licht.
• Ein Brite, der in den letzten 5 Jahren zweimal die Firma gewechselt hat, aber seinen Umgang mit dem Support nicht. Die Leute fliehen vor seinen Fällen wie vor der Pest oder nehmen ihn an, wohlwissend um die „Herausforderungen“ der Zusammenarbeit mit ihm. Er kann ohne Vorwarnung die Kontrolle über eine Remote-Sitzung übernehmen (um seine E-Mails, gelegentlich auch private, zu prüfen), Ingenieure und das Management mit kleinsten Kleinigkeiten unter Druck setzen und letztendlich auch Anfragen überraschend mit dem Kommentar „DUPLIKAT“ schließen.
• Ein Inder mit einem komplizierten und unaussprechlichen Nachnamen, der alle Mythen über indische IT widerlegt: höflich, ruhig, kompetent, liest Dokumentationen, hört auf die Ratschläge des Ingenieurs und erledigt alles stets selbst. Außerdem trägt er einen beeindruckenden Turban (ja, wir haben ihn auf Facebook gefunden) und hat eine perfekte Oxford-Aussprache.

Solche «namhaften» Kunden kann sich jeder Ingenieur ohne großes Nachdenken an etwa fünf erinnern. Mit einigen erschrecken wir unsere Neulinge (»Wenn du dich im Labor schlecht benimmst, kommt der Bösewicht und...«), mit anderen zeigen wir an, wie sehr wir sie schätzen (»Ich habe bereits 5 Anfragen von N. bearbeitet!«). Meistens wissen und verstehen wir jedoch, dass positive und negative Beispiele nur unsere Wahrnehmung sind, die aus der Kommunikation mit unseren Kunden und deren Rückmeldungen an uns resultiert.

Und diese Kommunikation kann sehr unterschiedlich sein.

Einmal haben wir bereits über die «Dämonen» berichtet, die Ingenieuren die Arbeit mit Kunden erschweren, und jetzt möchte ich zeigen, wie es in der Praxis aussieht.

Hier ist ein gutes Beispiel aus zwei Jahren: die Reaktion eines Kunden auf die „traditionellen“ Troubleshooting-Schritte des Ingenieurs und umgekehrt, die Reaktion des Ingenieurs auf den Kommunikationsstil des Kunden.

Fallbeispiel zur Fragmentierung

Also, das Fallbeispiel: Ein sehr erfahrener und technisch versierter Kunde eröffnet eine Supportanfrage und stellt eine direkte Frage, wobei er zahlreiche Details bereitstellt, um die Situation zu beschreiben.

Ich habe mir die Freiheit genommen, die Korrespondenz in einen Dialog umzuschreiben, um die stilistischen Besonderheiten beizubehalten.

Kunde (K): — Guten Tag, mein Herr. Mein Name ist Marco Santino. Wir haben Ihre besten Praktiken genutzt und die neueste von Ihnen empfohlene Technologie bei uns installiert, aber wir stellen fest, dass die Systemleistung aufgrund hoher Fragmentierung kritisch niedrig wird. Ist das normal?

Ingenieur (I): — Hallo Marco! Ich bin Ignat und ich helfe Ihnen gerne. Tritt das immer auf? Haben Sie eine Defragmentierung versucht?

(K): — Verehrter Ignat! Ja, das tritt immer auf. Wir haben die Defragmentierung versucht, aber leider dauert es bei vollständiger Systemstillstand zu lange, weshalb es nicht möglich ist.

(I): — Hören Sie, ich kann diese besten Praktiken nicht finden. Wo haben Sie die entdeckt? Und vielleicht sollten wir doch die Defragmentierung durchführen, hm?

(K): — Sehr geehrter Ignat! Wir verstehen, dass Sie unser Problem nicht ernst nehmen und es Ihnen schwerfällt, eine direkte, nicht politisch korrekte Antwort zu geben. Dennoch versuchen wir, Ihnen zu antworten. Wir haben nicht Ihre Erfahrung (wir sind erst seit 1960 im IT-Bereich tätig), und sind Ihnen sehr dankbar für Ihre Arbeit und Ihre Mühe in unserer Aufklärung. Best Practices wurden uns von Ihren Produktmanagern beim Abendessen in Barcelona übermittelt, und ich habe Ihnen den Link dazu geschickt. Als Ivan fragen wir Sie direkt: Ist diese Situation normal? Wenn Sie kein Interesse daran haben, mit uns zu sprechen, bitte finden Sie jemanden, der uns helfen kann.

(I): — Marko, ich konnte diese Best Practices nicht finden. Ich brauche die Logs und werde das Problem an einen anderen Ingenieur weitergeben. Ich sage Ihnen folgendes: wenn Sie Fragmentierung sehen und nicht defragmentieren — das ist dumm und verantwortungslos. Und wie konnten Sie überhaupt den edlen Namen „Ignat“ mit mir, Ivan, verwechseln?

(K): — Genug! Ich bin nicht Ihr Bruder oder Bekannter, Ignat, darum bitte ich Sie, mich Herr Santino zu nennen! Wenn Sie ein Dokument nicht finden können und solch eine einfache Aufgabe nicht bewältigen, dann kündigen Sie oder fragen Sie den Autor, der uns dieses Dokument übergeben hat! Was die Logs betrifft, können wir Ihnen diese nicht ohne besondere Genehmigung übergeben, da wir mit vertraulichen Dokumenten arbeiten. Ihre Entrüstung über meinen Fehler zeigt Ihre Unwissenheit und Unhöflichkeit. Es tut mir leid für Sie. Und zuletzt: wenn wir sagen, dass wir „defragmentiert haben“ und es „nicht möglich ist“, dann bedeutet das, dass wir es versucht haben und es eben nicht möglich ist. Ignat, ich bitte Sie, hören Sie auf, Unsinn zu reden, und konzentrieren Sie sich auf Ihre Arbeit – geben Sie uns entweder eine Antwort oder finden Sie diejenigen, die sie uns geben können!

Nach diesem wurde die Anfrage auf die nächste Ebene weitergeleitet, wo sie einfach gestorben ist – der Kunde hat die Logs nicht bereitgestellt, umfassende Tests haben nichts ergeben, und das Problem konnte schlichtweg nicht bestätigt werden.

Frage: Was hätte der Ingenieur tun können, um das Konfliktniveau zu senken und die Eskalation zu vermeiden?

(Versuchen Sie, diese Frage selbst zu beantworten, bevor Sie weiterlesen).

Lyrische technische Abschweifung
Für Rätsel- und Krimi-Fans: Das Problem war viel gravierender als erwartet: Die Fragmentierung von ReFS beeinflusste nicht nur die Festplattenoperationen, sondern führte in einigen Fällen auch zu einer bis zu zehnfachen Erhöhung des CPU- und RAM-Verbrauchs, und das nicht nur bei Veeam-Kunden – alle ReFS-Nutzer könnten betroffen sein.

Microsoft benötigte über ein Jahr, unterstützt von vielen Anbietern, um schließlich diesen Fehler zu beheben (worin wir auch einen Teil unseres Verdienstes sehen – zahlreiche Diskussionen über die Unterstützung dieses Giganten auf allen Ebenen wurden geführt).

In Bezug auf die Frage 'Was hätte man tun können?' möchte ich eine andere, ewige Frage aufwerfen: 'Wer ist schuld?'

Aus beruflicher Solidarität möchte ich sagen: 'Der Kunde ist schuld', und den Ingenieur in Schutz nehmen. Als Führungskraft, die ständig die Arbeit ihrer Ingenieure bewertet, sehe ich die Fehler, die Ignat gemacht hat. Wer hat also recht?

Lassen Sie uns alles der Reihe nach angehen

Dieser Fall ist sehr hart; es gibt mehr Fragen als Antworten.

Formell hat Ignat alles ziemlich gut gemacht:

• Eine der grundlegenden Werte von Veeam war: Kommunikation aus dem Herzen;
• sprach den Kunden mit Namen an;
• klärte die Situation, bevor er eine Lösung anbot.

Hätte er eine derartige Eskalation vermeiden können?

Ja: Er hätte beobachten können, wie Herr Santino sich verhält (immer nur 'Sie' und mit Nachnamen), die 'grundlegenden Fragen' vermeiden, sein Interesse am Problem zeigen und versprechen können, herauszufinden, ob dies normales Verhalten ist.

Minimale Schritte, ohne technische Details – und sie hätten bereits geholfen, die Situation zu 'entkräften'. Aber selbst wenn das übersehen wurde – einfach 'nichts tun' hätte auch ein wenig geholfen.

Klingt offensichtlich: keine Tippfehler persönlich nehmen, sich nicht von einem schnippischen Kunden verletzen lassen (auch wenn alles auf ein übersteigertes Selbstbewusstsein hindeutet), das Gespräch nicht persönlich werden lassen, nicht auf Provokationen eingehen… Wie viele 'Nicht'-Handlungen es gibt, und alle sind wichtig, und alle betreffen die Kommunikation.

Und wie steht es mit dem Kunden? Briefe werden in einem 'hohen Stil' verfasst, ständige Verweise auf seine Verbindungen ganz oben, verhüllte Beleidigungen und die Empfindung mangelnden Respekts? Ja, wir können das so lesen. Andererseits – ist Herr Santino wirklich in seinem Zorn so unrecht?

Und dennoch, was hätte man auf beiden Seiten tun können? So sehe ich das:

Von der Ingenieurseite:

• die Formalität des Kunden einschätzen;
• weniger der „grundlegenden Isolation“ folgen;
• (das wird jetzt subjektiv) die E-Mails sorgfältiger lesen;
• Fragen beantworten und nicht ausweichen;
• und schließlich nicht auf Provokationen eingehen und persönlich werden.

Für den Kunden:

• die Frage im ersten Schreiben klar benennen, ohne sie in technischen Details zu verbergen (das ergibt sich nicht direkt aus dem Dialog, aber glauben Sie mir, die Detailtiefe war erstaunlich);
• ein wenig toleranter gegenüber Fragen sein – nicht jeder denkt gleich, und manchmal muss man viel fragen, um das Herz des Problems zu verstehen;
• möglicherweise das Verlangen zügeln, seine Bedeutung und Kontakte „auf höchster Ebene“ zu zeigen;
• und, wie für Ignat, vermeiden, persönlich zu werden.

Ich wiederhole – das ist nur meine Sichtweise, meine Einschätzung, die keineswegs Empfehlungen oder Anleitungen dafür darstellt, „wie man leben und arbeiten sollte“. Dies ist eine von vielen Möglichkeiten, die Situation zu betrachten, und ich freue mich, wenn Sie Ihre Vorschläge einbringen.

Ich verteidige den Ingenieur nicht – er ist ein selbstgerechter Bösewicht. Ich beschuldige den Kunden nicht – er hat das Recht, auf seine Weise zu kommunizieren, selbst wenn dies in einer subtilen, fast höflichen Beleidigung verpackt ist (ein gutes Beispiel für einen modernen Edelmann, der nicht mit Krieg und Söldnerei, sondern mit IT handelt – obwohl…).

»Der Stein hat die Klinge gefunden« – so könnte ich diesen Schriftverkehr zusammenfassen, oder anders gesagt, mit einer Wahrheit, an die ich aufrichtig glaube: „An Konflikten sind normalerweise immer zwei beteiligt.“

Man könnte es mit den Worten unseres Business-Coaches ausdrücken: „Frühere Erfahrungen, Kommunikationsgewohnheiten und unterschiedliche Weltanschauungen behindern erfolgreiche Kommunikation.“ Man kann an die goldene ethische Regel erinnern: „Behandle andere so, wie du selbst behandelt werden möchtest.“

Man könnte einfach sagen: In jeder Kommunikation sind immer zwei beteiligt, und auf der anderen Seite des Telefons oder Bildschirms sitzt ein lebendiger Mensch, der auch Angst, Freude, Traurigkeit oder etwas anderes empfindet. Es wird angenommen, dass Emotionen und Geschäft nicht vereinbar sind, aber wohin sollen wir mit den Emotionen? Sie waren, sind und werden immer sein. Selbst wenn wir technischer Support sind und ganz bestimmte Aufgaben lösen, wird unsere Hauptaufgabe genau durch das zweite Wort definiert: "Unterstützung".

Unterstützung bedeutet Menschen.

***

Erinnern Sie sich, ich habe bereits zweimal geschrieben, dass immer zwei dafür verantwortlich sind? Nun, in der Tat sind in dieser konkreten Situation alle drei schuldig. Warum? Einfach, weil der Ingenieur nicht isoliert ist, sondern Teil des Supports, und es ist unsere Aufgabe und unsere Verantwortung, den Mitarbeiter darin zu schulen, mit ähnlichen Situationen umzugehen. Wir versuchen, aus unseren Fehlern zu lernen – und unseren Mitarbeitern zu helfen, diese zu vermeiden.

Kann man solchen Situationen immer ausweichen? Nicht immer. Egal wie gut der hypothetische Ingenieur Ignat auch sein mag, "auf der anderen Seite" könnte eine Person sitzen, die alles tun wird, um die Situation zu verschärfen.

Die Schönheit der Arbeit im Veeam-Support, eine unserer Werte, auf die wir stolz sind, ist die Teamarbeit. Es ist sehr wichtig, sich daran zu erinnern: "Du bist nicht allein" und wir tun alles, um sicherzustellen, dass es so bleibt.

Kann man lernen, in solchen Situationen zu leben und zu arbeiten? Ja, das kann man.

Wir können, wir lieben, wir praktizieren – dafür haben wir unser internes Schulungsprogramm aufgebaut und verfeinern es ständig weiter. In den zweieinhalb Jahren seit der beschriebenen Situation haben wir intensiv an unserem Schulungsprogramm gearbeitet – und nutzen jetzt aktiv Fallstudien, simulieren Situationen und sammeln und analysieren ständig unsere Fehler sowie kommunikativen Feinheiten.

Wir glauben, dass unser Team jetzt viel besser auf alle Situationen vorbereitet "ins Feld" geht. Und wenn etwas Unerwartetes auftritt, sind wir da und bereit zu helfen, und ergänzen unsere Kurse dann mit neuen Beispielen.

Und es lohnt sich. Hier ist zum Beispiel das Feedback eines unserer Kunden zu unserer Arbeit:

„Wir sind seit über 20 Jahren in der IT-Branche tätig und sind uns einig, dass kein Anbieter den gleichen technischen Support bietet wie Veeam. Es ist erfreulich, mit dem technischen Personal von Veeam zu sprechen, da sie kompetent sind und Probleme schnell lösen. Der Support sollte nie unterschätzt werden. Er ist ein Maßstab für das Engagement und den Erfolg eines Unternehmens. Veeam ist die Nummer 1 im Support.“

„Wir arbeiten in der IT-Branche seit mehr als 20 Jahren, und wir behaupten, dass kein anderer Anbieter ein so hohes Maß an technischer Unterstützung wie Veeam bietet. Es ist sehr angenehm, mit den Ingenieuren von Veeam zusammenzuarbeiten, da sie ihr Handwerk verstehen und Probleme schnell lösen können. Technischer Support sollte niemals unterschätzt werden. Dies ist ein Maßstab dafür, wie verantwortungsbewusst und erfolgreich ein Unternehmen ist. Veeam hat den besten technischen Support.“

***

Kommunikation ist ein Feld für Experimente und Fehler, ob wir das wollen oder nicht. Meiner Meinung nach ist es vollkommen normal, Fehler zu machen; mein Aufruf lautet: Macht Fehler! Es geht nicht darum, ob ihr fallt, sondern darum, ob ihr lernt, sicher wieder aufzustehen.

Manchmal ist es schwierig, sich selbst zu fangen und sich an all die Anweisungen und Ratschläge zu erinnern, die großzügig von den „Gurus“ der Kundenkommunikation oder erfahrenen Kollegen geteilt werden. Es ist oft viel einfacher, sich daran zu erinnern: „Ich spreche mit einem Menschen“.

***

Ich erhebe keinen Anspruch auf überlegene Kenntnisse oder besondere Qualitätsstandards im Kundenkontakt. Eine Liste meiner Fehler würde für ein ganzes Lehrbuch ausreichen.

Mein Ziel war es, zu zeigen, wie der technische Support sein kann und eine Diskussion darüber anzuregen, was in solchen Fällen als akzeptabel anzusehen ist und was nicht.

Was denken Sie?

Quelle: habr.com