Système de tickets Microsoft : les 5 vraies options en 2026

Microsoft propose-t-il un système de tickets ?

Pas en tant que produit que vous pouvez acheter sous ce nom.

Le plus proche est Dynamics 365 Customer Service, que Microsoft positionne avec la phrase « Permettez aux représentants du service de résoudre rapidement les problèmes grâce aux agents IA ». C'est une application de gestion de cas posée sur la pile Dynamics 365 et Power Platform, vendue comme se vend le logiciel d'entreprise : le seul appel à l'action de chaque palier payant est Contactez-nous. La ligne commerciale est assurée du lundi au vendredi, de 6h à 15h, heure du Pacifique.

Ce cadrage compte plus qu'il n'y paraît. Un système de tickets est une file avec un flux de travail. Un cas CRM est un enregistrement rattaché à un client, et les deux se recoupent suffisamment pour que certains acheteurs se retrouvent à chercher un système de tickets CRM au lieu de trancher entre les deux voies. Mais le parcours d'achat et le prix ne se ressemblent en rien, ni l'effort de mise en place, ce qui explique pourquoi tant d'équipes IT finissent par construire quelque chose elles-mêmes.

Encore un changement de vocabulaire à connaître avant de lire une page Microsoft en 2026. Microsoft a renommé les humains. Sur les pages Customer Service, la personne qui répond aux tickets est désormais un « représentant du service » ou « service rep », et le mot « agent » a été réattribué à l'IA. La section dédiée sur la page produit est littéralement intitulée SERVICE AGENTS, décrivant un « service agentique ». Quand une documentation Microsoft dit qu'un agent a traité le cas, cela ne veut pas dire qu'une personne l'a fait.

Les cinq voies, côte à côte

Voici la comparaison honnête avant de passer en revue chacune d'elles. Chaque prix ci-dessous est le tarif catalogue US, par utilisateur et par mois, payé annuellement, tiré des pages tarifaires de Microsoft elles-mêmes au 31 juillet 2026.

Deux choses sautent aux yeux dans ce tableau. Le reporting manque dans le bas de gamme de chaque voie, y compris le propre produit à 50 $ de Microsoft. Et l'ID de ticket, ce qui fait qu'une file est vraiment une file, n'existe correctement qu'à partir de la voie trois. Si l'IA sur la file est la vraie raison de votre comparaison, mon analyse plus large sur l'IA pour les systèmes de tickets vaut la lecture en complément de celle-ci.

Voie 1 : la boîte mail partagée

Presque toutes les files de support Microsoft commencent ici, et pendant un temps, ça fonctionne bien. Une boîte mail partagée dans Outlook ne coûte rien au-delà des licences Microsoft 365 que vous avez déjà. Tout le monde peut la voir, et personne n'a besoin d'apprendre quoi que ce soit de nouveau. Pour les systèmes de tickets des petites équipes qui ne dépassent jamais une poignée d'agents, c'est souvent la réponse complète.

Elle échoue sur un point : aucun ID de ticket, donc aucun état. Vous ne pouvez pas savoir si un e-mail est en cours de traitement. Vous ne pouvez pas savoir si le fil arrivé mardi est le même problème que celui de la semaine dernière. Et deux agents finiront par répondre au même client à une minute d'écart. Chaque solution de contournement que les gens inventent (catégories de couleur, dossier « pris en charge », convention de nommage dans l'objet) est une réimplémentation artisanale d'un champ de statut.

Le seuil est plus bas que ce que les équipes attendent. Dès que plus de deux personnes travaillent sur la même boîte mail, ou dès que quelqu'un demande « combien de temps met-on à répondre ? », la boîte mail a cessé d'être suffisante. J'ai écrit une comparaison plus complète de la boîte partagée contre le système de tickets, plus un regard séparé sur les logiciels de support par e-mail pour les équipes qui veulent garder l'e-mail comme porte d'entrée sans perdre la file.

Le verdict : correct comme point de départ, mais ne construisez pas votre organisation autour. Au moment où vous écrivez des règles sur qui touche quoi, vous l'avez déjà dépassée.

Voie 2 : une liste SharePoint avec Power Automate par-dessus

