Quando si parla di service desk, il primo ostacolo da superare non è tecnologico, organizzativo o metodologico.
È culturale.
In molte aziende il service desk continua a essere percepito come il luogo dove finiscono i problemi. Una struttura incaricata di gestire richieste, smistare ticket e rispondere agli utenti. Una visione apparentemente innocua che però influenza il modo in cui vengono prese decisioni, progettati servizi e distribuite responsabilità.
Per comprendere perché questa percezione sia limitante, è necessario partire da alcune dinamiche che si ripetono quotidianamente all’interno delle organizzazioni. Ma per capire davvero cosa cambia nel service desk, bisogna andare oltre la definizione e osservare la sua funzione reale dentro il sistema di servizio: è qui che emerge il suo vero ruolo.
Quando il service desk diventa il contenitore di tutto ciò che non si sa gestire.
In molte organizzazioni non esiste davvero una distinzione tra help desk e service desk. Esiste una sovrapposizione di parole che, nella pratica quotidiana, si traduce in un’unica aspettativa: c’è un problema, qualcuno deve risolverlo.
Il punto è che questa semplificazione non è neutra. Non è solo una questione terminologica o organizzativa. È un’impostazione culturale che definisce il modo in cui un’intera azienda interpreta il valore del supporto.
Nella realtà operativa, il service desk viene spesso trattato come il punto di raccolta di tutto ciò che non funziona o che non si sa dove collocare.
Richieste, incidenti, dubbi, eccezioni: tutto converge lì. Ma non perché sia il design corretto del sistema, bensì perché è il punto più “tollerabile” dove scaricare complessità.
E questa scelta, spesso inconsapevole, cambia completamente la natura del service desk.
In questo schema mentale, il service desk non è parte del processo decisionale.
È una fase successiva.
Qualcosa che entra in gioco quando la decisione è già stata presa, quando il cambiamento è già stato pianificato, quando il problema è già esploso.
Il giorno in cui abbiamo progettato un problema.
Ricordo un’esperienza avuta in passato, in cui il team di sviluppo aveva implementato una nuova funzionalità. Questa nuova funzionalità del servizio non era stata completata per mancanza di tempo, ma si era scelto di pubblicare lo stesso l’aggiornamento seppur incompleto. Il team di sviluppo aveva deciso che, se gli utenti avessero utilizzato quella funzionalità, il service desk sarebbe intervenuto a posteriori per sistemare i problemi generati dalla funzionalità stessa. Un po’ come a dire “so di generare il problema, ma visto che non sarò io a doverlo gestire non me ne preoccupo”. Avevano deciso tutto senza coinvolgere il service desk e senza avvertire gli utenti che sarebbe stato meglio non utilizzare la funzionalità.
Quello che accadde il giorno successivo era facilmente prevedibile, ma nessuno aveva deciso di considerarlo.
Decine di segnalazioni aperte.
Urgenza estrema nella gestione del problema.
Clienti infuriati perché la funzionalità era fallata.
Incremento del flusso di segnalazioni non preventivato, collasso del team di supporto che non riusciva più a rimanere nei tempi di risposta e risoluzione.
Risultato? Cliente insoddisfatto, generazione di un problema e un’emergenza evitabile: immagine aziendale danneggiata.
Il risultato è quasi sempre lo stesso: comunicazioni tecniche corrette ma inefficaci, utenti disorientati o preoccupati per i possibili effetti sulla propria operatività, escalation improvvise, e una gestione emergenziale che ricade inevitabilmente sul service desk.
Non perché non fosse evitabile, ma perché non è stato progettato insieme.
La marginalizzazione invisibile del service desk.
Ed è qui che nasce la distorsione: il service desk non viene visto come un attore del servizio, ma come il luogo dove il servizio “si aggiusta dopo”.
Questa visione produce effetti molto concreti, anche se raramente vengono esplicitati.
Il primo effetto è una marginalizzazione sistemica del team.
Non dichiarata, ma evidente nei comportamenti quotidiani.
- il service desk non viene coinvolto nelle fasi di analisi
- le decisioni sugli impatti utente vengono prese altrove
- la comunicazione viene costruita senza chi dovrà poi gestirne le conseguenze
Il secondo effetto è più sottile: la perdita di autorevolezza interna. Se un team viene percepito come “reattivo per definizione”, allora diventa automaticamente escluso da tutto ciò che è preventivo.
Eppure, paradossalmente, è proprio nel service desk che si generano alcune delle informazioni più critiche del servizio: come reagiscono gli utenti, dove si bloccano, cosa non è chiaro, cosa crea attrito.
Nei framework di service management come ITIL, il service desk non è mai descritto come una funzione puramente reattiva, ma come un elemento chiave del miglioramento continuo del servizio.
Questa dinamica diventa evidente nei momenti di cambiamento.
Un rilascio, una nuova funzionalità, una modifica di processo: spesso il service desk viene coinvolto quando tutto è già pronto. A quel punto non si discute più di “se” o “perché”, ma solo di “come gestire le conseguenze”.
Il problema è che le conseguenze sono già state definite a monte, senza il punto di vista di chi vive quotidianamente l’interazione con l’utente. Anzi, spesso capita che per motivi di tempistiche o scadenze si scelga di pubblicare qualcosa di incompleto o parzialmente funzionante, proprio perché a come gestire le conseguenze ci penserà il service desk.
Quando questa visione si consolida, non genera solo inefficienza operativa: diventa la radice di errori sistemici che coinvolgono l’intera organizzazione.
Quando il service desk viene coinvolto, il risultato cambia.
Ricordo una seconda vicenda in cui, invece, siamo stati coinvolti e abbiamo coordinato le attività.
In questo caso era un cambio dello stack tecnologico che gestisce gli accessi al sistema. Siamo passati da credenziali semplici a un sistema di autenticazione multi fattore. Abbiamo preparato a priori tutti gli utenti, abbiamo inviato una comunicazione con istruzioni e un video tutorial su come configurare il nuovo accesso e fornito supporto a chi aveva difficoltà.
Inoltre, per non concentrare eventuali problematiche tutte nello stesso periodo abbiamo creato un calendario di migrazione, in modo che gli utenti fossero migrati a lotti e non tutti insieme. Avendo coordinato noi l’attività avevamo la gestione della comunicazione con gli utenti e il controllo su quello che accadeva all’interno dell’azienda e nei team tecnici. Il risultato è stato una migrazione apprezzata dai clienti, compresa e senza effetti collaterali.
Il coinvolgimento del service desk ha trasformato una migrazione tecnica in un’esperienza guidata per gli utenti. L’attività da gestire era la stessa. La tecnologia era la stessa. Ciò che è cambiato è stato il modo in cui l’organizzazione ha deciso di accompagnare le persone attraverso il cambiamento.
Il vero errore: confondere il supporto con l’osservazione.
Il vero nodo, infatti, non è operativo, è concettuale.
L’errore culturale sta nel considerare il service desk come un punto di accesso al supporto, invece che come un sistema di osservazione del servizio.
Ogni ticket racconta qualcosa del servizio.
Non soltanto che esiste un problema, ma come quel problema viene percepito.
Un errore tecnico può essere grave e generare poche segnalazioni.
Una modifica apparentemente insignificante può creare decine di richieste di supporto.
È proprio in questa differenza che il service desk diventa un osservatorio privilegiato.
Perché non osserva il servizio dal punto di vista dell’architettura o del codice, ma da quello dell’esperienza vissuta dagli utenti.
Nel primo caso, il valore è misurato in termini di risposta: quanto velocemente prendi in carico, quanto rapidamente fornisci risposte, quanto velocemente risolvi.
Nel secondo caso, il valore è misurato in termini di comprensione: quanto anticipi, quanto migliori il sistema, quanto riduci la probabilità che il problema si ripresenti.
Questa differenza cambia tutto. Cambia le metriche, cambia le priorità, cambia il ruolo del team.
E soprattutto cambia una cosa spesso sottovalutata: la posizione del service desk dentro l’organizzazione con lo scopo di generare qualità del servizio. Questo forse è il cambio di visione più difficile da comprendere, ma anche quello più rivoluzionario. Perché è molto più difficile misurare la qualità del servizio piuttosto che i tempi di intervento, ma è anche quell’aspetto che maggiormente impatta sulla percezione di valore da parte del cliente.
Quando il service desk viene ridotto a funzione reattiva, l’organizzazione perde un sensore fondamentale.
Non vede i segnali deboli.
Non intercetta i pattern ricorrenti.
Non collega le informazioni tra loro.
E soprattutto non trasforma le interazioni quotidiane con gli utenti in conoscenza strutturata.
A quel punto il sistema diventa inevitabilmente più lento, più reattivo e più costoso, anche se formalmente “funziona”.
Il service desk non nasce come help desk evoluto. Nasce come punto nevralgico del servizio, come motore di generazione di valore e asset per il miglioramento continuo del servizio stesso.
Ma quando viene interpretato solo come struttura di supporto, perde la sua funzione più importante: quella di collegamento tra ciò che l’organizzazione progetta ed eroga e ciò che l’utente vive davvero.
Un service desk non è il luogo dove si gestiscono i problemi.
È il luogo dove si capisce, in tempo reale, se il servizio sta funzionando davvero. E se questa funzione viene ignorata, non è il service desk a diventare inefficiente.
È l’intero sistema a perdere la capacità di vedere sé stesso attraverso gli occhi dei propri utenti.
Questa confusione iniziale si riflette anche nel modo in cui vengono costruite e interpretate le metriche del servizio.