Silnik BPM wpięty w istniejący CRM — w 9 dni

Wyzwanie

Platforma SaaS obsługująca klientów na rynku amerykańskim miała dobrze działający panel administracyjny i CRM, ale procesy, które trwają dni i tygodnie, odbywały się poza systemem. Nowe konto bez aktywności, wieloletni klient, który nagle przestał korzystać z usługi, prośba o potwierdzenie od klienta przed zmianą konfiguracji — każda z tych sytuacji wymagała kilku kroków rozłożonych w czasie i pamiętania, kto ma co zrobić i kiedy.

Wymaganie było jasne: procesy mają działać automatycznie tam, gdzie się da, a ludzie mają dostawać zadania tam, gdzie już pracują. Żadnego osobnego narzędzia, którego nikt nie będzie otwierał.

Rozwiązanie

Silnik Flowable 7 uruchomiliśmy jako osobną usługę obok istniejącego systemu. Procesy opisaliśmy w BPMN, a kroki automatyczne wywołują istniejące API platformy — wystawienie kuponu, wysłanie e-maila, sprawdzenie, czy klient zaczął korzystać z usługi. Systemy źródłowe nie wiedzą o istnieniu silnika procesów; dla nich to kolejny klient API.

Cztery procesy na start:

Aktywacja nowych kont — konto bez aktywności przez tydzień dostaje kupon aktywacyjny. Po kolejnym tygodniu silnik sprawdza konwersję; jeśli jej nie ma, wysyła ofertę pomocy, a po następnym — tworzy zadanie „zadzwoń do klienta” dla działu sprzedaży, z terminem ważności.
Wykrywanie odchodzących klientów — model statystyczny ocenia, czy cisza po stronie klienta jest nietypowa dla tego konkretnego klienta, a nie względem średniej. Kluczowi klienci trafiają do opiekuna, który wybiera reakcję; pozostali dostają automatyczną wiadomość. Proces pamięta o okresie karencji, żeby nie wracać do tego samego klienta co tydzień.
Potwierdzenia od klienta — ogólny wzorzec zadania, które wykonuje sam klient: e-mail z linkiem, logowanie istniejącym kontem, formularz, przypomnienie, limit czasu.
Wygaszanie starej integracji — proces oparty na tym wzorcu: klient potwierdza gotowość, zespół dostaje zadanie techniczne.

Integracja z interfejsem

Zadania dla ludzi pojawiły się w istniejącym panelu administracyjnym jako nowa sekcja:

lista zadań z przejmowaniem, zwalnianiem i zamykaniem zadania,
formularze generowane z definicji procesu — nowy proces z nowymi polami nie wymaga zmian we frontendzie,
podgląd diagramu procesu z zaznaczonym krokiem, na którym stoi konkretna instancja,
sygnalizacja zaległości — po pierwszym tygodniu okazało się, że zespół nie zagląda sam na listę zadań. Dodaliśmy przekierowanie po zalogowaniu, licznik w menu i codzienny e-mail o zadaniach otwartych dłużej niż kilka dni.

Uwierzytelnianie jest wspólne: silnik BPM akceptuje te same tokeny co panel, z tymi samymi rolami. Klient nigdy nie łączy się z silnikiem bezpośrednio — jego zadania przechodzą przez API klienckie, które bierze tożsamość z sesji.

Efekt

4 dni od pierwszego commita kodu aplikacji do wdrożenia produkcyjnego na klastrze Kubernetes.
9 dni do pełnej integracji z panelem: lista zadań, formularze, diagramy, powiadomienia.
Pierwszy nocny skan wytypował do procesu aktywacji kilkudziesięciu klientów.
Kolejny proces — potwierdzenia od klienta — dodaliśmy później jako krótką iterację, bez zmian w panelu.

Szczegóły dwóch decyzji projektowych opisaliśmy osobno: dlaczego zadania BPM w CRM, a nie w osobnym panelu oraz jak klient wykonuje zadanie procesu z linku w e-mailu.