C'est la construction maison classique, et celle sur laquelle on m'interroge le plus. Une liste SharePoint contient les tickets. Un flux Power Automate détecte les nouveaux éléments et déclenche des notifications, et un onglet Teams affiche la liste. Ça a l'air gratuit parce que vous payez déjà pour les trois, même s'il vaut la peine de vérifier les tarifs SharePoint face à un outil dédié avant de supposer que cela tient à grande échelle.

C'est une option réelle. Elle porte aussi le plafond le plus précisément documenté de toute la pile Microsoft, et presque personne ne vérifie ce plafond avant de construire.

Le mur des 5 000 éléments

Le List View Threshold de SharePoint est de 5 000. Dans les propres termes de Microsoft : « Les opérations qui dépassent cette limite sont bloquées ». La raison est le verrouillage de lignes SQL : au-delà d'environ 5 000 lignes verrouillées, SQL Server trouve plus efficace de verrouiller la table entière, donc Microsoft bloque la requête à la place.

Trois détails qui passent à la trappe dans la plupart des analyses :

• L'avertissement se déclenche à 3 000, pas à 5 000. Vous le verrez sur la page des paramètres de liste bien avant que quoi que ce soit ne casse réellement.
• Le chiffre n'est pas fixe. Microsoft le nuance directement : « Le chiffre réel n'est pas toujours de 5 000, et peut varier selon votre site, le volume d'activité dans la base de données et la configuration de votre site. »
• Vous ne pouvez pas le relever. L'exception de 20 000 éléments pour les auditeurs et administrateurs est une fonctionnalité de SharePoint Server. Dans SharePoint Online, la limite "ne peut pas être modifiée".

La liste elle-même peut contenir 30 millions d'éléments. C'est le chiffre que les gens citent quand ils disent que SharePoint monte en charge sans problème. Mais une file est en réalité une vue sur une liste, et les vues cassent bien avant la liste. Une équipe qui clôture 200 tickets par mois entre dans la zone d'avertissement en 15 mois, et dans la zone de blocage en deux ans.

Le flux qui la fait tourner est sur le pire palier

Power Automate classe chaque compte dans un profil de performance. Une équipe qui construit sur les licences Microsoft 365 qu'elle possède déjà atterrit sur Low, la pire ligne de chaque tableau publié par Microsoft. Sur Low :

• 10 000 requêtes Power Platform par 24 heures, contre 200 000 sur Medium et 500 000 sur High.
• Apply to each plafonne à 5 000 éléments de tableau, contre 100 000 sur tout autre profil. La pagination plafonne aussi à 5 000, ce qui s'ajoute au seuil SharePoint au lieu de l'annuler.
• L'intervalle minimal de récurrence est de 60 secondes, donc un flux « nouveau ticket » en polling a un délai de détection dans le pire cas d'une minute complète avant que quoi que ce soit ne se déclenche.
• Le connecteur SharePoint lui-même limite à 600 appels API par connexion toutes les 60 secondes.

Et le tueur silencieux : selon la documentation des limites de Power Automate de Microsoft, un flux qui reste au-dessus des limites « pendant 14 jours, le système le désactive ». Les flux en erreur sont eux aussi désactivés après 14 jours. Une file dont le routage s'arrête silencieusement deux semaines après un pic de volume, c'est un très mauvais mardi.

Encore un piège de licence se trouve ici. Une simple licence Microsoft 365 porte 6 000 requêtes Power Platform par utilisateur et par 24 heures, pas les 40 000 dont bénéficie un siège Power Platform payant. Chaque appel de connecteur compte comme une requête, de même que chaque action HTTP, et de même que chaque action intégrée, de l'initialisation d'une variable jusqu'à un simple compose. Microsoft le dit clairement dans sa documentation sur les limites de requêtes : « Les actions réussies comme les actions échouées comptent dans ces limites. Les nouvelles tentatives et les requêtes issues de la pagination comptent aussi. »

Le verdict : un bon choix pour une petite file interne avec un volume prévisible et sans plan de croissance. N'y placez pas de file orientée client, et mettez un rappel dans votre calendrier pour le jour où la liste dépassera 3 000 lignes.

Voie 3 : Power Apps sur Dataverse

Si la construction SharePoint est le point de départ des équipes, c'est ici qu'elles montent en gamme quand ça commence à craquer. Une Power App pilotée par modèle sur Dataverse vous donne un vrai modèle de données, de vraies relations, un vrai ID de ticket, et une interface que vous contrôlez.

