Automatyzacje dla operatora telekomunikacyjnego — scenariusz wdrożenia

Abonent regionalnego operatora zgłasza brak internetu tam, gdzie mu wygodnie: dzwoni do biura, wypełnia formularz, pisze e-mail albo zostawia komentarz na profilu w mediach społecznościowych. Każdy z tych kanałów ma inny format i innego adresata, a część zgłoszeń dotyczy tego samego zdarzenia — jednej awarii na odcinku sieci. Dyżurny musi najpierw zorientować się, ile to jest naprawdę różnych spraw, potem ustalić, czy to awaria masowa, czy problem u jednego abonenta, i dopiero wtedy przypisać ekipę. W godzinach szczytu ta praca wstępna potrafi zająć więcej niż samo rozwiązanie problemu, a abonent przez ten czas nie dostaje żadnej informacji zwrotnej.

Większość ofert automatyzacji obsługi klienta zaczyna się w tym miejscu od chatbota na stronie. Naszym zdaniem dla operatora sieci to najgorszy możliwy punkt startu, z powodu, który wystarczy powiedzieć na głos: abonent, któremu przestał działać internet, nie wejdzie na Waszą stronę. Zgłoszenia przychodzą telefonem i wiadomością z komórki, więc automatyzacja, która nie obejmuje tych dwóch kanałów, poprawia statystyki widżetu, a nie pracę dyżurnego. Uważamy też, że nie każdy kanał trzeba automatyzować — czasem tańsze i uczciwsze jest zamknięcie kanału i przekierowanie ludzi tam, gdzie ktoś naprawdę odpowiada, i taką rekomendację również zdarza nam się wypowiedzieć.

• Zgłoszenia o tej samej awarii wpływają równolegle kilkoma kanałami
• Część zgłoszeń nie zawiera danych, których potrzebuje ekipa techniczna: adresu, numeru umowy, opisu objawów
• Zapytania o ofertę i o dostępność usługi mieszają się ze zgłoszeniami awarii
• Wiadomości z mediów społecznościowych bywają zauważane najpóźniej
• Przypomnienia o płatnościach i o kończącej się umowie wysyłane są ręcznie albo wcale
• Nie ma jednego miejsca, w którym widać status wszystkich otwartych spraw

Sensowny pilotaż nie obejmuje całej obsługi abonenta, tylko jeden strumień — najczęściej zgłoszenia awarii, bo tam efekt widać najszybciej. Agent w takim scenariuszu zbiera zgłoszenia z uzgodnionych kanałów, sprowadza je do wspólnego formatu, dopytuje o brakujące dane i grupuje zgłoszenia dotyczące tego samego obszaru sieci. Dopiero tak przygotowaną sprawę pokazuje dyżurnemu, razem z proponowaną kwalifikacją. Człowiek zatwierdza albo poprawia — a to zatwierdzenie jest jednocześnie materiałem, na którym mierzymy jakość klasyfikacji, więc pomiar nie wymaga osobnej pracy. Trzymamy się zasady, że agent proponuje, a nie rozstrzyga, i nie jest to ostrożność na pokaz: przy awariach koszt pomyłki ponosi abonent, który czeka, a nie system, który się pomylił.

1. 01Jeden wspólny wlotFormularz, skrzynka, wiadomości z profilu i notatki z rozmów telefonicznych trafiają do jednej kolejki o wspólnej strukturze.
2. 02Uzupełnienie danychAgent sprawdza, czy zgłoszenie ma adres, dane abonenta i opis objawów. Jeśli czegoś brakuje, wysyła jedno pytanie zwrotne w tym samym kanale, w którym przyszło zgłoszenie.
3. 03Wstępna kwalifikacjaZgłoszenie dostaje proponowaną kategorię: awaria masowa, usterka u abonenta, zapytanie o ofertę, sprawa rozliczeniowa. Propozycja idzie do zatwierdzenia, nie do automatycznego wykonania.
4. 04Grupowanie i przypisanieZgłoszenia z tego samego obszaru łączone są w jedną sprawę, a ta trafia do właściwej ekipy według reguł ustalonych z operatorem.
5. 05Informacja zwrotnaAbonent dostaje potwierdzenie przyjęcia i status sprawy, a przy awarii masowej — jedną wspólną komunikację zamiast kilku różniących się odpowiedzi.

