Ticketing sieht auf dem Papier sauber aus. Man erhält die Zahlen, die Warteschlangen, die Dashboards. Doch in der Realität misst dieses Modell den Schmerz erst, wenn das System bereits versagt hat. Der kostspielige Teil des Problems beginnt meist viel früher. Er beginnt, wenn ein Mitarbeiter 10 Minuten verliert, dann 20 und schließlich einfach aufgibt. Die Versuchungssinn. Sie verpassen das Meeting oder teilen die falsche Datei, weil der richtige Weg nicht mehr funktioniert. Und genau das ist der Teil, den die meisten Support-Teams noch immer nicht sehen. Beim besten internen Support-Modell von heute geht es nicht um schnellere Triage. Es geht darum, die Notwendigkeit einer Triage komplett zu beseitigen. Stellen Sie sich einen autonomen Agenten in Microsoft 365 vor, der den Kontext überwacht, Reibungspunkte früh erkennt und handelt, bevor jemand überhaupt daran denkt, ein Portal zu öffnen.

In dieser Episode zeige ich Ihnen, warum das Helpdesk-Modell versagt, was es tatsächlich ersetzt und wie Sie es steuern können, ohne Chaos zu stiften. Wenn dieser Wandel für Ihre Arbeit wichtig ist, abonnieren Sie im Trat 65 FM, denn eine Ebene tiefer ist das eigentliche Problem nicht die Warteschlange, sondern das Modell dahinter. Das Ende des Tickets. Der alte Support-Ablauf ist noch überland zu treffen. Etwas geht kaputt. Ein Benutzer bemerkt es. Der Benutzer versucht es zu erklären. Dann übersetzt die IT diese Erklärung in eine Kategorie, eine Priorität und vielleicht eine Zuweisungsgruppe. Das Problem landet in einer Warteschlange. Jemand sichtet es. Jemand anderes fragt nach weiteren Detailn. Ein weiteres Team wird hinzugezogen. Die Zeit läuft weiter, während die eigentliche Arbeit stecken bleibt. Dieser Prozess fühlt sich normal an, weil er vertraut ist. Aber vertraut und effektiv sind nicht dasselbe.

Ein Ticket ist kein Support. Ein Ticket ist der Beweis dafür, dass der Support zu spät kann. Bis ein Ticket überhaupt existiert, ist der Mitarbeiter bereits auf ein Hindernis gestoßen und hat seinen Kontext verloren. Er hat seine Aufmerksamkeit bereits von der Arbeit abgewendet, die er eigentlich erledigen wollte. Die verlangt es nicht der Service. Die Warteschlange ist ein Protokollschalter. In großen Microsoft 365 Umgebungen wird die manuelle Triage zum eigentlichen Flaschenhals. Das passiert nicht, weil Support-Teams faul wären. Es passiert, weil von Menschen Dinge verlangt werden, die nicht mehr zum Maßstab der Umgebung passen. Sie haben mehr Benutzer, mehr Geräte, mehr Apps, mehr Richtlinien. Sie haben mehr Grenzfälle, die gleichzeitig Teams SharePoint, Exchange, Intune und Entra betreffen. Das Volumen wächst nicht nur. Die Kombinationen wachsen. An diesem Punkt bricht das alte Modell zu sein.

Die meisten Teams reagieren, indem sie mehr Struktur hinzufügen. Sie bauen ein weiteres Portal, einen weiteren Bot oder eine weitere Routing-Regel. Doch in der Realität fügt das nur eine weitere Ebene zwischen dem Mitarbeiter und der Lösung hinzu. Das System wartet immer noch darauf, dass der Benutzer das Problem bemerkt, es beschreibt und auf die richtige Weise um Hilfe bittet. Arbeit beginnt nicht in einem Support-Portal, sie beginnt in Teams, in Outlook, in einem Dokument, das jemand gerade braucht oder einem Meeting, das in 30 Sekunden startet. Genau dort entsteht der Support-Bedarf tatsächlich und das Ticket-Modell ist von diesem Moment völlig entkoppelt. Die versteckten Kosten sind viel höher, als es ihr Warteschlangen-Bericht sei. Die Leute wechseln ständig im Kontext. Doppelte Vorfälle stapeln sich unter verschiedenen Bezeichnungen. Wissensartikel verhalten. Analysten verbringen ihren ganzen Tag mit Sortieren, Zuweisen und Klären, anstatt die Dinge tatsächlich zu reparieren.

