Microsoft-Ticketsystem: die 5 echten Optionen 2026

Hat Microsoft ein Ticketsystem?

Nicht als Produkt, das du unter diesem Namen kaufen kannst.

Das nächstgelegene ist Dynamics 365 Customer Service, das Microsoft mit der Zeile "Service-Mitarbeiter befähigen, Probleme mit KI-Agenten schnell zu lösen" positioniert. Es ist eine Fallverwaltungsanwendung, die auf dem Dynamics-365- und Power-Platform-Stack sitzt, verkauft so, wie Enterprise-Software verkauft wird: Der einzige Call-to-Action jeder bezahlten Stufe ist Kontaktiere uns. Die Vertriebsleitung ist Montag bis Freitag von 6 bis 15 Uhr Pacific Time besetzt.

Diese Einordnung ist wichtiger, als sie klingt. Ein Ticketsystem ist eine Warteschlange mit einem Workflow. Ein CRM-Fall ist ein Datensatz, der an einen Kunden gebunden ist, und die beiden überlappen sich genug, dass manche Käufer nach einem CRM-Ticketsystem suchen, statt sich für eine Spur zu entscheiden. Aber die Kaufmotion und der Preis sind überhaupt nicht vergleichbar, ebenso wenig der Einrichtungsaufwand, weshalb so viele IT-Teams am Ende etwas selbst bauen.

Noch eine Umbenennung, die man kennen sollte, bevor man 2026 irgendeine Microsoft-Seite liest. Microsoft hat die Menschen umbenannt. Auf den Customer-Service-Seiten heißt die Person, die Tickets beantwortet, jetzt "Service-Mitarbeiter" oder "Service-Rep", und das Wort "Agent" ist jetzt der KI zugeordnet. Der eigene Abschnitt auf der Produktseite ist buchstäblich mit SERVICE-AGENTEN überschrieben und beschreibt "agentischen Service". Wenn eine Microsoft-Doku sagt, ein Agent habe den Fall bearbeitet, ist damit keine Person gemeint.

Die fünf Wege im Vergleich

Hier ist der ehrliche Vergleich, bevor ich jeden einzeln durchgehe. Jeder Preis unten ist der US-Listenpreis, pro Nutzer und Monat, bei jährlicher Zahlung, entnommen aus Microsofts eigenen Preisseiten am 31. Juli 2026.

Zwei Dinge fallen an dieser Tabelle auf. Reporting fehlt am günstigen Ende jedes Wegs, auch bei Microsofts eigenem 50-$-Produkt. Und die Ticket-ID, das, was eine Warteschlange erst zu einer Warteschlange macht, existiert erst richtig ab Weg drei. Wenn KI auf der Warteschlange der eigentliche Grund für deinen Vergleich ist, lohnt sich mein breiterer Blick auf KI für Ticketsysteme ergänzend zu diesem hier.

Weg 1: das geteilte Postfach

Fast jede Microsoft-Support-Warteschlange beginnt hier, und eine Weile funktioniert das gut. Ein geteiltes Postfach in Outlook kostet nichts über die Microsoft-365-Lizenzen hinaus, die du bereits hast. Jeder kann es sehen, und niemand muss etwas Neues lernen. Für Ticketsysteme kleiner Teams, die nie über eine Handvoll Agenten hinauswachsen, ist es oft die vollständige Antwort.

Es scheitert an einer Sache: keine Ticket-ID, also kein Status. Du kannst nicht sagen, ob eine E-Mail bereits bearbeitet wird. Du kannst nicht sagen, ob der Thread, der am Dienstag ankam, dasselbe Problem ist wie der von letzter Woche. Und irgendwann antworten zwei Agenten innerhalb einer Minute demselben Kunden. Jeder Workaround, den Teams erfinden (Farbkategorien, ein "erledigt"-Ordner, eine Namenskonvention in der Betreffzeile), ist eine selbstgebaute Nachbildung eines Statusfelds.

Die Schwelle liegt niedriger, als Teams erwarten. Sobald mehr als zwei Personen dasselbe Postfach bearbeiten, oder sobald jemand fragt "wie lange dauert unsere Antwortzeit?", hat das Postfach aufgehört zu genügen. Ich habe einen ausführlicheren Vergleich zwischen geteiltem Postfach und Ticketsystem geschrieben, plus einen separaten Blick auf E-Mail-Helpdesk-Software für Teams, die E-Mail als Eingangstür behalten wollen, ohne die Warteschlange zu verlieren.

