Gestor nexo i Sfera: integracja CRM, w której najcenniejszy jest zapis, a nie odczyt

Integracja, która jest już w połowie zrobiona

Każdy przewodnik z tej serii zaczynał się dotąd tak samo: program, API, połączenie, którego jeszcze nie macie. Z Gestorem nexo jest inaczej — i za pierwszym razem trudno w to uwierzyć.

Jeśli klient ma Gestora nexo obok Subiekta nexo, CRM nie stoi obok ERP jako drugi system z przepaścią do przerzucenia. InsERT pisze wprost: oba programy pracują na wspólnych kartotekach klientów i asortymentu, cenników i promocji. Oferty z Gestora przekształcają się w dokumenty handlowe i magazynowe Subiekta. Jeden podmiot. Kontrahent, którego czytacie przez Sferę dla Subiekta, to dokładnie ten sam rekord, na który patrzy handlowiec w CRM-ie.

Więc kiedy klient pyta, ile kosztuje dorzucenie do tego jeszcze CRM-u, uczciwa odpowiedź brzmi: spora część roboty jest już za Wami. Model połączenia, referencje do bibliotek, ograniczenie .NET Framework, konto serwisowe, dyscyplina wersji — wszystko przenosi się ze strony Subiekta bez zmian. Opisałem to tam i nie będę powtarzał.

Potem przychodzi część, która się nie przenosi. I nie jest techniczna.

Licencja jest na program, nie na instalację

Sfera w linii nexo jest funkcją wersji PRO. Napisałem to w przewodniku po Subiekcie i myślałem, że mam temat z głowy. Nie miałem. Ma drugą połowę, która wychodzi dopiero wtedy, gdy w podmiocie pojawia się drugi program.

Subiekt nexo PRO daje Sferę dla Subiekta. Nie daje Sfery dla Gestora. Sfera dla Gestora siedzi w Gestorze nexo PRO, obok zaawansowanych pól własnych, słowników własnych, flag, raportów, punktów rozszerzania i własnych automatycznych akcji. Materiały InsERT-u o Sferze PRO+ wymieniają programy osobno dokładnie z tego powodu — Subiekt, Gestor, Rewizor, Rachmistrz, Gratyfikant — i wyceniają każdy na stanowisko.

Teraz typowy przypadek, a naprawdę jest typowy. Dystrybutor kupił Subiekta nexo PRO dwa lata temu, bo integrator potrzebował Sfery do sklepu. Handlowcy poprosili o CRM później, nikt nie miał powodu dopłacać do wersji PRO, więc Gestor wszedł w wersji zwykłej. Dziś ta firma trzyma dane CRM, po które przychodzicie, w tej samej bazie, do której macie już połączenie — i nie ma licencyjnej drogi, żeby Wasz kod ich dotknął.

Ten scenariusz trzeba nazwać, bo nie objawia się komunikatem błędu. Wasza integracja się nie wywali. Ktoś z zespołu znajdzie tabele Gestora przez połączenie, które już ma, napisze zapytanie i ono zadziała. Dane naprawdę tam leżą. Rachunek przychodzi kilka miesięcy później: aktualizacja przesuwa tabele, ktoś otwiera rozmowę o licencji, której nikt nie planował, a InsERT nie ma obowiązku przyjąć zgłoszenia serwisowego. Ten sam błąd co replika SQL tylko do odczytu, przed którą ostrzegałem po stronie enova365 — tyle że tutaj kusi bardziej niż gdziekolwiek indziej, bo wspólna baza sprawia, że wygląda legalnie.

Pytajcie o wersję każdego programu w podmiocie, z nazwy, w pierwszej rozmowie. Nie „czy macie nexo PRO". Które programy, która wersja, ile stanowisk. Odpowiedź decyduje o tym, kto musi usiąść przy stole — a dowiedzieć się przed wyceną kosztuje mniej niż po niej.

Dlaczego sam odczyt jest tu prawie bezwartościowy

Teraz rzecz, która przy pierwszym takim projekcie szczerze mnie zaskoczyła.

W każdym innym wpisie z tego cyklu namawiam na to samo pierwsze wdrożenie: zacznijcie od odczytu. Stany, kontrahenci, ceny, rozrachunki. Prawo do zapisu zarobicie później. Dla ERP to rada słuszna — pierwszy zapis dotyka pieniędzy, towaru albo podatku, a sam odczyt od razu się przydaje, bo dane siedzą w systemie, do którego większość firmy nie ma wglądu.

