Il ticket risolto in un minuto

Narratore: Le voci di questo episodio sono generate sinteticamente. È lunedì mattina. Il Junior prende in carico un ticket del cliente: l’accesso al servizio continua a fallire. Nel sistema, però, il tempo massimo di presa in carico è quasi scaduto.

Junior Developer: Ho preso il ticket. Il cliente segnala che l’accesso al servizio continua a fallire. Gli ho chiesto qualche dettaglio in più, perché senza capire in quale punto si blocca non so da dove iniziare. La risposta è partita e il ticket è già cambiato stato. Mi dice che la pratica è chiusa. Aspetta: io ho fatto una domanda, non ho risolto il problema. Nel report risulta chiuso perché ho risposto? Se il cliente non riesce ancora ad accedere, che cosa stiamo misurando esattamente? Capisco che il tempo di presa in carico fosse quasi scaduto, ma la presa in carico e la soluzione non sono la stessa cosa.

Senior Developer: Il sistema misura il tempo della prima risposta. Da anni rispondiamo subito con una formula cortese, poi riapriamo il caso quando arriva il tempo di indagare. È una procedura. Non è la procedura che avremmo disegnato, ma ormai ha una sua procedura, il che è un progresso rispetto a quando la facevamo a memoria.

Junior Developer: Quindi il ticket è chiuso perché abbiamo risposto, e lo riapriamo quando possiamo lavorarci. Ma il cliente vede la stessa chiusura che vede il report? Perché, se legge che il caso è risolto, potrebbe pensare che l’accesso funzioni. E invece noi stiamo ancora cercando di capire perché fallisce.

Senior Developer: Sì. La prima risposta fa scattare il criterio dell’SLA. La soluzione richiede di indagare, e quella parte non rientra in quel numero. Il messaggio automatico, invece, usa la parola “risolto”. Sono due cose diverse, ma il sistema le fa comparire una dopo l’altra come se fossero la stessa cosa. Poi riapriamo il ticket e continuiamo.

Narratore: Entra il Product Owner. Ha ricevuto dal cliente una richiesta di aggiornamento: nel report interno il ticket è chiuso, ma il problema è ancora presente.

Product Owner: Il cliente vuole sapere a che punto siamo. Il report dice chiuso, ma ci ha scritto che continua a non accedere. Devo dargli un aggiornamento comprensibile e una data, senza trasformare questo caso in un nuovo progetto. Prima però devo capire: abbiamo una soluzione in corso o abbiamo soltanto rispettato il tempo della prima risposta?

Senior Developer: Per ora abbiamo chiesto dettagli. La presa in carico è tempestiva; la soluzione non c’è ancora. Per indagare dobbiamo prima capire in quale punto fallisce l’accesso. Se mandiamo una data prima di sapere che cosa stiamo cercando, la data diventa un altro problema da aggiornare.

Product Owner: Va bene, allora aggiorno il cliente sullo stato reale. Però il messaggio che ha ricevuto dice che il problema è stato risolto. Non posso chiedergli di ignorare quella frase mentre gli spiego che stiamo ancora indagando. Possiamo almeno distinguere chiaramente la presa in carico dalla soluzione?

Narratore: Entra il Commerciale. Vuole rassicurare il cliente e ha già guardato il messaggio automatico.

Commerciale: Possiamo presentare il dato come presa in carico tempestiva. È vero: abbiamo risposto subito. Non direi che questo dimostra che il problema è stato risolto, perché non è quello che è successo. Però il messaggio automatico dice proprio che è stato risolto. Quindi rassicuriamo il cliente sul fatto che lo stiamo seguendo e, intanto, allineiamo quello che comunichiamo con quello che il sistema gli ha già scritto.

Product Owner: Allora l’aggiornamento deve dire due cose diverse: abbiamo preso in carico la segnalazione e stiamo ancora indagando. Non posso dare una data per la soluzione se non sappiamo ancora quale sia. Almeno il cliente riceve un’informazione che corrisponde allo stato del problema, anche se il report continua a chiamarlo chiuso.

Commerciale: Sì, lo rassicuriamo senza promettere una data che non abbiamo. La presa in carico è avvenuta; la soluzione resta da verificare. Lo dirò in questi termini. Mi resta solo da capire come spiegare che, nello stesso momento, il sistema gli ha già comunicato che il problema è risolto.

Junior Developer: Se gli scriviamo anche che il messaggio automatico non descrive lo stato reale, almeno non gli chiediamo di fidarsi di due versioni opposte. Possiamo dire chiaramente che l’accesso non è ancora ripristinato e che stiamo indagando, senza far passare la risposta iniziale per una soluzione.

Product Owner: Sì. Nel prossimo aggiornamento non userò «chiuso» come sinonimo di «risolto». La segnalazione è stata presa in carico; il problema resta da verificare. È una distinzione piccola nel testo, ma è quella che il cliente ci sta chiedendo.

Senior Developer: Per adesso riapriamo il caso quando arriva il tempo di indagare. È quello che facciamo da anni. Il numero della prima risposta resta corretto, e il problema resta da risolvere. Se cambiamo il testo automatico, almeno le parole smettono di dichiarare concluso un lavoro che non è concluso.

Narratore: Tre giorni dopo, il ticket è stato riaperto e il problema è stato corretto. Nel report mensile risultano una chiusura rapida, una riapertura e un nuovo ticket collegato. L’SLA è verde.