Sulla carta il ticketing sembra sempre. Si ottengono numeri, code, dashboard. Ma in realtà quel modello misura solo i problemi dopo che il sistema ha già avuto problemi. La parte costosa del problema solitamente inizia molto prima. Inizia quando un dipendente perde 10 minuti, poi 20 e poi alla fine si arrende. Riprovo. Chiede a un collega, perde la riunione o condivide il file sbagliato perché il percorso corretto ha smesso di funzionare. E' questa la parte che la maggior parte dei team di supporto ancora non vede. Il miglior modello di supporto interno di Erno non riguarda un triage più rapido. Riguarda l'eliminazione completa della necessità di triage. Immagina un agente autonomo all'interno di Microsoft 365 che osserva il contesto, individua tempestivamente gli attriti e agisce prima ancora che una persona pensi di aprire un portale. In questo episodio voglio mostrarti perché il modello di Helpdesk non funziona, cosa lo sostituisce effettivamente e come puoi gestirlo senza creare caos.

Se questo cambiamento è importante per il tuo lavoro, abbonati a M365FM perché ha un livello più profondo. Il vero problema non è la coda ma il modello che la sostiene. La morte del ticket. Il vecchio flusso di supporto è ancora ovunque. Qualcosa si rompe. Un utente se ne accorge. L'utente cerca di spiegarlo. Quindi l'IT traduce quella spiegazione in una categoria, una priorità e forse un gruppo di assegnazione. Il problema entra in una coda. Qualcuno lo smista. Qualcun altro chiede maggiori dettagli. Viene coinvolto un altro team. Il tempo continua a scorrere mentre il lavoro effettivo rimane bloccato. Quel processo sembra normale perché è familiare, ma familiare ed efficace non sono la stessa cosa. Un ticket non è supporto. Un ticket è la prova che il supporto è arrivato in ritardo. Quando un ticket esiste il dipendente ha già incontrato un ostacolo e ha perso il contesto. Ha già spostato la sua attenzione dal lavoro che stava cercando di svolgere.

La coda non è il servizio. La coda è una registrazione di errori. Nelle grandi aziende Microsoft 365 lo smistamento manuale diventa il vero punto di strozzatura. Ciò non accade perché i team di supporto sono un big. Succede perché gli esseri umani viene chiesto di fare qualcosa che non si adatta più alle dimensioni dell'ambiente. Hai più utenti, più dispositivi, più app, più criteri. Hai più casi limite che attraversano Teams, SharePoint, Exchange, Intune ed entra esattamente nello stesso momento. Il volume non aumenta solo. Crescono le combinazioni. È qui che il vecchio modello non funziona. La maggior parte dei team risponde aggiungendo più stupi. Creano un altro portale, un altro bot, un'altra regola di routing. Ma in realtà questo aggiunge solo un ulteriore livello tra il dipendente e la risoluzione. Il sistema è ancora in attesa che l'utente noti il problema, lo descriva e chiede assistenza nel modo giusto.

Il lavoro non inizia in un portale di supporto. Inizia in Teams, inizia in Outlook. Inizia in un documento di cui qualcuno ha bisogno. In quel momento, in una riunione che inizia tra 30 secondi, è lì che inizia effettivamente la richiesta di supporto e il modello di ticketing è completamente separato da quel momento. Il costo nascosto è molto più grande di quanto mostra il report della call. Le persone cambiano contatto. Gli incidenti duplicati si accumulano sotto etichette diverse. Gli articoli della knowledge base diventano. Gli analisti trascorrono un'intera giornata a ordinare, instradare e chiarire invece di risolvere effettivamente le cose. I tempi di risoluzione si allungano perché ogni passaggio di consegna aggiunge un ritardo e ogni ritardo elimina il contesto originale. Le ricerche sull'intelligenza artificiale agentica e sulle operazioni IT indicano strutturale. Almeno l'80% di sforzi è ancora intrappolato in un lavoro reattivo in stile ETIL.

