Sur le papier, les tickets sont propres. Vous avez les chiffres, les files d'attente, les tableaux de bord. Mais en réalité, ce modèle ne mesure la douleur qu'après que le système a déjà échoué. La partie coûteuse du problème commence généralement bien plus tôt. Elle commence lorsqu'un employé perd 10 minutes, puis 20, puis finit par abandonner. Il réessaye. Il demande à un collègue. Il manque la réunion ou partage le mauvais fichier parce que le bon chemin ne fonctionne plus. Et c'est la partie que la plupart des équipes d'assistance ne voient toujours pas. Le meilleur modèle d'assistance interne aujourd'hui ne consiste pas à accélérer le triage. Il s'agit de supprimer complètement le besoin de triage. Imaginez un agent autonome au sein de Microsoft 365 qui surveille le contexte, détecte les frictions à un stade précoce et agit avant même qu'une personne ne pense à ouvrir un portail. Dans cet épisode, je vais vous montrer pourquoi le modèle du service d'assistance est défaillant en ce qu'il remplace réellement et comment vous pouvez le gérer sans créer le chaos.

Si ce changement est important pour votre travail, abonnez-vous à M365FM car à un niveau plus profond, le vrai problème n'est pas la file d'attente, mais le modèle qui la sous-tend. La fin du ticket. L'ancien flux d'assistance est toujours présent. Quelque chose ne va pas. Un utilisateur le remarque. L'utilisateur essaie de l'expliquer. Le service informatique traduit ensuite cette explication en une catégorie, une priorité et éventuellement un groupe d'affectation. Le problème entre dans une file d'attente. Quelqu'un le trie. Quelqu'un d'autre demande plus de détails. Une autre équipe intervient. Le temps continue de s'écouler tandis que le travail réel reste bloqué. Ce processus semble normal car il est familier, mais familier et efficace ne sont pas la même chose. Un ticket n'est pas une assistance. Un ticket est la preuve que l'assistance est arrivée en retard. Au moment où un ticket existe, l'employé a déjà rencontré des difficultés et perdu le contexte.

Il a déjà détourné son attention du travail qu'il essayait de faire. La file d'attente n'est pas le service. La file d'attente est un enregistrement d'échecs. Dans les grands domaines Microsoft 365, le tri manuel devient le véritable point d'étranglement. Cela n'arrive pas parce que les équipes d'assistance sont paresseuses. Cela arrive parce que l'on demande aux humains de faire quelque chose qui ne correspond plus à l'échelle de l'environnement. Vous avez plus d'utilisateurs, plus d'appareils, plus d'applications, plus de politiques. Vous avez davantage de cas limites qui traversent les équipes. SharePoint, Exchange, Intune et Entra en même temps. Le volume ne fait pas qu'augmenter. Les combinaisons augmentent. C'est là que l'ancien modèle tombe en panne. La plupart des équipes réagissent en ajoutant plus de structures. Elle crée un autre portail, un autre botte ou une autre règle de routage.

Mais en réalité, cela ne fait qu'ajouter une couche supplémentaire entre l'employé et la résolution. Le système attend toujours que l'utilisateur remarque le problème, le décrive et demande de l'aide de la bonne manière. Le travail ne commence pas dans un portail d'assistance, il commence dans Teams, il commence dans Outlook, il commence dans un document dont quelqu'un a besoin, immédiatement ou dans une réunion qui commence dans 30 secondes. C'est là que la demande d'assistance commence réellement, et le modèle de ticket est complètement détaché de ce moment, moment. Le coût caché est bien plus élevé que ce que montre votre rapport de fil d'attente. Les personnes contactent à nouveau. Les incidents en double s'accumulent sous différentes étiquettes. Les articles de la base de connaissances deviennent obsolètes. Les analystes passent toute leur journée à trier, à acheminer et à clarifier les choses au lieu de réellement corriger les choses.