Das Fazit: in Ordnung als Startpunkt, aber baue nicht darauf auf. In dem Moment, in dem du Regeln aufschreibst, wer was bearbeitet, hast du es bereits überwachsen.

Weg 2: eine SharePoint-Liste mit Power Automate darauf

Das ist der klassische Selbstbau, und der, nach dem ich am häufigsten gefragt werde. Eine SharePoint-Liste hält die Tickets. Ein Power-Automate-Flow fängt neue Elemente ab und löst Benachrichtigungen aus, und ein Teams-Tab zeigt die Liste an. Es wirkt kostenlos, weil du für alle drei bereits bezahlst, wobei sich ein Blick auf die SharePoint-Preise im Vergleich zu einem dedizierten Desk lohnt, bevor du annimmst, dass das im großen Maßstab so bleibt.

Es ist eine echte Option. Sie trägt aber auch die am präzisesten dokumentierte Obergrenze im gesamten Microsoft-Stack, und fast niemand prüft diese Obergrenze, bevor er baut.

Die 5.000-Elemente-Wand

SharePoints List View Threshold liegt bei 5.000. In Microsofts eigenen Worten: "Vorgänge, die dieses Limit überschreiten, werden blockiert." Der Grund ist SQL-Row-Locking: Ab etwa 5.000 gesperrten Zeilen findet SQL Server es effizienter, die gesamte Tabelle zu sperren, weshalb Microsoft die Abfrage stattdessen blockiert.

Drei Details, die in den meisten Beiträgen untergehen:

• Die Warnung erscheint schon bei 3.000, nicht bei 5.000. Du siehst sie auf der Seite Listeneinstellungen, lange bevor tatsächlich etwas kaputtgeht.
• Die Zahl ist nicht fix. Microsoft relativiert das direkt: "Die tatsächliche Zahl ist nicht immer 5.000 und kann je nach deiner Website, der Aktivität in der Datenbank und der Konfiguration deiner Website variieren."
• Du kannst sie nicht anheben. Die 20.000-Elemente-Ausnahme für Prüfer und Administratoren ist eine SharePoint-Server-Funktion. In SharePoint Online kann das Limit "nicht geändert werden".

Die Liste selbst fasst 30 Millionen Elemente. Das ist die Zahl, die Leute zitieren, wenn sie sagen, SharePoint skaliere problemlos. Aber eine Warteschlange ist eigentlich eine Ansicht über eine Liste, und Ansichten brechen lange, bevor die Liste es tut. Ein Team, das 200 Tickets im Monat schließt, ist innerhalb von 15 Monaten im Warnbereich und innerhalb von zwei Jahren im Blockbereich.

Der Flow, der es betreibt, läuft auf der schlechtesten Stufe

Power Automate sortiert jedes Konto in ein Leistungsprofil. Ein Team, das auf den Microsoft-365-Lizenzen aufbaut, die es bereits besitzt, landet auf Low, der schlechtesten Zeile in jeder Tabelle, die Microsoft veröffentlicht. Auf Low:

• 10.000 Power-Platform-Anfragen pro 24 Stunden, gegenüber 200.000 auf Medium und 500.000 auf High.
• Apply to each deckelt bei 5.000 Array-Elementen, gegenüber 100.000 bei jedem anderen Profil. Die Paginierung deckelt ebenfalls bei 5.000, sodass sich das mit der SharePoint-Schwelle summiert, statt sie aufzuheben.
• Das minimale Wiederholungsintervall liegt bei 60 Sekunden, sodass ein pollender "neues Ticket"-Flow im schlechtesten Fall eine volle Minute Erkennungsverzögerung hat, bevor überhaupt etwas ausgelöst wird.
• Der SharePoint-Connector selbst throttelt bei 600 API-Aufrufen pro Verbindung und 60 Sekunden.

Und der stille Killer: Laut Microsofts Power-Automate-Limits-Dokumentation "schaltet das System einen Flow aus", der die Limits 14 Tage lang überschreitet. Flows mit Fehlern werden ebenfalls nach 14 Tagen abgeschaltet. Eine Warteschlange, deren Routing zwei Wochen nach einem Volumenspitzenwert einfach still stehenbleibt, ist ein sehr schlechter Dienstag.

