Ci sono casi in cui un ticket non racconta davvero il rischio che porta con sé.
Può avere una priorità, una classificazione, un gruppo assegnatario, una descrizione, una coda di lavoro e uno stato di avanzamento. Tutto formalmente corretto. Eppure, sotto quella struttura ordinata, può nascondere qualcosa che richiede un’attenzione diversa.
L’ho imparato in una situazione che, all’inizio, sembrava una normale segnalazione da gestire secondo processo. Poi è diventata un caso interno, con telefonate, riunioni straordinarie, e-mail, tensioni tra gruppi e scarichi di responsabilità.
Alla fine, molti si concentrarono su un punto: la priorità del ticket.
Come se tutto il problema fosse lì.
Ma non era solo una priorità sbagliata.
Era un problema di gestione del rischio, di responsabilità tra gruppi, di escalation, di presidio e di processo.
Una segnalazione che non poteva essere trattata come le altre.
Un utente aveva segnalato una situazione molto delicata: accedendo con il proprio account, visualizzava dati riconducibili a un’altra persona.
Non era una schermata che non caricava, una funzione momentaneamente non disponibile o un errore applicativo generico. Era una segnalazione con un potenziale impatto sulla sicurezza, sulla riservatezza dei dati e sulla fiducia del cliente nel servizio.
Una risorsa del mio team prese in carico il ticket e, a mio avviso, fece la cosa giusta: riconobbe subito la gravità della situazione e avviò le procedure previste per quel tipo di casistica. I gruppi coinvolti vennero informati, la segnalazione fu portata all’attenzione del team competente e il rischio venne evidenziato fin dall’inizio.
Questo punto è importante.
Il service desk, in casi del genere, non deve limitarsi a smistare. Deve capire cosa sta passando dalle sue mani.
Una richiesta può sembrare piccola nel numero di utenti coinvolti, ma enorme per la natura dell’anomalia. Se una sola persona vede dati che non dovrebbe vedere, il problema non può essere valutato solo guardando alla quantità di utenti impattati.
Il rischio non è sempre proporzionale al volume.
A volte è nella tipologia della segnalazione.
Un ticket relativo a dati, accessi, profili o autorizzazioni non può essere trattato come un’anomalia qualunque, anche quando riguarda un solo utente. In quei casi, la domanda non è solo “quante persone sono bloccate?”, ma “che tipo di rischio stiamo lasciando aperto?”.
È lì che il service desk deve fare un salto di qualità: non guardare soltanto lo stato operativo della richiesta, ma leggere il significato della segnalazione dentro il servizio.
In quella fase iniziale, la mia risorsa lo fece.
Il problema nacque dopo.
Quando un ticket viene rimbalzato, il rischio non sparisce.
In un primo momento, il team responsabile degli accessi non riuscì a replicare l’anomalia.
Da lì iniziò la parte più fragile della gestione.
Quando un’anomalia non è replicabile, la tentazione è abbassarne immediatamente il peso. Succede spesso. Se non la vedo, se non la riproduco, se non riesco a dimostrarla nel mio ambiente, allora forse non è così grave. Forse è un caso isolato. Forse l’utente ha capito male e possiamo metterla in coda.
Questa reazione è comprensibile.
Ma non sempre è corretta.
Ci sono segnalazioni che, anche se non replicabili al primo tentativo, devono restare sotto presidio perché il rischio potenziale è troppo alto per essere archiviato mentalmente come “non dimostrato”.
La mia risorsa, davanti a un primo rimbalzo che percepì come troppo superficiale, insistette. Era stata formata in modo preciso su questo tipo di situazioni e sapeva che un’anomalia legata all’accesso ai dati non poteva essere trattata come un normale malfunzionamento. Tornò quindi a ingaggiare il gruppo di competenza, cercando di far percepire il peso del caso.
Dopo ulteriori verifiche, il problema venne compreso meglio.
Non era semplice da gestire.
Proprio in quel momento, però, la storia prese una direzione pericolosa.
Quando un problema viene riconosciuto come complesso, ma non viene agganciato a un presidio chiaro, rischia di finire in una zona grigia. Non è più ignorato, ma non è nemmeno davvero governato. Esiste, viene citato, viene rimandato, magari inserito in una coda insieme ad altre attività considerate più urgenti.
Formalmente è vivo.
Operativamente si sta spegnendo.
La coda di lavoro non può sostituire il presidio. Una coda ordina attività, ma non valuta sempre il rischio trasversale. Un ticket può non essere bloccante per l’operatività immediata di un singolo utente e restare comunque molto delicato per la natura dell’anomalia.
Se riguarda accessi, dati, autorizzazioni o informazioni non visibili correttamente, non basta chiedersi se l’utente riesca a lavorare.
Bisogna chiedersi che rischio stia rimanendo aperto.
Nel frattempo passarono giorni, poi settimane. Era periodo di ferie, i passaggi di consegne non furono ottimali e la segnalazione perse progressivamente attenzione. La mia risorsa continuava a sollecitare, interveniva nelle riunioni di allineamento, provava a riportare il tema sul tavolo.
Ma quando un’attività non ha un protocollo forte a proteggerla, dipende troppo dalla sensibilità delle singole persone.
Se qualcuno insiste, resta viva. Se smette di insistere, scompare.
E nei casi ad alto rischio questa è una debolezza enorme.
Il caso esplode quando esce dal processo.
A distanza di circa un mese, l’incidente venne gestito.
Il problema, però, non fu eliminato del tutto.
L’anomalia si ripresentò e il cliente, ormai impaziente, chiamò un commerciale per lamentarsi della situazione. Da lì partì il caso.
Telefonate interne. Riunioni straordinarie. E-mail. Ricostruzioni. Tentativi di capire chi avesse fatto cosa, quando, con quale priorità e con quale responsabilità.
È una dinamica che molte organizzazioni conoscono bene.
Finché il problema resta dentro il processo, anche se procede male, sembra ancora gestibile. Quando però arriva fuori dal processo e coinvolge canali commerciali, stakeholder interni o clienti insoddisfatti, improvvisamente diventa urgente per tutti.
A quel punto la domanda cambia.
Non è più solo: “Come risolviamo questa situazione?”
Diventa anche: “Chi ha causato l’escalation?”
Ed è lì che spesso le organizzazioni fanno il danno peggiore. Invece di analizzare il sistema, cercano il punto più semplice su cui scaricare la tensione.
In questo caso, quel punto diventò la risorsa del mio team.
Ricordo molto bene una call. C’eravamo io, il mio responsabile di allora e l’advisor che aveva in carico la segnalazione. Il mio responsabile contestò alla mia risorsa di aver abbassato la priorità del ticket da bloccante a maggiore, attribuendole una parte rilevante della responsabilità per i ritardi di intervento.
Sono generalmente una persona equilibrata.
In quel momento, però, feci molta fatica a restare neutrale.
Per me il concetto di squadra è molto forte. Quando una risorsa lavora correttamente, prova a far emergere un rischio, insiste con i gruppi coinvolti e tiene viva una segnalazione che altri stanno sottovalutando, non posso accettare che diventi il bersaglio più semplice quando il caso esplode.
Difendere una persona non significa dire che non possa aver commesso errori.
Significa impedire che un errore collettivo venga ridotto alla scelta più comoda da raccontare.
In quella situazione, il tema non poteva essere solo il cambio di priorità. Una priorità abbassata non poteva giustificare settimane di scarsa attenzione. Un rimpallo tra gruppi non poteva essere attribuito solo alla classificazione del ticket. Un caso con potenziale esposizione di dati non poteva dipendere esclusivamente dal fatto che, a un certo punto, la priorità fosse passata da bloccante a maggiore.
La priorità era un elemento della storia.
Non la storia.
La priorità è un indicatore, non un processo.
Inserire le priorità corrette è importante.
Anzi, è un’arte operativa.
Una priorità sbagliata può generare rumore, ritardi, aspettative errate o interventi sproporzionati. Se tutto è bloccante, niente è davvero bloccante. Se ogni ticket viene alzato di livello per ottenere attenzione, il sistema perde capacità di distinguere.
Allo stesso tempo, però, la priorità non può essere l’unico meccanismo di governo.
Nel caso che sto raccontando, la modifica fatta dall’advisor aveva anche una logica: nel momento in cui l’operatività dell’utente viene sbloccata, una priorità bloccante può essere rivista. Il termine stesso lo suggerisce. Se non c’è più un blocco operativo diretto, può avere senso ridurre il livello di urgenza.
Il punto è che l’urgenza operativa non coincide sempre con il rischio o l’impatto.
Questa distinzione è fondamentale.
Un ticket può non essere più bloccante per l’utente, ma restare critico per il servizio. Può non impedire il lavoro quotidiano, ma indicare una vulnerabilità. Può riguardare un solo caso, ma segnalare un difetto profondo nella gestione dei profili, degli accessi o dei dati.
Se il processo non distingue questi piani, tutto finisce dentro la stessa logica: priorità, coda, assegnazione, attesa.
Ma alcune segnalazioni non dovrebbero essere governate solo così.
La vera lezione che mi porto dietro da quell’episodio è questa: non basta censire correttamente una richiesta e assegnarle una priorità. Serve definire processi operativi distinti per tipologie diverse di segnalazione.
Alcuni casi devono attivare un protocollo specifico, indipendentemente dalla priorità ordinaria del ticket. Penso, per esempio, a segnalazioni che riguardano possibile esposizione di dati, anomalie sugli accessi, errori di autorizzazione o profilazione, bug non replicabili ma ad alto rischio, incidenti con impatto reputazionale, casi che coinvolgono più gruppi di lavoro o situazioni in cui il cliente ha già evidenziato forte sensibilità.
In questi casi, la domanda non può essere solo: “Che priorità ha il ticket?”
Serve chiedersi quale protocollo debba attivare quella tipologia di rischio.
La differenza è enorme.
Una priorità organizza l’urgenza.
Un protocollo protegge la gestione.
Significa stabilire chi deve essere coinvolto, entro quali tempi, con quale livello di presidio, con quali aggiornamenti, con quali passaggi di escalation e con quale responsabilità di chiusura.
Senza questo livello di chiarezza, i ticket delicati dipendono troppo dalla buona volontà delle persone.
E la buona volontà, da sola, non è un processo.
Il rimpallo non è sempre malafede.
C’è un altro punto che vale la pena chiarire.
Quando parliamo di rimpallo tra gruppi di lavoro, immaginiamo spesso persone che non vogliono prendersi responsabilità. A volte succede anche questo. Molto più spesso, però, il rimpallo nasce da confini poco chiari, processi incompleti, priorità non condivise o metriche che spingono ogni team a proteggere il proprio perimetro.
Un gruppo guarda la replicabilità tecnica.
Un altro guarda l’impatto utente.
Un altro ancora guarda la coda delle emergenze.
Il service desk guarda la segnalazione, la relazione con l’utente, lo stato del ticket e la necessità di mantenere viva l’attenzione.
Tutti vedono un pezzo.
Il problema nasce quando nessuno tiene insieme il quadro.
È lì che serve un processo trasversale: non per colpevolizzare i gruppi, ma per evitare che ogni team agisca in modo coerente con il proprio punto di vista e incoerente rispetto al servizio complessivo.
Un’organizzazione matura non elimina i conflitti tra priorità.
Li rende governabili.
Guardando indietro, la domanda più utile non è: “Chi ha sbagliato?”
La domanda più utile è: “Cosa avrebbe dovuto impedire che questa situazione arrivasse fino a quel punto?”
La risposta, per me, sta in tre elementi.
Il primo è una classificazione più intelligente delle segnalazioni ad alto rischio. Alcuni ticket devono essere riconosciuti non solo per la loro urgenza, ma per la natura del rischio che rappresentano.
Il secondo è un presidio esplicito. Se una segnalazione coinvolge dati, accessi o sicurezza, non può dipendere soltanto dai solleciti del service desk. Deve avere un percorso definito, con responsabilità chiare e verifiche periodiche.
Il terzo è una cultura di gestione che non cerchi subito un colpevole quando qualcosa esplode. Se una risorsa ha segnalato, insistito e provato a far emergere il tema, il sistema dovrebbe chiedersi perché quel segnale non è stato raccolto.
Non sempre una persona che si trova vicino al ticket è la persona responsabile del problema.
A volte è semplicemente quella che ha provato più di altri a tenerlo visibile.
La lezione che mi porto dietro.
Da quell’esperienza ho imparato una cosa che oggi considero fondamentale.
La priorità di un ticket conta, ma non basta.
Serve una capacità più profonda di leggere la natura della segnalazione, distinguere l’urgenza operativa dal rischio, attivare i gruppi corretti e mantenere presidio sulle situazioni che non possono essere lasciate alla sola logica della coda.
Il service desk, in questo, ha un ruolo delicato.
Non è proprietario di tutti i problemi che intercetta. Spesso, però, è il primo punto in cui quei problemi diventano visibili.
Questo significa che deve saper classificare, insistere, documentare, sollecitare e, quando serve, alzare la mano. Allo stesso tempo, l’organizzazione deve dargli processi e protocolli adeguati, altrimenti si finisce per chiedere alle persone di compensare con sensibilità individuale ciò che dovrebbe essere governato dal sistema.
C’è poi una lezione più manageriale.
Quando una risorsa fa il proprio lavoro e prova a proteggere il servizio, va protetta a sua volta. Non per spirito di appartenenza cieco, ma perché scaricare la responsabilità su chi ha tenuto aperto il problema è uno dei modi più rapidi per insegnare al team una cosa pericolosa: la prossima volta, meglio non esporsi.
E un service desk in cui le persone smettono di esporsi è un service desk più debole.
Forse più silenzioso, ma anche molto più fragile.
Per questo, ripensando a quel caso, continuo a credere che il punto non fosse la priorità sbagliata.
La priorità era solo il punto visibile.
Sotto c’era molto altro: un rischio non presidiato abbastanza, un rimpallo tra gruppi, un processo incompleto e una responsabilità distribuita male.
Il vero miglioramento nasce quando smettiamo di cercare il colpevole più vicino al ticket e iniziamo a chiederci quale parte del sistema non ha funzionato.
Perché spesso il problema non è solo chi ha abbassato una priorità.
È tutto ciò che, dopo, ha permesso al rischio di restare lì.