Le délai de résolution s'allonge, car chaque transfert ajoute un délai et… Chaque délai supprime le contexte d'origine. Les recherches sur l'IA agentique et les opérations informatiques mettent en évidence le même problème structurel. Moins 80% des efforts sont toujours bloqués dans un travail réactif de type ETL. Ce chiffre est important, car il indique exactement où va le travail. Il ne s'agit pas de résilience ou de prévention, mais de réaction, mais de réaction. Une fois que vous voyez cela, le ticket commence à ressembler moins à un modèle opérationnel qu'à un symptôme. C'est le symptôme d'un système qui ne réagit qu'une fois que les dommages sont visibles. La question suivante n'est donc pas de savoir comment traiter les tickets plus rapidement, mais ce que le système doit faire avant qu'un ticket ne soit nécessaire. Le modèle de l'employé invisible Alors qu'est-ce qui remplace réellement le ticket ?

Ce n'est pas juste un autre chatbot qui se trouve au-dessus du même désordre, et ce n'est certainement pas une porte d'entrée plus jolie, vers la même vieille file d'attente. Le changement va bien plus moins que cela, car l'employé invisible est un travailleur opérationnel qui vit au sein de votre environnement. Microsoft 365 a… Cet agent possède sa propre identité, un périmètre de travail défini, une mémoire de ce qu'il a fait hier, et des règles strictes sur ce qu'il peut et ne peut pas toucher… La distinction est importante. Un chatbot attend que vous saisissiez une invite, mais un employé invisible surveille les changements de conditions. Il part du contexte, au lieu de partir d'une conversation. Comme il peut voir les états de connexion, l'état de santé des appareils, l'état des licences et la manière dont les fichiers sont partagés, il n'a pas besoin d'attendre qu'une friction apparaisse.

Au lieu de demander comment il peut aider après une panne, il pose constamment une question différente en arrière-plan, en arrière-plan. Qu'est-ce qui s'éloigne de l'état dont cet employé a besoin pour faire son travail maintenant ? C'est là que les choses changent. Le modèle est directement intégré au travail lui-même. Lorsqu'une personne rejoint une réunion et que le routage audio échoue, ou qu'un invité ne peut pas ouvrir un fichier qui vient de lui être envoyé, l'ancien monde crée un rapport et un transfert. Dans le nouveau modèle, l'agent voit immédiatement le modèle, vérifie si la condition correspond à un problème connu et prend la prochaine mesure de sécurité pour le résoudre. Peut-être qu'il réinitialise un chemin ou déclenche une vérification de politique, ou peut-être qu'il redirige une demande et lance l'authentification multifacteur avant de documenter la correction. Le principe est simple.

La première réponse ne nécessite plus qu'un humain, vise une description vague et devine ce qui s'est passé. Cela semble invisible lorsque cela fonctionne bien, car il n'y a pas de salle d'attente ni de formulaire. Veuillez sélectionner une catégorie plaignant remplir. Le support apparaît comme un flux rétabli. Employé retourne simplement au travail. Et dans de nombreux cas, il ne voit même pas les machines fonctionner en coulisses. Vous pouvez déjà voir comment cela modifie votre logique de dotation en personnel. L'ancien modèle embauchait des personnes pour absorber le volume, trier les demandes et nettoyer les contextes rompus entre différentes équipes. Le nouveau modèle nécessite moins de personnes pour le tri et plus de personnes pour concevoir des garde-fous, définir les états souhaités et superviser le comportement de ces agents au fil du temps. Les humains restent dans le système, mais la forme globale de leur travail quotidien change.

Les recherches sur l'IA agentique dans le support continuent d'aller dans cette direction. Le support de routine peut évoluer vers une gestion basée sur les exceptions, ce qui génère des gains d'efficacité considérables lorsque l'environnement et les politiques sont bien délimités. Cette dernière partie est essentielle, car ce n'est pas magique. Si vos données sont faibles ou si votre processus est désordonné, l'agent ne deviendra pas intelligent simplement parce que vous avez décidé de le qualifier d'autonome. Tout cela a fait-il pour moi lorsque j'ai arrêté de considérer l'agent comme une fonctionnalité logicielle et que j'ai commencé à le considérer comme un employé non humain avec un mec, un badge ? Un véritable travailleur a besoin d'une entité, d'une description de poste, d'autorisation et d'un responsable à qui rend des comptes. L'agent a besoin exactement de ces mêmes choses car la valeur provient d'une action fiable au sein d'un système et non d'un langage intelligent dans une fenêtre de chat.