Noch eine Lizenzfalle sitzt hier. Eine einfache Microsoft-365-Lizenz trägt 6.000 Power-Platform-Anfragen pro Nutzer und 24 Stunden, nicht die 40.000, die ein bezahlter Power-Platform-Sitzplatz erhält. Jeder Connector-Aufruf zählt als eine Anfrage, ebenso jede HTTP-Aktion, und ebenso jede integrierte Aktion, von der Initialisierung einer Variable bis zu einem einfachen Compose. Microsoft sagt es klar in seiner Dokumentation zu Anfragelimits: "Sowohl erfolgreiche als auch fehlgeschlagene Aktionen zählen zu diesen Limits. Wiederholungen und Anfragen aus der Paginierung zählen ebenfalls."

Das Fazit: eine gute Wahl für eine kleine interne Warteschlange mit vorhersagbarem Volumen und ohne Wachstumsplan. Setz keine kundenseitige Warteschlange darauf, und stell dir eine Erinnerung für den Tag, an dem die Liste 3.000 Zeilen überschreitet.

Weg 3: Power Apps auf Dataverse

Wenn der SharePoint-Bau der Startpunkt ist, ist das die Eskalationsstufe, wenn er zu knirschen anfängt. Eine modellgesteuerte Power App auf Dataverse gibt dir ein echtes Datenmodell, echte Beziehungen, eine echte Ticket-ID und eine UI, die du selbst steuerst.

Der Haken ist die Lizenzierung, und Microsoft formuliert es so klar wie möglich: "Das Erstellen von Apps ist nicht kostenpflichtig, die Nutzung erfordert jedoch bezahlte Lizenzen." Der kostenlose Power Apps Developer Plan deckt das Erstellen und Testen über drei Entwicklerumgebungen ab, mit einer Obergrenze von 750 Automatisierungsflows im Monat. Produktion ist eine andere SKU.

Der echte Boden liegt also bei 35 $ pro Agent und Monat, bei jährlicher Bindung, bevor auch nur ein Ticket beantwortet ist. Zehn Agenten sind 350 $ im Monat oder 4.200 $ im Jahr, für Software, die du immer noch selbst bauen und pflegen musst.

Zwei Fußnoten schlagen in der Praxis zurück. Erstens werden die Dataverse-Berechtigungen auf Mandantenebene gepoolt statt pro Nutzer: 250 MB Datenbank und 2 GB Datei pro Premium-Sitzplatz, sodass zehn Agenten sich 2,5 GB Datenbank teilen. Ein Ticketsystem mit Anhängen erschöpft den Datenbankpool lange vor dem Dateipool, und ihn zu erweitern kostet 40 $ pro GB im Monat. Zweitens sind Microsofts agentische Funktionen in Power Apps "nur in modellgesteuerten Apps verfügbar" - baust du deine Warteschlange als Canvas-App, ist diese Ebene für dich einfach nicht vorhanden.

Das Delegationsproblem, vor dem niemand warnt

Wenn du auf SharePoint statt auf Dataverse baust, verändert die Power-Apps-Delegation still, was deine App leisten kann. Das, das jeden erwischt: SharePoint-ID-Felder sehen in Power Apps wie Zahlen aus, sind aber darunter Text, weshalb SharePoint für die Delegation bei einem ID-Feld nur die "Gleich ('=')-Operation unterstützt". Relationale Operatoren funktionieren einfach nicht. "Zeig mir jedes Ticket mit einer ID über 4.000" ist keine delegierbare Abfrage.

Not delegiert nie. Vierzehn Systemfelder delegieren nie. UpdateIf und RemoveIf delegieren praktisch überhaupt nicht, sie "funktionieren lokal und simulieren die Delegation bis zu einem Limit von 500/2000 Datensätzen." Jedes davon ist für sich allein überlebbar. Zusammen sind sie der Grund, warum selbstgebaute Microsoft-Warteschlangen dafür bekannt sind, am ersten Tag schnell und am 400. Tag langsam zu sein.