Die Lösungszeit zieht sich in die Länge, da jede Übergabe eine Verzögerung verursacht und jede Verzögerung den ursprünglichen Kontext schmälert. Forschung zu agentischer KI- und IT-Betrieb deutet auf dasselbe strukturelle Problem hin. Mindestens 80% des Aufwands stecken immer noch in reaktiver Arbeit nach IT-Lat fest. Diese Zahl ist wichtig, weil sie ihnen genau sagt, wohin die Arbeit fließt. Sie fließt nicht in Resilienz oder Prävention, sondern in Reaktion. Sobald man das erkennt, wirkt das Ticket weniger wie ein Betriebsmodell und mehr wie ein Symptom. Es ist das Symptom eines Systems, das erst reagiert, wenn der Schaden sichtbar ist. Die nächste Frage ist also nicht, wie man Tickets schneller bearbeitet, sondern was das System tun sollte, bevor überhaupt ein Ticket nötig ist. Das Modell des unsichtbaren Mitarbeiters. Was ersetzt also das Ticket tatsächlich? Es ist nicht einfach ein weiterer Chatbot, der auf demselben Chaos aufbaut und ganz sicher keine schönere Fassade für dieselbe alte Warteschlange.

Der Wandel geht viel tiefer, denn der unsichtbare Mitarbeiter ist eine operative Kraft, die in ihrer Microsoft 365 Umgebung lebt. Dieser Agent hat eine eigene Identität, einen definierten Aufgabenbereich, ein Gedächtnis für das, was er gestern getan hat und strikte Regeln für seine Befugnisse. Dieser Unterschied ist entscheidend. Ein Chatbot wartet darauf, dass sie einen Prompt eingeben, aber ein unsichtbarer Mitarbeiter achtet auf sich ändernde Bedingungen. Er geht vom Kontext aus, anstatt von einem Gespräch. Da er Anmeldestatus, Gerätezustand, Lizenzstatus und Dateifreigaben sieht, muss er nicht warten, bis Probleme auftreten. Anstatt zu fragen, wie er helfen kann, nachdem etwas kaputt gegangen ist, stellt er im Hintergrund ständig eine andere Frage. Was weicht von dem Zustand ab, den dieser Mitarbeiter braucht, um seine Arbeit jetzt zu erledigen? Genau hier verändern sich die Dinge. Das Modell ist direkt in die Arbeit selbst eingebettet.

Wenn jemand einem Meeting beitritt und das Audio-Routing fehlt, schlägt oder ein Gast eine gerade gesendete Datei nicht öffnen kann, erstellt die alte Welt einen Bericht und eine Übergabe. Im neuen Modell erkennt der Agent das Muster sofort, prüft, ob die Bedingung einem bekannten Problem entspricht und führt die nächste sichere Aktion zur Behebung aus. Vielleicht setzt der Entfahrt zurück, löst eine Richtlinienprüfung aus oder leitet eine Anfrage um und fordert eine MFA an, bevor er die Korrektur dokumentiert. Der Punkt ist einfach. Die erste Reaktion erfordert keinen Menschen mehr, der eine vage Beschreibung liest und raten muss, was passiert ist. Wenn es gut funktioniert, wirkt es unsichtbar, denn es gibt kein Wartezimmer und kein Formular, bei dem man eine Kategorie auswählen muss. Support zeigt sich als wiederhergestellter Arbeitsfluss. Der Mitarbeiter kann einfach weiterarbeiten und sieht in vielen Fällen nicht einmal den Mechanismus, der im Hintergrund abläuft.