Quel numero è importante perché ti dice esattamente dove sta andando il lavoro. Non sta andando verso la resilienza o la prevenzione, sta andando verso la reazione. Una volta che lo vedi, il ticket inizia ad assomigliare meno a un modello operativo e più a un sintomo. È un sintomo di un sistema che risponde solo dopo che il danno è visibile. Quindi la domanda successiva non è come elaborare i ticket più velocemente, ma cosa dovrebbe fare il sistema prima che un ticket sia necessario? Modello del dipendente invisibile. Quindi cosa sostituisce effettivamente il ticket? Non è solo un altro chatbot seduto in cima allo stesso pasticcio e di certo non è una porta d'ingresso più carina per la stessa vecchia coda. Il cambiamento è molto più profondo di così perché il dipendente invisibile è un lavoratore operativo che vive all'interno del tuo ambiente Microsoft 365. Questa gente ha una propria identità, un ambito di lavoro definito, la memoria di ciò che ha fatto il giorno prima e regole rigide su ciò che può e non può toccare.

Questa distinzione è importante. Chatbot attende che tu digiti un prompt, ma un dipendente invisibile osserva i cambiamenti delle condizioni. Parte dal contesto, anziché da una conversazione. Poiché può vedere gli stati di accesso, l'integrità del dispositivo, lo stato della licenza e il modo in cui vengono condivisi i file, non deve attendere che si verifichino problemi. Invece di chiedere come può essere d'aiuto dopo che qualcosa sia rotto, pone costantemente una domanda diversa in background. Cosa si sta allontanando dallo stato di cui questo dipendente ha bisogno per svolgere il proprio lavoro in questo momento? È qui che le cose cambiano. Il modello è incorporato direttamente nel lavoro stesso. Quando qualcuno si unisce a una riunione, l'estradamento audio non riesce, o un ospite non riesce ad aprire un file che gli è stato appena inviato. Il vecchio mondo crea un report e un passaggio di consegne.

Nel nuovo modello, la gente vede immediatamente lo schema, verifica se la condizione corrisponde a un problema noto ed esegue l'azione sicura successiva per risolverlo. Forse reimposta un percorso, attiva un controllo delle policy, o forse reindirizza una richiesta e richiede l'MFA prima di documentare la curazione. Punto è semplice. La prima risposta non richiede più che un essere umano legga una vaga descrizione e indovini cos'è successo. Questo sembra invisibile quando funziona bene perché non c'è una sala d'attesa, nessun modulo seleziona una categoria da compilare. Il supporto si presenta come un flusso ripristinato. Il dipendente torna semplicemente al lavoro e in molti casi non vede nemmeno i macchinari in funzione dietro le quinte. Puoi già vedere come questo cambia la logica del personale. Vecchio modello assumeva persone per assorbire il volume, smistare le richieste e ripulire i contesti interrotti tra i diversi team.

Il nuovo modello ha bisogno di meno persone che si occupino del triage e di più persone che progettino protezioni definiscono gli stati desiderati e supervisiono il comportamento di questi agenti nel tempo. Gli esseri umani rimangono nel sistema ma l'intera forma del loro lavoro quotidiano cambia. La ricerca sull'intelligenza artificiale agentica nel supporto continua a puntare in questa direzione. Il supporto di routine può spostarsi verso una gestione basata sulle eccezioni che crea enormi guadagni in termini di efficienza quando l'ambiente e le policy sono ben delimitati. Quest'ultima parte è fondamentale perché non si tratta di magia. Se i dati sono deboli e il processo è disordinato l'agente non diventerà intelligente solo perché è deciso di definirlo autonomo. Tutto questo mi è diventato chiaro quando ho smesso di pensare alla gente come ha una funzionalità software e ho iniziato a considerarlo come un dipendente non umano con un badge.