Poza zgłoszeniami awarii nadają się w takiej firmie pod automatyzację jeszcze trzy rzeczy: sprawdzanie dostępności usługi pod adresem, obsługa zapytań o ofertę i przedłużenie umowy oraz przypomnienia o płatnościach. Sprawdzanie dostępności to pytanie o zasięg sieci pod konkretnym adresem — agent może odpowiedzieć na podstawie danych, które operator już ma, i przekazać kontakt do handlowca wtedy, gdy adres jest poza zasięgiem. Przypomnienia o płatnościach da się prowadzić automatycznie, ale ich treść, terminy i moment zaprzestania ustala operator, bo to bezpośrednia komunikacja z abonentem. Mamy tu wyraźne zdanie: przypomnienie o płatności to nie jest windykacja i nie zbudujemy automatu, którego zadaniem jest naciskać. Jedno uprzejme przypomnienie przed terminem załatwia większość spraw, a sekwencja kilkunastu wiadomości kosztuje naszym zdaniem więcej w utraconym zaufaniu abonenta, niż odzyskuje w płatnościach.

Warstwę techniczną dobieramy pod to, co operator już ma: Make lub n8n na przepływy, Node.js i TypeScript tam, gdzie logika wychodzi poza gotowe bloki, Next.js i React na panel, Vercel do hostowania, Google Workspace na zestawienia. Nie wymieniamy działającego systemu obsługi zgłoszeń po to, żeby dołożyć do niego automatyzację — migracja rejestru zgłoszeń to osobny projekt z własnym ryzykiem i uważamy za nieuczciwe przemycanie go w projekcie automatyzacji. Jeżeli operator pracuje na systemie, który da się odpytać, automatyzacja ma go obudować, a nie zastąpić; jeżeli nie da się go odpytać, mówimy o tym na starcie, zamiast odkrywać to w połowie wdrożenia.

Operator ma w tej sytuacji przewagę: większość danych potrzebnych do pomiaru już u niego jest, w rejestrze zgłoszeń i w systemie billingowym. Punkt odniesienia zbieramy przed uruchomieniem pilotażu, z okresu porównywalnego sezonowo — inaczej porównamy zimę z latem i wyjdzie z tego nieporozumienie. Poniżej zestaw wskaźników, od którego zaczynamy rozmowę. Kolumna z wartościami jest pusta świadomie: nie prowadzimy wdrożenia automatyzacji u operatora telekomunikacyjnego, więc nie mamy czego w niej wpisać. Wolimy pokazać pustą tabelę niż case study z procentami, których nikt nie może zweryfikować — takich liczb każdy czytelnik widział już dosyć i uważamy, że dawno przestały cokolwiek znaczyć. Sprawdzalne jest to, co zamierzamy liczyć i skąd, i to jest jedyna część oferty, którą da się ocenić przed podpisaniem umowy.

Jeden wskaźnik z tej tabeli traktujemy inaczej niż resztę. Czas oczekiwania abonenta na pierwszą odpowiedź jest jedynym, który abonent naprawdę odczuwa — i jeśli po pilotażu poprawi się tylko on, uznamy wdrożenie za udane, nawet gdy pozostałe liczby wyjdą przeciętnie. Jest też sytuacja, w której odradzimy start: jeżeli operator nie prowadzi dziś żadnego rejestru zgłoszeń, nie ma z czym porównać wyniku, a wtedy pierwszym projektem powinien być rejestr, a nie agent. Powiemy to na rozmowie, choć jest to rekomendacja tańsza dla klienta i wyraźnie gorsza dla nas.

Zacznijmy od rozbrojenia obietnicy, którą łatwo tu usłyszeć: agent nie skróci czasu naprawy przerwanego światłowodu. To praca ekipy w terenie i żadne oprogramowanie tego nie zmieni. Skróci czas, w którym nikt jeszcze nie wie, że światłowód jest przerwany, oraz czas, w którym abonent nie wie, że ktokolwiek się jego sprawą zajął. Te dwie rzeczy bywają w ofertach mylone, a różnią się wszystkim, łącznie z tym, ile są warte. Dalej idą granice twarde. Dane abonentów to dane osobowe, a operator telekomunikacyjny podlega dodatkowo obowiązkom związanym z tajemnicą telekomunikacyjną. Agent pracuje więc na minimalnym zakresie danych potrzebnym do obsługi sprawy, w środowisku uzgodnionym z operatorem, a zakres przetwarzania trzeba opisać przed uruchomieniem, nie po. Druga granica dotyczy decyzji: rozwiązanie umowy, zmiana warunków, rozliczenie, korekta faktury, odstąpienie od naliczenia — to zostaje u człowieka, a agent może co najwyżej przygotować sprawę do decyzji. Trzecia jest techniczna: agent nie ma wglądu w stan sieci, jeśli operator mu go nie udostępni, więc rozpoznanie awarii masowej opiera się na zgłoszeniach, a nie na pomiarze.

