Ontleding van 'n saak oor kommunikasie met 'n "moeilike" kliënt

Ontleding van 'n saak oor kommunikasie met 'n "moeilike" kliënt

Soms staan ​​'n tegniese ondersteuningsingenieur voor 'n moeilike keuse: om die "Ons is vir 'n hoëdienskultuur!"-dialoogmodel toe te pas. of "Druk die knoppie en jy sal die resultaat kry"?

...Nadat die vlerk van watte gebreek is,
Kom ons lê in die wolke, soos in kripte.
Ons digters is selde heiliges,
Ons digters is dikwels blind.
(Oleg Ladyzhensky)


Werk in Tegniese Ondersteuning beteken nie net snaakse stories oor selfspringtyd en GPS-eenhorings nie, en nie eers net speurraaisels in die styl van Hercule Poirot nie.

Tegniese ondersteuning is eerstens kommunikasie, en kommunikasie beteken mense, en onder ons kliënte is daar baie verskillende karakters:

  • Die Duitser, wat van 'n kafee oorkant sy kantoor in Berlyn werk, het werklik Nordiese selfbeheersing, ideale kalmte, 'n noukeurig gekalibreerde netwerk, 'n uitgebreide bedienervloot en die kognitiewe vermoë om dit alles by A+ op te stel en te onderhou. Versoeke van hom veroorsaak gewoonlik dieselfde reaksie as die laaste kluitjie op 'n bord in 'n groot maatskappy en die lig wat op die verkeerde tyd afgeskakel word.
  • 'n Brit wat twee maatskappye oor die afgelope 5 jaar verander het, maar nie sy styl om met ondersteuning te werk nie. Hulle hardloop óf weg van sy gevalle soos die builepes, óf hulle vat dit, en verwag vooraf al die "bekoring" van die werk met hierdie persoon, want hy kan sonder waarskuwing beheer neem van 'n afgeleë sessie (om sy e-pos na te gaan, soms persoonlik), plaas druk op ingenieurs en bestuur oor die kleinste kleinighede en sluit uiteindelik aansoeke ewe skielik af met die opmerking “DUPLICAAT”.
  • 'n Indiër met 'n polisillabiese en onuitspreekbare van, wat al die mites oor Indiese IT weerlê: beleefd, kalm, bekwaam, dokumentasie lees, luister na die raad van 'n ingenieur en altyd alles self doen, eienaar van 'n sjiek tulband (ja, ons het gevind dit op Facebook) en perfekte Oxford-uitspraak.

Elke ingenieur kan aan sowat vyf sulke "naam"-kliënte dink, sonder om eers te veel daaroor te dink. Ons maak ons ​​nuwelinge bang met sommige (“as jy jou sleg gedra in die laboratorium, kom ’n vrou en!..”), met sommige spog ons (“en ek het reeds 5 aansoeke met N. gesluit!”). En meestal onthou en verstaan ​​ons selfs dat positiewe en negatiewe voorbeelde net ons persepsie is, en dit volg uit kommunikasie, ons s'n met kliënte en kliënte met ons.

En hierdie kommunikasie kan baie anders wees.

Ons het eenkeer geskryf oor “duiwels” wat ingenieurs verhoed om met kliënte te werk, en nou wil ek wys hoe dit gebeur met 'n lewendige voorbeeld.

Hier is 'n goeie voorbeeld van twee jaar gelede: die kliënt se reaksie op die "tradisionele" stappe van probleemoplossing aan die kant van die ingenieur en die ingenieur op die kliënt se kommunikasiestyl.

Saak oor fragmentasie

So hier is die geval: 'n baie ervare en tegnologie-vaardige kliënt maak 'n ondersteuningskaartjie oop en vra 'n direkte vraag, wat baie detail verskaf om die situasie te beskryf.

Ek het die vrymoedigheid geneem om die korrespondensie in 'n dialoog te omskep, en die stilistiese kenmerke te bewaar.

Kliënt (K): - Goeiemiddag, meneer. My naam is Marco Santino, ons het jou beste praktyke gebruik en die nuutste tegnologie geïnstalleer wat deur jou aanbeveel word, maar ons sien dat die werkverrigting van die stelsel krities laag word as gevolg van hoë fragmentasie. Sê asseblief vir my, is dit normaal?

