Un cliente invia un'email per un ordine rotto, poi chiama il giorno dopo, poi apre una chat perché nessuno sembra sapere cosa sia successo e ripetono la stessa storia ogni volta mentre il tuo team di supporto cerca tra inbox, note e strumenti separati. È esattamente questo che risolve la gestione dei casi di Dynamics 365. Immagina un caso come una cartella etichettata in un ufficio affollato dove ogni parte di un problema del cliente finisce in quella cartella dalla prima domanda alla risposta finale. Io sono Milko Peters di M365FM e in questa pilola di conoscenza vedremo come casi, routing, scadenze di risposta, articoli di supporto e chiusura si integrano tra loro. Cosa sia effettivamente un caso in 20 parole? Quindi cos'è esattamente un caso? Un caso, un record per un problema di un cliente che necessita di una risposta o di una soluzione, il problema potrebbe essere un prodotto danneggiato, una domanda di fatturazione, un problema di accesso, una richiesta di assistenza per un servizio.

Ecco il punto, un cliente può avere diversi casi contemporaneamente. Un singolo cliente potrebbe chiedere informazioni su una fattura lunedì, segnalare un dispositivo guasto martedì e aver bisogno di aiuto per cambiare indirizzo venerdì. Sono problemi separati, quindi Dynamics 365 vi mantiene al record di casi distinti invece di accumulare ogni conversazione in un unico thread confuso. Quando un agente crea un caso lo collega direttamente al cliente. Quel cliente può essere un contatto intendendo una persona fisica oppure un account intendendo l'azienda per cui lavora. Quindi se Jamie di Northwind Traders segnala un problema il caso può puntare sia a Jamie che all'azienda e chiunque apre il record può vedere chi ha bisogno di aiuto e a quale organizzazione appartiene il problema. Il caso necessita anche di una chiara descrizione del problema solitamente iniziando con un titolo come la stampante si ferma dopo l'aggiornamento software o cliente ha debitato due volte per il piano annuale e quel titolo aiuta le persone a scansionare un elenco di casi aperti senza aprire ogni record.

Sotto quel titolo l'agente aggiunge i dettagli. Cosa è successo? Quando è iniziato? Cosa ha già provato il cliente? Quale prodotto è coinvolto? E se si tratta di una domanda? Una richiesta? Un guasto? Questi dettagli trasformano un messaggio vago in un lavoro che qualcuno può prendere in carico e risolvere. Analizziamolo più a fondo. Un caso può contenere oggetto, prodotto, priorità e tipo di caso. L'oggetto raggruppa il problema in un'area come fatturazione o supporto tecnico, il prodotto identifica cosa usa il cliente, la priorità, indica al team quanto rapidamente intervenire. Il tipo di caso offre un ulteriore metodo per smistare il lavoro in base al processo di supporto. Nessuno di questi campi risolve da solo il problema dei clienti ma aiutano il team di supporto a visualizzare il lavoro chiaramente, specialmente quando arrivano centinaia di casi da clienti diversi. Un team che gestisce un grave disservizio non dovrebbe dover cercare tra le domande generiche per trovarlo. Ora, un caso non è solo un modulo che qualcuno compila e dimentica. Diventa il registro di lavoro per l'intera conversazione. Le mail possono essere collegate al caso, le telefonate possono apparire lì e un agente può aggiungere note dopo una chat, impostare un'attività di follow up o registrare un appuntamento. Ogni attività rimane legata allo stesso problema del cliente, così la persona successiva non deve ricostruire la storia da zero. Immagina che un agente inizia a lavorare al mattino e poi passi il caso a uno specialista di prodotto dopo pranzo. Senza il registro del caso, lo specialista potrebbe ricevere solo un breve messaggio come, oh, puoi dare un'occhiata a questo? Che non è sufficiente. Con il registro del caso può vedere il problema originale, i dettagli del cliente, cosa è successo durante la chiamata e cosa ha già verificato il primo agente. Questo offre un passaggio di consegne a modulo. Dynamics 365 mantiene il caso in uno stato chiaro mentre avanza nel processo di supporto. Può rimanere attivo mentre il team indaga e, una volta che il team risolve il problema o fornisce la risposta finale, lo chiude. Se la richiesta non richiede più lavoro, magari perché è arrivata per errore o il cliente l'ha ritirata, il team può annullarla.