Sie sehen bereits, wie dies ihre Personalplanung verändert. Im alten Modell stellt man Leute ein, um das Volumen aufzufangen, Anfragen zu sortieren und fehlerhafte Zusammenhänge zwischen Teams zu bereinigen. Das neue Modell benötigt weniger Personal für die Triage und mehr Leute, die Leitplanken entwerfen, soll Zustände definieren und das Verhalten dieser Agenten dauerhaft überwachen. Menschen bleiben im System, aber die gesamte Struktur ihrer täglichen Arbeit verschiebt sich. Die Forschung zu agentischer KI im Support weist immer wieder in diese Richtung. Routinesupport kann sich in Richtung ausnahmebasierter Abwicklung bewegen, was bei gut definierten Umgebungen und Richtlinien enorme Effizienzgewinne bringt. Dieser letzte Teil ist entscheidend, denn das ist keine Zauberei. Wenn Ihre Daten schwach oder Ihre Prozesse chaotisch sind, wird der Agent nicht allein dadurch intelligent, dass Sie ihn autonom nennen.

Mir wurde das klar, als ich aufhörte, den Agenten als Softwarefunktion zu sehen und anfing, ihn als nichtmenschlichen Mitarbeiter mit Dienstausweis zu betrachten. Ein echter Mitarbeiter benötigt eine Identität, eine Stellenbeschreibung, Berechtigungen und einen Vorgesetzten. Der Agent benötigt genau dasselbe, denn der Wert entsteht durch zuverlässiges Handeln innerhalb eines Systems, nicht durch kluge Formulierungen in einem Chatfenster. Der unsichtbare Mitarbeiter ist kein UI-Trick. Es ist eine neue Support-Ebene, die Reibungsverluste in der gesamten Microsoft 365 Umgebung überwacht, innerhalb der Richtlinien agiert und menschliche Aufmerksamkeit auf die Ausnahmen lenkt, die tatsächlich ein Urteilsvermögen erfordern. Sobald dieses Modell klar ist, wird die nächste Frage sehr praxisnah. Wie funktioniert Prävention eigentlich? Die Architektur der Prävention. Wie funktioniert Prävention also eigentlich innerhalb von Microsoft 365?

Der Wandel vollzieht sich von Anfrage und Antwort hin zur Ereignisanalyse und Orchestrierung. Das klingt technisch, aber das Modell ist einfach, wenn man es in seine Einzelteile zerlegt. Zuerst ändert sich etwas in der Umgebung, dann interpretiert das System, ob diese Änderung ein Risiko oder eine Abweichung darstellt, und schließlich führt es die genehmigte Aktion mit den bereits vorhandenen Tools aus. Beginnen wir mit der Ereignis-E... Microsoft 365 erzeugt bereits überall Signale. Entra erfasst Anmeldeverhalten, während Intune den Gerätestatus und die Compliance überwacht. Defender achtet auf verdächtige Aktivitäten und Teams zeigt ihnen genau, wann ein Meeting-Field schlägt oder die Anrufqualität sinkt. SharePoint und Exchange legen Zugriffsmuster und Inhaltsaktivitäten offen, während Service Health Signale melden, wenn die Plattform selbst das Problem ist. Wenn man die Benutzeraktion hinzunimmt, erhält man einen konstanten Strom an Kontextinformation.

Die meisten Unternehmen erfassen diese Signale, aber nur wenige nutzen sie tatsächlich als Unterstützungssystem. Rohe Ereignisse allein helfen nicht, da sie eine Analyse-Ebene benötigen, um aus dem Rauschen einen Sinn zu ergeben. Hier hört der unsichtbare Mitarbeiter auf, nur Automatisierungstheater zu sein und beginnt, wie ein echter Operator zu handeln. Der Agent betrachtet das Signal, vergleicht den aktuellen Zustand mit dem Zielzustand und entscheidet, welche Art von Aktion sicher ist. Ein Audioproblem in einem Meeting ist nicht dasselbe wie eine riskante Anmeldung, und ein defekter Freigabelink unterscheidet sich von einer Lizenz in Conway. Der Agent muss das Problem zuerst klassifizieren, denn Handeln ohne Klassifizierung führt nur schneller zu Fehlern. Dann kommt die Orchestrierung. Sobald der Agent das Problem versteht, kann er den richtigen Mechanismus zur Reaktion nutzen. Das könnte Power Automate für Workflows, Copalette Studio für Logik oder Microsoft Graph für Systemaktion und Kontext sein.