• Nie rozwiązuje umów i nie zmienia warunków abonamentu
• Nie podejmuje decyzji o rozliczeniach, korektach i ulgach
• Nie udostępnia danych abonenta w kanale, w którym nie da się potwierdzić tożsamości
• Nie zastępuje ekipy technicznej w ocenie, co wydarzyło się na sieci
• Nie wysyła komunikacji o awarii masowej bez zatwierdzenia przez dyżurnego
• Nie prowadzi windykacji — przypomnienie o płatności to nie jest postępowanie

Jedną z tych granic utrzymamy także wtedy, gdy klient poprosi o jej zniesienie. Komunikat o awarii masowej nie wychodzi bez zatwierdzenia człowieka. Rozpoznanie awarii masowej z samych zgłoszeń jest z natury niepewne, a jedna błędna informacja rozesłana do wszystkich abonentów kosztuje więcej niż cały czas dyżurnego, który mieliśmy zaoszczędzić — i kosztuje w walucie, której nie da się odzyskać, czyli w zaufaniu. Jeżeli warunkiem projektu ma być pełna automatyzacja tej komunikacji, nie jesteśmy właściwym wykonawcą i powiemy to wprost, zamiast zgodzić się i cicho liczyć, że nic się nie wydarzy.

Najgroźniejszy w tym scenariuszu jest błąd grupowania. Jeśli agent scali dwa różne zdarzenia w jedną sprawę, druga awaria znika z widoku i nikt jej nie szuka, bo formalnie jest już obsłużona — a to stan gorszy niż bałagan sprzed wdrożenia, bo bałagan przynajmniej widać. Drugie ryzyko jest miękkie: pytanie zwrotne o brakujące dane, wysłane do abonenta, który czeka trzecią godzinę bez internetu, potrafi zaszkodzić bardziej niż brak odpowiedzi. Dlatego reguły dopytywania ustalamy razem z operatorem i ograniczamy je do jednego pytania, nawet jeśli technicznie dałoby się zadać cztery. Trzecie ryzyko to rozrost zakresu w trakcie — skoro agent już czyta zgłoszenia, to niech przy okazji obsłuży sprzedaż; kończy się to projektem bez daty końca i bez wskaźnika, który cokolwiek rozstrzyga.

• Operator oczekuje, że agent zastąpi dyżurnego, zamiast przygotować mu sprawę do decyzji
• Warunkiem projektu jest automatyczna komunikacja o awarii masowej bez zatwierdzenia człowieka
• Nie istnieje żaden rejestr zgłoszeń — wtedy pierwszym projektem powinien być rejestr, nie agent
• Dane abonentów miałyby trafiać poza uzgodnione środowisko bez opisanego zakresu przetwarzania
• Zadaniem automatu ma być prowadzenie windykacji, a nie przypominanie o płatności
• Liczba zgłoszeń jest na tyle mała, że dyżurny obsługuje je z marszu — wtedy wdrożenie się nie zwróci
• Automatyzacja ma być pretekstem do wymiany działającego systemu obsługi, ukrytej w innym budżecie

Trzeba też powiedzieć, czego nie wiemy. Nie mamy zweryfikowanego rzędu wielkości zgłoszeń u regionalnego operatora tej skali ani przetestowanej skuteczności automatycznej kwalifikacji na realnych danych — byłby to dla nas pierwszy taki projekt i nie udajemy, że jest inaczej. Wataha Media to jednoosobowa działalność, co dla operatora oznacza zaletę i ryzyko naraz: kontakt bez warstwy pośredników, ale też jeden zasób, który trzeba uwzględnić w harmonogramie i w planie na wypadek awarii w niewygodnym momencie. Wolimy, żeby to zdanie padło przed umową, niż żeby ktoś odkrył je sam w połowie wdrożenia.