Un vero lavoratore ha bisogno di identità ha una descrizione del lavoro ha autorizzazione e responsabile a cui rispondere. L'agente ha bisogno esattamente delle stesse cose perché il valore deriva da un'azione affidabile all'interno di un sistema non dal linguaggio intelligente in una finestra di chat. Il dipendente invisibile non è un trucco dell'interfaccia utile. È un nuovo livello di supporto che controlla l'attrito nell'ambiente di Microsoft 365 agisce in base alle policy e indirizza l'attenzione umana verso le eccezioni che necessitano effettivamente di giudizio. Una volta chiarito questo modello la domanda successiva diventa molto pronta. Come funziona effettivamente la prelazione? L'architettura della prelazione. Quindi come funziona effettivamente la prelazione all'interno di Microsoft 365? Passaggio passa dalla richiesta risposta al ragionamento e all'orchestrazione degli eventi.

Sembra tecnico ma il modello è semplice una volta analizzato. Innanzitutto qualcosa nell'ambiente cambia quindi il sistema interpreta se tale cambiamento comporta un rischio o una deviazione. Infine esegui l'azione approvata utilizzando gli strumenti già presenti nel tuo stack. Inizia con il livello degli eventi. Microsoft 365 produce già segnali ovunque il che significa che entra e rileva il comportamento di accesso mentre Intune monitora lo stato e la conformità del dispositivo. Defendere il monitor alle attività sospette Teams ti mostra esattamente quando una riunione non riesce o la qualità delle chiamate diminuisce. SharePoint ed Exchange espongono modelli di accesso e contenuti mentre i segnali di integrità del servizio ti indicano quando la piattaforma stessa è il problema. Quando aggiungi le azioni degli utenti a tutto ciò hai un flusso costante di contesto. La maggior parte delle organizzazioni raccoglie tali segnali ma in realtà sono in pochi ad utilizzarli come sistema di supporto.

Gli eventi grezzi da soli non aiutano perché hanno bisogno di un livello di ragionamento per dare un senso rumore. È qui che il dipendente invisibile smette di essere un teatro di automazione e inizia a comportarsi come un vero operatore. L'agente esamina il segnale confronta lo stato corrente con quello desiderato e decide quale classe di azione sicura da intraprendere. Un problema audio durante una riunione non è uguale a un accesso rischioso e un collegamento di condivisione interrotto è diverso da una mancata corrispondenza della licenza. L'agente deve prima classificare il problema perché agire senza classificazione

notta che l'agente ha compreso il problema può utilizzare il meccanismo giusto per rispondere. Potrebbe trattarsi di Power Automate per i flussi di lavoro, Copilot Studio per la logica o Microsoft Graph per le azioni di sistema e il contesto. Gli strumenti sono importanti ma il punto più importante è il modo in cui si collegano tra loro. Non stai creando un prompt intelligente ma piuttosto una catena in grado di rilevare, decidere, agire e verificare. Quest'ultima parte viene sempre trascurata. Un sistema autocorrettivo non si ferma una volta e entra per esalazione. Esegue un ciclo in cui rileva il problema, verifica la condizione, applica la correzione e verifica il risultato prima di registrare che cosa è successo. La ricerca sulla logica autocorrettiva chiarisce che questi sistemi funzionano tramite feedback e modelli di correzione piuttosto che tramite una risposta isolata da un modello linguistico.

Se la prima azione non riesce, il sistema ha bisogno di un modo per valutarne il motivo in modo da poter rivedere il passato successivo restando dentro i limiti definiti. È possibile immaginare chiaramente questo in alcuni casi di Microsoft 365 quando un utente viene bloccato perché la sua licenza e l'ambito dei criteri non corrispondono, l'agente rileva la mancata corrispondenza e verifica il profilo del ruolo previsto.

e registra la modifica senza che nessuno lo chieda. Se in entra viene visualizzato un accesso rischioso l'agente rileva l'evento di rischio e verifica immediatamente le regole di accesso condizionale. Richiede una verifica più approfondita o blocca l'accesso in base ai criteri quindi registra il risultato affinché un essere umano possa esaminarlo in un secondo momento. Quando un collegamento di condivisione obsoleto continua a non funzionare in SharePoint è il percorso di autorizzazione corrente con le regole di condizione previste. Sostituisce la radice danneggiata con quella approvata e invia il collegamento corretto nel contesto il che chiude il ciclo prima che un analista debba leggere un ticket intitolato problema di accesso urgente. Il supporto per le riunioni è un altro ottimo esempio. Se un dispositivo della sala si guasta o un percorso di collegamento si interrompe pochi secondi prima dell'inizio di una chiamata la gente può rilevare la condizione e convalidare la roba.