Die Werkzeuge sind wichtig, aber der entscheidende Punkt ist, wie sie miteinander verbunden sind. Sie bauen nicht einen einzelnen intelligenten Prompt, sondern eine Kette, die er kennen, entscheiden, handeln und verifizieren kann. Dieser letzte Teil wird ständig übersehen. Ein selbstkorrigierendes System stoppt nicht, sobald die Aktion ausgeführt wurde. Es durchläuft eine Schleife, es erkennt das Problem, prüft den Zustand, wendet die Korrektur an und verifiziert das Ergebnis, bevor es alles protokolliert. Die Forschung zur selbstkorrigierenden Logik macht deutlich, dass diese Systeme durch Feedback und Korrekturmuster arbeiten, statt durch eine isolierte Antwort eines Sprachmodells. Wenn die erste Aktion fehlschlägt, muss das System bewerten können, warum, um den nächsten Schritt anzupassen und dabei innerhalb definierter Grenzen zu bleiben. Sie können sich das an einigen Microsoft-Raven von 60 Beispielen gut vorstellen.

Wenn ein Benutzer blockiert wird, weil Lizenz und Richtlinienumfang nicht übereinstimmen, erkennt der Agent die Abweichung und prüft das vorgesehene Rollenprofil und Profil. Er wendet die zulässige Korrektur an, bestätigt den Benutzerzugriff und protokolliert die Änderung, ohne jemanden fragen zu müssen. Wenn eine riskante Anmeldung in Entra auftritt, sieht der Agent das Risikoereignis und prüft sofort ihre Richtlinien für den bedingten Zugriff. Er fordert eine stärkere Verifizierung an oder blockiert den Zugriff gemäß ihrer Richtlinie und zeichnet das Ergebnis zur späteren Überprüfung durch einen Menschen auf. Wenn ein veralteter Freigabelink in SharePoint ständig fehlschlägt, vergleicht der Agent den aktuellen Berechtigungspfad mit den erwarteten Freigaberegeln. Er ersetzt den defekten Pfad durch den korrekten und sendet den funktionierenden Link direkt in den Kontext, noch bevor ein Support-Mitarbeiter ein Ticket mit der Überschrift dringendes Zugriffsproblem lesen muss.

Muss. Meeting Support ist ein weiteres großartiges Beispiel. Wenn ein Raumgerät ausfällt oder eine Verbindung kurz vor Beginn eines Anrufs abbricht, kann der Agent den Zustand erkennen und den Fehler validieren. Er versucht einen risikoarm Wiederherstellungsschritt und benachrichtigt den Organisator in Teams mit einem Status-Update genau dort, wo die Arbeit stattfindet. Diese Kommunikationsebene ist ein wesentlicher Teil des Designs. Support muss dort stattfinden, wo die Unterbrechung auftritt. Wenn Ihre Arbeit in Teams, Outlook und im M365 Arbeitsbereich stattfindet, sollte der Support Sie auch dort erreichen. Sie sollten den Benutzer nicht woanders hinlotsen müssen, wenn Sie das Problem direkt im Kontext lösen können. Das bedeutet nicht, dass jede einzelne Aufgabe vollautomatisiert wird, denn das wäre leichtsinnig. Risikoarme Aktionen können automatisch ausgeführt werden, aber Änderungen mit großen Auswirkungen benötigen immer noch die Genehmigung der Person.

Dieser Genehmigungspfad muss von Anfang an Teil der Architektur sein, anstatt ihn später nachträglich hinzuzufügen. Der Agent sollte wissen, wann er handeln, wann er nachfragen und wann er genau aufhören muss. Und sobald Sie dies in den Ablauf integrieren, geht es in der Diskussion nicht mehr nur um Automatisierungsfunktionen. Es geht dann um Kontrolle, Governance, Vertrauen und die Identität des Agenten. Wenn der Support beginnt, eigenständig zu handeln, taucht sofort eine schwierige Frage auf. Wer erledigt eigentlich die Arbeit? Wenn diese Antwort vage bleibt, bricht das gesamte Modell zusammen. Ein Agent darf in Ihrer Umgebung nicht als unklarer Helfer mit weitreichenden Zugriffen und ohne klaren Besitz existieren. Er benötigt eine echte Identität in Entra. Er braucht einen namentlich genannten Besitzer, einen definierten Aufgabenbereich und einen Lebenszyklus, der aus einem bestimmten Grund beginnt und endet.