Attivo, risolto e annullato. Questi tre stati offrono al team una visione condivisa dello stato di ogni problema, così nessuno deve indovinare se un caso necessiti ancora di attenzione e i manager non devono trattare vecchi lavori conclusi come problemi recenti. Un singolo registro ti offre controllo e la cronologia completa del cliente fornisce all'agente il contesto. La storia del cliente di fra il caso. Un caso ti dice cosa deve essere riparato. Il registro del cliente ti dice cosa porta a questo modo. Quando un agente apre un caso in Dynamics 365 Customer Service può guardare oltre l'ultimo messaggio. Vede il quadro generale, i casi precedenti, le mail passate, i prodotti collegati al cliente e la loro cronologia di supporto. Il contesto cambia la conversazione. Perché il contesto è importante? Immagina che un cliente segnale un guasto al dispositivo. Se l'agente vede solo il messaggio di oggi potrebbe iniziare con domande di base. Che modello è? Quando è iniziato? L'ha riavviato? Ma il cliente ha già contattato l'assistenza due volte questa settimana. Il primo agente ha inviato i passaggi per la risoluzione dei problemi e il secondo ha organizzato la sostituzione di un compito. Un terzo agente che vede quello storico non chiederà al cliente di ricominciare da cap. Invece dirà vedo che ha già provato quei passaggi e che il pezzo sostitutivo non ha risolto il problema. Proviamo con qualcos'altro. È molto diverso da un può rispiegarmi il problema? Questo viene spesso chiamato visione a 360 gradi e clic. Il nome sono sofisticato ma è semplice. Significa che l'agente vede il cliente da più angolazioni non solo da un singolo messaggio isolato. L'agente vede la persona, l'azienda, le precedenti richieste di supporto, le conversazioni passate e i prodotti ad essi collegati. Per un team di supporto questo sostituisce le congetture con un chiaro punto di partenza. Ora non tutti i clienti ricevono lo stesso tipo di supporto. Un cliente potrebbe aver acquistato una garanzia, la sua azienda potrebbe pagare per un numero fisso di ore di supporto o potrebbe avere un contratto che consente un certo numero di casi o un supporto premium con assistenza più rapida. Nella Mix 365 tiene traccia di tutto questo tramite i diritti. Un diritto è l'accordo di supporto del cliente all'interno del sistema. Pensatelo come le condizioni di servizio associate al loro account. Prima che un agente prometta l'intervento di un tecnico o inizia un lavoro a pagamento verifica quale supporto è applicabile. Ciò evita spiacevoli sorprese. Ad esempio un cliente potrebbe avere ancora la copertura in garanzia per un prodotto difettore. Caso può seguire quel percorso. Un altro cliente potrebbe aver esaurito tutte le sue ore di supporto. L'agente lo vede prima di impegnarsi in un lavoro fuori contratto. Aiuta anche il team di supporto a trattare i clienti in modo evo. L'agente non deve cercare tra vecchi contratti o chiedere a un altro reparto. Le condizioni di supporto si trovano insieme alle informazioni del cliente proprio dove la gente può trovare. Poi c'è la base di conoscenza. I team di supporto risolvono gli stessi problemi più o più volte. Reimpostazione da password, distruzione di configurazione, un errore noto dopo un aggiornamento, una domanda di fatturazione con una risposta standard. Un articolo del knowledge base archiva quella risposta in no. All'interno dell'area di lavoro del servizio un agente può cercare articoli mentre lavora su un caso. Un articolo può includere una spiegazione semplice dei passaggi, uno screenshot o le verifiche esatte che il team dovrebbe completare.