CRM odwraca obie te połowy. Odczyt nie daje prawie nic: lista klientów to najmniej tajne dane w firmie, a każdy, kto ich potrzebuje, ma je na ekranie. Za to zapis, o który naprawdę chodzi, jest najtańszy w całym modelu obiektowym InsERT-u.

Działanie — w słowniku Gestora zadanie, spotkanie, telefon, list albo notatka — nie zmienia pieniędzy, towaru, pozycji podatkowej ani stanu dokumentu. To zapis, że coś się wydarzyło: data, klient, osoba. Jeśli agent utworzy złe, człowiek je przeczyta i skasuje. Całkowity koszt pomyłki: piętnaście sekund lekkiej irytacji.

Zestawcie to z drabiną uprawnień, którą opisałem wcześniej: czytaj, proponuj, zapisuj, wyślij lub podpisz — z prawdziwą granicą między trzecim a czwartym szczeblem. Drabina się broni. Gestor pokazuje tylko tyle, że nie jest jedna na całą firmę. Trzeci poziom w CRM-ie jest bezpieczniejszy niż drugi w księgach. Układanie uprawnień według czasownika to skrót. Ułóżcie je według tego, ile kosztuje cofnięcie pomyłki, a wiele sporów o automatyzację kończy się szybciej.

Skrzynka pocztowa jest największą wartością

Gestor ma wbudowanego klienta poczty po IMAP, więc korespondencja z klientami mieszka w podmiocie, obok ofert, działań i kartotek.

Jeśli budujecie agenta, to najcenniejsze dane w całym InsERT-cie, z jednego powodu: tylko tam zapisane jest dlaczego. ERP wie, że klient zamówił we wtorek osiemdziesiąt kartonów. Wątek mailowy wie, że najpierw pytał, czy dostawa w czwartek jest możliwa, że handlowiec to obiecał i że trzy ostatnie rozmowy dotyczyły uszkodzonej palety, której nikt jeszcze nie skorygował. Żaden dokument tego nie niesie. Wszystko sensowne, co robi agent po stronie sprzedaży — szkic odpowiedzi, wyłapanie oferty, która ucichła, brief przed telefonem, zauważenie, że klient zadaje to samo pytanie trzeci raz — bierze się z korespondencji, nie z ksiąg.

Dwa ostrzeżenia. Oba tanie na początku, drogie na końcu.

Kwestie danych ustalcie przed projektowaniem. To skrzynka pocztowa w bazie ERP, z danymi osobowymi ludzi, którzy nie są pracownikami Waszego klienta. Retencja, kto może czytać, co się dzieje przy eksporcie, co się dzieje, gdy handlowiec odchodzi. Zapytajcie raz, na piśmie, na starcie. Nie szukacie opinii prawnej. Szukacie człowieka z imienia i nazwiska, który odpowiada za tę odpowiedź.

Liczcie się z tym, że to będzie największa rzecz w bazie. Poczta z załącznikami przerasta tabele dokumentów bez trudu, a ten przyrost produkuje dokładnie te sufity, które opisałem po stronie Optimy — baza nigdy nieprojektowana pod taki wolumen spotyka limit, którego nikt nie pilnował. Zapytajcie, ile podmiot waży dziś i jak urósł przez ostatni rok. Jedno pytanie. Uratowało mnie przed dwiema złymi wycenami.

Oferta jest szwem

Wszystko, co w CRM-ie miękkie, zatrzymuje się na jednym obiekcie.

Oferty w Gestorze przekształcają się w dokumenty Subiekta — także wiele ofert w ramach jednego procesu ofertowego. To moment, w którym CRM przestaje opisywać świat i zaczyna go zmieniać: ceny, ilości, zobowiązania. Dlatego to jedyny obiekt CRM, na którym granica dla agenta wraca do reguł ERP: proponuj, nigdy nie zatwierdzaj, decyzję podejmuje wskazany z nazwiska człowiek.

Zdanie, którego używam z klientami, jest krótkie na tyle, żeby przeżyć spotkanie: agent może opisywać, co się wydarzyło, ile chce, i nigdy nie może być ostatnią stroną decydującą, ile coś kosztuje. Działania, notatki, briefy, uporządkowane kartoteki, szkice odpowiedzi — bez nadzoru. Cokolwiek przekształcalnego w fakturę — zaproponowane, przejrzane, zatwierdzone przez człowieka.