Wenn dieser Agent Daten lesen, Workflows auslösen oder Nachrichten an Ihre Benutzer senden kann, müssen Sie ihn wie einen aktiven Teilnehmerantennen steuern. Sie dürfen ihn nicht wie ein Feature behandeln, das jemand aktiviert und dann vergessen. Deshalb ist die Agentenidentität zu entscheiden für das System. Sie müssen genau wissen, was der Agent ist, welche Systeme er berühren kann und wer benachrichtigt wird, wenn die Dinge aus dem Ruder laufen. Das Prinzip der geringsten Rechte muss hier die Grundlage bilden. Sie dürfen sich nicht mit Bequemlichkeit zufrieden geben oder sich einreden, dass Sie die Berechtigung später einschränken werden. Da der Wirkungsradius eines Supportagenten vollständig von seinen Berechtigungen abhängt, ist die Gestaltung dieser Berechtigung ein Kernbestandteil des Supportdesigns. Agent 365 dient in diesem Aufbau als notwendige Steuerungsebene, da es die gesamte Agentenumgebung sichtbar macht.

Es bietet das Verzeichnis, die Genehmigungsworkflows und die Richtlinienvorlagen für einen sicheren Betrieb. Auch wenn diese Elemente nach Verwaltungsaufwand klingen, lösen sie ein massives, strukturelles Problem. Die meisten Unternehmen scheitern nicht an fehlenden KI-Funktionen, sondern daran, dass sie das bestehende Umfeld nicht überblicken oder steuern können. Die Forschungsergebnisse hierzu sind eine. Nur eine kleine Minderheit großer Unternehmen kann jeden aktuell laufenden Agenten im System vollständig erfassen. Bevor Führungskräfte über die Skalierung von autonomem Support sprechen, müssen sie eine einfachere Frage beantworten. Wissen wir überhaupt, welche Agenten existieren und was sie gerade tun? Die Überwachung muss zudem dem jeweiligen Risikoniveau entsprechen. Ein Produktivitätsagent für Einzelpersonen ist eine Sache. Oder ein kollaborativer Agent mit Zugriff auf geteilte Inhalte etwas völlig anderes.

Dann gibt es Unternehmensagenten, die in sensiblen Workflows agieren, was eine andere Risikokategorie darstellt. Deshalb ist das Risiko-Zonen-Modell persönlich kollaborativ und unternehmensweit so wichtig. Ihr Kontrollmodell sollte mit der möglichen Tragweite wachsen. Behandelt man jeden Agenten gleich, ersticken risikoarme Aufgaben in langsamen Freigaben, während risikoreiche Aufgaben kaum geprüft durchschlüpfen. Ihr Kontrollstack in Microsoft 365 sollte für Ihr Team zumindest vertraut wirken. Sie nutzen Identitäten über Entra, Datengrenzen durch Purview und Überwachung mittels Defender. Sie wenden Zugriffsbedingungen über Conditional Access an und stellen sicher, dass Auditierbarkeit von Anfang an integriert ist. Sie müssen nach einem Vorfall exakt rekonstruieren können, was passiert ist, ohne raten zu müssen. Menschliche Aufsicht muss in die Logik integriert sein, statt sie in der Krise zu improvisieren.

Aktionen mit hoher Tragweite sollten immer auf eine menschliche Freigabe warten. Die Entscheidungsfindung sollte in einer Form protokolliert werden, die für Menschen nachvollziehbar ist. Rollback-Optionen müssen vorhanden sein, bevor die erste autonome Aktion live geht, um. Wenn ein Agent den Zugriff aktualisiert oder eine Routing-Richtlinie ändert, muss dies nachverfolgbar und sauber rückgängig machbar sein. Ein weiterer Faktor wird oft übersehen, weil frühe Demos so überzeugend wirken. Die Kosten der Nacharbeit. Wenn ein Agent ihrem Team dauerhaft Aufräumarbeit beschert, schmilzt die geplante Ersparnis sofort dahin. Das ist die Steuer auf Nacharbeit. Es ist die Zeit, die man mit der Korrektur schlechter Ergebnisse, dem Widerwurf falscher Aktionen oder der Suche nach Nebeneffekten verbringt. Wenn ihr Team 10 Minuten bei der Ausführung spart, aber 8 Minuten mit Aufräumarbeiten verbringt, haben sie den Support.