Le piège, c'est la licence, et Microsoft le formule aussi clairement que possible : « Créer des applications n'est pas facturé, mais leur utilisation nécessite des licences payantes. » Le Power Apps Developer Plan gratuit couvre la construction et les tests sur trois environnements de développeur, avec un plafond de 750 flux d'automatisation par mois. La production est une référence différente.

Le plancher réel est donc de 35 $ par agent et par mois, avec engagement annuel, avant même de répondre à un seul ticket. Dix agents, c'est 350 $ par mois, ou 4 200 $ par an, pour un logiciel qu'il faut malgré tout construire et maintenir soi-même.

Deux notes de bas de page mordent en pratique. D'abord, les allocations Dataverse sont mutualisées au niveau du tenant plutôt que par utilisateur : 250 Mo de base de données et 2 Go de fichiers par siège Premium, donc dix agents mutualisent 2,5 Go de base de données. Un système de tickets avec pièces jointes épuisera le pool de base de données bien avant le pool de fichiers, et l'étendre coûte 40 $ par Go et par mois. Ensuite, les fonctionnalités agentiques de Microsoft dans Power Apps sont "disponibles uniquement dans les applications pilotées par modèle" - si vous construisez votre file en tant qu'application canvas, cette couche est tout simplement absente pour vous.

Le problème de délégation dont personne ne vous prévient

Si vous construisez sur SharePoint plutôt que sur Dataverse, la délégation de Power Apps change silencieusement ce que votre application peut faire. Celle qui piège tout le monde : les champs ID SharePoint ressemblent à des nombres dans Power Apps mais sont du texte en dessous, donc SharePoint ne "prend en charge que l'opération d'égalité ('=')" pour la délégation sur un champ ID. Les opérateurs relationnels ne fonctionnent tout simplement pas. « Montre-moi chaque ticket avec un ID supérieur à 4 000 » n'est pas une requête délégable.

Not ne se délègue jamais. Quatorze champs système ne se délèguent jamais. UpdateIf et RemoveIf ne se délèguent en réalité pas vraiment, ils « fonctionnent localement et simulent la délégation avec une limite de 500/2000 enregistrements ». Chacun est gérable isolément. Réunis, ils expliquent pourquoi les files Microsoft maison ont la réputation d'être rapides le premier jour et lentes au jour 400.

Le verdict : la bonne construction si votre flux de travail est vraiment inhabituel et que vous avez un développeur dans l'équipe. Si vos besoins sont « tickets, statuts, attribution, SLA », vous êtes sur le point de passer des mois à reconstruire un support interne qui existe déjà en produit prêt à l'emploi. Plusieurs supports internes prêts à l'emploi couvrent exactement ce format d'origine, et si le coût des licences est l'objection, il existe un système de tickets open source que vous pourriez auto-héberger. Microsoft lui-même le présente ainsi, en listant la « gestion de support » comme un de ses modèles Power Apps prêts à l'emploi, aux côtés de l'intégration des employés et du suivi des équipements.

Voie 4 : un agent Copilot Studio dans Teams

Celle-ci est davantage une couche de déviation qu'un système de tickets, et cela vaut la peine de la distinguer, car beaucoup de projets « on a construit un système de tickets dans Teams » sont en réalité ceci.

Copilot Studio est la plateforme low-code de Microsoft pour construire des agents. Elle a absorbé Power Virtual Agents, se publie dans Teams, SharePoint et Microsoft 365 Copilot, et atteint plus de 1 400 connecteurs. Microsoft affirme que 90 % du Fortune 500 l'utilise. Sur G2, elle obtient une note de 4,4 sur 5 sur 156 avis.

Pour une file IT de questions répétitives (« comment réinitialiser mon VPN », « où est la politique de notes de frais »), un agent dans Teams qui lit votre SharePoint et Confluence est une bonne utilisation légitime de la pile, et c'est exactement le type de travail que l'IA dans Microsoft Teams fait bien - c'est essentiellement un bot de support IT dans Teams posté devant votre file. Ce que vous n'obtenez pas, c'est une file, un statut, une attribution, ou un rapport sur ce qu'il n'a pas réussi à répondre.

Le modèle de coût est ce qu'il faut comprendre avant de s'engager, et il mérite sa propre section.

Le second compteur : les Copilot Credits