Invece di far scrivere a ogni agente la propria versione a memoria usano una risposta condivisa che il team ha revisionato. Ciò mantiene il supporto coerente. Aiuta anche gli agenti più recenti. Non servono anni di esperienza per gestire bene i problemi comuni perché le soluzioni note del team sono disponibili quando servono. I riepiloghi dei casi di Copilot aiutano con un altro problema comune, le lunghe cronogie dei casi. Un caso può accumulare molte mail note e aggiornamenti nel tempo. Leggeri tutti richiede tempo specialmente dopo un passaggio di conseglie. Copilot crea un breve riepilogo che raccoglie titolo del caso, cliente, oggetto, prodotto, priorità, tipo di caso, descrizione e attività recente. Un rapid briefing prima che l'agente inizia a lavorare. L'agente controlla comunque il record e usa il proprio giudizio, ma comprende la situazione più velocemente. Questo aiuta quando il cliente è in attesa e il caso è passato attraverso diverse mani. Una volta che l'agente comprende il cliente e il problema, il caso deve arrivare alla persona giusta. Dalla presa in carico alla corretta. Un cliente può chiedere aiuto in molti modi. E-mail, telefonata, chat, social media, portale self-service. Il canale cambia, ma il team di supporto ha comunque bisogno di un unico posto chiaro per gestire la richiesta. Dynamics 365 può creare casi da quelle conversazioni quando la configurazione include regole di creazione record. Pensa a un'email che arriva a un indirizzo di supporto condiviso. Invece di lasciarla in una casella di posta finché qualcuno non la nota, una regola trasforma quell'email in un caso. Il messaggio diventa l'inizio del lavoro all'interno del servizio cliente. Ciò riduce la copia manuale. Stessa idea si applica ad altri canali connessi. Il team sceglie quali messaggi creano un nuovo caso e quali appartengono a un esistente.

Una risposta a un problema aperto rimane con quel problema. Una nuova domanda ottiene il proprio caso. Poi il caso ha bisogno di una collocazione mentre qualcuno se ne suona. Quella collocazione ha spesso una coda. Una coda è un'area di lavoro condivisa per un team. Non è la posta in arrivo di un singolo agente e non appartiene a chi ha visto la richiesta. Invece offre a tutto il team un posto dove vedere il lavoro in attesa di attenzione. Immagina un'azienda con un team di fatturazione, un team di supporto tecnico, un team per i resi. Ogni team ha la propria coda. Le domande di fatturazione vanno alla fatturazione i difetti di prodotto al supporto tecnico, le richieste di reso a chi conosce il processo di reso. Sembra semplice perché lo è. Una classificazione chiara evita alle persone di passarsi il lavoro alla cieca. Le regole di routing aiutano in questa classificazione. Una regola di routing controlla i dettagli di un caso e lo invia alla coda o alla persona giusta. Un caso su uno specifico prodotto va al team di prodotto. Un caso da una certa regione va al supporto locale. Un problema grave va in una coda urgente. Una domanda generale rimane con il team standard. Alcune organizzazioni distribuiscono il lavoro in base alle competenze. Ad esempio un cliente che scrive in francese ha bisogno di un operatore che parli francese. Un problema tecnico richiede qualcuno formato su uno specifico prodotto. L'instradamento avvicina il caso alla persona in grado di risolverlo invece di trattare ogni richiesta allo stesso modo. L'automazione aiuta ma le decisioni spettano ancora le persone.