Prova una fase di ripristino a basso rischio e notifica all'organizzatore in Teams un aggiornamento di stato proprio dove si sta svolgendo il lavoro. Quel livello di comunicazione è una parte fondamentale della progettazione. Il supporto deve risiedere dove si verifica l'interruzione. Se il tuo lavoro si svolge in Teams Outlook nell'area di lavoro e mette rispondere anche lì. Non dovresti trascinare l'utente altrove quando puoi soddisfare l'evento nel contesto. Niente di tutto ciò significa eseguire ogni singola attività perché sarebbe imprudente. Le azioni a basso rischio possono essere eseguite automaticamente ma le modifiche ad alto impatto necessitano comunque dell'approvazione di un'approvazione. Quel percorso di approvazione deve far parte dell'architettura sin dall'inizio anziché essere aggiunto in un secondo momento. La gente deve sapere quando agire quando chiedere ed esattamente quando fermarsi.

E una volta integrato nel flusso la conversazione non riguarda più le funzionalità di automazione diventa una questione di controllo governance fiducia identità dell'agente. Quando l'assistenza inizia ad agire in autonomia sorge immediatamente una domanda difficile. Chi sta effettivamente svolgendolo? Se la risposta è vaga l'intero modello crolla un agente non può esistere nel tuo ambiente come un semplice aiutante vago con ampio accesso e nessun proprietario che ha. Ha bisogno di una vera identità in entra. Ha bisogno di un proprietario denominato un ambito definito o un ciclo di vita che inizia e finisce per un motivo specifico. Se quella gente può leggere dati attivare flussi di lavoro o inviare messaggi agli utenti devi gestirlo come un partecipante attivo nel talent. Non puoi trattarlo come una funzionalità che qualcuno ha attivato o poi dimenticato. Ecco perché l'identità dell'agente è così fondamentale per il sistema.

Devi sapere esattamente cos'è l'agente e quali sistemi può toccare chi riceve la chiamata quando le cose iniziano ad andare verso giusto. Privilegio minimo deve essere la linea di base in questo caso. Non puoi accontentarti di una comodità ampia a dire a te stesso che in seguito rafforzerai le autorizzazioni. Poiché il raggio di azione di un agente di assistenza dipende interamente dalle sue autorizzazioni la progettazione di tali autorizzazioni è una parte fondamentale della progettazione dell'assistente. Agent 365 funge da livello di controllo necessario in questa configurazione perché rende visibile l'intero parco agenti. Fornisce il registro i flussi di lavoro di approvazione e i modelli di policy che garantiscono il funzionamento sicuro delle cose. Sebbene queste parti possano sembrare compiti amministrativi risolvono un enorme problema strutturale. La maggior parte delle organizzazioni non ha difficoltà perché non dispongono di funzionalità di intelligenza artificiale ma perché non riescono a vedere o controllare ciò che è già in esecuzione.

La ricerca su questo punto è schietta. Solo una piccola minoranza di grandi aziende può effettuare un inventario completo di tutti gli agenti attualmente in esecuzione nel loro sistema. Prima che i leader iniziano a parlare di supporto autonomo scalabile devono rispondere a una domanda molto più semplice. Sappiamo quali agenti esistono e cosa stanno facendo in questo momento. Anche la supervisione deve essere all'altezza del livello di rischio. Un agente di produttività personale che lavora in una corsa stretta è una cosa ma un agente collaborativo che tocca contenuti condivisi è un'altra cosa. Poi ci sono agenti aziendali che agiscono su flussi di lavoro sensibili che rientrano in una diversa categoria di rischio. Ecco perché il modello di zona di rischio personale, collaborativo e aziendale è così importante. Il tuo modello di controllo dovrebbe crescere insieme al possibile impatto. Se tratti ogni agente allo stesso modo il lavoro a basso rischio viene seppellito da approvazioni lente mentre il lavoro ad alto rischio sfugge a un controllo debole.

