Il cliente chiama preso dal panico: come gestisce la situazione un buon Sistemista

Sono le 9 di mattina e il telefono squilla: è il titolare di un’azienda cliente. Voce alta, frasi spezzate: "non funziona niente. La posta non parte, il gestionale è giù, le persone non riescono ad accedere. Cosa sta succedendo?" Dietro di lui si sentono voci.

Questa è la prova che un Sistemista affronta prima ancora di aprire il pannello di gestione. Una prova relazionale molto prima che tecnica.

Il primo minuto conta più dei successivi trenta

Quando un cliente chiama in questa condizione, quello che dice nei primi sessanta secondi determinerà tutto quello che viene dopo — il livello di collaborazione che riceverà, la sua disponibilità ad aspettare, la fiducia che manterrà anche se il problema richiederà ore per essere risolto.

Il meccanismo del panico funziona così: chi è in panico cerca un punto fermo; quindi se il Sistemista risponde con la stessa urgenza caotica, entrambi sprofondano nel problema. Se invece risponde con calma e struttura, il cliente si aggrappa a quella solidità.

Questo non significa minimizzare ma ignifica prendere il controllo della comunicazione prima ancora di prendere il controllo del problema tecnico.

Una risposta efficace nei primi sessanta secondi suona così: "ho capito. Sto già verificando; dimmi: le persone non riescono ad accedere ai sistemi — da quando esattamente? E il gestionale dà un errore specifico o si blocca in caricamento?"

Con queste due domande sono successe tre cose: il cliente sa che il suo interlocutore ha "sentito" il problema, sa che sta agendo e sa che sta già raccogliendo le informazioni diagnostiche che servono.

La differenza tra rispondere e reagire

Un Sistemista che reagisce all’emergenza fa quello che sente nell’immediato: promette soluzioni rapide per calmare il cliente, apre sessioni remote su tutto contemporaneamente, prova azioni senza una sequenza logica.

Un Sistemista invece che risponde all’emergenza fa il contrario: stabilizza prima la comunicazione, poi inizia la diagnosi in modo metodico.

Elaborazione su casistiche di gestione incidenti IT in contesti MSP

L’aggiornamento periodico è uno degli elementi più sottovalutati: il silenzio, anche quando si sta lavorando intensamente sul problema, viene vissuto dal cliente come abbandono. Un messaggio ogni venti minuti — anche solo "sto ancora lavorando, ho trovato X, sto verificando Y" — mantiene il canale aperto e riduce l’ansia.

Comunicare con chi non parla la stessa lingua

Il problema con i clienti non tecnici non è che spesso non capiscono la tecnologia. La usano per lavorare e quando non funziona si bloccano sul lavoro, non sul sistema.

Tradurre un problema tecnico per un non tecnico non significa semplificarlo ma ancorarlo alle conseguenze operative che il cliente conosce.

"Il server di Active Directory non risponde" non dice niente a chi gestisce un’azienda di trasporti. "Gli utenti non riescono ad accedere ai computer perché il sistema che verifica le credenziali non è raggiungibile" dice tutto.

La stessa logica vale per i tempi: "devo fare un’analisi del dump di memoria e verificare i log degli eventi" non ha senso fuori dal contesto IT. "Ho bisogno di circa un’ora per capire la causa precisa — nel frattempo posso fare accedere le persone più urgenti in questo altro modo" ha senso per chiunque.

Quando il problema non si risolve in tempi ragionevoli

Ci sono situazioni in cui il problema è più grave del previsto, i tempi si allungano e il cliente inizia a perdere pazienza. Questa è la parte più difficile, e spesso dove si vede la differenza tra un professionista e chi è ancora in formazione.

La tentazione è di continuare a promettere tempi sempre più vicini per tenere buono il cliente. È il comportamento che produce più danni: ogni promessa non mantenuta erode la fiducia in modo cumulativo.

L’alternativa è la trasparenza progressiva: "la situazione è più complessa di quanto stimavo inizialmente. Ho trovato che il problema è X e sto valutando due approcci — il primo è più veloce ma provvisorio, il secondo richiede più tempo ma risolve definitivamente. Qual è la tua priorità in questo momento?"

Questa domanda sposta il cliente da spettatore ad attore della soluzione. Nella maggior parte dei casi, riduce immediatamente la pressione.

FAQ

Come si mantiene la calma quando un cliente è aggressivo al telefono durante un’emergenza?

La prima cosa è non ricambiare il tono. L’aggressività del cliente in un’emergenza è quasi sempre paura travestita da rabbia. Rispondere con fermezza e senza alzare la voce — "capisco che la situazione è urgente, sto già lavorando" — spezza il ciclo reattivo. Dopo aver preso il controllo della comunicazione, il cliente si calma nella grande maggioranza dei casi entro pochi minuti.

È giusto fare promesse sui tempi di risoluzione anche se non si è certi?

No. La promessa di un tempo non verificabile è peggio del silenzio: quando non si mantiene, l’effetto sulla fiducia è moltiplicato. La formula più efficace è la finestra: "entro 20 minuti ti dico cosa ho trovato e quanto tempo stimo" invece di "in 20 minuti sistemo tutto". La finestra è sempre mantenibile; la promessa spesso no.

Come si gestisce una situazione in cui non si riesce a trovare la causa del problema?

È una delle situazioni più frequenti e meno discusse. La risposta onesta è: "non ho ancora trovato la causa, ma sto procedendo in modo sistematico escludendo le ipotesi una alla volta". Ammettere l’incertezza tecnica, mantenendo però la certezza sul metodo e sulla presenza, è molto più efficace del fingere di avere il controllo che non si ha.

Il cliente vuole aggiornamenti continui ma ogni telefonata interrompe il lavoro: come si gestisce?

Una soluzione pratica è accordarsi proattivamente sulla frequenza degli aggiornamenti all’inizio dell’intervento: "ti aggiorno ogni 20 minuti via messaggio — se nel frattempo hai urgenza chiamami". Questo mette il cliente a proprio agio sulla presenza, riduce le chiamate spontanee e permette di lavorare con continuità. In alternativa, aggiornamenti brevi su WhatsApp o email funzionano meglio delle telefonate per il tipo di informazione che si vuole trasmettere.

Serve esperienza specifica per comunicare bene in emergenza, o si impara sul campo?

Si impara principalmente sul campo, ma si può accelerare il processo riflettendo consapevolmente sulle interazioni che non sono andate bene. La domanda utile dopo ogni emergenza gestita non è solo "cosa ho fatto tecnicamente" ma "come ha vissuto il cliente questa situazione". Chi si pone questa domanda sistematicamente migliora molto più velocemente di chi analizza solo l’aspetto tecnico.

Potrebbe interessarti anche

• SISTEMISTA IT
• IT SPECIALIST
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• ELECTRICAL DESIGN ENGINEER JUNIOR
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider
• SPACE SYSTEMS ENGINEER
• Fortinet per Sistemisti: perché è lo standard nelle PMI italiane
• Microsoft 365 e Azure per Sistemisti: competenze chiave nel 2026
• Quanto guadagna un Sistemista a Torino?
• ADDETTO/A PAGHE E CONTRIBUTI