Come si comunica, si gestisce un'urgenza e si protegge il lavoro dei tecnici — perché un servizio rapido e una squadra concentrata non sono in conflitto: sono la stessa cosa, se le regole sono chiare. Base operativa per la configurazione di ticketing e RMM.
Questo decalogo non è burocrazia: protegge sia la qualità del lavoro sia la velocità delle risposte. La ricerca sul context switching è netta.
Un'attività interrotta richiede il doppio del tempo e contiene il doppio degli errori rispetto a una svolta senza interruzioni.
Una "domanda da 2 minuti" non costa 2 minuti: può costare ore di contesto perso e ricostruito. La mente non cambia task all'istante.
Il context switching può consumare fino al 40% del tempo produttivo. È un problema di sistema, non di persone.
Rispetto dei ruoli, della concentrazione e delle richieste. Valgono per tutti — team interno e clienti.
Ogni richiesta nasce e vive nel sistema di ticketing. Niente ticket = niente tracciamento, niente SLA, niente memoria. Le richieste a voce o via chat vanno sempre trasformate in ticket prima di essere lavorate.
Perché Senza un canale unico, le richieste si perdono e nessuno sa chi fa cosa.
Il cliente parla con lo SPOC, non con il singolo tecnico. Lo SPOC qualifica, apre il ticket, dà tempi e tiene il cliente informato. È la voce calda; i tecnici sono la mano che esegue.
Perché Un unico interlocutore protegge il cliente (sa sempre con chi parlare) e il tecnico (non viene tirato da dieci parti).
Niente chiamate o messaggi diretti al tecnico mentre lavora su un intervento. Le richieste passano dal centralino e dal ticketing. Il tecnico risponde quando raggiunge un punto naturale di stop, non a ogni squillo.
Perché Un'interruzione raddoppia tempi ed errori. Proteggere il focus è proteggere la qualità del servizio.
Ticketing per le richieste, chat interna per il coordinamento veloce, telefono solo per le urgenze vere, email per l'ufficiale. Mai mischiare: una richiesta su WhatsApp personale non esiste, per l'azienda.
Perché Ogni canale ha un costo di attenzione diverso. Il telefono è il più invasivo: si usa quando serve davvero.
La priorità nasce da impatto × urgenza (vedi matrice P1–P4), non da chi alza di più la voce. Un cliente agitato non rende un problema P1: lo rende un problema da gestire con empatia, alla sua reale priorità.
Perché Senza criteri oggettivi, vince il più rumoroso e i problemi seri restano indietro.
Si sale di livello quando il tempo o la competenza lo impongono: L1 → L2 → L3 → CTO, e in parallelo la comunicazione al cliente sale allo SPOC → Owner. Mai saltare direttamente al titolare per accelerare.
Perché L'escalation informale "chiamo Simo che è più veloce" cannibalizza la struttura e centralizza tutto sul titolare.
Il Coordinatore Ops assegna il lavoro. Un tecnico non prende un ticket fuori coda perché "glielo ha chiesto un cliente": lo segnala al dispatch. Anche i lead, quando remano, seguono la pianificazione.
Perché L'auto-assegnazione rompe la pianificazione e crea doppioni e buchi.
Se la risposta può aspettare il prossimo punto di stop, è un messaggio, non una chiamata. Si interrompe qualcuno solo se davvero non può attendere. Le domande ripetute si scrivono una volta nella knowledge base.
Perché L'asincrono lascia a ciascuno il controllo del proprio focus. Il sincrono lo toglie: si riserva alle urgenze.
Ogni ticket si chiude con una comunicazione al cliente: cosa è stato fatto, come, e cosa fare se ricapita. Lo SPOC verifica la soddisfazione. Un intervento risolto ma non comunicato, per il cliente, non è risolto.
Perché La soddisfazione percepita nasce dalla comunicazione, non solo dalla soluzione tecnica.
Oltre l'orario di lavoro e nel weekend risponde solo la reperibilità di turno, per le sole urgenze P1–P2. Gli altri tecnici sono protetti: nessun contatto diretto, nessuna aspettativa di risposta. Kia Kaha vale anche per il riposo.
Perché Una squadra che recupera è una squadra che il lunedì lavora meglio. Il rispetto del tempo libero non è un lusso, è manutenzione.
Ogni canale ha uno scopo e un costo di attenzione. Usarli bene è metà del lavoro di comunicazione.
Standard ITIL adattato: la priorità nasce dall'incrocio tra quanto è esteso il danno (impatto) e quanto in fretta serve risolvere (urgenza). Quattro livelli, ognuno col suo tempo di risposta ed escalation. Toglie ambiguità e rende oggettivo il triage.
| Impatto ↓ / Urgenza → | Alta | Media | Bassa |
|---|---|---|---|
| Critico (tutta l'azienda) | P1 | P1 | P2 |
| Alto (reparto / più utenti) | P1 | P2 | P3 |
| Medio (singolo utente bloccato) | P2 | P3 | P4 |
| Basso (disagio, non blocco) | P3 | P4 | P4 |
Risposta immediata. Coinvolge L2–3 e, se serve, il CTO. Comunicazione proattiva al cliente.
Risposta rapida. Significativo ma non blocca tutta l'azienda. Escalation se non risolto nei tempi.
Coda standard. Singolo utente con problema gestibile. Workflow normale del service desk.
Pianificabile. Disagio o richiesta non urgente. Si lavora a saturazione, senza interrompere.
Dal primo contatto alla chiusura. Due binari paralleli: l'escalation tecnica (chi risolve) e l'escalation di comunicazione (chi parla al cliente). Non si confondono mai.
La richiesta arriva al centralino / SPOC. Si apre il ticket e si assegna la priorità con la matrice. Il cliente riceve subito un tempo di risposta onesto.
Il Coordinatore Ops assegna al livello giusto. P1–P2 entrano subito in lavorazione; P3–P4 vanno in coda. Nessun tecnico si auto-assegna.
Il tecnico lavora senza interruzioni dirette. Aggiorna il ticket; lo SPOC tiene informato il cliente. Il tecnico non parla direttamente col cliente per gli aggiornamenti.
Tecnica: L1 → L2 → L3 (Giuseppe) → CTO (Carlo), quando il tempo o la competenza lo impongono. Comunicazione: SPOC → Owner (Simo) solo per le relazioni critiche. I due binari salgono in parallelo, non si scavalcano.
Risolto il problema, lo SPOC chiude il loop col cliente: cosa è stato fatto e cosa fare se ricapita. Si verifica la soddisfazione. Solo allora il ticket è chiuso.
La leva organizzativa che rende reale la Regola 3. Gli smartphone dei tecnici possono chiamare in uscita, ma il loro numero non è mai il punto di contatto del cliente: ogni chiamata in entrata passa dal centralino.
Il tecnico chiama il cliente quando serve, ma il numero che il cliente vede è quello dell'azienda. Se il cliente richiama, non raggiunge il cellulare del tecnico: arriva al centralino, che qualifica e instrada. Il numero personale del tecnico resta invisibile e protetto.
Questo decalogo è la base logica per configurare ticketing e RMM in modo smart: una volta che le regole sono chiare, gran parte del triage, delle urgenze e degli instradamenti si automatizza. Ecco la mappa regola → configurazione.
Due campi Impatto e Urgenza alla creazione → il sistema calcola Priorità P1–P4 e applica lo SLA corrispondente. Il triage manuale sparisce sui casi standard.
Tag Origine (centralino, email, RMM, portale) per misurare da dove arrivano le richieste e spingere i clienti verso i canali corretti.
Routing per categoria + priorità → coda L1 / L2 / L3. P1–P2 notificano subito il reperibile; P3–P4 entrano in coda senza alert invasivi.
Se un ticket supera la soglia SLA senza avanzamento → escalation automatica al livello successivo + notifica allo SPOC. Il percorso L1→L2→L3→CTO è codificato.
Gli alert RMM (device giù, soglia superata, EDR) generano ticket pre-classificati per priorità, così il problema è in coda prima ancora della chiamata del cliente — proattività, non reattività.
Calendari di servizio per fascia oraria e turno sabato → fuori orario solo P1–P2 al reperibile; il resto attende l'apertura. Protezione del focus codificata nel sistema.
Aggiornamenti automatici di stato al cliente sui cambi di fase (preso in carico, in lavorazione, risolto) → lo SPOC personalizza solo dove serve il tocco umano.
Survey automatica alla chiusura → metrica CSAT per lo SPOC e dato per le QBR. La soddisfazione diventa numero, non impressione.
Impatto/Urgenza → Priorità, impostare le regole di escalation a tempo, collegare gli alert RMM e i calendari di servizio. Il decalogo è la specifica; la configurazione è l'implementazione.