L'employé invisible n'est pas une astuce d'interface utilisateur. C'est une nouvelle couche de support qui surveille les frictions au sein du parc Microsoft 365, agit dans le cadre de la politique et attire l'attention humaine sur les exceptions qui nécessitent réellement un jugement. Une fois ce modèle clair, la question suivante devient très pratique. Comment fonctionne réellement la préemption ? L'architecture de la préemption. Alors comment fonctionne réellement la préemption dans Microsoft 365 ? Le passage de la demande et de la réponse au raisonnement et à l'orchestration des événements. Cela semble technique, mais le modèle est simple une fois qu'on l'a décomposé. Tout d'abord, un élément change dans l'environnement, puis le système interprète si ce changement représente un risque ou une dérive. Et enfin, il prend l'action approuvée en utilisant les outils déjà présents dans votre pile.

Commencez par la couche d'événements. Microsoft 365 génère déjà des signaux partout, ce qui signifie qu'en travoie le comportement de connexion, tandis qu'un tune suit la posture et la conformité des appareils. Defender surveille les activités suspectes et Teams vous indique exactement quand une réunion échoue ou que la qualité des appels baisse. SharePoint et Exchange exposent les modèles d'accès et l'activité du contenu, tandis que les signaux d'intégrité du service vous indiquent quand la plateforme elle-même pose problème. Lorsque vous ajoutez des actions utilisateurs à cela, vous obtenez un flux constant de contexte. La plupart des organisations collectent ces signaux, mais très peu les utilisent réellement comme système de support. Les événements bruts seuls ne sont pas utiles, car ils ont besoin d'une couche de raisonnement pour donner un sens au bruit. C'est là que l'employé invisible cesse d'être un théâtre d'automatisation et commence à agir comme un véritable opérateur.

L'agent examine le signal, compare l'état actuel à l'état souhaité et décide de la classe d'action qu'il est sûr de prendre. Un problème audio lors d'une réunion n'est pas la même chose qu'une connexion risquée et un lien de partage rompu est différent d'une incompatibilité de licence. L'agent doit d'abord classer le problème, car agir sans classification ne fait que créer des erreurs plus rapidement. Vient ensuite l'orchestration. Une fois que l'agent a compris le problème, il peut utiliser le mécanisme approprié pour y répondre. Il peut s'agir de Power Automate pour les flux de travail, de Copelo Studio pour la logique ou de Microsoft Graph pour les actions système et le contexte. Les outils sont importants, mais le plus important est la manière dont ils se connectent les uns aux autres. Vous ne créez pas une invite intelligente, mais plutôt une chaîne capable de détecter, de décider, d'agir et de vérifier.

Cette dernière partie est systématiquement négligée. Un système autocorrecteur ne s'arrête pas une fois l'action entreprise. Il exécute une boucle dans laquelle il détecte le problème, teste la condition, applique le correctif et vérifie le résultat avant d'enregistrer ce qui s'est passé. Les recherches sur la logique autocorrectrice montrent clairement que ces systèmes fonctionnent par le biais de modèles de retour d'informations et de corrections, plutôt que par une réponse isolée issue d'un modèle linguistique. Si la première action échoue, le système a besoin d'un moyen d'évaluer la raison, afin de pouvoir réviser l'étape suivante, tout en restant dans les limites définies. Vous pouvez clairement l'imaginer dans quelques cas Microsoft 365, lorsqu'un utilisateur est bloqué parce que sa licence et son étendue de stratégie ne correspondent pas, l'agent détecte l'incompatibilité et vérifie le profil de rôle prévu.

Il applique la correction autorisée, confirme que l'utilisateur a accès et consigne la modification sans que personne ne le lui demande. Si une connexion à risque apparaît dans Antra, l'agent voit l'événement à risque et vérifie immédiatement vos règles d'accès conditionnelles. Il demande une vérification plus poussée ou bloque l'accès en fonction de votre stratégie, puis enregistre le résultat pour qu'un humain puisse l'examiner ultérieurement. Lorsqu'un lien de partage obsolète échoue à plusieurs reprises dans SharePoint, l'agent compare le chemin d'accès actuel aux règles de partage attendues. Il remplace la racine cassée par celle approuvée et envoie le lien, corrigé dans son contexte ce qui boucle la boucle, avant qu'un analyste de bureau n'ait à lire un ticket intitulé « Problème d'accès urgent ». Le support de réunion est un autre excellent exemple. Si un appareil de salle tombe en panne ou si un chemin de jonction est interrompu quelques secondes avant le début d'un appel, l'agent peut détecter la condition et valider la panne.