Das Fazit: der richtige Bau, wenn dein Workflow wirklich ungewöhnlich ist und du eine Fachperson im Team hast. Wenn deine Anforderungen "Tickets, Statusse, Zuweisung, SLAs" sind, bist du kurz davor, monatelang einen internen Helpdesk nachzubauen, der bereits als fertiges Produkt existiert. Etliche fertige interne Desks decken genau diese Form von Haus aus ab, und wenn Lizenzkosten der Einwand sind, gibt es ein Open-Source-Ticketsystem, das du selbst hosten könntest. Microsoft selbst rahmt es so, indem es "Helpdesk-Verwaltung" als eine seiner sofort einsatzbereiten Power-Apps-Vorlagen listet, neben Mitarbeiter-Onboarding und Anlagen-Checkout.

Weg 4: ein Copilot-Studio-Agent in Teams

Das hier ist eher eine Deflection-Ebene als ein Ticketsystem, und es lohnt sich, es gesondert zu betrachten, denn viele "wir haben ein Ticketsystem in Teams gebaut"-Projekte sind eigentlich genau das.

Copilot Studio ist Microsofts Low-Code-Plattform zum Bauen von Agenten. Es hat Power Virtual Agents absorbiert, veröffentlicht in Teams, SharePoint und Microsoft 365 Copilot, und erreicht über mehr als 1.400 Connectors. Microsoft behauptet, 90 % der Fortune 500 nutzten es. Auf G2 bewertet man es mit 4,4 von 5 über 156 Bewertungen.

Für eine IT-Warteschlange mit wiederkehrenden Fragen ("wie setze ich mein VPN zurück", "wo finde ich die Spesenrichtlinie") ist ein Agent in Teams, der dein SharePoint und Confluence liest, eine durchaus gute Nutzung des Stacks, und genau die Art Arbeit, die KI in Microsoft Teams gut erledigt - es ist im Grunde ein Teams-IT-Support-Bot, der vor deiner Warteschlange sitzt. Was du nicht bekommst, ist eine Warteschlange, ein Status, eine Zuweisung oder irgendeinen Bericht darüber, was er nicht beantworten konnte.

Das Kostenmodell ist das, was man verstehen sollte, bevor man sich festlegt, und es verdient seinen eigenen Abschnitt.

Der zweite Zähler: Copilot Credits

Hier kommt der Teil, der Leute überrascht, die Microsoft nur nach den Sitzplatzkosten bepreist haben. Die Sitzplatzlizenz enthält die KI nicht. Bei Customer Service Professional und Enterprise sind alle vier von Microsofts benannten Service-Agenten - der Case-Management-Agent, der Customer-Knowledge-Management-Agent, der Customer-Intent-Agent und der Quality-Evaluation-Agent - in Microsofts eigenem Plan-Vergleich mit "Erfordert Copilot Credits (separat verkauft)" markiert, was sich lohnt, zusammen mit jedem Ticket-Deflection-Plan zu lesen, den du dafür aufbaust.

Du kaufst Credits über Copilot Studio zu 200 $ für 25.000 Copilot Credits pro Monat, jährlich bezahlt. Das ergibt 0,008 $ pro Credit zum Listenpreis, obwohl Microsoft selbst nie einen Preis pro Credit angibt. Beide Credit-Pläne tragen dieselbe Voraussetzung, auf jeder Karte aufgedruckt: "Ein Azure-Abonnement wird benötigt, um Agenten zu nutzen."

Die Zahl, die du nicht bekommen kannst, ist die Zahl, die du brauchst. Microsofts eigene Fußnote sagt, dass immer, wenn eine Aktion oder Antwort von einem Agenten abgeschlossen wird, "eine variierende Anzahl von Copilot Credits abgerechnet wird, abhängig von der konkreten Nutzung", gemäß seiner Power-Automate-Preisseite. Veröffentlichte Sätze reichen von 1 Credit für eine klassische Antwort bis zu 100 für eine Premium-generative Antwort. Rechne 10 für Tenant-Graph-Grounding hinzu, und einen separaten Premium-Token-Zähler zusätzlich, wenn ein Reasoning-Modell beteiligt ist. Nirgends gibt es eine Zahl "Credits pro gelöstem Ticket", sodass du deine Kosten pro Credit-Paket berechnen kannst, aber niemals deine Kosten pro Ticket - genau die Lücke, die ein pro-Ticket bepreistes KI-Ticketsystem schließen soll.