Voici la partie qui surprend ceux qui ont chiffré Microsoft uniquement sur le coût du siège. La licence par utilisateur n'inclut pas l'IA. Sur Customer Service Professional et Enterprise, les quatre agents de service nommés par Microsoft - l'agent de gestion des cas, l'agent de gestion de la connaissance client, l'agent d'intention client et l'agent d'évaluation de la qualité - sont tous marqués « Nécessite des Copilot Credits (vendus séparément) » dans la propre comparaison des plans de Microsoft, ce qui vaut la peine d'être lu en parallèle de tout plan de déviation de tickets que vous construisez autour de cela.

Vous achetez des crédits via Copilot Studio à 200 $ pour 25 000 Copilot Credits par mois, payé annuellement. Cela revient à 0,008 $ par crédit au tarif catalogue, bien que Microsoft n'imprime jamais lui-même un taux par crédit. Les deux plans de crédits portent le même prérequis, imprimé sur chaque carte : « Un abonnement Azure est requis pour utiliser des agents. »

Le chiffre que vous ne pouvez pas obtenir est le chiffre dont vous avez besoin. La propre note de bas de page de Microsoft indique que chaque fois qu'une action ou une réponse est effectuée par un agent, « un nombre variable de Copilot Credits sera facturé selon l'usage précis », selon sa page de tarification Power Automate. Les taux publiés vont de 1 crédit pour une réponse classique jusqu'à 100 pour une réponse générative premium. Ajoutez 10 pour le grounding du graphe du tenant, et un compteur séparé de tokens premium par-dessus quand un modèle de raisonnement est impliqué. Nulle part n'existe un chiffre de crédits par ticket résolu, donc vous pouvez calculer votre coût par lot de crédits mais jamais votre coût par ticket - exactement l'écart qu'un système de tickets avec IA tarifé au ticket est conçu pour combler.

Le palier Premium à 195 $ liste une « capacité incluse » pour ces agents, mais la note de bas de page 6 la qualifie de « capacité de base en Copilot Credit » sans quantité publiée. Le chiffre n'existe que dans le guide de licence téléchargeable.

Rien de tout cela n'est un risque théorique. En juin 2026, un internaute sur r/copilotstudio a décrit exactement ce que fait un compteur imprévisible quand quelque chose boucle :

« J'ai ensuite déployé un agent de dev vers la prod. C'est tout - un seul agent. Aujourd'hui j'ai vérifié mon abonnement Azure et il y a une facture d'environ 47 000 $. »

Woke up to a $47K bill after deploying ONE Copilot Studio agent, Reddit

Le mécanisme est apparu dans les réponses, et c'est la partie qu'il faut intégrer avant d'activer quoi que ce soit :

« Les budgets pour le paiement à l'usage avec les abonnements Azure dans Copilot n'ont qu'un but d'alerte. Il n'y a pas d'arrêt de service strict pour ça… on avait un flux d'agent déclenché par un e-mail entrant qui s'est mis en boucle en s'envoyant des e-mails à sa propre boîte de réception par erreur. »

NikoThe1337, dans le même fil, Reddit

Un budget de paiement à l'usage dans Azure alerte, il n'arrête pas. Un flux déclenché par e-mail qui peut répondre à sa propre boîte de réception est une boucle, et le compteur continue de tourner jusqu'à ce que quelqu'un s'en rende compte.

Je veux être honnête ici. Ce n'est pas de l'incompétence, c'est un vrai problème de modélisation : l'usage varie vraiment, et un tarif fixe par ticket signifie que le fournisseur absorbe la variance au lieu du client. La propre recherche tarifaire d'eesel a néanmoins atterri fermement du côté opposé. Nous avons essayé des unités inventées et les avons abandonnées, parce que « crédit » forçait les clients à faire des calculs - la réaction qu'on entendait sans cesse ressemblait à « attends, qu'est-ce qu'un crédit ? » Les tickets et les sessions de chat sont des unités dans lesquelles les responsables support pensent déjà. Quand la personne qui doit défendre le budget ne peut pas prévoir la facture, le déploiement se bloque dans le processus d'achat, et aucune qualité de modèle ne sauve la situation.

Voie 5 : Dynamics 365 Customer Service

Le vrai produit. Si vous voulez que Microsoft vous vende un véritable système de tickets ITSM plutôt que les pièces détachées, c'est ici.