Un team lead potrebbe esaminare un caso difficile e assegnarlo direttamente all'operatore esperto. Magari qualcuno conosce già il cliente. Forse il problema riguarda diversi prodotti e richiede un'esperienza che una regola non può valutare. L'assegnazione manuale offre al team spazio per quella scelta umana. La titolarità di un caso può cambiare un operatore per aver bisogno di maggiori informazioni e restituire il caso a una coda. Un team potrebbe scoprire che il problema aspetta un altro reparto o una richiesta urgente potrebbe richiedere un'escalation se il team abituano un po' a risolverla. Dynamics 365 mantiene il lavoro in movimento invece di lasciarlo bloccato con qualcuno. A volte un singolo problema genera molti casi. Immagina un'interruzione software che colpisce decine di clienti. Ogni cliente contatta l'assistenza separatamente quindi ogni segnalazione necessita di un proprio ma tutte le segnalazioni sono collegate a un problema più alto. Un caso padre tiene traccia di tale problema mentre i casi figli tracciano le singole segnalazioni dei clienti al suo interno.

Ciò offre al team di supporto due prospettive contemporaneamente. Lavorano l'interruzione sottostante tramite il caso padre mentre ogni caso figlio mantiene informato il cliente corrispondente. Quando trovano una soluzione non devono indagare sulla stessa interruzione da zero per ogni chiamante. Casi duplicati creano un problema simile su scala ridotta. Un cliente potrebbe inviare un'email e chiamare per lo stesso problema oppure due operatori potrebbero aprire casi prima di accorgersi dell'altro. Invece di dividere gli sforzi il team può unire casi simili. Un caso diventa il record principale e il lavoro rimane unificato. Nessuno dovrebbe risolvere lo stesso problema due volte. Far arrivare un caso alla coda, la persona giusta è l'inizio del lavoro e il cliente si aspetta una risposta entro i tempi promessi. Mantenere le promesse con SLA e lavoro guidato. Far arrivare un caso alla persona giusta è solo metà del lavoro perché il cliente si aspetta anche assistenza entro i tempi promessi. Ed è qui che entra in gioco un accordo sul livello del servizio che chiamerò SLA. Uno SLA associa un timer al caso così il team sa esattamente quanto tempo ha per mantenere una promessa che si tratti della prima risposta o della risoluzione completa del problema. Ma qui l'automazione è fondamentale. Non sempre si tratta della stessa scadetta. Prendiamo un cliente che si aspetta il riscontro entro un'ora anche se al team tecnico servono due giorni lavorativi per trovare e testare la soluzione. Dynamics 365 tiene traccia separata dell'obiettivo di prima risposta e di quello di risoluzione così il team può agire rapidamente senza far credere che ogni problema si risolve istantaneamente. Ora immagina un cliente cui servizio ha smesso di funzionare. Non si aspetta una riparazione completa in dieci minuti ma si aspetta che qualcuno confermi che il problema è noto, spieghi cosa succederà e lo tenga informato. L'obiettivo di prima risposta tiene traccia del primo contatto mentre quello di risoluzione segue l'intero percorso verso una risposta a una soluzione e diversi clienti possono avere diverse promesse. Un'azienda con supporto premium ottiene obiettivi di risposta più rapidi rispetto a un cliente con un piano stand. Un'interruzione ad alta priorità ha una scadenza più breve rispetto a una domanda di routine. Gli accordi di supporto, la priorità e il tipo di caso, definiscono le regole temporiapiche. Ciò mantiene le promesse equi e chiare.