Die Premium-Stufe zu 195 $ listet "Enthaltene Kapazität" für diese Agenten, aber Fußnote 6 qualifiziert das als "Basis-Copilot-Credit-Kapazität" ohne veröffentlichte Menge. Die Zahl steht nur im herunterladbaren Lizenzierungsleitfaden.

Nichts davon ist ein theoretisches Risiko. Im Juni 2026 beschrieb ein r/copilotstudio-Poster genau, was ein nicht vorhersehbarer Zähler anrichtet, wenn sich etwas in einer Schleife dreht:

"Ich habe dann einen Agenten von dev nach prod deployt. Das war's - ein einziger Agent. Heute habe ich mein Azure-Abonnement geprüft und dort steht eine Rechnung über ~47.000 $."

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

Der Mechanismus tauchte in den Antworten auf, und das ist der Teil, den man verinnerlichen sollte, bevor man irgendetwas einschaltet:

"Budgets für PAYG mit Azure-Abonnements in Copilot dienen nur Alarmzwecken. Es gibt keinen harten Servicestopp dafür… wir hatten einen von eingehender Mail ausgelösten Agenten-Flow, der sich selbst in eine Schleife brachte, indem er versehentlich Mails an sein eigenes Postfach sendete."

NikoThe1337, im selben Thread, Reddit

Ein Pay-as-you-go-Budget in Azure alarmiert, es stoppt nicht. Ein E-Mail-ausgelöster Flow, der in sein eigenes Postfach antworten kann, ist eine Schleife, und der Zähler läuft weiter, bis jemand es merkt.

Ich will hier fair sein. Das ist keine Unfähigkeit, es ist ein echtes Modellierungsproblem: Die Nutzung variiert wirklich, und ein flacher Preis pro Ticket bedeutet, dass der Anbieter die Varianz trägt statt der Kunde. eesels eigene Preisforschung landete trotzdem hart auf der anderen Seite davon. Wir haben erfundene Einheiten ausprobiert und sie wieder zurückgezogen, weil "Credit" die Kunden zum Rechnen zwang - die Reaktion, die wir immer wieder hörten, war eine Variante von "warte, was ist ein Credit?" Tickets und Chat-Sitzungen sind Einheiten, in denen Support-Manager bereits denken. Wenn die Person, die das Budget verteidigen muss, die Rechnung nicht vorhersagen kann, stockt der Rollout im Einkauf, und keine Modellqualität rettet das.

Weg 5: Dynamics 365 Customer Service

Das eigentliche Produkt. Wenn du willst, dass Microsoft dir ein richtiges ITSM-Ticketsystem verkauft statt der Einzelteile, ist das hier die Antwort.

Was ein Fall eigentlich ist

Dynamics-Fälle sind eigenwilliger als die meisten Helpdesk-Tickets. Die Einschränkungen sollte man kennen, bevor man einen Workflow um sie herum entwirft.

• Drei Statusse sind von Haus aus vorhanden: Aktiv, Gelöst, Abgebrochen. Aktiv trägt benannte Unterstatusse (In Bearbeitung, Wartend, Wartet auf Details, In Untersuchung).
• Das Zusammenführen von Fällen deckelt bei 10. Standardmäßig kannst du bis zu 10 Fälle gleichzeitig zusammenführen, und der zusammengeführte Fall wechselt zu Abgebrochen mit dem Statusgrund Zusammengeführt.
• Die Hierarchie hat genau zwei Ebenen. Ein Kind-Fall kann keinen Kind-Fall haben, und ein Eltern-Fall kann kein Kind eines anderen Falls sein. Wenn dein Eskalationsmodell drei Verschachtelungsstufen hat, passt es nicht.
• Die SLA-Migration hat eine Obergrenze. Das Verschieben von mehr als 1.000 SLAs kann die Premigrationsprüfung scheitern lassen, und SLA-Bedingungen auf verwandten Entitäten sind auf eine Ebene begrenzt.

Keines davon ist ein Dealbreaker. Es sind alle die Art von Dingen, die man lieber in Woche eins entdeckt als in Woche neun, besonders wenn SLA-Management das Stück ist, das deinem Team wirklich wichtig ist.

Die Preise, und das Tor, das zählt