Ce qu'est réellement un cas

Les cas Dynamics sont plus rigides que la plupart des tickets de support. Les contraintes valent la peine d'être connues avant de concevoir un flux de travail autour d'eux.

• Trois statuts sortent d'usine : Actif, Résolu, Annulé. Actif porte des sous-statuts nommés (En cours, En attente, En attente de détails, En recherche).
• La fusion de cas est plafonnée à 10. Par défaut, vous pouvez fusionner jusqu'à 10 cas à la fois, et le cas fusionné passe à Annulé avec un motif de statut Fusionné.
• La hiérarchie compte exactement deux niveaux. Un cas enfant ne peut pas avoir de cas enfant, et un cas parent ne peut pas être l'enfant d'un autre cas. Si votre modèle d'escalade comporte trois niveaux d'imbrication, ça ne rentre pas.
• La migration des SLA a un plafond. Déplacer plus de 1 000 SLA peut faire échouer la vérification de prémigration, et les conditions de SLA sur des entités liées sont limitées à un niveau.

Aucun de ces points n'est rédhibitoire. Ce sont tous le genre de choses qu'on préfère découvrir la première semaine plutôt que la neuvième, surtout si la gestion des SLA est le point qui compte vraiment pour votre équipe.

Le prix, et la porte qui compte

Le point sensible ici, c'est la porte du reporting. À 50 $ par siège, Professional vous donne la gestion des cas et aucun analytics ni reporting KPI du tout. Pas d'intégration Microsoft Teams non plus, ni de routage unifié. Tout cela commence au siège Enterprise à 105 $, un bond de 110 % pour débloquer la capacité à mesurer votre propre file.

Notez aussi que Premium (195 $) est très proche d'Enterprise (105 $) plus Contact Center (110 $), regroupé avec une remise de 20 $. La voix est alors une troisième facture : la note de bas de page 8 précise que « le prix d'Azure Communication Services est distinct et non inclus », donc le siège à 195 $ achète le logiciel du centre de contact et non les minutes.

Ce que Microsoft peut prouver

Chaque élément de preuve sur la page provient du carrousel client de Microsoft, à lire donc comme publié par le fournisseur plutôt qu'indépendant. Le plus fort : Lenovo avec une réduction de 20 % du temps de traitement, Lexmark avec une augmentation de 23 % de la productivité du centre d'appels, et Hype avec un taux de résolution au premier appel de 90 % accompagné d'une réduction de 70 % de l'intervention des représentants du service. Le propre déploiement interne de Microsoft revendique 50 % d'économie de temps de traitement.

Le positionnement des analystes est réel. Microsoft est Leader dans le Forrester Wave pour les solutions de service client, T1 2026, publié le 11 mars 2026, et Leader dans le Magic Quadrant Gartner 2025 pour le centre d'engagement client CRM, la même catégorie où ServiceNow est en concurrence. Deux choses valent tout de même d'être notées. Le propre commentaire de Microsoft sur son positionnement dans le Wave utilise l'expression « vision équivalente », un langage étonnamment prudent à formuler volontairement sur soi-même. Et l'étude sur l'Impact Économique Total qu'il promeut date de mars 2024, deux ans avant la page sur laquelle elle figure.

Le verdict : la bonne réponse si le support est orienté client, le volume est réel, et que l'entreprise fonctionne déjà sur Dynamics. C'est la mauvaise réponse pour un service IT interne de 12 personnes, où la licence, le partenaire d'implémentation et le cycle de vente coûtent tous ensemble plus que le problème lui-même. Pour cette échelle, un système de tickets interne construit sur un outil plus léger - Jira inclus - vous y mène plus vite.

Calculez ce que cela vous coûterait réellement

Les prix catalogue cachent la forme de la facture, alors entrez vos propres chiffres.

Modifiez le nombre de sièges et les options pour voir comment se classent les quatre voies Microsoft pour votre équipe. Le moment intéressant est le point où la construction maison cesse d'être l'option la moins chère.

Exécutez-le avec dix personnes et la voie du fait-maison ressemble à une victoire facile à 350 $ par mois contre 500 $ pour Dynamics Professional. Exécutez-le avec dix personnes avec de l'IA sur la file et l'écart se réduit à 550 $ contre 700 $, pour un système que quelqu'un de votre équipe doit toujours posséder. Ces 150 $ par mois vous achètent un travail à temps partiel que vous n'aviez pas budgété.