Senza SLA un agente potrebbe lavorare sull'elemento più vecchio in lista mentre un caso urgente supera silenziosamente la sua scadenza. Con gli SLA la schermata del caso mostra indicatori temporali che dicono all'agente quale promessa richiede attenzione per primo. Vedrai la pressione aumentare. Un caso con molto tempo ha disposizione necessita di lavoro ma uno vicino alla scadenza di risposta richiede attenzione immediata. I team possono anche impostare avvisi o passaggi di escalation quando un obiettivo è vicino o già superato così un supervisore può intervenire prima che si è cliente a sollecitare. Gli obiettivi temporali guidano l'urgenza e i flussi di processo aziendale guidano il lavoro stesso. Un flusso di processo aziendale ha un insieme di fasi mostrate all'interno del caso. Fornisce all'agente un percorso chiaro da seguire in base a come l'organizzazione vuole che vengano gestiti i casi. Le fasi possono spaziare dall'acquisizione all'indagine fino alla risoluzione con le giuste domande e controlli in ogni punto. Pensalo come una lista di controllo inserita nel processo. Un nuovo agente non deve indovinare quali dettagli siano importanti prima di inviare un caso a uno specialista. Il flusso può richiedere il prodotto, il tipo di problema, l'impatto e altre informazioni necessarie al team successivo. Un agente più esperto può muoversi più velocemente ma il percorso condiviso mantiene comunque il team orientato nella stessa direzione. Ecco uno scenario. Arriva un'interruzione di servizio ad alta priorità. Il caso entra nella coda urgente e il suo SLA inizia il conto alla rovescia.

L'agente conferma i dettagli del cliente, registra l'impatto e invia la prima risposta prima che l'obiettivo scada. Successivamente il flusso di processo sposta il caso nella diagnostica dove il team raccoglie dettagli dell'errore e controlla i report correlati. Il caso passa poi alla risoluzione quando il team identifica la causa e prepara un aggiornamento per il cliente. Quella sequenza offre anche ai manager un quadro più chiaro. Possono vedere dove il caso rallenta durante la presa in carico, la diagnosi o la risposta finale al cliente. Il flusso non risolve il problema per il team ma impedisce che passaggi fondamentali vadano persi durante una giornata intensa. Dynamics 365 può anche controllare quali modifiche di stato gli agenti possono scegliere in vari momenti. Queste sono chiamate transizioni dei motivi di stato che suona tecnico ma l'idea è semplice. Un caso dovrebbe avanzare attraverso passaggi sensati. Non vuoi che qualcuno segni un caso come risolto mentre ancora in attesa di un controllo interno richiesto che passi da nuovo caso direttamente ad annullato senza registrarne il motivo? Le scelte consentite possono cambiare man mano che il caso evolve. Ad esempio un caso sotto indagine può consentire a un agente di metterlo in attesa in attesa dei tagli del cliente. Dopo che il cliente risponde l'agente può riportarlo all'orativo. Quando il problema è risolto il caso può passare a risolto. Ciò crea una cronologia dei casi più buono. Una risposta da sola non concluderà. Il team deve registrare come sia concluso il problema poi chiudere il caso correttamente. Risoluzione apprendimento e servizio migliore. Inviare una risposta non chiude automaticamente un caso. Il team deve registrare la risoluzione che significa scrivere cosa ha risolto il problema o quale risposta finale ha ricevuto il cliente. Potrebbe essere un dispositivo sostitutivo inviato, un pagamento duplicato o rimborsato, il cliente che ha aggiornato l'impostazione che bloccava l'accesso. Quella nota diventa parte della scheda cliente e offre al prossimo agente un utile punto di partenza se lo stesso cliente contatta nuovamente l'assistenza mesi dopo con un problema correlato. A volte la prima soluzione non funziona. Forse il cliente segue le istruzioni e l'errore si ripresenta. Forse arriva un pezzo di ricambio ma non risolve il guasto. In quella situazione il team può riaprire il caso o rimetterlo in coda per ulteriori interventi invece di avviare un nuovo record senza cronologia. Il caso continua da dove il team aveva interrotto. Questo contocambio è responsabile. Un nuovo agente può vedere cosa ha provato il precedente, cosa ha confermato il cliente, cosa deve ancora essere verificato. Il cliente non deve spiegare l'intrastoria dall'inizio solo perché un'altra persona ha preso in carico il lavoro. Nel tempo tutti quei casi dicono al team di supporto cosa sta succedendo al di là del singolo problema del cliente. I manager possono monitorare il tempo di risoluzione che tiene traccia di quanto tempo impiega nei casi dall'apertura alla chiusura.

