Start · Rozwiązania · Inne rozwiązania
Rozwiązanie · Inne rozwiązaniaOpiekun klienta dostaje kartę z faktami w kilka sekund, zamiast przerywać inżynierowi
Kto ma dyżur i co nie działa: odpowiedź w Teams
Alerty z monitoringu trafiają do Microsoft Teams już z usługą, inżynierem na dyżurze, listą dotkniętych klientów i otwartymi zgłoszeniami, a te same pytania można zadać na kanale.
Streszczenie dla zarządu
W czasie awarii osoba, która ją naprawia, jest też jedyną, która wie, których klientów dotyczy.
Łączymy fakty, które już istnieją, z kanałem, na którym się o nie pyta.
Dyżurny inżynier przestaje być centralą, więc czas przywrócenia usługi skraca się o minuty, które szły na odpowiadanie.
kanały Microsoft Teams; publiczna strona statusu; Jira Service Management
Problem biznesowy
Inżynieria
Organizacja inżynierska zwykle ma wszystkie potrzebne fakty i żadnego sposobu, by je podać. Grafiki dyżurów żyją w narzędziu paging, które otwierają wyłącznie inżynierowie. Kondycja usług żyje w Azure Monitor i Application Insights, które pokazują metryki, a nie nazwy klientów. Powiązanie usługi z klientami, którzy od niej zależą, żyje w arkuszu prowadzonym przez jednego architekta rozwiązań. Zgłoszenia klientów leżą w service desku, niepowiązane z incydentem.
Każda awaria wytwarza więc drugi incydent: falę pytań kierowanych do osób naprawiających pierwszy. Opiekunowie klientów zgadują, wsparcie ręcznie segreguje duplikaty, strona statusu jest opóźniona wobec rzeczywistości, a klient często dowiaduje się więcej z własnego monitoringu niż od dostawcy. Utrzymuje się to dlatego, że każde narzędzie należy do innego zespołu i żaden z nich nie jest właścicielem pytania.
Pytania są zawsze te same. Kto ma dyżur do tej usługi, co jest aktualnie niedostępne i których klientów to dotyczy. Nikt nie uznał, że odpowiadanie na nie jest pracą, więc robi to ten, kto akurat siedzi najbliżej klawiatury, a w czasie awarii jest to osoba, której nie należy przerywać.
Jak to wygląda dzisiaj
Poniższa sekwencja to obraz awarii, zanim cokolwiek zostanie połączone.
- CzłowiekW Azure Monitor odpala się alert, narzędzie paging dzwoni do dyżurnego inżyniera, który zaczyna diagnozę
- CzłowiekOpiekun klienta słyszy o problemie od klienta i pyta na trzech kanałach naraz
- OczekiwanieKtoś zgaduje, kto ma dyżur; prawidłowa odpowiedź pojawia się po drugiej albo trzeciej wiadomości
- CzłowiekWsparcie rejestruje duplikaty pojedynczo, każdy opisujący ten sam objaw inaczej
- CzłowiekCustomer success pyta inżynierię, których klientów to dotyczy; architekt rozwiązań otwiera swój arkusz
- Ryzyko błęduStrona statusu jest aktualizowana późno i ręcznie, więc monitoring klienta jest szybszy niż dostawca
- OczekiwanieRaport dostępności powstaje po kwartale z historii alertów, a nie z zapisu incydentów
Dlaczego obecny proces kosztuje więcej, niż widać
Najdroższa część tego procesu nie ma własnej pozycji kosztowej.
- Każde pytanie skierowane do dyżurnego inżyniera wydłuża awarię. Przerwanie płaci klient w minutach niedostępności, a nie żadne miejsce powstawania kosztów w godzinach.
- Duplikaty kosztują wsparcie dwa razy: raz przy segregowaniu dziewięciu opisów jednej usterki, drugi raz, gdy dziewięciu klientów dostaje dziewięć nieco innych odpowiedzi.
- Wolna albo błędna komunikacja z klientem zamienia awarię w roszczenie o karę umowną lub w rozmowę o odnowieniu. Sama naprawa techniczna rzadko to robi.
- Mapę usług i klientów trzyma jeden architekt, więc gdy jest na urlopie, nikt nie powie, kogo dotyczy problem, a odpowiedź w czasie incydentu staje się zgadywaniem z nazwiskiem klienta.
- Dostępność odtwarzana po fakcie z historii alertów nie jest dowodem. Gdy klient kwestionuje poziom usługi, obie strony argumentują z pamięci, a dostawca zwykle ustępuje.
Koszt zaniechania
To liczba klientów porusza tymi wierszami. Każdy nowy klient poszerza zasięg rażenia tej samej awarii: pyta więcej osób, przychodzi więcej duplikatów, a odpowiada na nie ten sam inżynier, próbując przy tym usunąć usterkę. Nowe usługi mnożą powiązania, których nikt nie utrzymuje, a etaty wsparcia rosną wtedy razem z duplikatami, a nie z liczbą klientów.
Koszty spoza tabeli są tymi, na które dyrektor obsługi klienta patrzy najpierw. Awaria trwa dłużej, bo naprawiający odpowiadał na pytania; kara umowna zostaje naliczona z umowy, która określa czasy komunikacji; klient dowiaduje się o incydencie z własnego monitoringu. Architekt trzymający mapę w arkuszu to to samo ryzyko w innej postaci, a awansuje albo odchodzi jak każdy.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Ilustracyjny dostawca oprogramowania dla logistyki, 210 pracowników, w tym 60 inżynierów, obsługujący 1 400 klientów biznesowych z platformy na Azure z Azure Monitor i Application Insights. Dyżury prowadzi narzędzie paging, zgłoszenia klientów Jira Service Management, bazę klientów CRM.
Około 320 pytań operacyjnych miesięcznie zadawanych w Microsoft Teams i mniej więcej 9 incydentów miesięcznie dotykających klientów, z których każdy wywołuje falę duplikatów. Umowne raporty dostępności dla największych klientów są składane ręcznie co kwartał.
Narzędzie paging publikuje surowy alert, cała reszta pyta na kanale, a o tym, kogo dotyczy problem, decyduje arkusz. Nic nie łączy zgłoszeń klientów z incydentem, który opisują.
Dyżurny inżynier jest naraz centralą i naprawiającym, a jedyną osobą potrafiącą powiązać usługę z klientem jest jeden architekt rozwiązań.
Alerty przychodzą wzbogacone: usługa, dyżurny inżynier, dotknięci klienci, otwarte zgłoszenia, wszystko na jednej karcie w Microsoft Teams. Te same odczyty odpowiadają na pytania z kanału pytań, duplikaty są łączone, a dostępność staje się zapisem zamiast rekonstrukcji.
W modelu większość pytań operacyjnych znajduje odpowiedź bez inżyniera, karta wpływu na klientów istnieje w kilka minut od alertu, a kwartalny raport dostępności nie wymaga składania. Wszystko ilustracyjnie; arytmetyka jest nasza, nie klienta.
Proponowane rozwiązanie
Łączymy fakty, które już istnieją, z kanałem, na którym się o nie pyta. Reguła alertu w Azure Monitor odpala się, jej action group wywołuje Azure Logic Apps, a Logic App uruchamia zadanie przez wyzwalacz API w UiPath Orchestrator. Robot UiPath robi potem to, co dziś robi człowiek. Ustala usługę, odczytuje z mapy usług i klientów w UiPath Data Fabric, którzy klienci od niej zależą, sprawdza dyżurnego inżyniera w narzędziu paging przez konektor z Connector Builder i pobiera z Jira Service Management otwarte zgłoszenia o tym samym objawie.
Powstaje z tego jedna karta, a nie surowy alert. Kanał operacyjny dostaje usługę, inżyniera, liczbę zgłoszeń i bieżący stan; customer success dostaje ten sam incydent wyrażony nazwami klientów i poziomami umów. Adaptive Cards aktualizują się w miejscu, więc karta na kanale nadąża za incydentem, zamiast stawać się skamieliną trzy wiadomości wyżej. Gdy trzeba coś powiedzieć publicznie, customer success potwierdza treść w Teams, a robot przepisuje ją na stronę statusu i wiąże duplikaty z incydentem.
Druga połowa jest cichsza i odpowiada na więcej pytań niż same alerty. Na dedykowanym kanale pytań każdy może wpisać krótką prośbę: dyżur do usługi, status usługi, wpływ na klienta, status zgłoszenia. Wyzwalacz wiadomości w konektorze Microsoft Teams uruchamia te same odczyty i zwraca kartę z faktami. Nic nie jest generowane: każda odpowiedź jest odczytem, a tylko takim ufa się na mostku incydentowym. Power BI raportuje potem dostępność w podziale na usługi i klientów z zapisu incydentów, a UiPath Insights pokazuje, ile pytań znalazło odpowiedź bez inżyniera.
Reguły alertów, action groups i testy dostępności Azure Monitor oraz Application Insights; kanały Microsoft Teams i Adaptive Cards z Universal Actions; wyzwalacze API, kolejki i dziennik audytowy UiPath Orchestrator; wyzwalacz wiadomości w konektorze Microsoft Teams
Mapę usług i klientów oraz robota, który utrzymuje jej rzetelność, logikę wzbogacania i kart, obsługę poleceń na kanale pytań, zapis incydentów i raport dostępności
Konektory z Connector Builder do narzędzia paging, strony statusu i CRM; konektory UiPath Integration Service do Microsoft Teams, Jiry i Microsoft Azure
Jak działa proces zautomatyzowany
- AutomatyzacjaAlert Azure Monitor odpala się, a jego action group uruchamia wzbogacanie przez Logic App i wyzwalacz API w Orchestratorze
- SystemRobot ustala usługę, odczytuje dyżurnego inżyniera z narzędzia paging i pobiera otwarte zgłoszenia o tym samym objawie
- AutomatyzacjaKarty trafiają na kanał operacyjny i do customer success: usługa, inżynier, dotknięci klienci, otwarte zgłoszenia, jeden widok
- CzłowiekCustomer success potwierdza treść skierowaną do klientów, zanim cokolwiek wyjdzie na zewnątrz
- AutomatyzacjaRobot aktualizuje stronę statusu, wiąże duplikaty z incydentem i odświeża karty wraz ze zmianą stanu
- AutomatyzacjaKażdy, kto zada pytanie na kanale pytań, dostaje kartę z faktami z tych samych odczytów
- SystemZapis incydentu zostaje zamknięty, dostępność usług i klientów zaktualizowana, a kwartalny raport nie wymaga składania
Model współpracy człowieka z automatem
Automatyzacja obsługuje
- Wzbogacanie każdego alertu o usługę, dotkniętych klientów, dyżurnego inżyniera i otwarte zgłoszenia
- Publikowanie i odświeżanie kart na kanale operacyjnym i u customer success
- Odpowiadanie na stałe pytania z kanału pytań na podstawie tych samych odczytów
- Wiązanie duplikatów z incydentem i utrzymywanie zapisu dostępności
Ludzie decydują
- Dyżurny inżynier diagnozuje i naprawia; przepływ w niczym tej pracy nie dotyka
- Customer success zatwierdza treść, zanim zmieni się strona statusu
- Zespół platformowy jest właścicielem mapy usług i klientów oraz każdej jej zmiany
- Kierownictwo inżynierii decyduje, co liczy się jako incydent na potrzeby umów
Przed i po
Systemy i integracje
Tam, gdzie wystarczy reguła, nie używamy modelu. Tam, gdzie potrzebny jest osąd, decyduje człowiek.
Wejścia
- reguły alertów Azure Monitor
- testy dostępności Application Insights
- grafik z narzędzia paging
- zgłoszenia Jira Service Management
- dane o subskrypcjach z CRM
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service i Connector Builder
- UiPath Data Fabric
Systemy docelowe
- kanały Microsoft Teams
- publiczna strona statusu
- Jira Service Management
- Power BI
Punkty styku z ludźmi: potwierdzenie treści dla klientów w Microsoft Teams; kanał pytań; miesięczny przegląd mapy przez zespół platformowy
Wykorzystane technologie
reguły alertów i testy dostępności dają sygnał; action groups uruchamiają wzbogacanie
Acel action group, który wywołuje wyzwalacz API Orchestratora
Awzbogacają alert, wykonują odczyty, publikują i odświeżają karty, wiążą duplikaty, rejestrują każdą operację
Akonektory Microsoft Teams, Jira i Microsoft Azure; konektory własne do narzędzia paging i strony statusu
Amiejsce, gdzie trafiają karty i padają pytania; wyzwalacz wiadomości na nie odpowiada
Amapa usług i klientów oraz zapis incydentów, z właścicielem i historią zmian
Adostępność w podziale na usługi i klientów, budowana z zapisu, a nie z historii alertów
Apytania obsłużone bez inżyniera, czas od alertu do karty wpływu na klientów
AIlustracyjny model ekonomiczny
Zacznijcie od kwestionowania założeń.
Piętnaście minut to nie czas jednej osoby; to czas pytającego i odpowiadającego razem, dlatego wygląda hojnie jak na pytanie z jednowierszową odpowiedzią. Udział 80 % pytań, które asystent rozstrzyga sam, jest wliczony w wolumen, więc kalkulator liczy 256 pytań miesięcznie zamiast 320, a 73 € to pełny koszt godziny inżyniera. Dwie pule zostają poza kalkulatorem. Pierwsza to koordynacja 108 incydentów rocznie po 40 minut dla trzech osób, około 15 768 €; druga to 22 duplikaty na incydent po pięć minut segregacji, około 7 326 €. Niczego tu nie zmierzono u klienta.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Dyżurny inżynier przestaje być centralą, więc czas przywrócenia usługi skraca się o minuty, które szły na odpowiadanie
- Opiekunowie klientów dostają kartę z faktami w kilka sekund zamiast zgadywać, więc klient najpierw słyszy prawdę od dostawcy
- Wsparcie obsługuje jeden incydent zamiast dziewięciu objawów, bo duplikaty są wiązane w miarę napływania
- Strona statusu odzwierciedla rzeczywistość w kilka minut, bo człowiek musi tylko potwierdzić treść przygotowaną przez kogoś innego
- Dostępność per klient staje się zapisem, więc raport umowny jest wytwarzany, a nie odtwarzany pod presją
- Mapa usług i klientów zmienia się w utrzymywany zasób z właścicielem, zamiast arkusza jednego architekta
Perspektywa zarządu
- Każdy aktywny incydent widać razem z wpływem na klientów i osobą odpowiedzialną na jednej karcie, bez telefonu po informacje
- Przerwania pracy inżynierów stają się mierzalne, bo pytania idą na kanał, który je rejestruje
- Wsparcie i inżynieria mają jeden zapis incydentu, co kończy spór o to, ile zgłoszeń wywołała awaria
- Pytanie zarządu o zeszłomiesięczną dostępność ma odpowiedź w danych, a nie w spotkaniu
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Audytor powinien móc odtworzyć każdą decyzję.
- Robot czyta monitoring, grafiki i zgłoszenia poświadczeniami tylko do odczytu; jedyne operacje zapisu to publikacja kart, wiązanie zgłoszeń i aktualizacja strony statusu
- Nic nie trafia na publiczną stronę statusu, dopóki wskazana osoba nie potwierdzi treści w Microsoft Teams, a to potwierdzenie jest częścią zapisu incydentu
- Nazwy klientów pojawiają się na kanałach wewnętrznych ograniczonych do operacji i customer success i nigdy nie są zapisywane przez automat na powierzchni publicznej
- Poświadczenia leżą w Azure Key Vault i są pobierane przez magazyn poświadczeń Orchestratora; mapa usług to nadzorowana encja Data Fabric z właścicielem i historią zmian
- Zapis incydentu ma retencję pod etykietą Microsoft Purview na czas ewentualnego sporu umownego, a przetwarzanie pozostaje w Państwa tenancie Microsoft 365 i regionie UE UiPath Automation Cloud
Dlaczego teraz
Umowy korporacyjne coraz częściej zapisują, jak szybko trzeba poinformować klienta o incydencie, co zamienia komunikację statusu z uprzejmości w zapis z karą umowną
Azure Monitor i Application Insights już niosą sygnał o kondycji usług, a ich action groups uruchamiają automatyzację wprost. Warstwa wzbogacania to więc konfiguracja i niewielka budowa, a nie projekt platformowy
Modelowe 4 672 € miesięcznie to czas inżynierów spędzony na odpowiadaniu zamiast na naprawie, a właśnie tych godzin nie da się dokupić, gdy awaria już trwa
Role kierownicze, których to dotyczy
Inżynierowie naprawiają, zamiast odpowiadać, a kondycja platformy staje się widoczna dla biznesu bez tłumaczenia
Obciążenie dyżurem spada, a przerwania pracy stają się mierzoną liczbą, a nie powracającą skargą
Wpływ na klientów jest znany w kilka minut, więc decyzje operacyjne w czasie incydentu zapadają na faktach
Wsparcie obsługuje jeden incydent zamiast dziewięciu zgłoszeń, a klient najpierw słyszy dostawcę
Częste pytania i zastrzeżenia
Publikuje alert. Nie mówi, którzy klienci zależą od usługi, które zgłoszenia już ją opisują ani kto jeszcze pyta o to samo. Produktem jest wzbogacenie, nie powiadomienie.
To kanał, którego już używają, a zmienia się to, że odpowiedzi zastępują pytania. Najwięcej zyskują opiekunowie klientów, którzy przestają o cokolwiek pytać inżynierów.
Zgoda i tak zostaje. Karta proponuje treść i wpływ, wskazana osoba potwierdza, a robot przepisuje, więc nikt nie pisze pod presją.
Kiedy to nie jest właściwe rozwiązanie
- Brak monitoringu z regułami alertów otagowanymi usługą; sygnał musi istnieć i dać się przypisać, zanim da się go wzbogacić
- Jeden produkt i garstka klientów, gdzie dyżurny inżynier po prostu powie wszystkim jedną wiadomością
- Mniej niż około dwudziestu inżynierów, gdzie przypięty grafik i jeden kanał robią większość tej pracy
Pytanie na najbliższe posiedzenie
Podczas zeszłomiesięcznych awarii kto mógł odpowiedzieć na pytanie „których klientów to dotyczy”, nie przerywając inżynierowi, który usuwał usterkę?
Podejście wdrożeniowe
Zaczynamy od jednego wycinka procesu i rozszerzamy dopiero po dowodzie.
Dostarczamy
- Miesiąc pytań z Teams i dziesięć ostatnich incydentów, skategoryzowanych pod kątem tego, co karta musi zawierać, by była użyteczna
- Mapę usług i klientów zbudowaną z danych CRM i subskrypcji, ze wskazanym właścicielem
- Robota wzbogacającego, karty, polecenia na kanale pytań i krok na stronie statusu
- Zapis incydentów oraz raport dostępności w Power BI per usługa i per klient
- Testy na odtworzonych incydentach przed rzeczywistymi oraz krótki przewodnik dla opiekunów klientów i wsparcia
Potrzebujemy od Państwa
- Reguł alertów otagowanych usługą oraz dostępu API do narzędzia paging i service desku
- Danych z CRM lub subskrypcji mówiących, który klient korzysta z której usługi
- Wskazanego właściciela mapy i jednej osoby w customer success, która potwierdza treści
Etapy
Analiza
Miesiąc pytań i dziesięć incydentów; zawartość każdej karty uzgodniona z tymi, którzy pytają
Projekt
Układ kart, zestaw poleceń, reguły eskalacji, model mapy i jej właścicielstwo
Budowa
Robot wzbogacający, konektory, karty w Teams, zapis incydentów i raport dostępności
Walidacja
Najpierw incydenty odtworzone, potem alerty na żywo dla jednego produktu, ze starymi nawykami obok
Uruchomienie
Pełne pokrycie alertów, kanał pytań otwarty dla opiekunów klientów i wsparcia, opieka powdrożeniowa
Szybki efekt. O nakładzie decyduje jakość otagowania reguł alertów usługą, to, czy narzędzie paging i strona statusu udostępniają użyteczne API, oraz ile pracy wymaga pierwsza wersja mapy usług.
Dwadzieścia osób zadaje trzy pytania; jedna z nich jednocześnie usuwa usterkę.
Prosimy o listę dziesięciu pytań, które najczęściej padają do inżynierów w czasie awarii, oraz o miesiąc historii incydentów i zgłoszeń. W zamian pokazujemy, na które z nich karta odpowiada sama, i szacujemy czas przerwań, który to usuwa.
Wyślij dziesięć pytań z awariiTen sam problem ma zwykle sąsiedni proces
Miesięczne raporty SLA powstają w Excelu z eksportów zgłoszeń, a kary umowne pierwszy wylicza klient.
Zobacz rozwiązanie Inne rozwiązaniaIncydenty obsadzone i zamknięte jednym procesemNarzędzie zapisuje, co się stało. Szukanie właścicieli, gonienie statusów i nieczytanie w piątek robią ludzie.
Zobacz rozwiązanie Inne rozwiązaniaStatusy, awarie i zmiany ogłaszane, zanim ktoś zapytaMail o awarii wychodzi po awarii, a co piąty komentarz w kolejce zgłoszeń to te same dwa słowa.
Zobacz rozwiązanieBranże, w których wdrażamy to najczęściejUsługi i ITFinanse i ubezpieczenia