Nicht wirklich automatisiert. Sie haben die Reibungsverluste lediglich in einen anderen Teil des Prozesses verlagert. Vertrauen entsteht nicht durch ausgefeilte Richtlinien oder große Ankündigungen. Es entsteht durch Nachweis im laufenden Betrieb. Die Leute müssen sehen, was der Agent gesehen, was er entschieden und was er tatsächlich im System geändert hat. So bauen sie Vertrauen in autonome Support auf. Der Beweis muss im Verhalten des Tools liegen, nicht im Branding des Projekts. Sobald das Fundament der Governance steht, kann die Diskussion von Sicherheitsjargon zu einer Sprache für Führungskräfte übergehen. Was bedeutet das konkret für das Geschäftsergebnis? Der neue ROI von unsichtbarem Support. Sobald Führungskräfte das Kontrollmodell akzeptieren, ändern sich die finanziellen Fragestellungen. Im alten Modell wird der Supportwert an sichtbarer Arbeit gemessen, wie geschlossenen Tickets, bearbeiteten Anrufen und SLA-Leistungen.

Diese Zahlen sind wichtig, beschreiben aber nur die Reaktionen auf ein Problem. Sie verraten nicht, wie viele Unterbrechungen die Warteschlange nie erreicht haben oder wie viel Arbeitszeit durch eine frühzeitige Problemlösung erhalten blieb. Das ist das Kernproblem der Erfolgsmessung. Unsichtbarer Support schafft Wert durch Abwesenheit. Der Wert zeigt sich, wenn kein Ticket anfällt, keine Eskalation nötig ist und kein Analyst 20 Minuten damit verbringt, ein Problem aus unvollständigen Notizen zu rekonstruieren. Wer nur den sichtbaren Aufwand des Supportteams misst, verfehlt das eigentliche Ziel. FALOI. Das Ziel war stabiles Arbeiten mit weniger Unterbrechung. Das Ticketvolumen ist für sich allein betrachtet ein schwaches Signal. Ein Rückgang der Tickets könnte bedeuten, dass die Nachfrage sank, aber auch, dass die Umgebung gesünder und die Supportebene intelligenter wurde. Das sind zwei völlig verschiedene Geschichten.

Führungskräfte benötigen ein KPI-Set, das zwischen diesen unterscheiden kann. Beginnen Sie damit, die autonome Lösungsrate zu betrachten. Es geht nicht darum, wie viele Konversationen der Bot führte, sondern wie viele Supportvorgänge komplett ohne menschliches Eingreifen gelöst wurden. Sie müssen zudem die Verringerung der durchschnittlichen Lösungszeit nachverfahren. In KI-gestützten Umgebungen erreichen Diagnose-intensive Abläufe auf Verbesserungen im Bereich von 40 bis 60 Prozent. Dann können Sie die Kosten pro Lösung und die zurückgewonnene Benutzerproduktivität analysieren. Diese letzte Kennzahl wird leicht übersehen, da sie nicht in einen Standardservice-Desk-Bericht passt. Dabei liegt genau dort auf der Ware wert. Jemand, der 15 Minuten blockiert ist, bevor er überhaupt ein Ticket eröffnet, hat bereits Kosten für das Unternehmen verursacht. Multipliziert man dies mit Besprechungsunterbrechungen und Zugriffshürden in einem großen Unternehmen, ist der versteckte Verlust viel größer, als es die Warteschlange vermuten lässt.

Deshalb ist das Modell der Kosten durch Nichtstun so wichtig für den Business Case. Sie berechnen die Stunden, die für manuellen Aufwand aufgewendet werden, bevor der formelle Support überhaupt beginnt. Dann addieren Sie noch die Kosten für Fehler und wiederholte Arbeit hinzu. Plötzlich klingt das Argument für Prävention nicht mehr wie eine bloße Theorie. Sie finanzieren nicht nur eine futuristische Support-Ebene. Sie schaffen eine versteckte Steuer ab, die seit Jahren Ihre tägliche Arbeit belastet. Die Wirtschaftlichkeit des spezifischen Anwendungsfalls macht dies noch deutlicher. Untersuchungen zum agentenbasierten IT-Support beziffern die manuelle Bearbeitung auf etwa 8,75 pro Fall. Im Gegensatz dazu können die Kosten bei spezialisierten Agenten auf unter 50 Cent pro Fall sinken, sobald das System entwickelt ist. Das bedeutet nicht, dass jede Support-Aktion so günstig sein wird. Führungskräfte sollten bei pauschalen Durchschnittswerten vorsichtig sein.