Possono osservare il tempo di fase che mostra dove i casi trascorrono nel loro tempo. Possono anche monitorare la risoluzione a primo contatto ovvero quanto spesso la prima persona che parla con il cliente riesce a risolvere il problema senza trasferimenti. Anche il carico di lavoro è importante. Se una coda si riempie ogni lunedì mattina il team può vederlo. Se i casi tecnici restano giorni in attesa di un controllo interno quel ritardo appare nei dati dei casi. Se un team chiude i casi rapidamente ma i clienti continuano a riaprirli il team ha motivo di esaminare meglio la qualità di quelle prime soluzioni. I numeri non spiegano tutto da soli. Indicano al team quali domande vale la pena porsi. Perché i casi su un determinato prodotto sono noi? Perché un certo tipo di caso richiede più tempo del previsto? Perché gli agenti cercano ripetutamente la stessa risposta senza trovare un articolo di conoscenza utile? I modelli trasformano il lavoro di assistenza quotidiana in apprendimento. Un aumento di casi simili può indicare un difetto del prodotto. Può mostrare che un recente aggiornamento ha confuso i clienti. Può rivelare che una guida alle istruzioni necessita dei passaggi più chiari. Invece di trattare ogni richiesta come non correlata il team può individuare la causa comune e lavorarci su. Ciò può ridurre il volume futuro dei casi. Anche il feedback dei clienti fa parte di questo quadro. Un caso chiuso può mostrare che il team ha rispettato l'obiettivo di risposta ma il cliente potrebbe comunque sentirsi frustrato se ha dovuto contattare l'assistenza tre volte. Guardare sia la cronologia del caso che il feedback offre ai manager la misione più completa dell'esperienza. Alcuni clienti preferirebbero abitare del tutto di creare un caso.

E' qui che un portale self-service può essere ad aiuto. Tramite un portale i clienti possono creare una richiesta, verificarne lo stato, aggiungere nuove informazioni o leggere articoli di supporto approvati senza chiamare il team di assistenza. Per domande semplici questo può far risparmiare tempo a tutti. Un cliente può controllare lo stato di una consegna, seguire una guida di configurazione quando gli è più comodo. Nel frattempo gli agenti possono dedicare più tempo ai problemi che richiedono una persona per indagare, spiegare o prendere una decisione. Dynamics 365 Customer Service può anche connettersi con strumenti Microsoft familiari durante il processo di gestione dei casi. Un agente può lavorare con le mail tramite Outlook. Un team può discutere di un problema difficile in Teams. Documenti e informazioni condivise possono risiedere in SharePoint. Power BI può trasformare i dati dei casi in report e dashboard, mentre gli strumenti di Power Platform possono supportare moduli aggiuntivi, avvisi o passaggi automatizzati per i processi del team. Ogni strumento ha il suo compito specifico. Il caso rimane il luogo in cui il problema di assistenza e la sua cronologia restano collegati, anche quando si utilizzano altri strumenti per comunicare e condividere file o rivedere il lavoro. La gestione dei casi non riguarda solo la compilazione di una schermata D. Si tratta di dare a ogni problema del cliente un percorso chiaro, una risposta registrata e un team che possa imparare da quanto così. Mantenete unita l'interastore del cliente. Ecco il vero punto fondamentale. La gestione dei casi di Dynamics 365 mantiene il problema, il lavoro, le promesse e il risultato in un unico record. Niente più contesto perso, soluzioni ripetute. Osserva il tuo processo di supporto o dove spariscono le informazioni dei clienti. È qui che riunire tutto cambia ogni cosa. Iscriviti sulla tua piattaforma podcast preferita per altri consigli Microsoft da me Mirko Peters su m365.fm dove spieghiamo in modo semplice gli strumenti Microsoft dietro il lavoro quotidiano.