A volte, l'ingegnere del supporto tecnico si trova di fronte a una scelta difficile: adottare il modello di dialogo "Noi siamo per una cultura del servizio elevata!" oppure "Clicca il pulsante e otterrai un risultato"?
…Spezzando un'ala di cotone,
Ci sdraiamo tra le nuvole, come in sarcofagi.
Noi, poeti, raramente siamo santi,
Noi, poeti, spesso siamo ciechi.
(Oleg Ladyzhensky)
Lavorare nel supporto tecnico non è solo raccontare divertenti aneddoti su tempi che saltano e unicorni GPS, né solo risolvere enigmi nello stile di Hercule Poirot.
Il supporto tecnico è, prima di tutto, comunicazione, e la comunicazione implica persone, e tra i nostri clienti ci sono personaggi molto diversi:
- Un tedesco, che lavora da un caffè di fronte al suo ufficio a Berlino, dotato di una vera pazienza nordica, calma perfetta, una rete ben calibrata, un ampio parco server e capacità cognitive per configurare e mantenere tutto al livello A+. Le richieste da lui in genere suscitano la stessa reazione della pasta ripiena finale in un grande gruppo e la luce spenta in modo non tempestivo.
- Un britannico che, negli ultimi 5 anni, ha cambiato due aziende, ma non il suo stile di approccio al supporto. I suoi casi fanno scappare le persone, come se fosse una peste bubbonica, oppure vengono presi, già prevedendo tutta la "bellezza" di lavorare con lui, dato che può senza preavviso prendersi il controllo in una sessione remota (per controllare la sua e-mail, a volte personale), pressare ingegneri e manager su minuzie e, infine, chiudere anche all'improvviso le richieste con il commento "DUPLICATO".
- Un indiano con un cognome complicato e impronunciabile, che smentisce tutti i miti sull'IT indiano: cortese, calmo, competente, legge documentazione, ascolta i consigli dell'ingegnere e fa sempre tutto da solo, con un meraviglioso turbante (sì, lo abbiamo trovato su Facebook) e una pronuncia inglese impeccabile.
Ogni ingegnere può ricordare circa cinque di questi clienti "nominali", senza doverci pensare troppo. Alcuni spaventano i nostri nuovi arrivati ("se ti comporti male in laboratorio, il babau arriverà e!...") e con alcuni ci vantiamo ("ho già chiuso 5 richieste con N."). Ma più spesso ricordiamo e comprendiamo che esempi positivi e negativi sono solo la nostra percezione, e questa deriva dalla comunicazione, tra noi e i clienti e viceversa.
E questa comunicazione può essere molto varia.
Una volta abbiamo già scritto di , e ora voglio mostrarvi come si presenta, con un esempio pratico.
Ecco un buon esempio di due anni fa: la reazione del cliente ai "tradizionali" passi di troubleshooting da parte dell'ingegnere e la risposta dell'ingegnere allo stile di comunicazione del cliente.
Caso sulla frammentazione
Quindi, il caso: un cliente molto esperto e tecnicamente preparato apre una richiesta di supporto e pone una domanda diretta, fornendo numerosi dettagli per descrivere la situazione.
Ho preso l'iniziativa di rielaborare la corrispondenza in un dialogo, mantenendo le peculiarità stilistiche.
Cliente (C): — Buongiorno, signore. Mi chiamo Marco Santino, abbiamo utilizzato le vostre best practices e installato la più recente tecnologia da voi raccomandata, ma vediamo che le prestazioni del sistema stanno diventando criticamente basse a causa dell'alta frammentazione. È normale?
Ingegnere (I): — Ciao, Marco! Mi chiamo Ignat e ti aiuterò. Questo si manifesta sempre? Hai provato a deframmentare?
(C): — Caro Ignat! Sì, si manifesta sempre. Abbiamo provato a deframmentare, ma purtroppo ci vuole troppo tempo durante un'inattività totale del sistema, quindi non è possibile.
(I): — Senti, ma non riesco a trovare questa best practices. Dove l'hai trovata? E, magari, dovremmo comunque procedere con la deframmentazione, eh?
(C): — Caro Ignat! Comprendendo che non prendi sul serio il nostro problema e trattenendoci a stento da una risposta diretta, non politically correct, proveremo comunque a risponderti. Non abbiamo la tua esperienza (siamo in IT solo dal 1960) e ti siamo molto grati per il tuo lavoro e sforzi per la nostra istruzione. Le Best Practices ci sono state date dai vostri Product Managers durante una cena a Barcellona, e ti ho inviato il link. Ti chiediamo, Ivan, direttamente: questa situazione è normale? Se non ti interessa parlare con noi, per favore trova qualcuno che possa aiutarci.
(I): — Marco, non riesco a trovare queste best practices. Ho bisogno dei log e passerò il problema a un altro ingegnere. Ti dico questo: se vedi la frammentazione e non deframmenti — è stupido e irresponsabile. E, in generale, come hai fatto a confondere il nobile nome “Ignat” e a chiamarmi Ivan?
(К): — Basta! Per me, Ignat, non sei né un fratello né un parente, quindi ti prego di rivolgerti a me come Gn. Santino! Se non riesci a trovare il documento, se non sei in grado di gestire un compito così semplice, allora o ti dimetti dalla compagnia, oppure chiedi all'autore che ci ha consegnato questo documento! Per quanto riguarda i log, non possiamo fornirli senza un accordo speciale, poiché lavoriamo con documenti riservati. Il tuo sdegno riguardo al mio errore mostra la tua ignoranza e maleducazione. Mi dispiace molto per te. E per concludere: se diciamo che abbiamo “provato a deframmentare” e che è “impossibile”, significa che abbiamo provato ed è impossibile. Ignat, ti prego, smettila di dire sciocchezze e occupati del tuo lavoro — o datti una risposta, o trova qualcuno che ce la dia!
Dopo ciò, la richiesta è stata trasferita a un livello superiore, dove è morta – il cliente non ha mai fornito i log, i test completi non hanno dato risultati e il problema non è stato semplicemente confermato.
Domanda: cosa avrebbe potuto fare l'ingegnere per evitare il riscaldamento degli animi e l'escalation del conflitto?
(Cerca di rispondere a questa domanda da solo prima di continuare a leggere).
Divagazione tecnica lirica
Per gli appassionati di enigmi e di risposte alla domanda «chi è il colpevole?»: il problema si è rivelato molto più serio: la frammentazione di ReFS non solo influiva sulle operazioni sui dischi, ma in alcuni casi aumentava l'uso della CPU e della RAM fino a dieci volte, e non solo per i clienti di Veeam – tutti gli utenti di ReFS potevano subirne le conseguenze.
Microsoft ha impiegato più di un anno, con il supporto di molti fornitori, per correggere finalmente questo errore (in cui vediamo anche il nostro merito – molte copie sono state rotte per il supporto a questo gigante a tutti i livelli).
Rispondendo alla domanda “cosa si poteva fare?”, voglio porre un'altra, eterna domanda: «E chi è il colpevole?»
Per solidarietà professionale, mi piacerebbe dire: «È colpa del cliente», — e cominciare a difendere l'ingegnere. Come responsabile, che valuta costantemente il lavoro dei suoi ingegneri, vedo gli errori commessi da Ignat. Chi ha ragione?
Analizziamo tutto per ordine
Questo caso è molto difficile, ci sono più domande che risposte.
Formalmente, Ignat ha fatto tutto piuttosto bene:
- ha seguito uno dei valori fondamentali di Veeam: Conversazione dal cuore;
- si rivolgeva al cliente per nome;
- chiedeva chiarimenti sulla situazione prima di proporre una soluzione.
Poteva evitare una tale escalation?
Poteva: notare come il signor Santino comunicava (solo usando il Lei e il cognome), rinunciare a "domande fondamentali", mostrare il suo interesse per il problema e promettere di chiarire se questo fosse un comportamento normale.
Passi minimi, senza la parte tecnica – e già avrebbero aiutato a "spegnere" la situazione. Ma anche se questo è stato trascurato – semplicemente "non fare" avrebbe anche aiutato un po'.
Sembra ovvio: non prendere un refuso sul personale, non offendersi per un cliente sarcastico (anche se tutto parla di un eccesso di autostima), non portare la conversazione sul personale, non cedere alle provocazioni… Quanti di questi "no", tutti importanti e tutti riguardanti la comunicazione.
E il cliente? Le lettere sono scritte "in uno stile elevato", continui riferimenti alle proprie conoscenze ai vertici, offese velate e risentimento per quello che sembra mancanza di rispetto? Sì, possiamo leggerlo proprio così. Dall'altra parte – ha veramente il signor Santino torto nella sua rabbia?
Eppure, cosa si poteva fare da entrambe le parti? La vedo così:
Dal lato dell'ingegnere:
- valutare il grado di formalismo del cliente;
- seguire meno la “isola di base”;
- (ora sarà soggettivo) leggere con maggiore attenzione le lettere;
- rispondere alle domande, invece di evitarle;
- e, infine, non cedere alle provocazioni e non portare la conversazione sul personale.
Al cliente:
- definire chiaramente la questione nella prima lettera, senza nasconderla nei dettagli tecnici (dal dialogo non appare direttamente, ma credetemi, la dettagliazione era sorprendente);
- essere un po' più tollerante verso le domande – non tutti ragionano allo stesso modo, e a volte bisogna chiedere molto per capire l'essenza del problema;
- forse trattenere il desiderio di mostrare la propria importanza e le conoscenze “ai massimi livelli”;
- e, come per Ignat, evitare di portare la conversazione sul personale.
Ripeto – questa è solo la mia visione, la mia valutazione, che in nessun modo si considera raccomandazioni o linee guida su “come vivere e lavorare”. Questa è una delle prospettive da cui si può guardare alla situazione, e sarei felice se proponeste le vostre.
Non difendo l'ingegnere: è un Burattino malvagio per conto suo. Non accuso il cliente: ha tutto il diritto di comunicare come ritiene opportuno, anche se la sua comunicazione è avvolta in un sottile velo di quasi educato offesa (un buon esempio del moderno idalgo, che non si occupa di mercenarismo e guerra, ma di IT – anche se…).
«La scure ha trovato la pietra» — così posso riassumere questa corrispondenza, o per dirla in altri termini, in una verità in cui credo sinceramente: «in ogni conflitto di solito sono responsabili in due».
Potremmo dire con le parole del nostro business trainer: «l'esperienza passata, le abitudini comunicative e le diverse visioni del mondo ostacolano la comunicazione efficace». Possiamo ricordare la regola d'oro della moralità: «Tratta gli altri come vorresti essere trattato».
Ma si può semplicemente dire: in ogni comunicazione ci sono sempre due partecipanti, e dall'altra parte del telefono o dello schermo c'è una persona viva, che ha anche paura, gioia, tristezza o qualsiasi altra emozione. Sì, si considera che emozioni e business siano inconciliabili, ma dove possiamo rifugiarci dalle emozioni? Esse erano, sono e saranno, e anche se noi siamo il Supporto Tecnico e affrontiamo compiti ben definiti, il nostro lavoro principale è definito proprio dalla seconda parola: «supporto».
Il supporto riguarda le persone.
***
Ricordate, ho scritto due volte che in questo caso sono responsabili in due? In realtà, più che due: in questa situazione sono responsabili tutti e tre. Perché? Semplicemente perché l'ingegnere non è un'entità a sé stante, ma parte del supporto tecnico, e questo è il nostro lavoro e la nostra responsabilità: insegnare il nostro collaboratore a affrontare situazioni simili. Cerchiamo di imparare dai nostri errori e di aiutare i nostri collaboratori ad evitarli.
È possibile evitare sempre situazioni simili? Non sempre. Per quanto bravo possa essere l'ipotetico Ignat, dall'altro lato potrebbe esserci una persona che farà di tutto per inasprire la situazione.
Ma la bellezza del lavoro nel Supporto Tecnico di Veeam, uno dei valori di cui ci vantiamo, è il lavoro di squadra. È molto importante ricordare: «Non sei solo», e facciamo tutto il possibile affinché sia così.
È possibile insegnare a vivere e lavorare in tali situazioni? Sì.
Sappiamo, amiamo, pratichiamo: è per questo che abbiamo strutturato la nostra formazione interna e continuiamo a rifinirla e migliorala. Negli ultimi due anni e mezzo, da quando si è verificata la situazione descritta, abbiamo lavorato seriamente al nostro programma di formazione e ora utilizziamo attivamente casi studio, modelli di situazioni, accumuliamo esperienze e torniamo costantemente sui nostri errori analizzando le sfumature della comunicazione.
Crediamo che i nostri ragazzi ora affrontino il “campo” molto più preparati a qualsiasi situazione; e se si presenta qualcosa a cui non sono pronti, noi siamo qui e pronti ad aiutare, e in seguito ad integrare i nostri corsi con nuovi esempi.
E questo porta dei risultati. Ecco, per esempio, il feedback di uno dei nostri clienti sul nostro lavoro:
“Abbiamo lavorato nell'industria IT per più di 20 anni e siamo tutti d'accordo che nessun fornitore offre il livello di supporto tecnico che offre Veeam. È un piacere parlare con il personale tecnico di Veeam perché sono competenti e risolvono i problemi rapidamente. Il supporto non dovrebbe mai essere sottovalutato. È una misura dell'impegno e del successo di un'azienda. Veeam è il numero 1 per il supporto.”
“Lavoriamo nell'industria IT da oltre 20 anni e affermiamo che nessun altro fornitore offre un livello di supporto tecnico come Veeam. È molto piacevole lavorare con gli ingegneri di Veeam, poiché conoscono il loro lavoro e possono risolvere i problemi velocemente. Il supporto tecnico non deve mai essere sottovalutato. È un indicatore della responsabilità e del successo di un'azienda. Veeam ha il miglior supporto tecnico.”
***
Qualsiasi comunicazione è un campo di esperimenti, errori, che ci piaccia o no. E la mia opinione è che sbagliare è normale; anzi, il mio invito è: sbagliate! Non si tratta di cadere, ma di imparare a mettere i piedi saldamente a terra dopo.
A volte è difficile tenere a mente tutte le istruzioni e le ricette che i “guru” della comunicazione con i clienti o i colleghi esperti condividono generosamente. È molto più semplice ricordarsi a volte: “sto parlando con una Persona”.
***
Non pretendo di avere la conoscenza suprema o uno standard speciale di qualità nella comunicazione con i clienti. Solo l'elenco dei miei errori basterebbe per scrivere un intero manuale.
L'obiettivo che mi sono posto è mostrare come può funzionare il Supporto Tecnico e avviare una discussione su ciò che può essere considerato accettabile in casi simili e ciò che non lo è.
Cosa ne pensate?
Fonte: habr.com
