Arriva una segnalazione: un utente non riesce ad accedere, una stampante non funziona, un server mostra errori. Qualcuno all'help desk trasforma questo in un ticket, sceglie una categoria e determina l'urgenza. Può l'AI subentrare in questo? In gran parte sì, con un'eccezione importante che varia da azienda ad azienda.
Tre assi sono determinanti: volume, margine di giudizio e contatto con il cliente.
Il volume è alto. Un help desk elabora quotidianamente da decine a centinaia di segnalazioni, e molte di queste sono variazioni su un numero limitato di problemi noti: password dimenticata, nessun accesso a una condivisione, laptop che non si avvia. In presenza di volumi elevati e ripetizione, un compito è per definizione adatto all'automazione, perché un modello impara da schemi che si ripetono spesso.
Il margine di giudizio è limitato. Urgenza e categoria derivano solitamente da un albero decisionale: quanti utenti sono colpiti, esiste una soluzione temporanea, quale sistema è coinvolto. Questo è esattamente il tipo di lavoro in cui i modelli linguistici eccellono: leggere una segnalazione, estrarne le caratteristiche e confrontarle con un modello di categorizzazione. Ciò che l'AI riesce a gestire oggi è il testo — le segnalazioni stesse, spesso digitate in modo informale dall'utente, e la loro ritraduzione in un ticket strutturato.
Il contatto con il cliente è funzionale, non relazionale. Un utente che segnala un guasto vuole soprattutto che venga preso in carico, non che si instauri una conversazione. Questo cambia nel momento in cui qualcosa va storto o diventa delicato — si veda a riguardo anche come una comunicazione di guasto viene trasmessa agli utenti, poiché si tratta di un compito diverso con un profilo diverso.
La componente fisica non gioca alcun ruolo: si tratta di lavoro amministrativo davanti a uno schermo, non di un intervento su apparecchiature. I costi in caso di errore sono medi. Una segnalazione con priorità sbagliata raramente porta a danni diretti, ma per i sistemi soggetti a compliance — un sistema finanziario, una cartella clinica — la situazione è diversa, e l'asse compliance ottiene qui un punteggio superiore alla media. Un guasto in un ambiente con obbligo di segnalazione legale richiede una motivazione documentata per la classificazione, non solo un'etichetta.
Il punto debole è la creatività, ed è proprio per questo che non si tratta di una completa sostituzione. Una segnalazione che non rientra nello schema noto — una nuova combinazione di sintomi, un sistema che si guasta per la prima volta, un utente che descrive il problema in modo poco chiaro — richiede qualcuno che ragioni invece di classificare. A questo si accompagna la supervisione: l'AI propone una categoria e un'urgenza, una persona approva o corregge, con motivazione. Questa è un'impostazione diversa da una sostituzione completa, ed è anche la pratica più diffusa tra le aziende che già lavorano con questo sistema.
In un'azienda con un panorama applicativo piccolo e ben organizzato e qualche centinaio di utenti, novanta parti su cento delle segnalazioni sono una ripetizione di qualcosa già verificatosi cento volte. Lì un modello con un buon sistema di categorizzazione può gestire autonomamente la maggior parte dell'intake, con una persona che vede solo le eccezioni.
In un'azienda con molti sistemi legacy, software su misura e una storia di fusioni, lo schema è meno prevedibile. Le segnalazioni sono più varie, le categorie sono meno nettamente delimitate, e la probabilità che una segnalazione esca dallo schema noto è maggiore. Lì una parte maggiore del lavoro resta a una persona, non perché l'AI non vorrebbe farlo, ma perché l'input è troppo destrutturato per ricavarne automaticamente qualcosa di affidabile.
La condizione determinante non è quindi la tecnologia ma l'intake: moduli di intake strutturati e un modello di categorizzazione degli incidenti ben sviluppato determinano in gran parte quanta parte di questo lavoro sia già trasferibile oggi. Senza questi due elementi, la maggior parte resta lavoro manuale, con l'AI come strumento di supporto anziché come esecutore.
Questo non è un consiglio sul personale né una giustificazione per ridurre un team di help desk. Se e come un'organizzazione trae conseguenze sul personale da un lavoro che cambia, spetta al datore di lavoro, e per questo valgono requisiti legali propri; per la diligenza necessaria in questo ambito si veda i punti di attenzione nell'eliminazione di funzioni. Questa pagina descrive solo ciò che accade al compito in sé.
È inoltre utile non considerare questo compito isolato dal resto dell'operatività IT. La registrazione degli incidenti è collegata a lavori come il monitoraggio delle prestazioni dei sistemi, che spesso fornisce i primi segnali prima che arrivi una segnalazione, e a compiti gestionali come l'esecuzione e il controllo dei backup o il mantenimento aggiornato dei dati anagrafici, che presentano la stessa combinazione di volume elevato e margine di giudizio limitato. Chi vuole sapere, per l'intero reparto IT, dove si trova già lo spostamento, farebbe meglio a guardare tutti i compiti insieme, non un singolo processo di ticketing.
Il risultato per il proprio help desk dipende da quante delle proprie segnalazioni rientrano in schemi riconoscibili e da quanto è già strutturato il proprio intake. Questo varia da azienda ad azienda e non può essere espresso con una regola empirica fissa.
La quickscan gratuita di FTE TO AI offre una prima indicazione a riguardo: dodici domande, senza account, con un'indicazione di quale parte delle ore nel suo profilo sia oggi trasferibile all'AI. La scansione completa del lavoro, che calcola il lavoro di un'intera azienda compito per compito in termini di capacità in fte, è ancora in fase di sviluppo.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.