Il tente une étape de récupération à faible risque et informe l'organisateur dans Teams avec une mise à jour de statut là où le travail se déroule. Cette couche de communication est une partie essentielle de la conception. Le support doit être présent là où l'interruption se produit. Si votre travail se déroule dans Teams, Outlook et l'espace de travail M365, le support, doit également vous répondre là-bas. Vous ne devriez pas avoir à déplacer l'utilisateur ailleurs lorsque vous pouvez répondre à l'événement dans son contexte. Rien de tout cela ne signifie qu'il faut effectuer une opération complète sur chaque tâche car ce serait imprudent. Les actions à faible risque peuvent s'exécuter automatiquement, mais les modifications à fort impact nécessitent toujours l'approbation de perte. Ce chemin d'approbation doit faire partie de l'architecture dès le début plutôt que d'être ajouté ultérieurement.

L'agent doit savoir quand agir, quand demander et quand exactement s'arrêter. Et une fois que vous avez intégré cela au flux, la conversation ne porte plus sur les fonctionnalités d'automatisation. Elle porte sur le contrôle, la gouvernance, la confiance et l'identité de l'agent. Lorsque le support commence à agir de son propre chef, une question difficile se pose immédiatement. Qui fait réellement le travail ? Si cette réponse est vague, tout le modèle s'effondre. Un agent ne peut pas exister dans votre environnement en tant qu'assistant flou avec un accès étendu et son propriétaire clair. Il a besoin d'une véritable identité d'entrée. Il a besoin d'un propriétaire nommé, d'une portée définie et d'un cycle de vie qui commence et se termine pour une raison spécifique. Si cet agent peut lire des données, déclencher des workflows ou envoyer des messages à vos utilisateurs, vous devez le gouverner comme un participant actif du locataire.

Vous ne pouvez pas le traiter comme une fonctionnalité que quelqu'un a activé puis oublié. C'est pourquoi l'identité de l'agent est si essentielle au système. Vous devez savoir exactement qui est l'agent, quel système il peut toucher et qui reçoit la peine lorsque les choses commencent à dériver. Le principe du moindre privilège doit être la base ici. Vous ne pouvez pas vous contenter d'une commodité générale ou vous dire que vous resserrez les autorisations plus tard. Étant donné que le rayon d'action d'un agent de support dépend entièrement de ses autorisations, la conception de ses autorisations est un élément essentiel de la conception du support. Agent 365 sert de couche de contrôle nécessaire dans cette configuration, car il permet de visualiser clairement l'ensemble du parc d'agents. Il fournit le registre, les flux de travail d'approbation et les modèles de politique qui garantissent le bon fonctionnement de l'ensemble.

Bien que ces éléments puissent sembler être des tâches administratives, ils résolvent un problème structurel majeur. La plupart des organisations ne rencontrent pas de difficultés parce qu'elles ne disposent pas de fonctionnalités d'IA, mais parce qu'elles ne peuvent pas voir ou contrôler ce qui est déjà en cours d'exécution dans leur environnement. Les recherches sur ce point sont catégoriques. Seule une petite minorité de grandes entreprises peuvent répertorier entièrement chaque agent actuellement en cours d'exécution dans leur système. Avant que les dirigeants ne commencent à parler de la mise à l'échelle du support autonome, ils doivent répondre à une question beaucoup plus simple. Savons-nous au moins quels agents existent et ce qu'ils font en ce moment ? La supervision doit également être à la hauteur du niveau de risque encouru. Un agent de productivité personnelle travaillant dans une voie étroite est une chose, mais un agent collaboratif touchant du contenu partagé en est une autre.

