Soms staat de support engineer voor een moeilijke keuze: het model van de dialoog "Wij gaan voor hoge servicekwaliteit!" of "Druk op de knop en je krijgt het resultaat"?
…Een gebroken vleugel van watten,
Laten we in de wolken liggen, als in grafkamers.
Wij, dichters, zijn zelden heilig,
Wij, dichters, zijn vaak blind.
(Oleg Ladyzhensky)
Werken in de technische ondersteuning is niet alleen grappige verhalen over zelfspringende tijd en GPS-eenhoorns, en zelfs niet alleen detectiveachtige raadsels in de stijl van Hercule Poirot.
Technische Ondersteuning is in de eerste plaats communicatie, en communicatie houdt mensen in, en onder onze klanten zijn er heel verschillende personages:
- Een Duitser, die vanuit het café tegenover zijn kantoor in Berlijn werkt, met een werkelijk noordelijke kalmte, ideale rust, een zorgvuldig afgesteld netwerk, een uitgebreide toolkit servers en cognitieve vermogens om alles op A+ niveau in te stellen en te onderhouden. Verzoeken van hem veroorzaken meestal dezelfde reactie als het laatste dumpling op een bord in een groot gezelschap en het plotseling doven van het licht.
- Een Brit, die in de afgelopen 5 jaar van twee bedrijven is veranderd, maar niet van stijl van werken met support. Van zijn cases rennen ze weg als van de pest of nemen ze aan, zich van tevoren bewust van de “charme” van het werken met deze persoon, want hij kan zonder waarschuwing de controle over een sessie overnemen (om zijn e-mail te checken, soms persoonlijk), druk uitoefenen op ingenieurs en management over de kleinste details en uiteindelijk ook zo plotseling aanvragen sluiten met de opmerking "DUPLICAAT".
- Een Indiaan met een complexe en onuitspreekbare achternaam, die alle mythen over Indische IT weerlegt: beleefd, kalm, competent, leest documentatie, luistert naar het advies van de ingenieur en doet alles altijd zelf, eigenaar van een prachtige tulband (ja, we hebben hem op Facebook gevonden) en perfecte Oxford uitspraak.
Dergelijke "naam-clients" kan elke ingenieur zich wel vijf herinneren, zelfs zonder er diep over na te denken. Sommigen beangstigen we onze nieuwkomers mee ("Als je je slecht gedraagt in de lab – komt de boeman en!..."), met anderen pronken we ("Ik heb al 5 verzoeken van N. afgesloten!"). Het meest herinneren we ons ook en begrijpen we dat positieve en negatieve voorbeelden slechts ons waarneming zijn, en dat die voortkomt uit de communicatie, onze met klanten en van klanten met ons.
En die communicatie kan heel verschillend zijn.
Eén keer hebben we al geschreven over , en nu wil ik laten zien hoe dit gaat, aan de hand van een live voorbeeld.
Hier is een goed voorbeeld van twee jaar geleden: de reactie van de klant op de "traditionele" stappen in het probleemoplossingsproces door de engineer en de engineer op de communicatiestijl van de klant.
Een geval over fragmentatie
Dus, het geval: een zeer ervaren en technisch onderlegde klant opent een ticket met de technische ondersteuning en stelt een directe vraag, waarbij hij veel details verstrekt om de situatie te beschrijven.
Ik heb de vrijheid genomen om de correspondentie in een dialoog om te zetten, met behoud van de stilistische kenmerken.
Klant (K): — Goede dag, mijnheer. Mijn naam is Marco Santino, we hebben uw best practices gevolgd en de nieuwste technologie geïmplementeerd die u aanbeveelt, maar we zien dat de prestaties van het systeem kritiek laag worden door hoge fragmentatie. Is dit normaal?
Engineer (E): — Hallo, Marco! Mijn naam is Ignat en ik help je. Komt dit altijd voor? Heb je geprobeerd te defragmenteren?
(K): — Geachte Ignat! Ja, dit komt altijd voor. We hebben geprobeerd te defragmenteren, maar helaas kost dit te veel tijd tijdens de volledige stilstand van het systeem, waardoor het niet mogelijk is.
(E): — Kijk, ik kan deze best practices niet vinden. Waar heb je het gevonden? Misschien kunnen we toch defragmentatie uitvoeren?
(K): — Geachte Ignat! Begrijpend dat u onze probleem niet serieus neemt en met moeite het paard van Troje kunt tegenhouden van een directe, in plaats van politiek correcte, reactie, proberen we u toch te antwoorden. We hebben niet uw ervaring (we zijn pas sinds 1960 in IT), en we zijn u zeer dankbaar voor uw werk en moeite om ons te onderwijzen. De best practices zijn ons overhandigd door uw Product Managers tijdens het diner in Barcelona, en ik heb u de link ertoe gestuurd. U, Ignat, vragen we rechtstreeks: is deze situatie normaal? Als u niet geïnteresseerd bent om met ons te praten, vindt u dan alstublieft iemand die ons kan helpen.
(E): — Marco, ik heb deze best practices niet gevonden. Ik heb de logbestanden nodig, en ik zal het probleem aan een andere engineer doorgeven. Laat me je dit zeggen: als je fragmentatie ziet en niet defragmenteert, is dat dom en onverantwoord. En hoe is het je gelukt om de edele naam "Ignat" te verwarren en me Ivan te noemen?
(K): — Genoeg! Ik ben geen broer of zwager van u, Ignat, zodat u me bij mijn voornaam kunt noemen; daarom verzoek ik u om mij de heer Santino te noemen! Als u het document niet kunt vinden en niet in staat bent om zo'n eenvoudige taak uit te voeren, dan kunt u ofwel ontslag nemen of de auteur vragen, die ons dit document heeft overhandigd! Wat betreft de logs, wij kunnen deze niet aan u overdragen zonder speciale goedkeuring, omdat we met geheime documenten werken. Uw verontwaardiging over mijn fout toont uw onwetendheid en onverzorgdheid aan. Het spijt me zeer voor u. En tot slot: als we zeggen dat we 'hebben geprobeerd te defragmenteren' en dat het 'niet mogelijk is', dan betekent dat, dat we het geprobeerd hebben en dat het onmogelijk is. Ignat, ik verzoek u, stop met de onzin en ga aan uw werk — geef ons een antwoord of vind degene die het ons kan geven!
Na dit werd de aanvraag naar een hoger niveau doorgestuurd, waar het gewoon is gestorven – de klant heeft de logs niet geleverd, grootschalige tests hebben niets opgeleverd en het probleem kon gewoon niet worden bevestigd.
Vraag: wat had de ingenieur kunnen doen om de gemoederen te bedaren en escalatie van het conflict te voorkomen?
(Probeer deze vraag zelf te beantwoorden voordat je verder leest).
Lyrisch technisch zijpad
Voor de liefhebbers van raadsels en de vraag ‘wie is de moordenaar?’: het probleem was veel serieuzer dan gedacht: de fragmentatie van ReFS beïnvloedde niet alleen de schijfoperaties, maar leidde in sommige gevallen ook tot een verhoging van het CPU- en RAM-gebruik tot tien keer, en niet alleen bij Veeam-klanten – ook alle gebruikers van ReFS konden hier last van hebben.
Microsoft heeft meer dan een jaar nodig gehad met de ondersteuning van vele leveranciers om deze fout eindelijk te verhelpen (waarbij we ook onze bijdrage zien – er zijn heel wat verwikkelingen geweest over de ondersteuning van deze gigant op alle niveaus).
Als ik antwoord geef op de vraag 'wat had er gedaan kunnen worden?', wil ik een andere, eeuwige vraag stellen: 'Wie is de schuldige?'
Uit professionele solidariteit zou ik heel graag willen zeggen: 'De klant is schuldig', — en de ingenieur verdedigen. Als leidinggevende die voortdurend het werk van zijn ingenieurs evalueert, zie ik de fouten die Ignat heeft gemaakt. Wie heeft gelijk?
We bespreken alles stap voor stap
Deze case is heel scherp, er zijn meer vragen dan antwoorden.
Formeel gezien deed Ignat alles goed:
- hij volgde een van de basiswaarden van Veeam: Conversation from the heart;
- ik sprak de klant bij zijn naam aan;
- ik verduidelijkte de situatie voordat ik een oplossing aanbood.
Had hij deze enorme emotie kunnen vermijden?
Ja: opmerken hoe de heer Santino communiceert (met u en op achternaam), afzien van 'basisvragen', zijn interesse in het probleem tonen en beloven te zullen uitzoeken of dit normaal gedrag is.
Minimale stappen, zonder technische details – en dat zou al geholpen hebben om de situatie te 'blussen'. Maar ook als dit is gemist – simpelweg 'niets doen' zou ook al een beetje hebben geholpen.
Het klinkt voor de hand liggend: neem typfouten niet persoonlijk, neem geen wrok tegen een sarcastische klant (ook al spreekt alles van een verhoogd zelfvertrouwen), leid het gesprek niet naar persoonlijke aanvallen, laat je niet provoceren… Kijk eens hoeveel 'nee's' er zijn, en allemaal zijn ze belangrijk, en ze gaan allemaal over communicatie.
En wat dacht de klant? Brieven geschreven in 'een hoogstaande stijl', constante verwijzingen naar zijn connecties aan de top, verhulde beledigingen en wrok over schijnbaar gebrek aan respect? Ja, we kunnen dit zo interpreteren. Maar aan de andere kant – heeft de heer Santino werkelijk ongelijk in zijn woede?
En toch, wat had er van beide kanten gedaan kunnen worden? Zo zie ik het:
Van de kant van de engineer:
- de mate van formaliteit van de klant inschatten;
- minder de 'basisisolatie' volgen;
- (nu wordt het subjectief) de e-mails aandachtiger lezen;
- antwoorden op vragen in plaats van ze te omzeilen;
- en tenslotte, niet achter zijn provocaties te vervallen en niet persoonlijk te worden.
Voor de klant:
- duidelijk de kwestie in de eerste e-mail aangeven, niet verstoppen in technische details (dit blijkt niet direct uit de dialoog, maar geloof me, de details waren verbluffend);
- iets toleranter zijn tegenover vragen – niet iedereen denkt hetzelfde, en soms moet je veel vragen om de kern van het probleem te begrijpen;
- misschien de behoefte onderdrukken om zijn belangrijkheid en connecties 'op het hoogste niveau' te tonen;
- en, net als voor Ignat, persoonlijk aanvallen vermijden.
Ik herhaal – dit is slechts mijn visie, mijn beoordeling, die op geen enkele manier aanbevelingen of richtlijnen geeft over 'hoe te leven en te werken'. Dit is een van de manieren om naar de situatie te kijken, en ik zou blij zijn als u uw eigen ideeën deelt.
Ik bescherm de ingenieur niet – hij is zelf een boosaardige Pinocchio. Ik beschuldig de klant niet – hij heeft het recht om te communiceren zoals hij dat nodig acht, ook al zijn zijn boodschappen soms verpakt in een verfijnde netheid van bijna subtiele beledigingen (een goed voorbeeld van een moderne hidalgo, die niet handelt op basis van huurlingen en oorlog, maar IT – hoewel...).
‘De maaiers hebben de steen gevonden’ – zo kan ik deze correspondentie samenvatten, of, om het anders te zeggen, met een waarheid waar ik oprecht in geloof: ‘in elk conflict zijn gewoonlijk twee mensen schuldig’.
Je zou de woorden van onze business trainer kunnen gebruiken: ‘succesvolle communicatie wordt bemoeilijkt door eerdere ervaringen, gewoontes en verschillende wereldbeelden’. Je kunt ook de gouden regel van moraliteit in herinnering roepen: ‘Behandel anderen zoals je zelf behandeld wilt worden’.
Of je kunt simpelweg zeggen: in elke communicatie zijn altijd twee partijen betrokken, en aan de andere kant van de telefoon of monitor zit een levend persoon, die ook bang, blij, verdrietig of iets anders kan zijn. Ja, het wordt vaak gezegd dat emoties en zaken niet samengaan, maar waar kunnen we heen met emoties? Ze zijn er geweest, zijn er nu, en zullen er altijd zijn, en zelfs als we – technische ondersteuning – specifieke taken oplossen, wordt ons belangrijkste werk gedefinieerd door het tweede woord: ‘ondersteuning’.
Ondersteuning gaat om mensen.
***
Vergeet niet dat ik al twee keer heb geschreven dat er twee schuldig zijn? Welnu, in deze situatie zijn zelfs alle drie schuldig. Waarom? Simpelweg omdat de ingenieur geen op zichzelf staand object is, maar een onderdeel van de technische ondersteuning, en het is onze taak en verantwoordelijkheid om de medewerker te leren omgaan met vergelijkbare situaties. We proberen van onze fouten te leren – en onze medewerkers te helpen deze te vermijden.
Kan men dergelijke situaties altijd vermijden? Niet altijd. Hoe goed de hypothetische Ignat ook mag zijn, aan de ‘andere kant’ kan er iemand zijn die alles doet om de situatie te verhitten.
Maar de schoonheid van werken in de Veeam technische ondersteuning, een van de waarden waar we trots op zijn – is teamwork. Het is erg belangrijk om te onthouden: ‘Je bent niet alleen’ – en we doen alles om dat gevoel te versterken.
Kan men leren leven en werken in dergelijke situaties? Ja, dat kan.
We know, love, and practice — this is why we developed our internal training and continue to refine and polish it. Over the past two and a half years since the described situation, we have made significant improvements to our training program — and now we actively use case studies, model situations, accumulate, and always revisit our mistakes to analyze the nuances of communication.
We believe our team is now entering the field much better prepared for any situation, and if something comes up that they're unprepared for — we are here and ready to help, and afterwards, we will enhance our courses with new examples.
And it pays off. For example, here is a review from one of our clients about our work:
“We’ve worked in the IT industry for more than 20 years, and we all agree no vendor offers the level of technical support that Veeam offers. It’s a pleasure to speak to Veeam’s technical staff because they’re knowledgeable and resolve issues fast. Support should never be underrated. It’s a measure of a company’s commitment and success. Veeam is #1 for support.”
“We have worked in the IT industry for over 20 years, and we claim that no other vendor provides the level of technical support that Veeam does. It’s a pleasure to work with Veeam engineers, as they know their stuff and can resolve issues quickly. Technical support should never be underestimated. It reflects how responsible and successful a company is. Veeam has the best technical support.”
***
Any communication is a field for experiments, mistakes, whether we like it or not. And my opinion is that making mistakes is normal; moreover, my call would be: make mistakes! It’s not about whether you slipped up, but whether you learned to stand firm afterward.
Sometimes it’s hard to catch yourself and remember all the instructions and recipes that 'gurus' of customer communication or experienced colleagues generously share. Sometimes it’s much easier to remind yourself: 'I am speaking to a Person.'
***
I do not claim to have superior knowledge or an exceptional standard of communication with clients. The list of my own mistakes alone would be enough for a full textbook.
The goal I set for myself: to show how it can be in Technical Support and to start a discussion about what can be considered acceptable in such cases, and what cannot.
What do you think?
Bron: habr.com