Come minimo il tuo stack di controllo in Microsoft 365 dovrebbe risultare familiare al tuo team. Utilizzi l'identità in entra i limiti dei dati tramite preview e il monitoraggio tramite defender. Applichi le condizioni di accesso tramite l'accesso condizionale e assicuri che la verificabilità sia integrata fin dall'inizio. Devi essere in grado di ricostruire esattamente cosa è successo senza dover fare supposizioni dopo che si è verificato un incidente. La supervisione umana deve essere integrata nella logica anziché essere improvvisata durante una crisi. Le azioni ad alto impatto dovrebbero sempre essere sospese ma umane. Il ragionamento dovrebbe essere registrato in una forma che le persone possano effettivamente ispezionare. Devi disporre di percorsi di rollback prima che venga attivata la prima azione autonoma. Se un agente aggiorna l'accesso o modifica una policy di routing qualcuno deve avere un modo per tracciare tale decisione e annullarla in modo pulito.

C'è un altro fattore che spesso i leader trascurano perché le prime demo sembrano così buone. Costo della rilaborazione. Se un agente crea cicli di pulizia per il tuo team i risparmi previsti scompaiono all'istante. Questa è la tassa di rilaborazione. È il tempo impiegato per correggere risultati errati annullare azioni sbagliate o individuare effetti collaterali indesiderati. Se il tuo team risparmia 10 minuti sull'esecuzione ma ne impiega 8 per ripulire il pasticcio in realtà non hai automatizzato il supporto. È solo spostato l'attrito in una parte diversa del processo. La fiducia non deriva da un policy deck rifinito o da un grande annuncio di lancio. Deriva dalle prove di runtime. Le persone devono vedere cosa ha visto la gente cosa ha deciso e cosa è effettivamente cambiato nel sistema. È così che si crea fiducia nel supporto autonomo. La prova deve risiedere nel comportamento dello strumento piuttosto che nel marchio del progetto.

Una volta che la base di governance è solida la conversazione

per i profitti. Il nuovo ROI del supporto invisibile. Una volta che i leader accettano il modello di controllo le questioni finanziarie a cambiare. Nel vecchio modello il valore dell'assistenza veniva misurato in base al lavoro visibile come i ticket chiusi le chiamate gestite le prestazioni SLA. Questi numeri sono ancora importanti ma descrivono solo una reazione a un problema. Non indicano quante interruzioni non sono mai arrivate in coda o quanto tempo i dipendenti hanno impiegato perché un problema è stato risolto in anticipo. Questo è il problema contabile principale. L'assistenza invisibile crea valore tramite l'assenza. Il valore si vede quando non ci sono ticket nessuna escalation e nessun analista impiega 20 minuti a ricostruire un problema da note incomplete. Se si misura solo lo sforzo visibile del team di assistenza si perde il risultato che si desiderava effettivamente. Si desiderava un lavoro stabile come in interruzione.

Il volume dei ticket è un segnale debole quando è isolato. Un calo dei ticket potrebbe significare un calo della domanda ma potrebbe anche significare che l'ambiente è diventato più sano e il livello di assistenza è più sano. Sono due storie molto diverse. I dirigenti hanno bisogno di un set di KPI in grado di distinguere tra loro. Si dovrebbe iniziare esaminando il tasso di risoluzione autonome. Non si tratta di quante conversazioni ha avuto il bot ma di quanti eventi di supporto sono stati risolti end-to-end senza che un essere umano li toccasse mai. È inoltre necessario monitorare la riduzione del tempo medio di risoluzione. Negli ambienti basati sull'intelligenza artificiale i flussi ad alta intensità di diagnosi spesso registrano miglioramenti nell'intervallo del 40-60. È quindi possibile esaminare il costo per risoluzione e la produttività degli utenti recuperati. Quest'ultima metrica è facile da ignorare perché non si inserisce perfettamente in un report standard del service desk.

