Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenDie Kundenbetreuung erhält in Sekunden eine Faktenkarte, statt die Technik zu unterbrechen
Wer Bereitschaft hat und was ausgefallen ist, in Teams
Meldungen aus der Überwachung erreichen Microsoft Teams bereits mit Dienst, Bereitschaft, betroffenen Kunden und offenen Tickets, und dieselben Fragen lassen sich im Kanal stellen.
Kurzfassung für die Geschäftsführung
Während einer Störung ist die Person, die sie behebt, auch die Einzige, die weiß, welche Kunden betroffen sind.
Wir verbinden Fakten, die bereits vorliegen, mit dem Kanal, in dem nach ihnen gefragt wird.
Die Bereitschaft ist nicht länger Vermittlungsstelle, sodass die Wiederherstellungszeit um die Minuten sinkt, die ins Antworten gingen.
Microsoft Teams Kanäle; die öffentliche Statusseite; Jira Service Management
Geschäftsproblem
Engineering
Eine Technikorganisation hat meist alle nötigen Fakten und keinen Weg, sie bereitzustellen. Bereitschaftspläne liegen im Paging-Werkzeug, das nur Ingenieure öffnen. Der Zustand der Dienste liegt in Azure Monitor und Application Insights, die Messwerte zeigen, keine Kundennamen. Die Zuordnung eines Dienstes zu den Kunden, die von ihm abhängen, liegt in einer Tabelle, die eine einzige Lösungsarchitektin pflegt. Kundentickets liegen im Service Desk, ohne Verbindung zur Störung.
Jede Störung erzeugt so eine zweite: die Flut von Fragen an genau die Leute, die die erste beheben. Die Kundenbetreuung rät, der Support sortiert Doppelmeldungen von Hand, die Statusseite hinkt der Wirklichkeit hinterher, und der Kunde erfährt aus der eigenen Überwachung oft mehr als von seinem Anbieter. Es bleibt so, weil jedes Werkzeug einem anderen Team gehört und keines von ihnen die Frage besitzt.
Die drei Fragen sind immer dieselben. Wer hat Bereitschaft für diesen Dienst, was ist gerade ausgefallen und welche Kunden sind betroffen. Niemand hat entschieden, dass ihre Beantwortung eine Aufgabe ist, also erledigt sie, wer der Tastatur am nächsten sitzt, und während einer Störung ist das genau die Person, die man nicht unterbrechen sollte.
Wie es heute läuft
Die folgende Abfolge zeigt eine Störung, bevor irgendetwas verbunden ist.
- MenschIn Azure Monitor löst eine Meldung aus, das Paging-Werkzeug ruft die Bereitschaft, die mit der Diagnose beginnt
- MenschDie Kundenbetreuung hört vom Kunden davon und fragt in drei Kanälen gleichzeitig
- WartezeitJemand rät, wer Bereitschaft hat; die richtige Antwort kommt nach der zweiten oder dritten Nachricht
- MenschDer Support erfasst Doppelmeldungen einzeln, jede beschreibt dasselbe Symptom anders
- MenschCustomer Success fragt die Technik, welche Kunden betroffen sind; die Architektin öffnet ihre Tabelle
- FehlerrisikoDie Statusseite wird spät und von Hand aktualisiert, sodass die Überwachung des Kunden schneller ist als der Anbieter
- WartezeitDer Verfügbarkeitsbericht entsteht nach dem Quartal aus dem Meldungsverlauf statt aus einem Datensatz
Warum der heutige Prozess mehr kostet, als sichtbar ist
Der teuerste Teil dieses Prozesses hat keine eigene Kostenstelle.
- Jede Frage an die Bereitschaft verlängert die Störung. Die Unterbrechung zahlt der Kunde in Minuten Ausfall, nicht eine Kostenstelle in Stunden.
- Doppelmeldungen kosten den Support zweimal: einmal beim Sortieren von neun Beschreibungen eines Fehlers und noch einmal, wenn neun Kunden neun leicht verschiedene Antworten erhalten.
- Langsame oder falsche Kundenkommunikation macht aus einer Störung eine Gutschriftsforderung oder ein Verlängerungsgespräch. Die technische Behebung allein tut das selten.
- Eine Architektin hält die Zuordnung von Diensten zu Kunden, also kann im Urlaub niemand sagen, wer betroffen ist, und die Antwort während einer Störung wird zum Raten mit einem Kundennamen daran.
- Nachträglich aus dem Meldungsverlauf zusammengesetzte Verfügbarkeit ist kein Nachweis. Bestreitet ein Kunde ein Serviceniveau, argumentieren beide Seiten aus der Erinnerung, und der Anbieter gibt meist nach.
Kosten des Nichthandelns
Die Kundenzahl bewegt diese Zeilen. Jeder neue Kunde vergrößert die Reichweite derselben Störung: Mehr Menschen fragen, mehr Doppelmeldungen kommen an, und dieselbe Person beantwortet sie alle, während sie den Fehler beheben soll. Neue Dienste vervielfachen Zuordnungen, die niemand pflegt, und der Support wächst dann mit den Doppelmeldungen statt mit den Kunden.
Die Kosten außerhalb der Tabelle sind die, auf die eine Leitung des Kundendienstes zuerst schaut. Eine Störung dauert länger, weil die behebende Person Fragen beantwortet hat; eine Gutschrift wird aus einem Vertrag gefordert, der Kommunikationszeiten festlegt; ein Kunde erfährt von der Störung aus der eigenen Überwachung. Die Architektin mit der Tabelle ist dasselbe Risiko in anderer Gestalt, und sie wird befördert oder geht wie alle anderen.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein illustrativer Softwareanbieter für die Logistik, 210 Beschäftigte, davon 60 in der Technik, der 1.400 Geschäftskunden von einer Plattform auf Azure mit Azure Monitor und Application Insights bedient. Die Bereitschaft läuft in einem Paging-Werkzeug, Kundentickets in Jira Service Management, der Kundenbestand im CRM.
Rund 320 operative Fragen im Monat in Microsoft Teams und etwa 9 kundenwirksame Störungen im Monat, jede mit einer Welle von Doppelmeldungen. Vertragliche Verfügbarkeitsberichte für die größten Kunden werden jedes Quartal von Hand erstellt.
Das Paging-Werkzeug postet die rohe Meldung, alle anderen fragen im Kanal, und über die Betroffenheit entscheidet die Tabelle. Nichts verbindet die Kundentickets mit der Störung, die sie beschreiben.
Die Bereitschaft ist Vermittlungsstelle und Behebung zugleich, und die einzige Person, die einen Dienst einem Kunden zuordnen kann, ist eine Lösungsarchitektin.
Meldungen kommen angereichert an: Dienst, Bereitschaft, betroffene Kunden, offene Tickets, alles auf einer Karte in Microsoft Teams. Dieselben Abfragen beantworten Fragen im Fragekanal, Doppelmeldungen werden verknüpft, und Verfügbarkeit wird ein Datensatz statt einer Rekonstruktion.
Im Modell werden die meisten operativen Fragen ohne Technik beantwortet, die Karte zur Kundenbetroffenheit liegt Minuten nach der Meldung vor, und der Quartalsbericht muss nicht mehr zusammengestellt werden. Durchgehend illustrativ; die Rechnung ist unsere, nicht die eines Kunden.
Vorgeschlagene Lösung
Wir verbinden Fakten, die bereits vorliegen, mit dem Kanal, in dem nach ihnen gefragt wird. Eine Alarmregel in Azure Monitor löst aus, ihre Action Group ruft Azure Logic Apps, und die Logic App startet über einen API-Trigger einen Auftrag in UiPath Orchestrator. Ein UiPath Robot erledigt dann, was heute ein Mensch tut: Er bestimmt den Dienst, liest aus einer Dienst-Kunden-Zuordnung in UiPath Data Fabric, welche Kunden davon abhängen, holt die Bereitschaft über einen mit Connector Builder gebauten Konnektor aus dem Paging-Werkzeug und zieht die offenen Tickets mit demselben Symptom aus Jira Service Management.
Heraus kommt eine Karte, keine rohe Meldung. Der Betriebskanal erhält Dienst, Bereitschaft, Ticketzahl und aktuellen Stand; Customer Success erhält dieselbe Störung ausgedrückt in Kundennamen und Vertragsstufen. Adaptive Cards aktualisieren sich an Ort und Stelle, sodass die Karte im Kanal mit der Störung Schritt hält, statt drei Nachrichten weiter oben zu versteinern. Muss etwas öffentlich gesagt werden, bestätigt Customer Success den Wortlaut in Teams, und der Roboter überträgt ihn auf die Statusseite und verknüpft die Doppelmeldungen mit der Störung.
Die zweite Hälfte ist leiser und beantwortet mehr Fragen als die Meldungen selbst. In einem eigenen Fragekanal kann jede Person eine kurze Anfrage stellen: Bereitschaft für einen Dienst, Status eines Dienstes, Betroffenheit eines Kunden, Stand eines Tickets. Der Nachrichten-Trigger des Microsoft Teams Konnektors startet dieselben Abfragen und liefert eine Faktenkarte zurück. Nichts wird erzeugt: Jede Antwort ist eine Abfrage, und nur der vertraut man in einer Störungsrunde. Power BI berichtet danach die Verfügbarkeit je Dienst und je Kunde aus dem Störungsdatensatz, und UiPath Insights zeigt, wie viele Fragen ohne Technik beantwortet wurden.
Alarmregeln, Action Groups und Verfügbarkeitstests in Azure Monitor und Application Insights; Microsoft Teams Kanäle und Adaptive Cards mit Universal Actions; API-Trigger, Warteschlangen und Prüfpfad in UiPath Orchestrator; der Nachrichten-Trigger des Microsoft Teams Konnektors
Die Dienst-Kunden-Zuordnung und den Roboter, der sie aktuell hält, die Anreicherungs- und Kartenlogik, die Befehle im Fragekanal, den Störungsdatensatz und den Verfügbarkeitsbericht
Connector-Builder-Konnektoren für das Paging-Werkzeug, die Statusseite und das CRM; UiPath Integration Service Konnektoren für Microsoft Teams, Jira und Microsoft Azure
So läuft der automatisierte Prozess
- AutomatisierungEine Azure Monitor Meldung löst aus, und ihre Action Group startet die Anreicherung über eine Logic App und einen Orchestrator API-Trigger
- SystemEin Roboter bestimmt den Dienst, liest die Bereitschaft aus dem Paging-Werkzeug und zieht die offenen Tickets mit demselben Symptom
- AutomatisierungKarten landen im Betriebs- und im Customer-Success-Kanal: Dienst, Bereitschaft, betroffene Kunden, offene Tickets, eine Ansicht
- MenschCustomer Success bestätigt den an Kunden gerichteten Wortlaut, bevor irgendetwas das Haus verlässt
- AutomatisierungDer Roboter aktualisiert die Statusseite, verknüpft die Doppelmeldungen mit der Störung und frischt die Karten bei jeder Änderung auf
- AutomatisierungWer im Fragekanal eine Frage stellt, erhält aus denselben Abfragen eine Faktenkarte zurück
- SystemDer Störungsdatensatz wird geschlossen, die Verfügbarkeit je Dienst und Kunde fortgeschrieben, der Quartalsbericht braucht keine Zusammenstellung
Modell der menschlichen Beteiligung
Die Automatisierung übernimmt
- Die Anreicherung jeder Meldung um Dienst, betroffene Kunden, Bereitschaft und offene Tickets
- Das Posten und Auffrischen der Karten im Betriebs- und im Customer-Success-Kanal
- Die Beantwortung der wiederkehrenden Fragen im Fragekanal aus denselben Abfragen
- Das Verknüpfen von Doppelmeldungen mit der Störung und die Pflege des Verfügbarkeitsdatensatzes
Menschen entscheiden
- Die Bereitschaft diagnostiziert und behebt; der Ablauf berührt diese Arbeit an keiner Stelle
- Customer Success gibt den Wortlaut frei, bevor sich die Statusseite ändert
- Das Plattformteam verantwortet die Dienst-Kunden-Zuordnung und jede Änderung daran
- Die Technikleitung entscheidet, was vertraglich als Störung zählt
Vorher und nachher
Systeme und Integrationen
Wo eine Regel reicht, nutzen wir kein Modell. Wo Urteilsvermögen nötig ist, entscheidet ein Mensch.
Eingänge
- Azure Monitor Alarmregeln
- Application Insights Verfügbarkeitstests
- der Plan aus dem Paging-Werkzeug
- Jira Service Management Tickets
- Abonnementdaten aus dem CRM
Automatisierungsebene
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service und Connector Builder
- UiPath Data Fabric
Zielsysteme
- Microsoft Teams Kanäle
- die öffentliche Statusseite
- Jira Service Management
- Power BI
Kontaktpunkte für Menschen: Freigabe des kundengerichteten Wortlauts in Microsoft Teams; der Fragekanal; die monatliche Durchsicht der Zuordnung durch das Plattformteam
Eingesetzte Technologien
Alarmregeln und Verfügbarkeitstests liefern das Signal; Action Groups starten die Anreicherung
AZiel der Action Group, das den Orchestrator API-Trigger aufruft
Areichern die Meldung an, führen die Abfragen aus, posten und frischen Karten auf, verknüpfen Doppelmeldungen, protokollieren jede Aktion
AKonnektoren für Microsoft Teams, Jira und Microsoft Azure; eigene Konnektoren für Paging-Werkzeug und Statusseite
Awo die Karten landen und die Fragen gestellt werden; der Nachrichten-Trigger beantwortet sie
Adie Dienst-Kunden-Zuordnung und der Störungsdatensatz, mit Verantwortung und Änderungshistorie
AVerfügbarkeit je Dienst und je Kunde, aufgebaut aus dem Datensatz statt aus dem Meldungsverlauf
Aohne Technik beantwortete Fragen, Zeit von der Meldung bis zur Karte der Kundenbetroffenheit
AIllustratives Wirtschaftlichkeitsmodell
Beginnen Sie damit, die Annahmen zu hinterfragen.
Fünfzehn Minuten sind nicht die Zeit einer Person; es ist die Zeit des Fragenden und des Antwortenden zusammen, weshalb sie für eine Frage mit einzeiliger Antwort großzügig wirkt. Der Anteil von 80 %, den der Assistent selbst klärt, steckt im Volumen, der Kalkulator rechnet also mit 256 Fragen im Monat statt mit 320, und 73 € sind Vollkosten je Technikstunde. Zwei Töpfe bleiben außerhalb des Kalkulators: die Koordination von 108 Störungen im Jahr zu je 40 Minuten für drei Personen, etwa 15.768 €, und 22 Doppelmeldungen je Störung zu je fünf Minuten Sortierung, etwa 7.326 €. 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
- Die Bereitschaft ist nicht länger Vermittlungsstelle, sodass die Wiederherstellungszeit um die Minuten sinkt, die ins Antworten gingen
- Die Kundenbetreuung erhält in Sekunden eine Faktenkarte statt zu raten, sodass Kunden die Wahrheit zuerst von ihrem Anbieter hören
- Der Support bearbeitet eine Störung statt neun Symptome, weil Doppelmeldungen beim Eintreffen verknüpft werden
- Die Statusseite bildet die Wirklichkeit binnen Minuten ab, weil ein Mensch nur noch einen vorbereiteten Wortlaut bestätigen muss
- Verfügbarkeit je Kunde wird zum Datensatz, sodass ein vertraglicher Bericht erzeugt und nicht unter Druck rekonstruiert wird
- Die Dienst-Kunden-Zuordnung wird zu einem gepflegten Bestand mit Verantwortung statt zur Tabelle einer einzelnen Architektin
Sicht der Geschäftsleitung
- Jede laufende Störung ist mit Kundenbetroffenheit und Verantwortung auf einer Karte sichtbar, ohne Anruf zur Klärung
- Unterbrechungen der Technik werden messbar, weil Fragen in einen Kanal gehen, der sie protokolliert
- Support und Technik teilen einen Störungsdatensatz, was den Streit darüber beendet, wie viele Tickets ein Ausfall erzeugt hat
- Die Frage der Geschäftsleitung nach der Verfügbarkeit des Vormonats wird aus Daten beantwortet statt in einer Sitzung
KPIs für die Geschäftsführung
Sicherheit und Governance
Ein Prüfer sollte jede Entscheidung nachvollziehen können.
- Der Roboter liest Überwachung, Pläne und Tickets mit ausschließlich lesenden Zugangsdaten; seine einzigen Schreibaktionen sind das Posten von Karten, das Verknüpfen von Tickets und das Aktualisieren der Statusseite
- Nichts erreicht die öffentliche Statusseite, ohne dass eine benannte Person den Wortlaut in Microsoft Teams bestätigt hat, und diese Bestätigung gehört zum Störungsdatensatz
- Kundennamen erscheinen in internen Kanälen, die auf Betrieb und Customer Success beschränkt sind, und werden von der Automatisierung nie auf eine öffentliche Fläche geschrieben
- Zugangsdaten liegen im Azure Key Vault und werden über den Credential Store des Orchestrators geholt; die Zuordnung ist eine geführte Data-Fabric-Entität mit Verantwortung und Änderungshistorie
- Der Störungsdatensatz wird unter einem Microsoft Purview Label für die Dauer eines möglichen Vertragsstreits aufbewahrt, und die Verarbeitung bleibt in Ihrem Microsoft 365 Tenant und der EU-Region der UiPath Automation Cloud
Warum jetzt
Unternehmensverträge halten zunehmend fest, wie schnell ein Kunde über eine Störung informiert werden muss, was Statuskommunikation von einer Höflichkeit in eine Klausel mit Gutschrift verwandelt
Azure Monitor und Application Insights tragen das Gesundheitssignal bereits, und ihre Action Groups starten eine Automatisierung direkt, sodass die Anreicherungsebene Konfiguration plus ein kleiner Bau ist statt eines Plattformprojekts
Die modellierten 4.672 € im Monat sind Technikzeit, die ins Antworten statt ins Beheben fließt, und genau diese Stunden lassen sich nicht nachkaufen, wenn eine Störung erst läuft
Relevante Führungsrollen
Ingenieure beheben, statt zu antworten, und der Zustand der Plattform wird für das Geschäft ohne Übersetzung sichtbar
Die Bereitschaftslast sinkt, und Unterbrechung wird eine gemessene Zahl statt einer wiederkehrenden Klage
Die Kundenbetroffenheit ist in Minuten bekannt, sodass operative Entscheidungen während einer Störung auf Fakten beruhen
Der Support bearbeitet eine Störung statt neun Tickets, und Kunden hören zuerst von ihrem Anbieter
Häufige Fragen und Einwände
Es postet die Meldung. Es sagt nicht, welche Kunden von dem Dienst abhängen, welche Tickets ihn bereits beschreiben oder wer sonst noch dasselbe fragt. Das Produkt ist die Anreicherung, nicht die Benachrichtigung.
Es ist der Kanal, den sie ohnehin nutzen, und neu ist, dass Antworten die Fragen ersetzen. Am meisten gewinnt die Kundenbetreuung, die die Technik gar nicht mehr fragen muss.
Einverstanden, und das bleibt so. Die Karte schlägt Wortlaut und Betroffenheit vor, eine benannte Person bestätigt, und der Roboter tippt, damit niemand unter Druck schreibt.
Wann diese Lösung nicht passt
- Keine Überwachung mit nach Diensten getaggten Alarmregeln; das Signal muss existieren und zuordenbar sein, bevor es angereichert werden kann
- Ein einzelnes Produkt mit einer Handvoll Kunden, wo die Bereitschaft es allen mit einer Nachricht sagen kann
- Weniger als etwa zwanzig Ingenieure, wo ein angehefteter Plan und ein Kanal das meiste davon schon leisten
Eine Frage für die nächste Sitzung
Wer konnte während der Störungen des letzten Monats die Frage „welche Kunden sind betroffen" beantworten, ohne die Person zu unterbrechen, die den Fehler behob?
Vorgehen bei der Umsetzung
Wir starten mit einem Ausschnitt und erweitern erst nach dem Nachweis.
Wir liefern
- Einen Monat Teams-Fragen und die letzten zehn Störungen, kategorisiert danach, was eine Karte enthalten muss, um zu nützen
- Die Dienst-Kunden-Zuordnung, aufgebaut aus CRM- und Abonnementdaten, mit benannter Verantwortung
- Den Anreicherungsroboter, die Karten, die Befehle im Fragekanal und den Schritt zur Statusseite
- Den Störungsdatensatz und einen Power BI Verfügbarkeitsbericht je Dienst und je Kunde
- Tests mit nachgespielten Störungen vor echten sowie eine kurze Anleitung für Kundenbetreuung und Support
Was wir von Ihnen brauchen
- Nach Diensten getaggte Alarmregeln sowie API-Zugang zum Paging-Werkzeug und zum Service Desk
- CRM- oder Abonnementdaten, die sagen, welcher Kunde welchen Dienst nutzt
- Eine benannte Verantwortung für die Zuordnung und eine Person in Customer Success, die Wortlaute freigibt
Etappen
Analyse
Ein Monat Fragen und zehn Störungen; der Inhalt jeder Karte mit den Fragenden abgestimmt
Design
Kartenlayouts, Befehlssatz, Eskalationsregeln, Modell der Zuordnung und deren Verantwortung
Bau
Anreicherungsroboter, Konnektoren, Teams-Karten, Störungsdatensatz und Verfügbarkeitsbericht
Validierung
Zuerst nachgespielte Störungen, dann echte Meldungen für ein Produkt, die alten Wege daneben
Inbetriebnahme
Volle Meldungsabdeckung, Fragekanal für Kundenbetreuung und Support geöffnet, Hypercare
Quick Win. Der Aufwand ergibt sich daraus, wie gut Alarmregeln nach Diensten getaggt sind, ob Paging-Werkzeug und Statusseite brauchbare APIs bieten, und wie viel Arbeit die erste Fassung der Zuordnung braucht.
Zwanzig Leute stellen drei Fragen; eine davon behebt zugleich den Fehler.
Nennen Sie uns die zehn Fragen, die Ihre Technik während einer Störung am häufigsten hört, und senden Sie einen Monat Störungs- und Ticketverlauf. Sie erhalten zurück, welche davon eine Karte allein beantwortet, und eine Schätzung der Unterbrechungszeit, die das erspart.
Zehn Störungsfragen sendenDer Nachbarprozess hat meist dasselbe Problem
Monatliche SLA-Berichte entstehen in Excel aus Ticketexporten, und die Gutschriften rechnet der Kunde zuerst aus.
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 ansehen Weitere LösungenStatus, Störung, Änderung: gemeldet, bevor jemand fragtDie Störungsmail geht nach der Störung raus, und jeder fünfte Ticketkommentar besteht aus denselben zwei Wörtern.
Lösung ansehenBranchen, in denen wir das am häufigsten umsetzenDienstleistungen & ITFinanzen & Versicherung