Vous avez ensuite des agents d'entreprise qui agissent sur des flux de travail sensibles, ce qui relève d'une catégorie de risque différente. C'est pourquoi le modèle de zone de risque, personnel, collaboratif et d'entreprise est si important. Votre modèle de contrôle doit être adapté à l'impact possible. Si vous traitez chaque agent de la même manière, les tâches à faible risque sont noyées dans des approbations lentes, tandis que les tâches à haut risque passent à travers les mailles du filet sans être examinées attentivement. Au minimum, votre pile de contrôle dans Microsoft 365 doit sembler familière à votre équipe. Vous utilisez l'identité dans Intra, les limites de données, via Purview et la surveillance via Defender. Vous appliquez des conditions d'accès via l'accès conditionnel, et vous assurez que l'auditabilité est intégrée dès le départ. Vous devez être en mesure de reconstituer exactement ce qui s'est passé sans avoir à deviner après qu'un incident se soit produit.

La supervision humaine doit être intégrée à la logique plutôt qu'improvisée en période de crise. Les actions à fort impact doivent toujours être interrompues pour une tignature humaine. Le raisonnement doit être consigné sous une forme que les personnes peuvent réellement inspecter et comprendre. Vous devez disposer de chemins de restauration avant que la toute première action autonome ne soit mise en œuvre. Si un agent met à jour l'accès ou modifie une stratégie de routage, quelqu'un doit avoir un moyen de retracer cette décision et de l'annuler proprement. Il existe un autre facteur que les dirigeants oublient souvent parce que les premières démonstrations ont l'air si bonnes. Le coût du remaniement. Si un agent crée des boucles de nettoyage pour votre équipe, les économies prévues disparaissent instantanément. C'est la taxe de reprise. C'est le temps passé à corriger les mauvais résultats, à annuler les mauvaises actions ou à traquer les effets secondaires imprévus.

Si votre équipe gagne 10 minutes sur l'exécution mais en perd 8 à nettoyer le désordre, vous n'avez pas, réellement, automatisé le support. Vous avez simplement déplacé la friction vers une autre partie du processus. La confiance ne vient pas d'une stratégie bien ficelée ou d'une grande annonce de lancement. Elle vient de preuve d'exécution. Les gens ont besoin de voir ce que l'agent a vu, ce qu'il a décidé et ce qui a réellement changé dans le système. C'est ainsi que vous établissez la confiance dans le support autonome. La preuve doit résider dans le comportement de l'outil plutôt que dans l'image de marque du projet. Une fois que cette base de gouvernance est solide, la conversation peut enfin s'éloigner du jargon de la sécurité et entrer dans le langage de la direction. Qu'est-ce que cela change réellement pour les résultats ? Une fois que les dirigeants acceptent le modèle de contrôle, les questions financières commencent à changer.

Dans l'ancien modèle, la valeur du support est mesurée par le travail visible comme les tickets fermés, les appels traités et les performances des SLA. Ces chiffres ont toujours de l'importance, mais ils ne décrivent qu'une réaction à un problème. Elles ne vous indiquent pas le nombre d'interruptions qui n'ont jamais atteint la file d'attente ni le temps de travail des employés qui restaient intacts parce qu'un problème a été résolu prématurément. C'est le problème comptable fondamental. Le support invisible crée de la valeur par l'absence. Voyez la valeur lorsqu'il n'y a pas de tickets, pas d'escalade, et aucun analyste ne passe 20 minutes à reconstituer un problème à partir de notes à moitié terminées. Si vous ne mesurez que l'effort visible de l'équipe de support, vous passez à côté du résultat que vous souhaitiez réellement, vous vouliez un travail stable avec moins d'interruptions. Le volume de tickets est un signal faible lorsqu'il est pris en compte.

Une baisse du nombre de tickets, une baisse de la demande, mais cela peut également signifier que l'environnement s'est amélioré, que la couche de support et de support et de support du support du plus intelligent. Ce sont deux histoires très différentes. Les dirigeants ont besoin d'un ensemble d'indicateurs clés de performance qui puissent faire la différence. Vous devriez commencer par examiner le taux de résolution autonome. Il ne s'agit pas du nombre de conversations que le bot a eu, mais du nombre d'événements de support qui ont été résolus de bout en bout sans qu'un humain n'ait jamais touché. Vous devez également suivre la réduction du délai moyen de résolution. Dans les environnements pilotés par l'IA, les flux des diagnostics intensifs enregistrent souvent des améliorations de l'ordre de 40 à 60%. Vous pouvez ensuite examiner le coût par résolution et la productivité utilisateur que vous avez retrouvé.