Ingenieur (I): - Hallo, Marco! My naam is Ignat, en ek sal help. Gebeur dit altyd? Het jy al probeer defragmenteer?

(K): - Liewe Ignat! Ja, dit verskyn altyd. Ons het probeer om te defragmenteer, maar, helaas, dit neem te veel tyd wanneer die stelsel heeltemal ledig is, en daarom is dit nie moontlik nie.

(I): - Luister, om een ​​of ander rede kan ek nie hierdie beste praktyke vind nie. Waar het jy hom gekry? En miskien moet ons tog 'n bietjie defragmentasie doen, nè?

(K): - Liewe Ignat! As ons verstaan ​​dat jy nie ons probleem ernstig opneem nie en sukkel om jouself te weerhou van 'n direkte eerder as polities korrekte antwoord, sal ons steeds probeer om jou te antwoord. Ons het nie jou ondervinding nie (ons is net sedert 1960 in IT), en ons is jou baie dankbaar vir jou werk en pogings om ons op te voed. Beste praktyke is tydens aandete in Barcelona deur jou produkbestuurders met ons gedeel, en ek het vir jou 'n skakel na hulle gestuur. Ons vra jou direk, Ivan: is hierdie situasie normaal? As jy nie belangstel om met ons te praat nie, kry asseblief iemand wat ons kan help.

(I): - Marco, om een ​​of ander rede het ek nie hierdie beste praktyke gevind nie. Ek het die logs nodig en sal die probleem na 'n ander ingenieur eskaleer. Ek sal jou sê wat: as jy fragmentasie sien en nie defragmenteer nie, is dit dom en onverantwoordelik. En in elk geval, hoe het jy dit reggekry om die edele naam “Ignat” te verwar en my Ivan te noem?

(K): - So, dit is genoeg! Ek is nie jou broer, Ignat, of jou pasmaat om my by die naam te noem nie, so spreek my asseblief aan as Gn. Santino! As jy nie die dokument kan vind nie of nie so 'n eenvoudige taak kan hanteer nie, verlaat dan die maatskappy of vra die outeur, wie vir ons hierdie dokument gegee het! Wat die logs betref, kan ons dit nie aan u oordra sonder spesiale goedkeuring nie, aangesien ons met geheime dokumente werk. Jou verontwaardiging oor my fout wys jou onkunde en jou slegte maniere. Ek is baie jammer vir jou. En laastens: as ons sê dat ons "probeer defragmenteer" en dit is "onmoontlik", dan het ons probeer en dit is onmoontlik. Ignat, ek vra jou, hou op om aan nonsens te ly en gaan aan met jou werk – óf gee ons die antwoord, óf kry iemand wat dit vir ons sal gee!

Hierna is die toepassing na 'n hoër vlak oorgeplaas, waar dit dood is - die kliënt het nooit logs verskaf nie, volskaalse toetsing het niks opgelewer nie, en die probleem kon eenvoudig nie bevestig word nie.

Vraag: wat kan die ingenieur doen om die hitte van passies en eskalasie van die konflik te vermy?

(Probeer om hierdie vraag self te beantwoord voordat jy verder lees).

Liriese tegniese afwyking
Vir diegene wat daarvan hou om raaisels op te los en die vraag "wie is die moordenaar?" te beantwoord: die probleem blyk baie ernstiger te wees: ReFS-fragmentasie het nie net skyfbedrywighede beïnvloed nie, maar in sommige gevalle het SVE en RAM-verbruik met tot tien verhoog keer, en nie net vir Veeam-kliënte nie – alle ReFS-gebruikers kan daaronder ly.

Dit het Microsoft meer as 'n jaar geneem, met die ondersteuning van baie verskaffers, om uiteindelik hierdie fout reg te stel (waarvoor ons ons eie meriete sien - baie kopieë is gebreek as gevolg van die ondersteuning van hierdie reus op alle vlakke).

Ek, met die antwoord op die vraag "wat kon gedoen word?", wil ek nog 'n, ewige vraag vra: "Wie is te blameer?"

Uit professionele solidariteit wil ek regtig sê: "Die kliënt is te blameer," en begin om die ingenieur te beskerm. As 'n bestuurder wat voortdurend die werk van sy ingenieurs evalueer, sien ek die foute wat Ignat gemaak het. Wie is reg?