Die scharfe Kante hier ist das Reporting-Tor. Bei 50 $ pro Sitzplatz gibt Professional dir Fallverwaltung und überhaupt kein Analytics oder KPI-Reporting. Auch keine Microsoft-Teams-Integration und kein einheitliches Routing. Das alles beginnt erst mit dem 105-$-Enterprise-Sitzplatz, ein Sprung von 110 %, um die Fähigkeit freizuschalten, die eigene Warteschlange zu messen.

Beachte auch, dass Premium (195 $) sehr nah bei Enterprise (105 $) plus Contact Center (110 $) liegt, gebündelt mit einem Rabatt von 20 $. Sprache ist dann eine dritte Rechnung: Fußnote 8 besagt, dass "die Preise für Azure Communication Services separat sind und nicht enthalten", sodass der 195-$-Sitzplatz die Contact-Center-Software kauft und nicht die Minuten.

Was Microsoft belegen kann

Jeder Beleg auf der Seite stammt aus Microsofts Kunden-Karussell, also lies sie als vom Anbieter veröffentlicht, nicht als unabhängig. Der stärkste: Lenovo mit einer Reduktion der Bearbeitungszeit um 20 %, Lexmark mit einem Anstieg der Call-Center-Produktivität um 23 %, und Hype mit einer First-Call-Resolution-Rate von 90 % bei einer Reduktion der Service-Rep-Intervention um 70 %. Microsofts eigenes internes Deployment behauptet 50 % Einsparung bei der Prozesszeit.

Die Analysten-Positionierung ist real. Microsoft ist ein Leader in der Forrester Wave für Customer Service Solutions, Q1 2026, veröffentlicht am 11. März 2026, und ein Leader im 2025 Gartner Magic Quadrant für das CRM Customer Engagement Center, dieselbe Kategorie, in der ServiceNow konkurriert. Zwei Dinge sind trotzdem erwähnenswert. Microsofts eigene Einordnung der Wave-Platzierung nutzt den Ausdruck "on-par vision", eine ungewöhnlich zurückhaltende Formulierung für das, was man über sich selbst freiwillig sagt. Und die Total-Economic-Impact-Studie, die dafür beworben wird, ist auf März 2024 datiert, zwei Jahre vor der Seite, auf der sie steht.

Das Fazit: die richtige Antwort, wenn Support kundenseitig ist, das Volumen real ist und das Unternehmen bereits auf Dynamics läuft. Es ist die falsche Antwort für einen internen IT-Desk mit 12 Personen, bei dem Lizenz, Implementierungspartner und Verkaufszyklus zusammen mehr kosten als das Problem selbst. Für diese Größenordnung bringt dich ein internes Ticketsystem, gebaut auf einem leichteren Desk - Jira eingeschlossen -, schneller ans Ziel.

Rechne aus, was es dich wirklich kosten würde

Listenpreise verschleiern die Form der Rechnung, also trag deine eigenen Zahlen ein.

Ändere die Sitzplatzanzahl und die Schalter, um zu sehen, wie die vier Microsoft-Wege für dein Team abschneiden. Der interessante Moment ist der Punkt, an dem der Selbstbau aufhört, die günstige Option zu sein.

Lässt du es bei zehn Personen laufen, sieht der Selbstbau-Weg wie ein leichter Gewinn aus: 350 $ im Monat gegenüber 500 $ für Dynamics Professional. Lässt du es bei zehn Personen mit KI auf der Warteschlange laufen, verengt sich die Lücke auf 550 $ gegenüber 700 $, für ein System, das immer noch jemand aus deinem Team besitzen muss. Diese 150 $ im Monat kaufen dir einen Teilzeitjob, den du nicht einkalkuliert hast.

Was Leute wirklich sagen, wenn sie Tickets auf Microsoft betreiben

Dafür habe ich viele r/sysadmin- und r/msp-Threads bis zurück ins Jahr 2020 gelesen, einschließlich reichlich Streit darüber, ob ein kostenloses Ticketsystem überhaupt einen Versuch wert ist, bevor man etwas kauft. Ein Satz taucht in fast allen davon auf, und es ist kein Feature-Vergleich.

"In meiner Karriere wurde der Satz 'warum nicht? wir haben die Lizenzen' mindestens einmal von jemandem in einer leitenden Geschäftsrolle (oder dem Projektmanager) für alle Projekte auf meiner Liste der zehn schlimmsten Projekte gesagt."

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

