Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenKategorie, Priorität und Zuständigkeit beim Eingang gesetzt, Eskalation läuft nach der Uhr
Tickets eingeordnet und zugewiesen, bevor jemand sie liest
Jedes Ticket, jede E-Mail und jede Teams-Nachricht erhält beim Eingang Kategorie, Priorität und Zuständigkeit aus Ihrer Matrix und wird per Timer eskaliert; Dispatcher entscheiden nur unsichere Fälle.
Kurzfassung für die Geschäftsführung
Die Priorität folgt den Großbuchstaben des Anfragenden, und ein P1 wartet, bis ein Dispatcher Zeit hat, es zu lesen.
Portal, die beiden Sammelpostfächer und der Teams-Kanal speisen UiPath Communications Mining, trainiert auf der eigenen Tickethistorie des Centers.
Tickets erreichen die richtige Gruppe innerhalb von Minuten nach Eingang statt nach der nächsten freien Minute des Dispatchers, in jeder Schicht.
ServiceNow (Tickets, Zuweisungsgruppen, CMDB); Power-BI-Dashboard
Geschäftsproblem
IT-Servicedesk
Triage ist eine Ermessensaufgabe, die unter Zeitdruck von demjenigen erledigt wird, der gerade frei ist, mit der vom Anfragenden gesetzten Priorität als Ausgangspunkt. Kategorien unterscheiden sich von Dispatcher zu Dispatcher, also unterscheidet sich auch die Weiterleitung, und ein Ticket in der falschen Gruppe verliert einen Tag, während zwei Gruppen es hin- und herschieben. Die Priorität spiegelt den Ton wider, nicht die geschäftliche Auswirkung, und so überholen Großbuchstaben einen Ausfall.
Eskalationsregeln stehen in einem Richtliniendokument, das darauf baut, dass jemand ein unbestätigtes P1 bemerkt, und in einer Schicht mit 300 neuen Tickets schaut niemand hin. Tickets, die per E-Mail oder im Teams-Kanal eingehen, haben weder Kategorie noch Priorität noch Gruppe, bis ein Mensch die Felder füllt; die Reaktionszeit des Desks ist also in Wahrheit die Lesezeit des Dispatchers.
Das Problem überlebt, weil Triage je Ticket billig aussieht und in der Summe unsichtbar bleibt: sechs Minuten für ein Ticket sind nichts; sechs Minuten für 6.400 Tickets sind eine Vollzeitstelle, die nichts löst. Die Werkzeuge gaben den Dispatchern ein Formular zum Ausfüllen, nichts, das für sie liest, und so kommt jeder neue Kanal als zusätzliches Lesen bei denselben Leuten an.
Wie es heute läuft
- SystemEin Ticket geht über das Portal, eines von zwei Sammelpostfächern oder den Teams-Kanal ein; Portaltickets tragen die Priorität des Anfragenden, die übrigen leere Felder
- WartezeitNeue Tickets liegen unzugewiesen, bis der Dispatcher der Schicht sie erreicht, nach der Besprechung und dem Rest der Warteschlange
- MenschDer Dispatcher öffnet jedes Ticket, liest es, rät die Kategorie, setzt eine Priorität und wählt eine Zuweisungsgruppe
- MenschDie Gruppenleitung weist einem Techniker zu; ein Ticket in der falschen Gruppe geht zurück und wird vom nächsten Dispatcher erneut gelesen
- FehlerrisikoEin P1, das niemand bestätigt hat, fällt erst auf, wenn der Anfragende „gibt es Neuigkeiten?“ ergänzt oder beim Desk anruft
- MenschEskaliert wird per Telefon oder Teams-Chat an die Leitung, die gerade antwortet, und die Priorität wird nachträglich korrigiert
- FehlerrisikoDer monatliche SLA-Bericht entsteht aus korrigierten Prioritäten und misst damit die aufgeräumte Version, nicht die, die die Anfragenden erlebt haben
Warum der heutige Prozess mehr kostet, als es scheint
Das Budget zeigt Stellen, nicht wofür sie draufgehen.
- Jedes fehlgeleitete Ticket wird zweimal gelesen, von zwei Gruppen, und der Anfragende verliert einen Tag, während es zurückwandert; nichts davon taucht in einer Zeiterfassung auf.
- Eine nach Ton gesetzte Priorität lässt einen Ausfall hinter einem Monitorwunsch warten, und teuer sind nicht die Minuten des Dispatchers, sondern die fünfzig Minuten von 300 Personen in der Lohnbuchhaltung.
- SLA-Kennzahlen auf Basis korrigierter Prioritäten zeigen Grün, während Anfragende Verzögerung erleben, und die Kapazität wird nach Kategorien geplant, die Dispatchergewohnheiten abbilden statt Nachfrage.
- Fehlt der Dispatcher, verschiebt sich die Reaktionszeit des ganzen Desks mit ihm: eine als Stelle getarnte Abhängigkeit von einer Person; ein zweiter Eingangskanal oder eine zweite Geschäftseinheit bedeutet einen zweiten Leser.
Kosten des Nichtstuns
Das Volumen wächst mit jeder Geschäftseinheit und jedem Eingangskanal, und jeder Zuwachs landet bei derselben Dispatcherschicht, sodass die Zeit bis zur Zuweisung länger wird und die Eskalationsrichtlinie seltener eingehalten wird. Das SLA-Reporting misst weiter korrigierte Prioritäten, sodass die Geschäftsführung Grün sieht, während die Anfragenden Verzögerung erleben, und die Nacharbeit wächst mit dem Volumen.
Erfahrene Dispatcher werden des Lesens müde und gehen, und der Desk stellt Leser ein statt Löser. Maklereskalationen bekommen dieselbe Lotterie wie interne Tickets, nun mit Reputationsrisiko. Binnen eines Jahres hat das Center mehr Tickets, dieselbe Latenz und eine Warteschlange, die niemand in einheitlichen Kategorien beschreiben kann.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Das Shared-Service-Center einer Versicherungsgruppe in Polen bearbeitet IT- und interne Servicetickets für 2.100 Beschäftigte sowie Eskalationen von Maklern in derselben ServiceNow-Instanz; Microsoft 365 E3.
Rund 6.400 Tickets im Monat über das Self-Service-Portal, zwei Sammelpostfächer und einen Teams-Kanal; die eigene Stichprobe des Centers zeigt, dass jedes achte Ticket bei der ersten Zuweisung fehlgeleitet wird und die Priorität bei einem Drittel der Störungen nachträglich korrigiert wird.
Ein Dispatcher je Schicht liest die Warteschlange nacheinander und weist nach eigenem Ermessen zu; eskaliert wird per Telefon; der SLA-Bericht entsteht monatlich aus korrigierten Prioritäten; im nächsten Jahr kommt eine zweite Geschäftseinheit mit demselben Dispatcherteam dazu.
Rund sechs Minuten Dispatcherzeit je Ticket, bevor irgendjemand daran arbeitet, und eine Warteschlange, deren Latenz der Verfügbarkeit einer einzigen Person entspricht.
UiPath Communications Mining liest jedes Ticket beim Eingang und sagt Kategorie, Dringlichkeit, betroffenen Service und die Schlüsselfelder vorher; ein Roboter wendet die Weiterleitungs- und Prioritätsmatrix des Centers an und aktualisiert ServiceNow über UiPath Integration Service; unsichere Fälle erreichen den Dispatcher als UiPath Action Center Aufgabe in Microsoft Teams; Orchestrator-Timer eskalieren unbestätigte P1 an die Gruppenleitungen in Teams.
Im Modellfall erhalten rund 85 von 100 Tickets Kategorie, Priorität und Zuweisung ohne Dispatcherentscheidung, sobald das Modell aus der Historie des Centers gelernt hat, die Trefferquote der ersten Zuweisung steigt, weil die Matrix in jeder Schicht gleich angewendet wird, und ein P1 wird nach der Uhr eskaliert; die Zahlen beschreiben ein Modell, keine Messung.
Vorgeschlagene Lösung
Portal, die beiden Sammelpostfächer und der Teams-Kanal speisen UiPath Communications Mining, trainiert auf der eigenen Tickethistorie des Centers. Für jeden neuen Eingang sagt es Anliegen, Dringlichkeit, betroffenen Service und Stimmung vorher und extrahiert, was ein Techniker braucht (Standort, Inventarnummer, betroffene Nutzer, Geschäftseinheit), jeweils mit einem Konfidenzwert. Es erkennt und extrahiert; es entscheidet nicht.
Die Entscheidung ist deterministisch und gehört dem Center. Ein Roboter wendet die Weiterleitungs- und Prioritätsmatrix an, deren Eigentümer der Servicemanager ist: betroffener Service und Nutzerzahl bestimmen die Priorität, Kategorie und Geschäftseinheit bestimmen die Zuweisungsgruppe. Er schreibt diese Felder über den Integration-Service-Konnektor in ServiceNow und ergänzt eine zweizeilige Zusammenfassung, die UiPath GenAI Activities aus dem Tickettext erzeugen, angezeigt über der Originalnachricht, nie an ihrer Stelle. Unterhalb der vereinbarten Konfidenzschwelle wird das Ticket zu einer Action Center Aufgabe für den Dispatcher in Microsoft Teams, mit vorbefüllter Vorhersage, und die Entscheidung des Dispatchers fließt in die nächste Trainingsrunde ein.
Eskalation läuft über Timer statt über Aufmerksamkeit: Zeittrigger in Orchestrator vergleichen Bestätigung und Lösung mit dem SLA je Priorität, und ein unbestätigtes P1 geht an die Gruppenleitung in Teams, danach an den Servicemanager. Diese Lösung löst nichts: Sie legt fest, was jedes Ticket ist, wie dringend es ist und wem es gehört, und behält dann die Uhr im Blick. Tier-1-Anfragen zu erledigen, bevor ein Ticket entsteht, und eine Störung bis zum Abschluss zu führen, sind eigene Lösungen.
Vorhersagen für Anliegen, Dringlichkeit und Felder mit Konfidenzwerten in UiPath Communications Mining; UiPath GenAI Activities (Summarize Text) unter AI-Trust-Layer-Richtlinien; Warteschlangen, Zeittrigger und Prüfpfad in UiPath Orchestrator; UiPath Integration Service Konnektoren für ServiceNow, Microsoft Outlook 365 und Microsoft Teams; UiPath Action Center Aufgaben, erledigt in Microsoft Teams; Power BI
Die Weiterleitungs- und Prioritätsmatrix als versionierte Regeln, den Roboter für die Ticketaktualisierung, die Konfidenzschwelle und die Dispatcheraufgabe, die Eskalationstimer und ihre Teams-Nachrichten, die Korrekturschleife zurück ins Training und das Power-BI-Dashboard
Zuordnung des Labels für den betroffenen Service zu Konfigurationselementen in der CMDB und ihren SLA-Definitionen in ServiceNow; Attribute des Anfragenden (Geschäftseinheit, Standort) aus Microsoft Entra ID über Microsoft Graph
So läuft der automatisierte Prozess
- AutomatisierungEin neues Ticket, eine Postfachnachricht oder ein Teams-Beitrag wird von einem Integration-Service-Ereignistrigger aufgegriffen und in Orchestrator eingereiht
- AutomatisierungCommunications Mining sagt Kategorie, Dringlichkeit, betroffenen Service und Stimmung vorher und extrahiert die Schlüsselfelder, jeweils mit Konfidenzwert
- SystemEin Roboter wendet die Weiterleitungs- und Prioritätsmatrix an und schreibt Kategorie, Priorität, Zuweisungsgruppe, die extrahierten Felder und die zweizeilige Zusammenfassung ins Ticket
- MenschEine Vorhersage unterhalb der Konfidenzschwelle wird zur Action Center Aufgabe in Microsoft Teams; der Dispatcher bestätigt oder korrigiert sie in Sekunden, und die Korrektur fließt in den nächsten Trainingssatz
- AutomatisierungZeittrigger in Orchestrator prüfen Bestätigung und Lösung gegen das SLA; ein nicht rechtzeitig bestätigtes P1 wird an die Gruppenleitung in Teams eskaliert, danach an den Servicemanager
- MenschGruppenleitungen handeln auf Eskalationen; der Servicemanager ist Eigentümer der Matrix und prüft monatlich Trefferquote und Korrekturen
- AutomatisierungJede Vorhersage, Regel und menschliche Entscheidung wird protokolliert, und das Power-BI-Dashboard zeigt Trefferquote, Korrekturen und SLA-Erfüllung je Gruppe
Zusammenspiel von Mensch und Automatisierung
Die Automatisierung übernimmt
- Das Lesen jedes Tickets, jeder E-Mail und jeder Chatnachricht beim Eingang, auf jedem Kanal
- Die Vorhersage von Kategorie, Dringlichkeit, betroffenem Service und Stimmung sowie die Extraktion der Felder, die der Techniker braucht
- Die Anwendung der Weiterleitungs- und Prioritätsmatrix, die Aktualisierung des Tickets und die Zusammenfassung
- Die zeitgesteuerte Eskalation, wenn Bestätigung oder Lösung die SLA-Schwelle überschreiten
Menschen entscheiden
- Über Tickets mit geringer Konfidenz, mit angezeigter Vorhersage und einem Klick zum Bestätigen oder Ändern
- Über die Weiterleitungsmatrix und die Prioritätsdefinitionen, verantwortet von einem namentlich benannten Servicemanager
- Was geschieht, sobald eine Eskalation die Gruppenleitung erreicht
- Über die monatliche Prüfung von Trefferquote, Korrekturen und Modelldrift und darüber, wann ein nachtrainiertes Modell live geht
Vorher und nachher
Systeme und Integrationen
Jeder Eintrag lässt sich in der Herstellerdokumentation prüfen. Die Evidenzklasse steht daneben.
Eingänge
- ServiceNow-Self-Service-Portal
- zwei Outlook-Sammelpostfächer
- der IT-Support-Kanal in Microsoft Teams
Automatisierungsschicht
- UiPath Communications Mining
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
- UiPath GenAI Activities
Zielsysteme
- ServiceNow (Tickets, Zuweisungsgruppen, CMDB)
- Power-BI-Dashboard
Berührungspunkte für Menschen: Action Center Aufgaben in Microsoft Teams für unsichere Tickets; Eskalationsnachrichten an Gruppenleitungen in Teams; die Warteschlange des Technikers in ServiceNow mit der Zusammenfassung obenauf
Eingesetzte Technologien
sagt Kategorie, Dringlichkeit, betroffenen Service und Stimmung vorher; extrahiert Felder mit Konfidenzwerten
Awenden die Matrix an, aktualisieren Tickets, führen die SLA-Zeittrigger aus, wiederholen, protokollieren und auditieren
AEreignistrigger für neue Tickets und Mails, Feldaktualisierungen, Eskalationsnachrichten in Teams
ADispatcherentscheidungen zu unsicheren Tickets, ohne Teams zu verlassen
Adie zweizeilige Zusammenfassung, die ein Techniker zuerst liest, unter AI-Trust-Layer-Richtlinien
AAttribute des Anfragenden und Gruppenzugehörigkeit für die Weiterleitungsregeln
ATrefferquote der Weiterleitung, Korrekturen, Zeit bis zur Zuweisung und SLA-Erfüllung je Gruppe
AIllustratives Wirtschaftlichkeitsmodell
Die Rechnung ist offen, damit man ihr widersprechen kann.
Lesen, Entscheiden und Ziehen: mehr decken die sechs Minuten nicht ab; die Arbeit des Technikers bleibt außerhalb dieser Tabelle. Der Kalkulator bepreist nur den Anteil, den das Modell ohne Dispatcherentscheidung bearbeitet, 85 von 100 Tickets, daher steht unten 5.440 statt 6.400 als Volumen; dieser Anteil wird nach dem Training auf den eigenen Tickets des Centers erreicht und beginnt niedriger. 39 € ist ein vollbelasteter Stundensatz in einem mitteleuropäischen Shared-Service-Center. Die Nacharbeit hinter fehlgeleiteten Tickets ist stattdessen in der Tabelle zu den Kosten des Nichtstuns bepreist: 768 Tickets im Monat × 15 Minuten in zwei Gruppen = 192 h, also 7.488 € im Monat. Nichts davon wurde bei einem Kunden gemessen.
Rechnen Sie mit Ihren Zahlen
Eine illustrative Schätzung aus Ihren Eingaben. Sie modelliert freigesetzte Kapazität und verspricht keine Einsparung.
Geschäftlicher Nutzen
- Tickets erreichen die richtige Gruppe innerhalb von Minuten nach Eingang statt nach der nächsten freien Minute des Dispatchers, in jeder Schicht
- Die Priorität spiegelt die geschäftliche Auswirkung wider, weil die Regeln den betroffenen Service und die Nutzerzahl lesen, nicht die Betreffzeile
- Fehlleitungen sinken, und mit ihnen der Tag, den ein Ticket verliert, während zwei Gruppen es hin- und herschieben
- Ein P1 wird nach der Uhr eskaliert, sodass niemand einen unbestätigten Ausfall aus einem „gibt es Neuigkeiten?“-Kommentar erfährt
- Dispatcher wechseln vom Lesen von allem zum Entscheiden der schwierigen Fälle und zur Pflege der Matrix, dem Teil, der ihre Erfahrung brauchte
- Eine zweite Geschäftseinheit oder ein neuer Eingangskanal kommt durch Training des Modells und Erweiterung der Matrix hinzu, nicht durch die Einstellung eines weiteren Lesers
Aus Sicht der Geschäftsführung
- Triage wird zu einem gemessenen Schritt: Trefferquote der Weiterleitung, Korrekturquote, Zeit bis zur Zuweisung und SLA-Erfüllung je Gruppe, aus Ticketdaten statt aus Anekdoten
- Eskalation wird von einer Richtlinie, an die sich jemand erinnert, zu einer Kontrolle, die ausgeführt wird, mit einem Protokoll jedes Alarms und dessen, wer darauf reagiert hat
- Die Kapazität wird nach Kategorien geplant, die in jeder Schicht dasselbe bedeuten, sodass ein Trend in den Zahlen ein Trend in der Nachfrage ist
- Die Warteschlange des Dispatchers enthält nur die Fälle, bei denen das Modell unsicher war, und ihre Größe zeigt, wie gut die Matrix zur Wirklichkeit passt
KPIs für die Geschäftsführung
Sicherheit und Governance
Vertrauen in Automatisierung entsteht durch den Prüfpfad, nicht durch ein Versprechen.
- Tickettexte enthalten oft personenbezogene Daten, deshalb maskieren AI-Trust-Layer-Richtlinien persönliche Identifikatoren vor jedem Modellaufruf, beschränken Modelle auf Ihre Freigabeliste und legen das LLM-Regionsrouting fest; Communications Mining läuft in der EU-Region der UiPath Automation Cloud, und die Ticketdaten bleiben in Ihrem Tenant
- Das Servicekonto des Roboters darf Kategorie, Priorität, Gruppe und Zusammenfassungsfelder in den definierten Warteschlangen ändern und sonst nichts: Es kann weder schließen noch löschen noch einer Person zuweisen, und sein Geheimnis liegt in einem Credential Store, nicht im Workflow
- Jede Vorhersage, jeder Konfidenzwert, jede ausgelöste Regel und jede menschliche Korrektur wird ins Prüfprotokoll geschrieben, sodass ein Prüfer nachvollziehen kann, wie und von wem ein Ticket seine Priorität erhielt
- Die Weiterleitungsmatrix und die Prioritätsdefinitionen sind versioniert und werden nur von ihrem benannten Eigentümer geändert; ein nachtrainiertes Modell geht erst nach der monatlichen Prüfung der Korrekturen live; Maklereskalationen werden beim Eingang gekennzeichnet und unter Ihren Aufbewahrungsrichtlinien in Microsoft Purview geführt
Warum jetzt
Der Auslöser ist meist eine Konsolidierung: eine zweite Geschäftseinheit, ein zusammengelegter Desk oder ein neuer Eingangskanal, den das heutige Dispatcherteam nicht mehr lesen kann; hier kommt die zweite Einheit im nächsten Jahr, zusätzlich zu den modellierten 21.216 € im Monat für das Lesen durch Dispatcher
Communications Mining liest E-Mails, Tickets und Chats in einem Modell, und die Integration-Service-Konnektoren für ServiceNow und Jira transportieren Ereignisse in beide Richtungen, sodass die Triage neben dem Ticketsystem läuft, ohne Migration
Makler- und Partnereskalationen teilen sich heute die Warteschlange mit internen Tickets, und ein Partner, der fünfzig Minuten auf eine Bestätigung wartet, erzählt es weiter
Relevante Führungsrollen
Die SLA-Erfüllung wird zu einer echten Zahl statt zu einem Bericht auf Basis korrigierter Prioritäten, und der Desk nimmt eine zweite Geschäftseinheit ohne zweite Dispatcherschicht auf
Techniker erhalten korrekt weitergeleitete und zusammengefasste Tickets, sodass ihr erster Zugriff Arbeit ist und nicht Lesen
Dieselbe Triageschicht bedient die Warteschlangen von HR, Finanzen und Gebäudemanagement, sobald die IT sie an eigenen Tickets bewiesen hat
Makler- und Partnereskalationen werden nach Auswirkung priorisiert und gehen nie hinter internem Rauschen verloren
Häufige Fragen und Einwände
Die Vielfalt ist der Grund, ein Modell statt Stichwortregeln zu nutzen. Der Schattenbetrieb zeigt die Trefferquote auf Ihren eigenen Tickets, bevor etwas geschrieben wird, und unterhalb der Schwelle geht ein Ticket mit angehängter Vorhersage an einen Menschen.
Einige davon klassifizieren Tickets, die über das Portal eingehen. Wenige lesen zwei Sammelpostfächer und einen Teams-Kanal, wenden Ihre Matrix statt ihrer eigenen an, eskalieren per Timer und übergeben unsichere Fälle mit Belegen an einen Menschen; wo die Plattformfunktion einen Schritt abdeckt, nutzen wir sie.
Sie hören auf, 6.400 Tickets zu lesen, und beginnen, die zu entscheiden, bei denen das Modell unsicher ist, pflegen die Matrix und prüfen die Trefferquote, also den Teil, der sie brauchte; hier ist die freigesetzte Kapazität das, was die zweite Geschäftseinheit benötigt.
Wann diese Lösung nicht passt
- Weniger als etwa tausend Tickets im Monat oder Tickets, die ausschließlich über ein Portal eingehen, dessen Pflichtfelder tatsächlich gefüllt werden: ein paar Regeln kosten weniger als ein Modell
- Keine brauchbare Tickethistorie zum Trainieren oder eine Migration des Ticketsystems in den nächsten Monaten; dann bauen wir nach der Migration
- Niemand lässt sich als Eigentümer der Weiterleitungsmatrix benennen; ohne Eigentümer lernt das Modell die Inkonsistenz von gestern und behält sie bei
Eine Frage für die nächste Sitzung
Die zehn jüngsten P1-Tickets: Welche davon waren ein P1, bevor ein Mensch sie gelesen hat, und wie lange lief die Uhr schon, als jemand entschied?
Vorgehen bei der Umsetzung
Die Umsetzung läuft in Etappen, damit sie jederzeit gestoppt werden kann.
Wir liefern
- Analyse eines Quartals an Tickets: Trefferquote der Weiterleitung, Zeit bis zur Zuweisung, die Matrix, wie sie tatsächlich angewendet wird
- Training von Communications Mining auf Ihrer Tickethistorie, mit Labeling-Sitzungen für Ihre Dispatcher
- Die Prioritäts- und Weiterleitungsregeln, die Konfidenzschwelle und das Ausnahmedesign für unsichere Tickets
- Integration mit ServiceNow oder Jira Service Management, den Sammelpostfächern und dem Teams-Kanal
- Eskalationstimer, die Dispatcheraufgabe in Teams, Tests im Schattenbetrieb und Einführung Gruppe für Gruppe
- Das Power-BI-Dashboard, Dokumentation, Dispatcherschulung und laufende Überwachung
Wir brauchen von Ihnen
- Einen Ticketexport über mindestens ein Quartal mit Kategorien, Gruppen, Prioritäten und Neuzuweisungshistorie
- Einen Dispatcher als Product Owner und eine abgestimmte Prioritätsmatrix
- Ein ServiceNow-Servicekonto, beschränkt auf Feldaktualisierungen in den betreffenden Warteschlangen, sowie Zugriff auf die Postfächer und den Teams-Kanal
Etappen
Analyse
Ausgangswerte aus dem Ticketexport: Trefferquote der Weiterleitung, Zeit bis zur Zuweisung, die heute angewendete Matrix
Design
Labelset, Prioritäts- und Weiterleitungsregeln, Konfidenzschwelle, Eskalationszeiten, Sicherheitsmodell
Training
Modelltraining auf historischen Tickets, Labeling einer Kalibrierungsstichprobe durch Dispatcher, Feinjustierung der Schwelle
Schattenbetrieb
Das Modell sagt auf Live-Tickets vorher, während Dispatcher weiterhin zuweisen, bis die Pilotgruppe die vereinbarte Trefferquote erreicht
Go-live
Der Roboter beginnt, Felder für die Pilotgruppe zu schreiben, dann für weitere Gruppen und Kanäle, mit Hypercare
Optimierung
Monatliche Prüfung der Korrekturen, Nachtraining, Matrixänderungen, Anbindung der zweiten Geschäftseinheit
Abteilungsweit. Der Aufwand hängt an der Zahl der Zuweisungsgruppen und wirklich verschiedenen Kategorien, an der Brauchbarkeit der Tickethistorie als Trainingsmaterial und daran, wie viele Eingangskanäle Freitext tragen.
Das Ticket mit DRINGEND wünscht einen Monitor. Der Ausfall steht unter „Frage“.
Senden Sie uns 500 anonymisierte Tickets aus dem letzten Quartal mit der Gruppe, in der jedes zuletzt gelandet ist. Sie erhalten den Anteil, den das Modell korrekt kategorisiert, die Fälle, in denen weiterhin ein Dispatcher entscheiden würde, und ein kurzes Auswertungsgespräch zu den Zahlen.
Das Modell an 500 Ihrer Tickets testenDer Nachbarprozess hat meist dasselbe Problem
Ihre besten Mitarbeitenden sortieren morgens Post, statt sie zu beantworten.
Lösung ansehen Weitere LösungenDie IT-Anfrage, die nie zum Ticket wirdVier von zehn IT-Tickets folgen einer bekannten Prozedur, und jedes wartet trotzdem in der Schlange auf einen Analysten.
Lösung ansehen Weitere LösungenStörungen und Änderungen in einem einzigen AblaufDas Werkzeug protokolliert. Verantwortliche suchen, Status nachhalten und freitags nichts lesen erledigen Menschen.
Lösung ansehenBranchen, in denen wir das am häufigsten umsetzenProduktion & IndustrieTransport & LogistikDienstleistungen & ITShared Services