Tuttavia è spesso lì che risiede il valore reale. Una persona bloccata per 15 minuti prima ancora di aprire un ticket ha già creato un costo per l'azienda. Quando si moltiplica questo per le interruzioni delle riunioni e l'attrito di accesso in un tenant di grandi dimensioni la perdita nascosta è molto più grande di quanto suggerisca la compagnia. Ecco perché il modello del costo di nazione è così importante per il business case. Si calcolano le ore spese in attività manuali prima ancora che inizi il supporto formale. Quindi si aggiungono il costo degli errori ripetuto. Improvvisamente l'argomentazione a favore della predazione smette di sembrare una teoria. Non stai solo finanziando un futuristico livello di support. Stai eliminando una tassa che è rimasta incastrata nel tuo lavoro quotidiano per anni. L'economia del caso specifico lo rende ancora più chiaro. La ricerca sul supporto IT agentico stima che la gestione umana si aggiri intorno agli 8,75 dollari per problema.

Al contrario la gestione agentica ristretta può scendere sotto i 50 centesimi per problema una volta sviluppato il sistema. Ciò non significa che ogni azione di supporto sarà così economica e i leader dovrebbero fare attenzione alle medie generali. La qualità e la governance della telemetria influiranno sempre sul costo finale ma la direzione della tendenza è inequivocabile. Questo è il momento in cui l'IT esce dalla vecchia storia dei centri di costo. Non perché il supporto scompaia ma perché il supporto si trasforma in un livello di affidabilità che protegge la produttività dei dipendenti in background. L'azienda percepisce questo come un lavoro più fluido piuttosto che come un evento di supporto drammatico. Se ottengono meno interruzioni un ripristino più rapido e meno lavoro sprecato per l'instradamento e la chiarificazione. Tuttavia una misurazione errata può facilmente falsificare i progressi.

Se la telemetria è debole la gente potrebbe semplicemente riassumere un errore più velocemente invece di prevenirlo effettivamente. Se la rilaborazione rimane fuori dalla dashboard il errore sembrerà molto più chiaro di quanto non si è. Se il tempo recuperato torna ad essere impiegato in attività di basso valore i leader esagereranno il guadagno. Il caso finanziario deve basarsi su prove concrete come incidenti prevenuti ai minori interventi manuali. Devi misurare il tempo effettivamente restituito al lavoro utile. Una volta misurato correttamente la funzione di supporto smette di sembrare un sovraccarico da tagliare. Inizia ad assomigliare a una capacità operativa che l'azienda finalmente recupera. Quali conseguenze avrà questo per il team su? Pensa quali conseguenze avrà effettivamente per il team sul campo perché questo cambiamento non riguarda tanto la riduzione del personale quanto il cambiamento di ciò che le persone fanno effettivamente ragionate.

Nella vecchia configurazione la maggior parte della capacità di supporto viene assorbita da reimpostazione di passo all'inseradamento di ticket e infiniti cicli di chiarimento. Hai persone che cercano aggiornamenti e spostano dati tra sistemi che non sono mai stati progettati per comunicare tra loro. Nessuna di queste attività rende l'ambiente più stabile impedisce solo che la coda trabocchi. Quando gli agenti si occupano di quel prevedibile lavoro di routine lo sforzo umano finalmente sale di livello. Gli ingegneri dell'assistenza iniziano a dedicare il loro tempo a definire l'aspetto di uno stato sano e a perfezionare la logica alla base di approvazione. Si concentrano sul miglioramento delle fonti di conoscenza sul test del comportamento delle policy e sulla verifica che l'agente rimanga entro i limiti a sé. Questo è un lavoro completamente diverso dal fissare le righe dell'oggetto tutto il giorno o cercare di indovinare cosa desidera effettivamente un utente.