Ce que les gens disent réellement sur le fait de gérer des tickets sur Microsoft

Pour cela, j'ai lu de nombreux fils r/sysadmin et r/msp remontant jusqu'à 2020, y compris pas mal de débats sur la question de savoir si un système de tickets gratuit vaut même la peine d'être essayé avant d'acheter quoi que ce soit. Une expression revient dans presque tous ces fils, et ce n'est pas une comparaison de fonctionnalités.

« Au cours de ma carrière, la phrase 'pourquoi pas ? on a les licences' a été prononcée au moins une fois par quelqu'un occupant un poste commercial senior (ou le chef de projet) pour tous les projets de ma liste des dix pires projets. »

BrainWaveCC, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

C'est le moteur de la décision, et cela vaut la peine de le nommer, car « on paie déjà pour ça » est un argument sur la facture plutôt que sur l'adéquation. Dans le même fil, quelqu'un dont l'entreprise s'était déjà engagée décrit le résultat :

« On vient de démarrer un projet utilisant Dynamics comme remplaçant de notre système de tickets. Jusqu'ici on n'est pas impressionnés. Mais notre DSI a continué quand même parce qu'on avait des licences pour ça. »

admlshake, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

Les fils sur Power Apps se divisent selon une ligne plus nette, et la division porte sur qui le maintient plutôt que sur la question de savoir si ça fonctionne du tout. Les gens qui ont construit leur propre solution rapportent qu'elle fonctionne bien depuis des années :

« J'ai développé un système de tickets avec Power Apps et un peu de Power Automate (anciennement Flow). Toute notre base de données est sur SharePoint Online. C'est en production depuis novembre 2019, ça fonctionne très bien. »

Neiviv2828, Building a ticketing system using the MS Power Platorm?, Reddit

Les gens qui en ont hérité racontent une histoire bien différente :

« Mon prédécesseur l'utilisait pour apprendre la power platform. Super... mais le problème c'est qu'il existe une douzaine de très bons systèmes de tickets, dont la plupart sont gratuits dans une certaine mesure, et qui ne sont vraiment pas chers de toute façon. Donc ce qu'on a récupéré, c'était une bouse pleine de bugs à laquelle il manquait 90 % des fonctionnalités de base qu'on s'attendrait à voir (et dont on avait besoin). Après une semaine à se battre avec, ça a fini à la corbeille. »

canadian_sysadmin, O365 ticketing, Reddit

Les deux témoignages sont vrais en même temps, ce qui est l'intérêt de les lire côte à côte. Une file Power Apps maison est un projet personnel qui se retrouve par hasard critique pour l'activité. Elle fonctionne exactement le temps que son auteur est encore là.

Le dernier thème est l'échelle, et les chiffres avancés par les gens sont plus bas qu'on ne l'imaginerait. Un administrateur système qui avait construit la version liste SharePoint plus Power Automate, notifications et mise en évidence des SLA compris, a conclu son témoignage par une recommandation catégorique contre :

« Je ne le recommanderais pas. 300 employés, c'est suffisant pour justifier d'investir dans un VRAI service desk. »

Ayy4K, O365 ticketing, Reddit

Comment vraiment choisir

En retirant la question des licences, tout se résume à quatre questions.

La file est-elle orientée client ? Si oui, passez les voies un et deux et regardez plutôt un vrai système de tickets basé sur le cloud. Un seuil de vue à 5 000 éléments et un délai de polling de 60 secondes sont des problèmes tolérables en interne, et les clients n'ont pas cette tolérance.

Devez-vous le mesurer ? Si quelqu'un va demander le temps de première réponse, il vous faut le siège Enterprise à 105 $ ou un autre outil. Le palier à 50 $ ne peut pas répondre à cette question, et construire vous-même le reporting sur Power BI ajoute une autre licence. Ce même écart de mesure est la raison pour laquelle la classification des tickets doit venir en premier - vous ne pouvez pas générer un rapport sur une catégorie que vous n'avez jamais étiquetée.

Quelqu'un possède-t-il la construction ? Un système de tickets Power Apps vient avec un mainteneur, qu'il soit nommé ou non. Si la réponse est « notre responsable IT le fera à côté de son travail », le coût réel est plus élevé que la licence.