To mówi Wam też, gdzie włożyć wysiłek. Obiekty przekształcalne to niewielka mniejszość tego, czym CRM zajmuje się przez cały dzień. Ogromna, nieefektowna większość — pamiętanie, zapisywanie, łączenie rozmowy z rekordem — jest dokładnie tą połową, w której maszyny są dobre, a ludzie słabi.

Najpierw sprawdźcie, co już macie

Zanim napiszecie linijkę kodu na Sferze, zobaczcie, co wersja PRO już daje klientowi. Spora część próśb o automatyzację CRM-u w ogóle nie potrzebuje programisty.

Gestor nexo PRO ma własne automatyczne akcje i własne definicje zestawów dynamicznych klientów — zestawów, które same się aktualizują w miarę zmian danych. Razem pokrywają sporo z tego, co ludzie mają na myśli, mówiąc „chcemy, żeby system nam przypominał". Dołóżcie zaawansowane pola własne wraz ze słownikami własnymi i uporządkowane pole, które zamierzaliście dopisać kodem, może się okazać ekranem konfiguracji.

Dwa powody, żeby sprawdzić. Oczywisty: nikt nie powinien płacić programiście za funkcję, którą już ma w licencji. Mniej oczywisty — i to dla niego robię to za każdym razem: to, co klient już skonfigurował, mówi Wam, czego naprawdę będzie używał. Firma z trzema działającymi automatycznymi akcjami i utrzymywanymi zestawami dynamicznymi jest gotowa na agenta. Firma, w której nic z tego nigdy nie zostało włączone, ma problem z nawykiem, a nie z oprogramowaniem — i integracja na Sferze wyląduje dokładnie tam, gdzie wylądowały nieużywane funkcje.

Jeśli i tak budujecie pola własne, wszystko, czego nauczyłem się na własnych błędach o polach własnych jako nieudokumentowanej zmianie schematu, obowiązuje tu bez poprawek. Nazwy inne, pułapka identyczna.

Co zbudowałbym najpierw

Jedna liczba przed jakimkolwiek kodem: wskaźnik pokrycia działaniami — jaki udział realnych kontaktów z klientami z ostatniego kwartału istnieje w Gestorze jako działanie.

Policzcie rekordy działań z jednego miesiąca, a potem poproście handlowców, żeby oszacowali, ile rozmów z klientami faktycznie odbyli. Luka jest zawsze duża i zawsze ma ten sam kształt. Spotkania są zapisane; czterdzieści maili wokół każdego spotkania już nie. Dziwne o tyle, że przy kliencie pocztowym Gestora te maile już są w bazie — obecne jako wiadomości, nieobecne jako struktura. Nie trzeba niczego zbierać. Trzeba to zamienić w rekordy.

Więc pierwsze wdrożenie to dokładnie to i nic więcej. Czytać korespondencję, proponować działanie dla każdej sensownej wymiany, z klientem i datą już wypełnionymi, zapisywać te, które człowiek zaakceptuje. Zapis trzeciego poziomu na najtańszym obiekcie w systemie, efekt widoczny w pierwszym tygodniu, a pomiar wbudowany: wskaźnik pokrycia przed i wskaźnik pokrycia miesiąc później.

Zbudujcie to jako cienką usługę HTTP na maszynie z Windows i instalacją nexo, dokładnie tak jak po stronie Subiekta — jeden komponent wie o istnieniu Sfery, cała reszta rozmawia z nim JSON-em. Ten adapter jest zresztą powodem, dla którego robota na Gestorze jest tania, kiedy robota na Subiekcie jest już zrobiona, i dla którego porównanie API dla integratorów opłaca się przeczytać przed wyborem punktu startu. Jeśli patrzycie na to szerzej niż na jedną integrację, osobno opisałem, jak wyglądają agenci AI dla firm w polskich realiach ERP.

Zastanawiacie się, czy integracja z Gestorem nexo jest warta zbudowania — czy może wersje licencji zabiją ją, zanim się zacznie? Odezwijcie się. Godzina z Waszym podmiotem, Waszymi licencjami i jednym miesiącem prawdziwej korespondencji rozstrzyga to szybciej niż jakakolwiek lista funkcji.