Cette dernière mesure est facile à ignorer, car elle ne figure pas clairement dans un rapport de services d'assistance standard. Cependant, c'est souvent là que réside la véritable barre. Une personne bloquée pendant 15 minutes avant même d'ouvrir un ticket a déjà généré un coût pour l'entreprise. Lorsque vous multipliez cela par les interruptions de réunion et les frictions d'accès sur un grand locataire, la perte cachée est bien plus importante que ne suggère la file d'attente. C'est pourquoi le modèle du coût de l'inaction est si important pour l'analyse de rentabilisation. Vous calculez les heures consacrées aux efforts manuels avant même que le support formel ne commence. Ensuite, vous ajoutez le coût des erreurs et du travail répété. Soudain, l'argument en faveur de la préemption cesse de ressembler à une théorie. Vous ne financez pas seulement une couche de support futuriste. Vous supprimez une taxe qui fait partie de votre travail quotidien depuis des années.

Les aspects économiques du cas restreint rendent cela encore plus clair. Les recherches sur le support informatique agentique estiment que la gestion humaine coûte environ 8 ou 75 dollars par problème. En revanche, la gestion agentique étroite peut tomber en dessous de 50 cents par problème une fois le système développé. Cela ne signifie pas que chaque action de support sera aussi bon marché et les dirigeants doivent faire attention aux moyennes générales. La qualité et la gouvernance de la télémétrie affecteront toujours le coût final, mais la direction de la tendance est indubitable. C'est le moment où l'informatique sort de l'ancienne histoire de centre de coût. Ce n'est pas parce que le support disparaît, mais parce que le support se transforme en une couche de fiabilité qui protège le rendement des employés en arrière-plan. L'entreprise considère cela comme un travail plus fluide plutôt qu'un événement de support dramatique.

Vous obtenez moins d'interruptions, une restauration plus rapide et moins de travail gaspillé en routage et en clarification. Cependant, une mauvaise mesure peut facilement fausser les progrès. Si votre télémétrie est faible, l'agent pourrait simplement résumer une défaillance plus rapidement au lieu de la prévenir réellement. Si les retouches ne figurent pas sur le tableau de bord, le retour sur investissement semblera beaucoup plus net qu'il ne l'est en rayon. Si le temps récupéré se retrouve simplement dans des activités à faible valeur ajoutée, les dirigeants surestimeront le gain. L'argumentaire financier doit reposer sur des preuves tangibles telles que la prévention des incidents et la réduction des interventions manuelles. Vous devez mesurer le temps réellement consacré au travail utile. Une fois que vous l'avez correctement mesuré, la fonction de support cesse de ressembler à des frais généraux à réduire.

Elle commence à ressembler à une capacité opérationnelle que l'entreprise récupère enfin. Quels sont les effets sur l'équipe de support ? Pensez à ce que cela signifie réellement pour l'équipe sur le terrain car ce changement ne consiste pas vraiment à réduire les effectifs, mais à changer la manière dont vos employés occupent leur journée. Dans l'ancienne configuration, la majeure partie de votre capacité de support était absorbée par les réinitialisations de mots de passe, le routage des tickets et les boucles de clarification sans fin. Vous aviez des personnes qui couraient après les mises à jour et qui déplaçaient des données entre des systèmes qui n'avaient jamais été conçus pour communiquer entre eux. Aucune de ces tâches ne rend l'environnement plus stable, elles empêchent simplement la file d'attente de déborder. Lorsque les agents prennent en charge ce travail de routine prévisible, l'effort humain passe enfin à un niveau supérieur.