L'IA est-elle la vraie raison de votre achat ? C'est celle qui est le plus souvent mal cadrée. Les équipes cherchent un nouveau système de tickets quand l'objectif réel est de réduire le nombre de tickets qui atteignent un humain. Migrer de plateforme pour obtenir de l'IA est la façon la plus coûteuse d'acheter de l'IA, et c'est pourquoi mon guide de l'IA pour le support IT plaide pour ajouter des couches plutôt que de changer d'outil dans presque tous les cas. Si votre équipe est déjà profondément ancrée dans Microsoft, le mouvement le plus rapide consiste généralement à automatiser le support Microsoft Teams par-dessus la file que vous avez déjà.

Il faut le dire clairement : rien de tout cela ne fait de Microsoft un mauvais choix. Dynamics 365 est un produit sérieux avec une vraie reconnaissance des analystes, et Power Platform peut réellement construire des choses qu'un support prêt à l'emploi ne peut pas. Le mode d'échec n'est pas de choisir Microsoft. C'est de choisir la voie bon marché de Microsoft pour un problème qui nécessitait la voie coûteuse, puis de découvrir l'écart aux 3 000 éléments de liste. Lisez mon analyse plus large sur le ticketing IT automatisé si vous êtes encore en train de décider quelle voie vous convient.

eesel pour une file de tickets Microsoft

Si la déviation est la raison pour laquelle vous lisez ceci, et non un nouvel outil, vous n'avez probablement pas besoin de changer de plateforme du tout.

eesel est une couche IA qui se branche sur l'outil et la documentation que vous exploitez déjà - votre base de connaissances interne incluse. Elle lit Microsoft Teams, SharePoint, Confluence et vos tickets existants, rédige ou envoie des réponses dans l'outil que votre équipe utilise déjà, et passe en production en quelques minutes au lieu d'un trimestre d'implémentation. Deux choses comptent particulièrement face aux voies Microsoft ci-dessus. Elle facture au ticket, pas au crédit, donc le chiffre que vous présentez aux finances est un chiffre que vous pouvez prévoir. Et chaque déploiement est d'abord simulé sur vos tickets historiques, donc vous voyez ce qu'elle aurait répondu, et avec quelle qualité, avant qu'elle ne touche une file en production. J'ai intégré cela parce que j'ai vu un bot qui a l'air sûr de lui donner silencieusement de mauvaises réponses, et une fois suffit.

Le service IT interne d'une fintech, fonctionnant sur Jira Service Management avec Confluence et Slack derrière, a mis eesel en place comme premier répondant sur sa file de support. La déviation est passée à 15 % en direction d'un objectif de 55 %. Leur responsable IT l'a formulé ainsi :

« On l'utilise pour être le premier répondant de nos tickets de support dans Jira. Il se comporte essentiellement comme le ferait un agent. »

Jason Loyola, Head of IT chez InDebted

C'est le même type de travail qu'un service IT sur pile Microsoft essaie d'accomplir quand il place de l'IA sur un support interne plutôt qu'un agent Copilot Studio, sans les calculs de crédits. Gratuit à essayer, et la mise en place prend à peu près le temps de lire cet article.

Où cela vous laisse

Il n'existe pas de système de tickets Microsoft. Il existe un CRM à 50-195 $ appelé Dynamics 365 Customer Service, et un kit de construction appelé Power Platform. La décision intéressante est de savoir laquelle des deux votre problème mérite réellement.

Les cinq voies sont réelles, et elles sont ordonnées. Boîte mail partagée jusqu'à ce que deux personnes se percutent. SharePoint et Power Automate jusqu'à 3 000 éléments. Power Apps quand le flux de travail est vraiment le vôtre et que quelqu'un le possède. Copilot Studio quand l'objectif est la déviation. Dynamics quand le support est le métier.

La seule chose que je ne ferais pas, c'est acheter le siège en supposant que l'IA est incluse. Sur Professional et Enterprise, elle ne l'est pas. Elle est mesurée dans une unité dont Microsoft ne publie pas le coût par ticket, et elle nécessite un abonnement Azure connecté avant même de fonctionner. Quelle que soit la voie que vous prenez, chiffrez ce compteur avant de signer plutôt qu'après.