Das ist der Entscheidungstreiber, und man sollte ihn benennen, denn "wir bezahlen ja schon dafür" ist ein Argument über die Rechnung, nicht über die Passung. Im selben Thread beschrieb jemand, dessen Firma sich bereits festgelegt hatte, das Ergebnis:

"Wir haben gerade ein Projekt gestartet, das Dynamics als Ersatz für unser Ticketsystem nutzt. Bisher sind wir nicht beeindruckt. Aber unser CIO hat es trotzdem durchgezogen, weil wir Lizenzen dafür hatten."

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

Die Power-Apps-Threads teilen sich entlang einer klareren Linie, und die Teilung geht darum, wer es pflegt, nicht darum, ob es überhaupt funktioniert. Leute, die es selbst gebaut haben, berichten, dass es jahrelang problemlos läuft:

"Ich habe ein Ticketsystem mit Power Apps und etwas Power Automate (früher Flow) entwickelt. Unsere gesamte Datenbank liegt auf SharePoint Online. Es ist seit November 2019 in Produktion, es funktioniert großartig."

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

Leute, die eines geerbt haben, erzählen eine ganz andere Geschichte:

"Mein Vorgänger hat es genutzt, um die Power Platform zu lernen. Toll... aber das Problem ist, dass es ein Dutzend großartige Ticketsysteme da draußen gibt, die meisten davon bis zu einem gewissen Grad kostenlos, und die eigentlich nirgends teuer sind. Was wir also hatten, war ein fehlerhaftes Schrott-Produkt, dem 90 % der Basisfunktionen fehlten, die ich erwarten (und brauchen) würde. Nach einer Woche Gefrickel landete es im Papierkorb."

canadian_sysadmin, O365 ticketing, Reddit

Beide Berichte sind gleichzeitig wahr, und das ist das Nützliche daran, sie nebeneinander zu lesen. Eine selbstgebaute Power-Apps-Warteschlange ist ein persönliches Projekt, das zufällig geschäftskritisch geworden ist. Sie funktioniert genau so lange, wie ihr Urheber noch da ist.

Das letzte Thema ist der Maßstab, und die Zahlen, die Leute nennen, sind niedriger, als man vermuten würde. Ein Sysadmin, der die SharePoint-Liste-plus-Power-Automate-Version gebaut hatte, mit Benachrichtigungen und SLA-Hervorhebung und allem, schloss seinen Bericht mit einer klaren Ablehnung:

"Ich würde das nicht empfehlen. 300 Mitarbeiter reichen aus, um in einen RICHTIGEN Service-Desk zu investieren."

Ayy4K, O365 ticketing, Reddit

Wie man wirklich entscheidet

Zieht man die Lizenzierung ab, läuft es auf vier Fragen hinaus.

Ist die Warteschlange kundenseitig? Wenn ja, überspring Weg eins und zwei und schau dir stattdessen ein richtiges cloudbasiertes Ticketsystem an. Eine 5.000-Elemente-Ansichtsschwelle und eine 60-Sekunden-Polling-Verzögerung sind Probleme, die man intern noch toleriert, aber Kunden haben diese Toleranz nicht.

Musst du es messen? Wenn jemand nach der ersten Antwortzeit fragt, brauchst du den 105-$-Enterprise-Sitzplatz oder einen anderen Desk. Die 50-$-Stufe kann die Frage nicht beantworten, und sich das Reporting selbst auf Power BI zu bauen, kostet eine weitere Lizenz. Genau diese Messlücke ist der Grund, warum Ticket-Klassifizierung zuerst kommen muss - man kann keine Kategorie melden, die man nie getaggt hat.

Besitzt irgendjemand den Bau? Ein Power-Apps-Ticketsystem kommt mit einem Betreuer, ob du einen benannt hast oder nicht. Wenn die Antwort lautet "unser IT-Manager macht das nebenbei zu seinem Job", sind die echten Kosten höher als die Lizenz.

Ist KI der eigentliche Grund für deinen Einkauf? Das ist die Frage, die am häufigsten falsch eingeordnet wird. Teams suchen nach einem neuen Ticketsystem, wenn das eigentliche Ziel weniger Tickets ist, die einen Menschen erreichen. Neu zu plattformieren, um an KI zu kommen, ist der teuerste Weg, KI zu kaufen, und deshalb argumentiert mein Leitfaden zu IT-Helpdesk-KI in fast jedem Fall für Aufschichten statt Wechseln. Wenn dein Team schon tief in Microsoft steckt, ist der schnellste Schritt meist, Microsoft-Teams-Support zu automatisieren, auf der Warteschlange, die du schon hast.

