Soms staat een technisch ondersteuningsingenieur voor een moeilijke keuze: het dialoogmodel ‘Wij zijn voor een hoge servicecultuur!’-dialoogmodel toepassen. of “Druk op de knop en je krijgt het resultaat”?
...Nadat ik de vleugel van watten had gebroken,
Laten we in de wolken liggen, zoals in crypten.
Wij dichters zijn zelden heiligen,
Wij dichters zijn vaak blind.
(Oleg Ladyzjenski)
Werken bij de Technische Ondersteuning betekent niet alleen grappige verhalen over zelfspringende tijd en GPS-eenhoorns, en niet eens alleen maar detectivepuzzels in de stijl van Hercule Poirot.
Technische ondersteuning is in de eerste plaats communicatie, en communicatie betekent mensen, en onder onze klanten zijn er heel verschillende karakters:
- De Duitser, die vanuit een café tegenover zijn kantoor in Berlijn werkt, beschikt over echte Scandinavische zelfbeheersing, ideale rust, een zorgvuldig gekalibreerd netwerk, een uitgebreid serverpark en het cognitieve vermogen om dit alles op A+ op te zetten en te onderhouden. Verzoeken van hem veroorzaken meestal dezelfde reactie als de laatste knoedel op een bord in een groot bedrijf en het licht dat op het verkeerde moment wordt uitgeschakeld.
- Een Brit die de afgelopen vijf jaar twee bedrijven heeft veranderd, maar niet zijn stijl van werken met ondersteuning. Ze rennen óf weg voor zijn zaken als de builenpest, óf ze nemen ze mee, vooruitlopend op alle ‘charme’ van het werken met deze persoon, omdat hij, zonder waarschuwing, de controle over een sessie op afstand kan overnemen (om zijn e-mail te controleren, soms persoonlijk), druk uitoefenen op ingenieurs en management over de kleinste kleinigheden en uiteindelijk net zo plotseling applicaties afsluiten met de opmerking “DUPLICATE”.
- Een Indiër met een meerlettergrepige en onuitspreekbare achternaam, die alle mythen over Indiase IT weerlegt: beleefd, kalm, bekwaam, leest documentatie, luistert naar het advies van een ingenieur en doet altijd alles zelf, eigenaar van een chique tulband (ja, we vonden op Facebook) en een perfecte Oxford-uitspraak.
Elke ingenieur kan ongeveer vijf van dergelijke ‘naam’-clients bedenken, zonder er zelfs maar al te veel over na te denken. Bij sommigen maken we onze nieuwkomers bang (“als je je slecht gedraagt in het lab, komt er een vrouw en!..”), bij sommigen scheppen we op (“en ik heb al 5 aanmeldingen bij N. gesloten!”). En meestal herinneren en begrijpen we zelfs dat positieve en negatieve voorbeelden slechts onze perceptie zijn, en dat deze voortvloeit uit de communicatie, die van ons met klanten en klanten met ons.
En deze communicatie kan heel verschillend zijn.
We schreven er ooit over , en nu wil ik laten zien hoe dit gebeurt met een live voorbeeld.
Hier is een goed voorbeeld van twee jaar geleden: de reactie van de klant op de ‘traditionele’ stappen voor het oplossen van problemen van de kant van de ingenieur, en de ingenieur op de communicatiestijl van de klant.
Casus over fragmentatie
Dit is dus het geval: een zeer ervaren en technisch onderlegde klant opent een supportticket en stelt een directe vraag, waarbij hij veel details geeft om de situatie te beschrijven.
Ik heb de vrijheid genomen om van de correspondentie een dialoog te maken, waarbij de stilistische kenmerken behouden bleven.
Cliënt (K): - Goedemiddag, meneer. Mijn naam is Marco Santino, we hebben uw best practices gebruikt en de nieuwste door u aanbevolen technologie geïnstalleerd, maar we zien dat de prestaties van het systeem kritisch laag worden vanwege de hoge fragmentatie. Vertel me alsjeblieft, is dit normaal?
Ingenieur (I): - Hallo, Marco! Mijn naam is Ignat, en ik zal helpen. Gebeurt dit altijd? Heb je geprobeerd te defragmenteren?
(K): - Beste Ignat! Ja, dit verschijnt altijd. We hebben geprobeerd te defragmenteren, maar helaas kost het te veel tijd als het systeem volledig inactief is, en daarom is dit niet mogelijk.
(I): - Luister, om de een of andere reden kan ik deze best practices niet vinden. Waar heb je hem gevonden? En misschien moeten we toch wat defragmenteren, hè?
(K): - Beste Ignat! Omdat we begrijpen dat u ons probleem niet serieus neemt en moeite hebt om u te weerhouden van een direct in plaats van een politiek correct antwoord, zullen we toch proberen u te antwoorden. Wij hebben uw ervaring niet (we zijn pas sinds 1960 actief in de IT) en we zijn u zeer dankbaar voor uw werk en inspanningen om ons op te leiden. De beste praktijken zijn met ons gedeeld door uw productmanagers tijdens een diner in Barcelona, en ik heb u een link ernaar gestuurd. We vragen je rechtstreeks, Ivan: is deze situatie normaal? Als u niet met ons wilt praten, zoek dan iemand die ons kan helpen.
(I): — Marco, om de een of andere reden heb ik deze best practices niet gevonden. Ik heb de logboeken nodig en zal het probleem escaleren naar een andere technicus. Ik zal je wat vertellen: als je fragmentatie ziet en niet defragmenteert, is dat dom en onverantwoordelijk. En hoe dan ook, hoe ben je erin geslaagd de nobele naam “Ignat” te verwarren en mij Ivan te noemen?
(K): - Zo, dat is genoeg! Ik ben niet je broer, Ignat, noch je koppelaarster om mij bij mijn naam te noemen, dus spreek mij alsjeblieft aan met Gn. Santino! Als u het document niet kunt vinden of zo'n eenvoudige taak niet aankunt, verlaat dan het bedrijf of vraag het aan de auteur, die ons dit document heeft gegeven! Wat de logboeken betreft, kunnen wij deze niet zonder speciale toestemming aan u overdragen, aangezien wij met geheime documenten werken. Uw verontwaardiging over mijn fout toont uw onwetendheid en uw slechte manieren aan. Het spijt me heel erg voor je. En tot slot: als we zeggen dat we “hebben geprobeerd te defragmenteren” en het “onmogelijk” is, dan hebben we het geprobeerd en is het onmogelijk. Ignat, ik vraag je: stop met lijden aan onzin en ga aan de slag - geef ons het antwoord, of zoek iemand die het ons wil geven!
Hierna werd de applicatie overgebracht naar een hoger niveau, waar deze stierf - de klant leverde nooit logbestanden op, volledige tests leverden niets op en het probleem kon eenvoudigweg niet worden bevestigd.
Vraag: wat zou de ingenieur kunnen doen om de hitte van de hartstochten en de escalatie van het conflict te voorkomen?
(Probeer deze vraag zelf te beantwoorden voordat je verder leest).
Lyrische technische uitweiding
Voor degenen die graag raadsels oplossen en de vraag beantwoorden "wie is de moordenaar?": het probleem bleek veel ernstiger: ReFS-fragmentatie had niet alleen invloed op de schijfbewerkingen, maar verhoogde in sommige gevallen het CPU- en RAM-verbruik met wel tien keer, en niet alleen voor Veeam-clients; alle ReFS-gebruikers zouden eronder kunnen lijden.
Het kostte Microsoft meer dan een jaar, met de steun van veel leveranciers, om deze fout eindelijk te corrigeren (waarvoor we onze eigen verdienste zien - veel exemplaren gingen kapot dankzij de steun van deze gigant op alle niveaus).
Ik, die de vraag beantwoordt "wat had er gedaan kunnen worden?", Ik wil een andere, eeuwige vraag stellen: "Wie is de schuldige?"
Uit professionele solidariteit wil ik heel graag zeggen: “De klant heeft de schuld”, en de ingenieur beginnen te beschermen. Als manager die voortdurend het werk van zijn ingenieurs evalueert, zie ik de fouten die Ignat heeft gemaakt. Wie heeft er gelijk?
Laten we alles op volgorde zetten
Deze zaak is erg zwaar, er zijn meer vragen dan antwoorden.
Formeel deed Ignat alles goed:
- volgde een van de kernwaarden van Veeam: Gesprekken vanuit het hart;
- de cliënt bij naam aangesproken;
- eerst de situatie verduidelijkt alvorens een oplossing voor te stellen.
Had hij zulke intense hartstochten kunnen vermijden?
Kon: merk op hoe Mr. Santino communiceert (alleen door jou en op achternaam), weigert ‘fundamentele vragen’, toont zijn interesse in het probleem en belooft uit te zoeken of dit gedrag normaal is.
Minimale stappen, zonder het technische gedeelte, en ze zouden al hebben geholpen de situatie te ‘blussen’. Maar zelfs als dit gemist wordt, zou simpelweg ‘het niet doen’ ook een beetje helpen.
Het klinkt voor de hand liggend: vat een typefout niet persoonlijk op, laat je niet beledigen door een sarcastische cliënt (ook al spreekt alles van een opgeblazen FER), maak het gesprek niet persoonlijk, geef niet toe aan provocaties... Er zijn er zo veel, deze 'nee's', en allemaal belangrijk, en alles over communicatie.
Hoe zit het met de cliënt? Zijn de brieven geschreven in een “hoge stijl”, constante verwijzingen naar uw kennissen aan de top, verhulde beledigingen en wrok vanwege schijnbaar gebrek aan respect? Ja, zo kunnen we het ook lezen. Aan de andere kant: is het zo, meneer? Heeft Santino eigenlijk ongelijk vanwege zijn woede?
En toch, wat zou er aan beide kanten gedaan kunnen worden? Ik zie het zo:
Van de kant van de ingenieur:
- de mate van formalisme van de cliënt beoordelen;
- volg minder “basisisolatie”;
- (nu zal het subjectief zijn) lees de brieven aandachtiger;
- beantwoord vragen in plaats van ze te vermijden;
- en, ten slotte, bezwijk niet voor provocaties en word niet persoonlijk.
Naar de klant:
- vermeld de kwestie duidelijk in de eerste brief, zonder deze in technische details te verbergen (dit volgt niet direct uit de dialoog, maar geloof me, de details waren verbazingwekkend);
- wees wat toleranter ten opzichte van vragen - niet iedereen denkt op dezelfde manier, en soms moet je veel vragen om de essentie van het probleem te begrijpen;
- beperk misschien de wens om uw belangrijkheid en kennissen “op het hoogste niveau” te tonen;
- en, wat Ignat betreft, zorg ervoor dat je niet te persoonlijk wordt.
Ik herhaal: dit is slechts mijn visie, mijn beoordeling, die op geen enkele manier aanbevelingen of richtlijnen vormt over ‘hoe te leven en te werken’. Dit is één manier om naar de situatie te kijken, en ik zal blij zijn als u de jouwe aanbiedt.
Ik verdedig de ingenieur niet - hij is zijn eigen kwaadaardige Pinocchio. Ik neem het de cliënt niet kwalijk - hij heeft het recht om te communiceren zoals hij dat nodig acht, ook al is deze communicatie meer verborgen in de elegante kant van een bijna verfijnde beleefde belediging (een goed beeld van een moderne hidalgo die niet handelt in huurlingen en oorlog, maar in IT - hoewel...).
"Ik vond een zeis op een steen" - dit is hoe ik deze correspondentie kan samenvatten, of zelfs met andere woorden kan zeggen, waarvan ik oprecht geloof: "Bij elk conflict zijn er meestal twee de schuldige."
We kunnen met de woorden van onze business coach zeggen: “succesvolle communicatie wordt belemmerd door ervaringen uit het verleden, communicatiegewoonten en verschillende beelden van de wereld.” U kunt zich de gouden regel van moraliteit herinneren: ‘Behandel andere mensen zoals u wilt dat zij u behandelen.’
Of je kunt simpelweg zeggen: bij elke communicatie zijn er altijd twee mensen betrokken, en aan de andere kant van de hoorn of monitor zit een levend persoon die ook bang, blij, verdrietig of iets anders is. Ja, er wordt aangenomen dat emoties en zakendoen onverenigbaar zijn, maar waar kunnen we wegkomen van emoties? Ze waren, zijn en zullen zo zijn, en zelfs als we technische ondersteuning zijn en zeer specifieke problemen oplossen, wordt ons belangrijkste werk gedefinieerd door het tweede woord: 'ondersteuning'.
Ondersteuning gaat over mensen.
***
Weet je nog dat ik al twee keer heb geschreven dat er twee de schuldige zijn? In deze specifieke situatie zijn dus in feite alle drie de schuldigen. Waarom? Simpelweg omdat een ingenieur geen ding op zichzelf is, maar een onderdeel van de technische ondersteuning, en het onze taak en verantwoordelijkheid is om een medewerker te leren soortgelijke situaties door te maken. We proberen van onze fouten te leren en onze medewerkers te helpen deze te vermijden.
Is het altijd mogelijk om dergelijke situaties te vermijden? Niet altijd. Hoe goed een ingenieur de hypothetische Ignat ook is, “aan de andere kant” kan er iemand zijn die er alles aan zal doen om de situatie te laten escaleren.
Maar het mooie van werken bij Veeam Technical Support, een van de waarden waar we trots op zijn, is teamwerk. Het is heel belangrijk om te onthouden: “Je bent niet de enige”, en we doen er alles aan om dit te bewerkstelligen.
Is het mogelijk om te leren hoe je in dergelijke situaties moet leven en werken? Kan.
We weten hoe, we houden ervan, we oefenen - dit is de reden waarom we onze interne training hebben opgebouwd en deze blijven verbeteren en verbeteren. In de twee en een half jaar die zijn verstreken sinds de beschreven situatie, hebben we serieus aan ons trainingsprogramma gewerkt - en nu gebruiken we actief cases, simuleren we situaties, besparen we geld en keren we voortdurend terug naar onze fouten en analyseren we de fijne kneepjes van de communicatie .
Wij zijn van mening dat onze jongens nu veel beter voorbereid het veld in gaan op elke situatie, en als er iets blijkt waar ze niet klaar voor zijn, zijn we dichtbij en klaar om te helpen, en vullen we onze cursussen vervolgens aan met nieuwe voorbeelden.
En het loont. Hier vindt u bijvoorbeeld een recensie van een van onze klanten over ons werk:
“We werken al meer dan twintig jaar in de IT-industrie en we zijn het er allemaal over eens dat geen enkele leverancier het niveau aan technische ondersteuning biedt dat Veeam biedt. Het is een genoegen om met de technische staf van Veeam te spreken, omdat zij deskundig zijn en problemen snel oplossen. Ondersteuning mag nooit worden onderschat. Het is een maatstaf voor de toewijding en het succes van een bedrijf. Veeam is #20 op het gebied van ondersteuning.”
“We zijn al meer dan twintig jaar actief in de IT-industrie en we zeggen dat geen enkele andere leverancier het niveau van technische ondersteuning biedt dat Veeam biedt. Het is een plezier om met Veeam-ingenieurs samen te werken, omdat ze verstand van zaken hebben en problemen snel kunnen oplossen. Technische ondersteuning mag nooit worden onderschat. Dit is een maatstaf voor hoe verantwoordelijk en succesvol een bedrijf is. Veeam heeft de beste technische ondersteuning.”
***
Elke communicatie is een veld voor experimenten en fouten, of we dat nu willen of niet. En mijn mening is dat het oké is om fouten te maken; bovendien zal mijn oproep zijn: maak fouten! Het gaat er niet om of je struikelde, maar of je daarna leerde stevig op de grond te staan.
Soms is het moeilijk om jezelf te betrappen en alle instructies en recepten te onthouden die 'goeroes' van communicatie met klanten of ervaren collega's genereus delen. Het is veel gemakkelijker om jezelf er soms aan te herinneren: ‘Ik praat met een Persoon.’
***
Ik pretendeer niet dat ik over superieure kennis of een speciale kwaliteitsstandaard beschik in de communicatie met klanten. Alleen al de lijst met mijn fouten zou voldoende zijn voor een volwaardig leerboek.
Het doel dat ik mezelf stelde: laten zien hoe het kan bij Technische Support en een discussie op gang brengen over wat in zulke gevallen wel en niet acceptabel is.
Wat denk je?
Bron: www.habr.com