Qualität und Steuerung der Telemetrie beeinflussen immer die Endkosten, doch die Richtung des Trends ist unverkennbar. Dies ist der Moment, in dem die IT das alte Image als reines Kostenzentrum hinter sich lässt. Nicht, weil der Support verschwindet, sondern weil er zu einer Zuverlässigkeitsebene wird, die im Hintergrund den Durchsatz der Mitarbeiter schützt. Das Unternehmen erlebt dies als flüssige Arbeitsabläufe statt als dramatische Supportereignisse. Sie erhalten weniger Unterbrechungen, schnellere Wiederherstellungen und weniger Zeitverschwendung durch Routing- und Klärungsbedarf. Dennoch können schlechte Messmethoden leicht Fortschritte vortäuschen. Wenn ihre Telemetrie schwach ist, könnte der Agent einen Fehler nur schneller zusammenfassen, statt ihn tatsächlich zu verhindern. Wenn Nachbesserungen nicht im Dashboard erscheinen, wird der ROI viel sauberer aussehen als er tatsächlich.

Wenn gewonnene Zeit einfach wieder in minderwertige Tätigkeiten fließt, werden Führungskräfte den Gewinn überschätzen. Das Finanzargument muss auf harten Fakten wie verhinderten Vorfällen und weniger manuellen Eingriffen basieren. Sie müssen die Zeit messen, die tatsächlich für produktive Arbeit zurückgewonnen wird. Sobald Sie dies korrekt messen, wirkt die Supportfunktion nicht mehr wie ein Overhead, der gekürzt werden muss. Sie beginnt wie eine Betriebskapazität auszusehen, die das Unternehmen endlich zurückgebringt. Was bedeutet das für das Support? Denken Sie darüber nach, was dies wirklich für das Team vor Ort bedeutet, denn bei diesem Wandel geht es nicht um Personalabbau, sondern darum, wie Ihre Mitarbeiter ihren Tag verbringen. Im alten Setup wird ein Großteil Ihrer Supportkapazität durch Passwort-Resets-Ticket-Rotting und endlose Klärungsschleifen verschlungen. Ihre Leute jagen Updates hinterher und verschieben Daten zwischen Systemen, die nie für eine Zusammenarbeit ausgelegt waren.

Nichts davon macht die Umgebung stabiler, es verhindert lediglich, dass die Warteschlange überläuft. Wenn Agenten diese vorhersehbaren Routineaufgaben übernehmen, steigt der menschliche Einsatz endlich auf eine höhere Ebene. Support-Ingenieure verbringen ihre Zeit damit, einen gesunden Systemzustand zu definieren und die Logik Hintergenehmigungen zu verfeinern. Sie konzentrieren sich darauf, Wissensquellen zu verbessern, das Verhalten von Richtlinien zu testen und sicherzustellen, dass der Agent innerhalb seiner vorgegebenen Grenzen bleibt. Da es ist ein völlig anderer Job als den ganzen Tag betrefft, seinen einzustarren und zu raten, was ein Benutzer eigentlich will. Genau hier bleiben die meisten Implementierungen stecken. Unternehmen versuchen, ihre alten, fehlerhaften Prozesse beizubehalten und einfach einen Agenten darüber zu legen, in der Hoffnung auf ein besseres Ergebnis. Doch der Prozess bleibt reaktiv, die Übergaben sind weiterhin chaotisch und das zugrunde liegende Wissen ist schwach.