È esattamente qui che la maggior parte delle distribuzioni si blocca. Le organizzazioni cercano di mantenere i loro vecchi processi non funzionanti e di aggiungere un agente in cima aspettandosi il risultato migliore. Tuttavia il processo è ancora reattivo i passaggi di consegne sono ancora disordinati di racconoscenza di base ancora di più. La gente diventa solo un altro strato di vernice sul muro che sta crollando. Potrebbe rispondere a una domanda più velocemente ma non può riparare un modello di assistenza che è stato costruito solitamente. Il modo migliore è riprogettare prima il lavoro. Devi decidere quali attività rimangono umane perché richiedono giudizio o comunicazioni sensibili. Quindi decidi quale lavoro passa a flussi autonomi perché il risultato è prevedibile e le azioni sono sicure. Questa divisione è fondamentale perché i team di assistenza non scompariranno. Stanno solo diventando le persone che progettano i controlli e gestiscono le eccezioni.

Ciò significa che anche il modo in cui formiamo le persone deve cambiare. I team devono imparare a supervisionare un sistema anziché limitarsi a eseguire un'attività manuale. Devono comprendere la logica di rollback, le revisioni di audit e come testare un agente prima che venga attivato. Devono inoltre essere in grado di individuare quando un modello non funziona perché un flusso di lavoro automatizzato non corretto è comunque un flusso non corretto. Semplicemente interrompere cose più o più. Se stai assumendo personale per questo futuro probabilmente non hai bisogno di un altro generalista per il Tretic. Hai bisogno di qualcuno in grado di riorchestrare i flussi nello stack di Microsoft 365 e definire i controlli che tengono sotto controllo gli agenti. Puoi persone in grado di migliorare l'ambiente in modo che la richiesta di supporto diminuisca effettivamente anziché aumentare. Quindi come puoi iniziare effettivamente senza che si trasformi in un enorme progetto di trasformazione plurina?

La mossa migliore è scegliere un singolo flusso che cause attriti costanti all'interno del tuo ambiente Microsoft 365. La correzione degli accessi è solitamente un ottimo candidato ma potreste anche prendere in considerazione il supporto per le riunioni trasferi in supporto per le riunioni trasferimenti di conformità dei dispositivi. Non importa quale scegli è importante che lo schema si verifichi spesso e che tu sappia esattamente come dovrebbe essere il risultato positivo. Una volta stabilito l'obiettivo devi definire le basi con vera disciplina. Devi sapere cosa significa essere sani e quali eventi specifici ti indicano che le cose stanno andando fuori controllo. Decidi quali azioni assicuro a automatizzare e da dove esattamente devi iniziare l'escalation umana. Prima di avviare qualsiasi attività assicurati di avere una linea di base per il numero di ticket e gli interventi manuali e per quanto tempo gli utenti stanno aspettando una correzione.

Devi anche mettere in atto la tua governance in del primo giorno. Assegna all'agente l'identità specifica assegnagli un responsabile umano e stabilisci chiare regole di approvazione. Ogni singola azione intrapresa dall'agente deve essere registrata. Dovresti anche avere un piano per quando quell'agente verrà dismesso o riassegnato in modo che non diventi solo un'automazione fantasma. Quando quel primo flusso inizia a funzionare l'intero modello operativo inizia a cambiare. L'assistenza smette di comportarsi come una reception che reagisce solo ai problemi. Invece inizia a comportarsi come un motore di affidabilità integrato direttamente nel sistema. Il supporto sta passando da una reazione visibile a una prevenzione integrata. Il ticket non è mai stato servizi. Era la prova che il servizio si è presentato troppo tardi. Scegli un flusso di supporto questo trimestre e riprogettalo per la prelazione anziché per la risposta.

Se vuoi saperne di più su M365 Copilot Azure Sicurezza e Modelli Operativi di Intelligenza Artificiale iscriviti a M3 Recensione e lascia una recensione. Connettiti con me Mirko Peter su LinkedIn per il prossimo argomento che vuoi approfondire.