Kom ons sorteer alles in volgorde uit

Hierdie saak is baie moeilik, daar is meer vrae as antwoorde.

Formeel het Ignat alles goed gedoen:

  • het een van Veeam se kernwaardes gevolg: Gesprek uit die hart;
  • die kliënt by die naam aangespreek het;
  • het die situasie uitgeklaar voordat 'n oplossing voorgestel is.

Kon hy sulke intense passies vermy het?

Kon: let op hoe mnr. Santino kommunikeer (slegs deur U en deur van), weier "basiese vrae", toon sy belangstelling in die probleem en belowe om uit te vind of hierdie gedrag normaal is.

Minimale stappe, sonder die tegniese deel, en hulle sou reeds gehelp het om die situasie te “blus”. Maar selfs as dit gemis word, sal eenvoudig "dit nie doen nie" ook 'n bietjie help.

Dit klink vanselfsprekend: moenie 'n tikfout persoonlik opneem nie, moenie aanstoot neem deur 'n sarkastiese kliënt nie (al sê alles van 'n opgeblase FER), moenie die gesprek persoonlik maak nie, moenie toegee aan provokasies nie... Daar is so baie van hulle, hierdie "nee's," en almal belangrik, en alles oor kommunikasie.

Wat van die kliënt? Is die briewe geskryf in 'n "hoë styl", konstante verwysings na jou kennisse heel bo, bedekte beledigings en wrok van oënskynlike disrespek? Ja, ons kan dit so lees. Aan die ander kant, is dit so mnr. Is Santino eintlik verkeerd vir sy woede?

En tog, wat kan aan beide kante gedoen word? Ek sien dit so:

Van die ingenieur se kant af:

  • assesseer die mate van formalisme van die kliënt;
  • volg minder "basiese isolasie";
  • (nou sal dit subjektief wees) lees die briewe noukeuriger;
  • beantwoord vrae eerder as om dit te vermy;
  • en, ten slotte, moenie swig voor provokasies nie en moenie persoonlik raak nie.

Aan die kliënt:

  • stel die kwessie duidelik in die eerste brief, sonder om dit in tegniese besonderhede weg te steek (dit volg nie direk uit die dialoog nie, maar glo my, die detail was verstommend);
  • wees 'n bietjie meer verdraagsaam teenoor vrae - nie almal dink dieselfde nie, en soms moet jy baie vra om die wese van die probleem te verstaan;
  • beteuel miskien die begeerte om jou belangrikheid en kennisse “op die hoogste vlak” te wys;
  • en, wat Ignat betref, vermy om te persoonlik te raak.

Ek herhaal - dit is net my visie, my beoordeling, wat geensins aanbevelings of leiding uitmaak oor "hoe om te leef en werk nie." Dit is een manier om na die situasie te kyk, en ek sal bly wees as jy joune aanbied.

Ek verdedig nie die ingenieur nie – hy is sy eie bose Pinocchio. Ek neem nie die kliënt kwalik nie – hy het die reg om te kommunikeer soos hy goeddink, al is hierdie kommunikasie meer versteek in die elegante kant van 'n byna verfynde beleefde belediging ('n goeie beeld van 'n moderne hidalgo wat nie handel dryf in huursoldate en oorlog, maar in IT - hoewel...) .

"Ek het 'n seis op 'n klip gevind" - dit is hoe ek hierdie korrespondensie kan opsom, of dit selfs in ander woorde kan stel, waarvan ek opreg glo: "in enige konflik is gewoonlik twee te blameer."

Ons kan in die woorde van ons besigheidsafrigter sê: "suksesvolle kommunikasie word belemmer deur vorige ervaring, kommunikasiegewoontes en verskillende beelde van die wêreld." Jy kan die goue reël van moraliteit onthou: "Doen aan ander mense soos jy wil hê hulle moet aan jou doen."

Of jy kan eenvoudig sê: in enige kommunikasie is daar altyd twee mense betrokke, en aan die ander kant van die selfoon of monitor van jou af is 'n lewende mens wat ook bang, gelukkig, hartseer of iets anders is. Ja, daar word geglo dat emosies en besigheid onversoenbaar is, maar waar kan ons wegkom van emosies? Hulle was, is en sal wees, en selfs al is ons Tegniese Ondersteuning en los baie spesifieke probleme op, word ons hoofwerk gedefinieer deur die tweede woord: "ondersteuning".

Ondersteuning gaan oor mense.

***

Onthou, ek het al twee keer geskryf dat twee te blameer is? So, in werklikheid, bowendien, in hierdie spesifieke situasie is al drie die skuld. Hoekom? Bloot omdat 'n ingenieur nie 'n ding op sigself is nie, maar 'n deel van tegniese ondersteuning, en dit is ons werk en ons verantwoordelikheid om 'n werknemer te leer om deur soortgelyke situasies te gaan. Ons probeer uit ons foute leer en ons werknemers help om dit te vermy.

Is dit altyd moontlik om sulke situasies te vermy? Nie altyd nie. Maak nie saak hoe 'n goeie ingenieur die hipotetiese Ignat is nie, "aan die ander kant" kan daar 'n persoon wees wat alles sal doen om die situasie te eskaleer.

Maar die skoonheid daarvan om by Veeam Technical Support te werk, een van die waardes waarop ons trots is, is spanwerk. Dit is baie belangrik om te onthou: “Jy is nie alleen nie,” en ons doen alles om dit so te maak.

Is dit moontlik om te leer hoe om in sulke situasies te leef en te werk? Kan.

Ons weet hoe, ons is lief vir, ons oefen - dit is hoekom ons ons interne opleiding gebou het en voortgaan om dit te ontfout en te poets. In die twee en 'n half jaar wat verloop het sedert die situasie beskryf is, het ons ernstig aan ons opleidingsprogram gewerk - en nou gebruik ons ​​gevalle aktief, simuleer situasies, spaar geld en keer heeltyd terug na ons foute en ontleed die ingewikkeldhede van kommunikasie .

Ons glo dat ons ouens nou baie meer voorbereid vir enige situasie uitgaan in die veld, en as daar iets verskyn waarvoor hulle nie gereed is nie, is ons naby en gereed om te help, en dan ons kursusse aan te vul met nuwe voorbeelde.

En dit betaal vrugte af. Hier is byvoorbeeld 'n resensie van een van ons kliënte oor ons werk:

“Ons werk al meer as 20 jaar in die IT-bedryf, en ons stem almal saam dat geen verskaffer die vlak van tegniese ondersteuning bied wat Veeam bied nie. Dit is 'n plesier om met Veeam se tegniese personeel te praat, want hulle is kundig en los probleme vinnig op. Ondersteuning moet nooit onderskat word nie. Dit is 'n maatstaf van 'n maatskappy se toewyding en sukses. Veeam is #1 vir ondersteuning.”

“Ons is al meer as 20 jaar in die IT-bedryf, en ons sê geen ander verskaffer verskaf die vlak van tegniese ondersteuning wat Veeam doen nie. Dit is 'n plesier om saam met Veeam-ingenieurs te werk aangesien hulle hul goed ken en probleme vinnig kan oplos. Tegniese ondersteuning moet nooit onderskat word nie. Dit is 'n maatstaf van hoe verantwoordelik en suksesvol 'n maatskappy is. Veeam het die beste tegniese ondersteuning.”

***

Enige kommunikasie is 'n veld vir eksperimente en foute, of ons dit wil hê of nie. En my mening is dat dit goed is om foute te maak; bowendien sal my oproep wees: maak foute! Die punt is nie of jy gestruikel het nie, maar of jy toe geleer het om jou voet stewig te plant.

Soms is dit moeilik om jouself te vang en al die instruksies en resepte te onthou wat "ghoeroes" van kommunikasie met kliënte of ervare kollegas mildelik deel. Dit is baie makliker om jouself soms te herinner: "Ek praat met 'n persoon."

***

Ek gee nie voor dat ek voortreflike kennis of 'n spesiale standaard van kwaliteit in kommunikasie met kliënte het nie. Die lys van my foute alleen sal genoeg wees vir 'n volwaardige handboek.

Die doelwit wat ek vir myself gestel het: om te wys hoe dit kan wees in Tegniese Ondersteuning en om 'n gesprek te begin oor wat in sulke gevalle as aanvaarbaar beskou kan word en wat nie.

Wat dink jy?

Bron: will.com

Voeg 'n opmerking