Der Agent ist dann nur ein weiterer Anstrich auf einer bröckelnden Wand. Er beantwortet eine Frage vielleicht schneller, kann aber kein Support-Modell reparieren, das auf Verzögerung ausgelegt. Der bessere Weg ist, die Arbeit zuerst neu zu gestalten. Sie müssen entscheiden, welche Aufgaben menschlich bleiben, weil sie Urteilsvermögen oder sensible Kommunikation erfordern. Dann entscheiden sie, welche Arbeit in autonome Abläufe übergeht, da das Ergebnis vorhersehbar und die Aktionen sicher sind. Diese Aufteilung ist wichtig, denn Support-Teams werden nicht verschwinden. Sie werden lediglich zu den Personen die Kontrollen entwerfen und Ausnahmen behandeln. Das bedeutet, dass sich auch die Art und Weise ändern muss, wie wir Mitarbeiter schulen. Teams müssen lernen, ein System zu überwachen, anstatt nur eine manuelle Aufgabe auszuführen. Sie müssen Rollback-Logik, Audit-Reviews und das Testen eines Agenten vor der Inbetriebnahme verstehen.

Sie müssen auch erkennen können, wann der Modell versagt, denn ein automatisierter schlechter Workflow bleibt ein schlechter Workflow bleibt ein schlechter Workflow. Er macht die Dinge nur schneller kaputt. Wenn Sie für diese Zukunft einstellen, brauchen Sie wahrscheinlich keinen weiteren Generalisten für die Ticket-Review. Sie brauchen jemanden, der Abläufe im Microsoft 365-Stick orchestrieren und die Kontrollen definieren kann, die Agenten im Zaum halten. Halb! Sie wollen Leute, die die Umgebung verbessern können, sodass die Support-Nachfrage tatsächlich sinkt, anstatt sich nur zu staunen. Wie fangen Sie also an, ohne dass es zu einem massiven, mehrjährigen Transformationsprojekt wird? Am besten wählen Sie einen einzelnen Ablauf aus, der in Ihrer Microsoft 365-Umgebung ständig für Reibung sorgt. Zugriffsbehebungen sind meist ein guter Kandidat, aber Sie könnten sich auch Meeting-Support oder Geräte-Compliance-Übergaben ansehen.

Es spielt keine Rolle, welchen Sie wählen, solange das Muster häufig auftritt und Sie genau wissen, wie ein erfolgreiches Ergebnis aussehen sollte. Sobald Sie das Ziel haben, müssen Sie die Grundlagen mit echter Disziplin definieren. Sie müssen wissen, was einen gesunden Zustand ausmacht und welche Ereignisse Ihnen signalisieren, dass etwas vom Kurs abweicht. Entscheiden Sie, welche Aktionen sicher automatisiert werden können und wo genau die menschliche Eskalation beginnen muss. Bevor Sie etwas in Betrieb nehmen, stellen Sie sicher, dass Sie eine Basislinie für Ticketsahlen, manuelle Eingriffe und die aktuelle Wartezeit der Benutzer haben. Außerdem müssen Sie Ihre Governance vom ersten Tag an etablieren. Geben Sie dem Agenten eine spezifische Identität, weisen Sie ihm einen menschlichen Besitzer zu und legen Sie klare Genehmigungsregeln. Jede einzelne Aktion, die der Agent ausführt, muss protokolliert werden.

Sie sollten auch einen Plan für die Stilllegung oder Neuzuweisung des Agenten haben, damit er nicht zu einer Geisterautomatisierung wird. Sobald der erste Ablauf funktioniert, beginnt sich Ihr gesamtes Betriebsmodell zu verändern. Der Support agiert nicht mehr wie ein Empfangsschalter, der nur auf Probleme reagiert. Stattdessen beginnt er wie eine Zuverlässigkeits-Engine zu arbeiten, die direkt in das System integriert ist. Der Support wandelt sich von einer sichtbaren Reaktion hin zu eingebetteter Prävention. Das Ticket war nie die eigentliche Dienstleistung. Es war der Beweis, dass der Service zu spät kam. Wählen Sie diesen Quartal einen Supportprozess aus und gestalten Sie ihn für Vorbeugung statt für Reaktion um. Wenn Sie mehr über M365 Co-Pilot Azure Sicherheit und KI-Betriebsmodelle erfahren möchten, abonnieren Sie M365 FM und hinterlassen Sie eine Bewertung. Vernetzen Sie sich mit mir, Mirko Pieter, auf LinkedIn mit dem nächsten Thema, das Sie besprechen möchten.