Es lohnt sich, das klar zu sagen: Nichts davon macht Microsoft zu einer schlechten Wahl. Dynamics 365 ist ein ernstzunehmendes Produkt mit echtem Analysten-Standing, und die Power Platform kann tatsächlich Dinge bauen, die ein fertiger Helpdesk nicht kann. Der Fehlerfall ist nicht, Microsoft zu wählen. Es ist, den günstigen Microsoft-Weg für ein Problem zu wählen, das den teuren gebraucht hätte, und dann die Lücke bei 3.000 Listenelementen zu finden. Lies meine breitere Einschätzung zu automatisiertem IT-Ticketing, wenn du noch entscheidest, welche Spur passt.

eesel für eine Microsoft-Ticketwarteschlange

Wenn Deflection der Grund ist, warum du das hier liest, und nicht ein neuer Desk, brauchst du wahrscheinlich überhaupt keine neue Plattform.

eesel ist eine KI-Ebene, die sich in den Desk und die Doku einklinkt, die du bereits betreibst - deine interne Wissensdatenbank eingeschlossen. Sie liest Microsoft Teams, SharePoint, Confluence und deine bestehenden Tickets, entwirft oder sendet Antworten in dem Tool, in dem dein Team ohnehin schon ist, und geht in Minuten live statt in einem Implementierungsquartal. Zwei Dinge zählen speziell gegenüber den oben genannten Microsoft-Wegen. Es rechnet pro Ticket ab, nicht pro Credit, sodass die Zahl, die du zur Finanzabteilung trägst, eine Zahl ist, die du vorhersagen kannst. Und jeder Rollout wird zuerst anhand deiner historischen Tickets simuliert, sodass du siehst, was es geantwortet hätte und wie gut, bevor es je eine laufende Warteschlange berührt. Ich habe das eingebaut, weil ich schon zugesehen habe, wie ein selbstbewusst klingender Bot leise falsche Antworten gibt, und einmal ist genug.

Der interne IT-Desk eines Fintechs, der auf Jira Service Management mit Confluence und Slack im Hintergrund läuft, setzte eesel als First Responder auf seiner Helpdesk-Warteschlange ein. Die Deflection stieg auf 15 % auf dem Weg zu einem Ziel von 55 %. Ihr Head of IT drückte es so aus:

"Wir nutzen es, um der First Responder für unsere Helpdesk-Tickets in Jira zu sein. Es verhält sich im Grunde genau wie ein Agent."

Jason Loyola, Head of IT bei InDebted

Das ist genau die Art Arbeit, die ein IT-Desk auf Microsoft-Basis anstrebt, wenn er KI auf einen internen Desk setzt statt einen Copilot-Studio-Agenten, nur ohne die Credit-Rechnerei. Kostenlos zu testen, und die Einrichtung dauert etwa so lange wie das Lesen dieses Beitrags.

Wo dich das zurücklässt

Es gibt kein Microsoft-Ticketsystem. Es gibt ein CRM namens Dynamics 365 Customer Service für 50 bis 195 $, und einen Baukasten namens Power Platform. Die interessante Entscheidung ist, welches der beiden dein Problem tatsächlich verdient.

Die fünf Wege sind real, und sie sind geordnet. Geteiltes Postfach, bis zwei Personen kollidieren. SharePoint und Power Automate, bis 3.000 Elemente. Power Apps, wenn der Workflow wirklich deiner ist und jemand ihn besitzt. Copilot Studio, wenn das Ziel Deflection ist. Dynamics, wenn Support das Geschäft ist.

Das eine, das ich nicht tun würde, ist, den Sitzplatz zu kaufen und anzunehmen, die KI sei schon dabei. Bei Professional und Enterprise ist sie es nicht. Sie wird in einer Einheit abgerechnet, deren Kosten pro Ticket Microsoft nicht veröffentlicht, und sie braucht ein angehängtes Azure-Abonnement, bevor sie überhaupt läuft. Egal welchen Weg du nimmst, bepreise diesen Zähler, bevor du unterschreibst, nicht danach.