eBOK dla operatora internetowego: panel klienta Skynet

Czym jest eBOK i dla kogo go zrobiliśmy?

eBOK to elektroniczne biuro obsługi klienta: strona, na której abonent załatwia sprawy bez dzwonienia do operatora. Zrobiliśmy go dla Skynet, operatora internetowego. Panel działa w przeglądarce, także na telefonie, i łączy się z systemem operatora przez jego API.

Odpowiadamy za interfejs, panel administratora, integrację z API i kolejne wydania. Marka i treści należą do operatora; zmienia je sam w panelu.

Technologie: React po stronie panelu klienta, REST API operatora, PHP i MySQL w panelu administratora, a do tego Chatwoot, GenieACS (TR-069) i Redmine tam, gdzie moduły ich używają.

Co klient może zrobić w panelu?

Wszystko, z czym abonent zwykle dzwoni do biura obsługi, a do tego kilka rzeczy, których przez telefon się nie da.

• Sprawdzić saldo i faktury: do zapłaty albo nadpłata, podgląd i pobranie PDF, kod QR do przelewu, zgłoszenie problemu z fakturą jednym kliknięciem.
• Przeczytać i zaakceptować dokumenty: umowy, aneksy i protokoły z podglądem, akceptacja kodem SMS.
• Zobaczyć aktywny pakiet telewizji.
• Wziąć udział w promocji „Testuj Prędkość”: aktywacja, codzienne przesłanie wyniku testu, jasny komunikat, dlaczego wynik nie przeszedł.
• Zmierzyć prędkość łącza i zgłosić wynik do biura obsługi.
• Zaplanować sieć WiFi w domu w planerze (osobna realizacja poniżej).
• Zamówić zwrot sprzętu: panel nadaje numer zwrotu, a klient wkleja go na stronie przewoźnika.
• Zobaczyć awarie i prace modernizacyjne w swojej okolicy oraz napisać do biura obsługi z gotową treścią zgłoszenia.

Jak panel łączy się z systemem operatora?

Panel klienta rozmawia z REST API operatora. Faktury, saldo, dokumenty, usługi i promocje pochodzą stamtąd na bieżąco. Panel zmienia tylko to, na co API pozwala klientowi: akceptację dokumentu, aktywację promocji, przesłanie wyniku.

Cała komunikacja siedzi w jednej warstwie (adapterze), więc ekrany nie znają szczegółów API. Wymiana źródła danych albo nowa wersja interfejsu nie wymaga przepisywania widoków.

• Tokeny z odświeżaniem: refresh token jest jednorazowy, więc równoległe zapytania czekają na jedno wspólne odświeżenie. Dzięki temu nie unieważniamy sesji klienta przez wyścig dwóch zapytań.
• Błędy biznesowe API przychodzą z kodem 200 i opisem w treści. Panel czyta treść odpowiedzi, a nie sam kod, więc odrzucony test prędkości nie wygląda jak sukces.
• Brak endpointu albo błąd statusu nie psuje ekranu: karta promocji po prostu się nie pokazuje.
• Nowe pola API (powód blokady promocji) obsługujemy z zachowaniem zgodności ze starszym backendem.

Jak chronimy konto klienta?

Logowanie ma dwa kroki: numer umowy i hasło, a potem kod wysłany SMS-em lub e-mailem. Przy pierwszym logowaniu panel wymusza zmianę hasła startowego i na żywo odhacza wymagania (długość, wielkie i małe litery, cyfra, inne niż hasło startowe), zamiast pokazywać błąd dopiero po wysłaniu.

Po stronie panelu administratora stosujemy tokeny CSRF, limity zapytań przy wrażliwych akcjach, dziennik zdarzeń i zapytania parametryzowane. Warstwa danych klienta jest w systemie operatora, a nie w panelu.

Co dostaje operator?

Panel administratora, w którym pracownicy zmieniają treści bez programisty: ofertę, banery, pytania i odpowiedzi, ogłoszenia, status usług, szablony e-maili i katalog urządzeń planera. Numer biura obsługi, adres e-mail i link do regulaminu promocji są ustawieniami, więc ich zmiana nie wymaga przebudowy panelu.

• Zgłoszenia i zamówienia klientów z podglądem i zmianą statusu; opcjonalnie każde tworzy zlecenie w Redmine.
• Awarie i prace modernizacyjne z mapą, statystykami i listą w trakcie i zrealizowanych.
• Statystyki użycia panelu.
• Moduły zbudowane i wyłączone w bieżącym wydaniu: czat na żywo (Chatwoot, podział na działy, godziny pracy ze świętami) i zdalne zarządzanie routerem (TR-069, GenieACS). Włączamy je flagą w kodzie panelu, kiedy operator zdecyduje.

Jak dbamy o jakość wydań?

Każde wydanie dostaje listę zmian, tabelę wykonanych sprawdzeń i osobną listę rzeczy, których nie udało się sprawdzić. Dzięki temu operator wie, na co zwrócić uwagę po wgraniu, zamiast zakładać, że wszystko jest przetestowane.

Trzy przykłady z notatek wydań:

• Nadpłata nie pojawiała się nigdy: wyrażenie regularne usuwało literę „s” zamiast spacji, więc każde saldo z jednostką dawało błąd. Przepisaliśmy to bez wyrażenia regularnego i sprawdziliśmy na dwunastu formatach kwot.
• Podgląd dokumentu na telefonie w poziomie pokazywał martwy przycisk: przeglądarka obrócona do 844 px była traktowana jak komputer. Kryterium zmieniliśmy z szerokości okna na rozmiar urządzenia, które nie zmienia się przy obrocie. Dzięki temu klient przed akceptacją dokumentu zawsze ma drogę, żeby go otworzyć lub pobrać.
• Awaria API wyglądała jak umowa bezterminowa. Pole „Koniec umowy” ma teraz trzy stany: data, czas nieokreślony i brak danych, a błąd serwera pokazujemy jako brak danych, nie jako umowę bez końca.