Les ingénieurs de support commencent à consacrer leur temps à définir à quoi ressemble un état sain et à peaufiner la logique sous-jacente aux approbations. Ils se concentrent sur l'amélioration des sources de connaissances, le test du comportement des politiques et la vérification que l'agent reste dans les limites qui lui ont été données. C'est un travail complètement différent de celui consistant à fixer des lignes d'objets toute la journée et à essayer de deviner ce que veut réellement un utilisateur. C'est exactement là que la plupart des déploiements stagnent. Les organisations essaient de conserver leurs anciens processus défaillants et de simplement ajouter un agent en plus tout en espérant un meilleur résultat. Mais le processus reste réactif, les transferts sont toujours désordonnés et les connaissances sous-genres faibles, faibles. L'agent n'est qu'une couche de peinture supplémentaire sur un mur qui s'effrite.

Il peut répondre à une question plus rapidement, mais il ne peut pas réparer un modèle d'assistance qui a été construit autour du retard. La meilleure façon de procéder est de repenser le travail en prime. Vous devez décider quelle tâche reste humaine car elle nécessite du jugement ou une communication sensible. Ensuite, vous décidez quelle tâche passe en flux autonome car le résultat est prévisible et les actions sont sûres. Cette division est essentielle car les équipes d'assistance ne vont pas disparaître. Elles deviennent simplement les personnes qui conçoivent les contrôles et gèrent les exceptions. Cela signifie que la manière dont nous formons les personnes doit également changer. Les équipes doivent apprendre à superviser un système plutôt qu'à simplement exécuter une tâche manuelle. Ils doivent comprendre la logique de restauration, les révisions d'audit et savoir comment tester un agent avant sa mise en service.

Ils doivent également être capables de repérer les défaillances d'un modèle car un mauvais workflow automatisé reste un mauvais workflow workflow. Cela accélère simplement les choses. Si vous recrutez pour cet avenir, vous n'avez probablement pas besoin d'un autre généraliste pour trier les tickets. Vous avez besoin de quelqu'un qui puisse orchestrer les flux dans la pile Microsoft 365 et définir les contrôles qui permettent de contrôler les agents. Vous voulez des personnes capables d'améliorer l'environnement afin que la demande de support diminue réellement au lieu de simplement s'accumuler. Alors comment démarrer cela sans que cela ne se transforme en un projet de transformation massive sur plusieurs années ? La meilleure solution est de choisir un seul flux qui provoque des frictions constantes au sein de votre environnement. Microsoft 365 et la correction des accès est généralement un excellent candidat mais vous pouvez également envisager le support de réunion ou les transferts de conformité des appareils.

Peu importe celui que vous choisissez tant que le modèle se reproduit souvent et que vous savez exactement à quoi devrait ressembler le résultat positif. Une fois que vous avez l'objectif vous devez définir les bases avec une véritable discipline. Vous devez savoir à quoi ressemble une situation saine et quels événements spécifiques vous indiquent que les choses déraillent. Décidez quelles actions peuvent être automatisées en toute sécurité et où exactement l'escalade humaine doit commencer. Avant de mettre quoi que ce soit en ligne assurez-vous d'avoir une base de référence pour le nombre de tickets, les interventions manuelles et la durée pendant laquelle les utilisateurs attendent actuellement une correction. Devez également mettre en place votre gouvernance dès le premier jour. Donnez à l'agent une identité spécifique attribue lui un propriétaire humain et définissez des règles d'approbation claires.

Chaque action entreprise par l'agent doit être consignée. Vous devez également prévoir le moment où cet agent sera mis à la retraite ou réaffecté afin qu'il ne devienne pas une simple automatisation fantôme. Lorsque ce premier flux commence à fonctionner tout votre modèle opérationnel commence à changer. Le support cesse d'agir comme un service d'accueil qui ne fait que réagir au problème. Au lieu de cela il commence à se comporter comme un moteur de fiabilité directement intégré au système. Le support passe d'une réaction visible à une prévention intégrée. Le ticket n'a jamais été le service. C'était la preuve que le service est arrivé trop tard. Choisissez un flux de support ce trimestre et repensez-le pour la préemption plutôt que la réponse. Si vous souhaitez en savoir plus sur M365 au pilote Azure la sécurité et les modèles d'exploitation de l'IA abonnez-vous à M365FM et laissez un avis.

Contactez-moi Mirko Peter sur LinkedIn pour discuter du prochain sujet que vous souhaitez aborder.