Ekspertyza · CRM i sprzedaż

System, w którym widać, kto został osiągnięty, przez jaki kanał i co jest dalej.

Budujemy system handlowy organizacji: organizacje i kontakty, ścieżkę etapów, kanały, które same dostarczają dane — połączenie, email, formularz, agent głosowy — oraz hamulce, które zatrzymują wysyłki, zanim staną się problemem. Nie sprzedajemy naszego CRM; budujemy taki pod sposób, w jaki pracujesz.

Omów projekt

Już zbudowaneDwie własne implementacje, w produkcji, cytowane niżej. (1) MEGA CRM — system, za pomocą którego nasz zespół prowadzi własną działalność handlową: `server.js` ma 9.516 linii i 99 tras HTTP, w repozytorium znajduje się 96 migracji SQL i około 95.000 linii TypeScript w interfejsie, a ostatni commit jest z 18 sierpnia 2026. (2) Konektory CRM w platformie Kallina: 12 funkcji serwera dla amoCRM, 4 dla Bitrix24, plus udokumentowany przepływ OAuth dla Zoho CRM oraz 10 funkcji dla Google Sheets. Ważne doprecyzowanie: **MEGA CRM nie jest na sprzedaż.** Pokazujemy go jako dowód rzemiosła, nie jako produkt — nie ma ścisłej izolacji danych między klientami i nie ma procesu instalacji, który nie zakładałby dostępu do serwera. Usługa brzmi: „zbudujemy taki system dla ciebie”, a nie „damy ci licencję na nasz”.

Większość firm nie ma problemu z CRM, ma problem z ewidencją: nie wiadomo, kto został skontaktowany, przez jaki kanał, co zostało powiedziane i co dalej. Gotowe narzędzie rozwiązuje to wtedy, gdy twoja praca przypomina pracę, do której narzędzie zostało zaprojektowane. Gdy nie przypomina — bo pracujesz jednocześnie z administracją publiczną i firmami prywatnymi albo dlatego, że połowa kontaktów pochodzi od agenta głosowego — kończysz na męczeniu narzędzia, a zespół trzyma prawdę w osobnym pliku. Wtedy warto zbudować coś.

System, który pokazujemy jako dowód, to ten, z którym pracujemy. Jest zorganizowany w osobne projekty, każdy z własnym typem organizacji i własnym schematem pól, tak aby ta sama aplikacja działała zarówno dla urzędu miasta, jak i dla firmy prywatnej, bez nowych kolumn w bazie przy każdym nowym typie. Pod organizacją stoją kontakty, nad nią stoją kampanie. Lead przechodzi przez trasę siedmiu etapów, od „niekontaktowany” do „umowa podpisana”, i może być osiągany przez dziewięć różnych kanałów, od połączenia agenta głosowego po wizytę.

Trudna część, i ta, której uczy się na własnej skórze, nie polega na wysyłaniu. Polega na zatrzymywaniu. System ma godziny pracy zapisane w kodzie, listy wykluczeń, deduplikację po adresie zapisanym małymi literami — nie po organizacji —, okres chłodzenia między kampaniami, dzienny limit dzielony między kampanie oraz wyłącznik, który odmawia uruchomienia orchestratora, bez drogi obejścia. Każdy z nich został dodany po tym, jak raz go zabrakło. Wyliczamy je nie jako listę funkcji, lecz jako listę lekcji.

Drugą rzeczą, którą budujemy prawie za każdym razem, jest automatyczne zasilanie danymi. CRM, w którym dane wpisuje się ręcznie, opróżnia się w trzy tygodnie. U nas połączenie agenta głosowego zapisuje się samo na karcie organizacji, z transkryptem i podsumowaniem, i przesuwa lead dalej na trasie, jeśli wynik połączenia to uzasadnia. Odpowiedzi na maile są pobierane ze skrzynki co dziesięć minut i wiązane z wysyłką, która je wywołała. Otwarcia i kliknięcia są śledzone osobno. Człowiek ingeruje, żeby zdecydować, a nie żeby wprowadzać dane.

Zapobieganie spamowi w CRM — wnioski, które warto śledzić · wideo po rumuńsku, z napisami i transkrypcją po polsku

Pełna transkrypcja

Cześć! W dzisiejszej analizie rozbieramy problem, z którym w pewnym momencie trafia absolutnie każda firma, która chce skalować się. Jak dokładnie automatyzujemy prospecting handlowy, żeby wszystko nie zamieniło się w irytujący i agresywny spam? Chcemy rosnąć, chcemy usprawniać, jasne. Ale dziś zaglądamy pod maskę fascynującego materiału technicznego, żeby zobaczyć, jak zapobiega się spamowi przez dokładnie 6 jasnych, pierścieniowych mechanizmów, zintegrowanych w naprawdę bezpieczny system Ceremic. Nie chodzi tylko o standardowe ustawienia, które zaznaczamy i o nich zapominamy, ale o realne architektury, fakty i liczby. Wejdźmy w dane! Dobra, krótko mówiąc, oto struktura naszej rozmowy. Zaczynamy od problemu przyspieszenia bez hamulców, potem analizujemy studium przypadku, incydent tych 42 wiadomości, przechodzimy do rdzenia analizy, czyli 6 mechanizmów ochrony, mówimy o poprawnym zarządzaniu wypisami i kończymy klasycznym dylematem: kiedy warto budować system, a kiedy lepiej go kupić.

Zacznijmy! Więc zasadnicze pytanie, od którego ruszamy, jest takie. Jak upewnić się, że automatyzacja, którą wdrażamy, nie staje się po prostu spamem? To tu jest niesamowicie cienka granica. Intencja za tym zawsze jest dobra: chcemy kontaktować się z ludźmi, chcemy generować sprzedaż, ale jeśli systemowi pozwoli się przyspieszać na oślep, bez bardzo restrykcyjnych kontroli technicznych zakodowanych bezpośrednio w jego strukturze, wpływ na markę może być katastrofalny. Docieramy do sekcji 1: przyspieszenie bez hamulców. Spójrzmy na fundamentalny problem oczywistości w tych automatycznych systemach. Wyobraźcie sobie to jak bardzo mocny samochód, ale bez systemu hamowania. Kiedy standardowy soft nie alignuje się z codzienną rzeczywistością pracy, sprawy szybko wymykają się spod kontroli. Na przykład załóżmy, że zespół współpracuje zarówno z administracją publiczną, jak i z prywatnymi firmami.

Zupełnie przeciwne struktury decyzyjne, prawda? Ich dane po prostu nie mieszczą się w tych samych sztywnych polach w generycznym CRM. I co dzieje się w praktyce? Ludzie zaczynają trzymać prawdę osobno, w plikach Excel albo notatkach na biurku, podczas gdy główna automatyzacja dalej działa w próżni na błędnych danych. To po prostu chaos. A nasze źródło ma tu absolutnie genialny cytat, brutalną prawdę z branży. CRM, do którego dane wpisuje się ręcznie, opróżnia się w 3 tygodnie. To ma bardzo dużo sensu. Ludzie się męczą, pojawiają się błędy, a morale spada. Osoby sprzedażowe muszą budować relacje, a nie być robotami do wprowadzania danych. Czy chodzi o inteligentnego voice agenta, który automatycznie transkrybuje rozmowy, czy o e-maile, które same synchronizują się w tle co 10 minut, idea jest jasna.

Automatyczne zasilanie danych nie jest już luksusem. To obowiązkowy fundament każdego funkcjonalnego systemu. Przechodzimy do sekcji drugiej, incydentu tych 42 wiadomości. Rozłóżmy anatomię rzeczywistej porażki. 42. To nie jest tylko jakaś liczba, ale prawdziwa historia z kampanii prospectingowej, która uruchomiła prawdziwą reformę techniczną. Wyobrażacie to sobie? Jedna skrzynka mailowa dostała dokładnie 42 wiadomości w ciągu kilku godzin, tego samego dnia. Oczywiście zespół techniczny najpierw pomyślał: okej, to bug, zwykła pętla w kodzie, która wysyła bez końca. Ale kiedy przyjrzeli się dokładniej bazie danych, rzeczywistość była znacznie bardziej złożona. Wyjaśnienie? System został ustawiony tak, by pobierać i wysyłać wiadomości per organizację, a nie per adres e-mail. Tak więc z logicznego punktu widzenia algorytm wykonał swoją pracę idealnie. Znalazł 42 firmy odrębne prawnie.

Problem, i to rzeczywistość, którą często widzimy na lokalnym rynku, polegał na tym, że wszystkie te 42 podmioty używały dokładnie tego samego adresu e-mail. Czy to firmy macierzystej, czy tego samego zewnętrznego księgowego, który obsługiwał dziesiątki firm. Podmioty były unikalne na papierze, ale końcowy adres wiadomości był jeden. I żeby umieścić to w odpowiedniej perspektywie, wiecie, ilu prawdziwych ludzi z krwi i kości dotknęła ta lawina wiadomości? Tylko 11. 11 osób, które zarządzały tymi dziesiątkami biznesów. Ten incydent pokazał jedną rzecz bardzo jasno. Dobre intencje i kod, który na pierwszy rzut oka wygląda poprawnie, nigdy nie wystarczą. Baza danych zawsze ma niewidoczne powiązania, a system musi je przewidywać. To prowadzi nas do najważniejszej części, sekcji 3. Sześciu mechanizmów ochrony, czyli hamulców zakodowanych bezpośrednio w sercu systemu.

Tu jest rozwiązanie. Źródło szczegółowo opisuje pierścień ochrony złożony z sześciu odrębnych mechanizmów, które sprawdzają się nawzajem. 1. Ustawienie ścisłych godzin pracy, między 8 a 18. Nikt nie chce e-maila sprzedażowego w niedzielę o 3 nad ranem. 2. Stałe listy wykluczeń, czyli blokowanie wrażliwych instytucji, takich jak szkoły albo ambasady. 3. I to właśnie zapobiegłoby wcześniejszemu incydentowi: obowiązkowa deduplikacja po adresie e-mail zapisanym małymi literami, a nie po nazwie firmy. 4. 5-dniowy okres chłodzenia dla każdego kontaktowanego adresu, żeby uniknąć dławienia odbiorców. 5. Sztywne dzienne limity, żeby nie rozdrażnić globalnych filtrów antyspamowych. I wreszcie szósty mechanizm, przycisk paniki. Spośród wszystkich ten mechanizm 6, czyli kill switch, albo wyłącznik awaryjny, jest elementem kluczowym. Został wdrożony dokładnie po tamtym incydencie z 42 wiadomościami.

Czym on właściwie jest? Prostą zmienną, która jeśli jest aktywowana, po prostu zabrania centralnemu systemowi dalszego uruchamiania się. Bez wyjątków, bez żadnej ukrytej komendy nadpisania w kodzie. Każda poważna architektura automatyzacji potrzebuje takiego fizycznego, mówiąc obrazowo, przycisku, który absolutnie każdy z zarządu może nacisnąć bez znajomości programowania. Przechodzimy do czwartej sekcji, prawidłowe zarządzanie wypisami. Bo, uwaga, oznacza to znacznie więcej niż tylko zwykły link umieszczony na końcu strony. Gdy wiadomość zostanie wysłana, jeśli ta osoba chce wyjść z bazy, proces musi być bezbłędny i dobrze zabezpieczony. Analiza pokazuje nam solidny proces w trzech krokach. Krok 1. Wypisanie z nagłówka jednym kliknięciem, zgodnie z nowymi globalnymi standardami, takimi jak RFC 8058. Krok 2. Wizualne centrum preferencji, gdzie ta osoba może wybrać, jakiego typu wiadomości już nie chce.

Ale krok 3 jest w rzeczywistości najważniejszy i to na nim wiele systemów się wykłada. Całkowite usunięcie. To nie znaczy zaznaczyć pole jako nieaktywne. To znaczy usunięcie adresu z, uwaga, 6 różnych tabel bazy danych, plus wpisanie go na stałą czarną listę. Tylko tak masz pewność, że ten adres nie pojawi się jak za dotknięciem czarodziejskiej różdżki przy kolejnym masowym imporcie danych. I nie mówimy tylko o technologii. Mówimy o szacunku i zgodności prawnej bezpośrednio w stopce e-maila. Kim jesteście? Kim jest oficer DPO? Jaka jest dokładnie podstawa prawna, na której wysłaliście wiadomość? I przede wszystkim, z jakiego rejestru publicznego początkowo pobraliście dane? Nasze źródło podkreśla złotą zasadę. Te podstawy trzeba weryfikować ponownie przy każdej zmianie legislacyjnej. Dlaczego? Bo możecie mieć najdroższy system na świecie.

Jeśli opierając się na uchylonej ustawie zamieniliście technologię w poważne ryzyko finansowe dla firmy. Dochodzimy do ostatniej, piątej sekcji. Kiedy budować, a kiedy kupować? Zobaczmy poprawną odpowiedź dla dojrzałej infrastruktury biznesowej. Dokumentacja podchodzi do tej decyzji bardzo obiektywnie. Gotowy CRM, pod klucz, jest absolutnie idealny. Z jednym ważnym warunkiem. Aby wasz przepływ pracy idealnie dopasował się do logiki wymyślonej przez twórców platformy. Jednak decyzja o zbudowaniu rozwiązania dostosowanego staje się jedyną drogą w trzech jasnych sytuacjach. Gdy pracujecie z bardzo różnymi typami organizacji, gdy macie ogromną liczbę automatyzacji, przy których ręczna praca staje się niemożliwa, i, co najważniejsze, gdy macie surowe zasady ochrony, takie jak te sześć mechanizmów, których gotowe oprogramowanie po prostu nie może wam zagwarantować na tak głębokim poziomie.

Dobra wiadomość? Zbudowanie czegoś bezpiecznego w tle nie oznacza wyrzucenia przez okno narzędzi, które zespół już zna. Te mechanizmy ochrony mogą działać cicho jak niewidoczna warstwa bezpieczeństwa, jednocześnie łącząc się ze zwykłymi interfejsami. Istnieją architektury możliwe do zademonstrowania, które mają konektory uruchamiające dziesiątki funkcji dwukierunkowych z popularnymi systemami, takimi jak Amos ERM, Bitrix24, Zohos ERM czy nawet klasyczne tabele Google Sheets. Krótko mówiąc, rdzeń bezpieczeństwa pozostaje nienaruszony, ale doświadczenie użytkownika jest równie przyjazne. I tak materiał zostawia nam dość niewygodny temat do przemyślenia, który warto zabrać ze sobą. Czy superzaawansowany system biznesowy, który tylko programista, który go napisał, jeszcze wie, jak wyłączyć, jest dla firmy superaktywem, czy tak naprawdę nieakceptowalnym ryzykiem? Na koniec dnia to przejrzystość, ten awaryjny wyłącznik umieszczony na widoku i jasna dokumentacja są rzeczami, które odróżniają zwykłą ślepą maszynę od naprawdę skalowalnego, profesjonalnego i odpowiedzialnego systemu biznesowego. Mam nadzieję, że ta analiza mechanizmów wniosła trochę więcej światła na to, jak powinna wyglądać prawidłowa automatyzacja. Do zobaczenia!

Co obejmuje

Praca, komponent po komponencie

Dane wchodzą do przepływu, z deduplikacją po trzech kluczach

Plik do 50 MB jest wgrywany i przetwarzany w strumieniu, w partiach po 200 wierszy, tak aby nie przekroczyć limitu czasu wykonania bazy, a postęp wraca w czasie rzeczywistym, po jednej linii dla każdego kroku. Przed importem budowany jest indeks deduplikacji po trzech kluczach — kodzie fiskalnym, adresie e-mail i telefonie — oraz walidowane są adresy: format, domeny jednorazowe, nieprawidłowe wzorce. Ta sama organizacja nie wchodzi dwa razy pod dwiema różnie zapisanymi nazwami.

Każdy kontakt trafia na kartę organizacji

Dziewięć kanałów komunikacji, od agenta głosowego i połączenia ludzkiego po wizytę, oraz trasa siedmiu etapów z rzeczywistymi etykietami: niekontaktowany, skontaktowany, odpowiedź otrzymana, oferta wysłana, aktywnie zainteresowany, negocjacje, umowa podpisana. Przy każdym etapie jest zapisane, jaki procent powinien przejść dalej — nie jako obietnica, lecz jako punkt odniesienia dla osoby patrzącej na lejek i chcącej wiedzieć, gdzie ginie.

Połączenie agenta głosowego przesuwa lead samo

Gdy agent kończy połączenie, wynik trafia do systemu przez webhook, którego podpis jest weryfikowany: transkrypt, podsumowanie, sentyment, adres nagrania, czas trwania. Organizacja jest identyfikowana po numerze telefonu, przez funkcję zapisaną w bazie dla formatów, w jakich numery pojawiają się w rzeczywistych danych, a połączenie jest wiązane z jej kartą. Jeśli wynik to „zainteresowany” albo „spotkanie zaplanowane”, lead automatycznie przechodzi dalej na trasie i aktualizowana jest data ostatniego kontaktu.

Wysyłka ma hamulce, nie tylko przyspieszenie

Godziny pracy zapisane w kodzie: 08:00–18:00, strefa czasowa Kiszyniów, od poniedziałku do soboty. Listy wykluczeń dla szkół, liceów, przedszkoli, ambasad i konsulatów. Deduplikacja po adresie zapisanym małymi literami — nie po organizacji, co ma ogromne znaczenie, gdy wiele firm używa tej samej skrzynki pocztowej. Pięciodniowe chłodzenie między kampaniami dla tego samego adresu. Globalny dzienny limit, dzielony proporcjonalnie między kampanie, plus limit na jedno uruchomienie, aby wysyłki były rozłożone na kilka godzin, a nie w jednym bloku.

Przełącznik, którego nie da się obejść

Orchestrator kampanii sprawdza zmienną środowiskową przed czymkolwiek innym. Jeśli jest ustawiona, odmawia uruchomienia i wychodzi — nie ma argumentu wiersza poleceń, który to ominie, nie ma „wymuś”. Został dodany 1 maja 2026, po incydencie z podwójnymi wysyłkami. System, który wysyła w twoim imieniu, potrzebuje zatrzymania, które może nacisnąć ktoś, kto nie jest programistą.

Wypisanie jednym kliknięciem, w trzech krokach

Pierwszy krok to standardowy nagłówek wypisania jednym kliknięciem, zgodny z RFC 8058 — wymaganie, które duzi dostawcy poczty elektronicznej narzucają przy wysyłkach masowych. Drugi to centrum preferencji, gdzie wypisanie można też cofnąć. Trzeci to pełne usunięcie na żądanie, które usuwa adres z sześciu tabel, dodaje go do trwałej listy blokady i zostawia ślad w dzienniku. Wszystkie trzy są chronione tokenem powiązanym z odbiorczynią lub odbiorcą, aby nikt nie mógł wypisać kogoś innego.

Odpowiedzi i reakcje są zbierane samoczynnie

Odpowiedzi na e-maile są odczytywane ze skrzynki pocztowej przez Microsoft Graph co dziesięć minut i są automatycznie łączone z wysyłką, która je wywołała. Status dostarczenia synchronizuje się od dostawcy wysyłki. Otwarcia są śledzone pikselem, kliknięcia przez przekierowanie, a panele dostarczalności pokazują domeny z problemami. Oddzielna usługa śledzi pozostały kredyt u płatnych dostawców i alarmuje, zanim się skończy — nie po.

Wyszukiwanie po tym, co organizacja robi, nie tylko po tym, jak się nazywa

Oprócz wyszukiwania w pełnym tekście zapytanie jest przekształcane w wektor za pomocą modelu osadzania, a dopasowanie odbywa się w bazie przez własną funkcję, z regulowanym progiem podobieństwa (domyślnie 0,25) i z limitem na projekt. W praktyce: „firmy zajmujące się transportem chłodniczym” znajduje też organizacje, które nie mają żadnego z tych słów w nazwie.

Połączenie z CRM, którego już używasz

Jeśli Twój zespół pracuje już w CRM, nie zastępujemy go z odruchu. Napisaliśmy i uruchomiliśmy konektor dla amoCRM — 12 funkcji serwerowych, w tym pełny przepływ OAuth, odświeżanie tokenu i sprawdzanie stanu — oraz Bitrix24 z OAuth i webhookiem, przewodnik OAuth dla Zoho i dziesięć funkcji dla Google Sheets, od odczytu struktury arkusza po import kontaktów.

Jak to wygląda

Trasa, krok po kroku.

Najpierw model, potem interfejs

Czym u Ciebie jest organizacja, czym jest kontakt, czym jest szansa, jakie pola są obowiązkowe, a które tylko przydatne. Ta rozmowa wydaje się powolna i jest jedyną, której nie da się nadrobić później: za zły model płaci się przy każdym raporcie, o który potem prosisz.

Trasa i etapy, zapisane jako reguły, nie jako nawyk

Etapy, przez które przechodzi lead, co przesuwa go dalej i co cofa go wstecz, kto jest odpowiedzialny na każdym z nich. Zapisujemy też reguły automatyczne — jaki wynik rozmowy telefonicznej przesuwa lead w górę, jaka bezczynność go obniża — bo trasa, która rusza się tylko wtedy, gdy ktoś sobie przypomni, żeby nacisnąć, nie jest trasą, jest listą.

Kanały, które same przynoszą dane

Połączenia z telefonii lub od agenta głosowego, odpowiedzi ze skrzynki pocztowej, formularze ze strony, webhooki z innych systemów. Każdy kanał jest podłączany i testowany osobno, a dla każdego ustalamy, co dzieje się z danymi, które nie pasują do niczego w bazie — bo to właśnie te dane giną po cichu.

Hamulce przed przyspieszeniem

Godziny wysyłki, listy wykluczeń, deduplikacja, chłodzenie, limity, wypisanie się, zatrzymanie awaryjne. Wstawiamy je przed pierwszą kampanią, nie po pierwszej skardze. To ta część, w której nasze doświadczenie kosztuje najmniej i daje najwięcej, bo jest zrobiona z błędów już opłaconych.

Przekazanie: procedury, role, dokumentacja

Kto ma jaką rolę, jak dodać osobę, jak zatrzymać kampanię, gdzie sprawdzić, kiedy coś nie zostało wysłane, co zrobić przy żądaniu usunięcia. System komercyjny, który tylko budowniczka lub budowniczy potrafi zatrzymać, jest ryzykiem, a nie aktywem.

Kanały, które zbiegają się do tej samej karty: połączenie agenta głosowego, połączenie z człowiekiem, e-mail i odpowiedź ze skrzynki, formularz na stronie, webhook z innego systemu — oraz hamulce, które decydują, co wraca.

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Gdzie są dane i jak są ustrukturyzowane: PostgreSQL przez Supabase, z 96 wersjonowanymi migracjami. Struktura jest hierarchiczna: projekty, pod nimi organizacje z elastycznymi polami w JSONB i wektorem wyszukiwania w pełnym tekście, pod nimi kontakty, a kampanie są przypięte do projektu. Każdy projekt definiuje własny schemat pól — dlatego ta sama aplikacja obsługuje i administrację publiczną, i firmy prywatne, bez rozrastania się bazy przy każdym nowym typie organizacji.
Co znajduje się w stopce każdego wysłanego e-maila: Pełna tożsamość firmy — nazwa, kod podatkowy, zarejestrowana siedziba — adres osoby odpowiedzialnej za ochronę danych, wskazana podstawa prawna oraz źródło adresu: publiczne rejestry i publiczne profile, powiedziane wprost, nie domyślnie. Plus wypisanie jednym kliknięciem i wariant awaryjny z odpowiedzią w jednym słowie. To, co dotyczy podstawy prawnej, jest ponownie sprawdzane przy każdej zmianie prawa — masowa wysyłka, która cytuje nieaktualną podstawę, jest problemem nawet wtedy, gdy reszta jest bez zarzutu.
Kto co widzi: Dostęp odbywa się przez uwierzytelnianie, trasy aplikacji są zamknięte za bramą, a obszar administracyjny ma dodatkową bramę. Role są rozdzielone: administracja, właściciel, sprzedaż, prospecting oraz odrębna rola dla agenta automatycznego — ponieważ agent, który zapisuje w systemie, nie powinien mieć uprawnień człowieka. Nie ma otwartej rejestracji.
Co sprawdzamy wyraźnie przy instalacji: Że każdy sekret jest faktycznie ustawiony na serwerze: sekret używany do podpisywania przychodzących webhooków oraz sekret używany do podpisywania tokenów wypisania. To są kontrole, które wydają się formalne, dopóki nie są: weryfikacja podpisu nie ma czego porównać, jeśli brakuje sekretu, a przewidywalny token to token, który nikogo nie chroni. Trafiają na listę odbiorczą, nie do założeń.
Co jest usuwane na żądanie, a co zostaje: Całkowite usunięcie usuwa adres z sześciu tabel i umieszcza go na stałej liście blokad, tak aby późniejszy import nie mógł go przywrócić. Zostaje ślad w dzienniku, wraz z powodem — bo trzeba móc wykazać, po roku, że żądanie zostało spełnione. Zagregowane statystyki, które nikogo nie identyfikują, też pozostają.

Przykład

Jeden adres otrzymał 42 e-maile w ciągu dnia. To nie była pętla.

Sytuacja

W kampanii prospectingowej skierowanej do organizacji jedna skrzynka pocztowa otrzymała 42 wiadomości tego samego dnia. Pierwsza, wygodna hipoteza, to pętla w kodzie. Tak nie było.

Co zbudowaliśmy

Wyodrębnianie odbiorców było wykonywane per organizacja, a nie per adres. Czterdzieści dwie organizacje korzystały z tej samej skrzynki pocztowej — sytuacja całkowicie zwyczajna w lokalnym środowisku biznesowym, gdzie księgowa, spółka matka albo administrator obsługują kilka podmiotów. Każda organizacja była, zgodnie z zasadami, jednym odbiorcą; adres nie był. Łączna liczba osób objętych tym incydentem wyniosła 11. Naprawa miała trzy części, a nie jedną: deduplikację przeniesiono na adres zapisany małymi literami, wprowadzono pięciodniowe wygaszenie między kampaniami dla tego samego adresu, a wszystkie skrypty wysyłkowe zostały zmuszone do przechodzenia przez wspólny moduł ochrony — ten, który odmawia zapisania wysyłki bez identyfikatora kampanii. Tego samego dnia dodano też wyłącznik, który całkowicie zatrzymuje orchestrator, bez możliwości obejścia.

Co z tego wyszło

Dzisiaj deduplikacja po adresie, lista wypisanych, filtry domenowe i pięciodniowe wygaszenie są gwarancjami wspólnego modułu, a nie zwyczajami skryptu, który akurat się uruchamia. Ręcznie napisany na szybko skrypt nie może już ominąć zabezpieczeń, bo nie ma już prawa sam wysyłać.

Czego nie mówi ten przypadek

Ta lekcja nie przenosi się automatycznie: każda baza danych ma własną formę duplikatu. W jednej jest to adres e-mail, w innej numer telefonu grupy firm, a w trzeciej osoba z dwiema funkcjami. Pierwszą rzeczą, którą robimy przy nowym imporcie, jest sprawdzenie, jaka jest tam forma duplikatu — nie zakładamy, że taka sama.

Pytania

O co pytają ludzie, zanim zadzwonią

Sprzedajecie CRM, z którego sami korzystacie?

Nie, i powód jest techniczny, nie handlowy. Nasz system jest szyty pod jeden zespół: nie ma ścisłego rozdziału danych między klientami i nie ma procesu instalacji, który nie zakładałby dostępu do serwera. Żeby można go było komuś przekazać, trzeba byłoby przepisać dokładnie te dwa elementy. Pokazujemy go z tego samego powodu, dla którego stolarz pokazuje swój warsztat — mówi to więcej o rzemiośle niż broszura. To, co sprzedajemy, to budowa systemu pod to, jak pracujesz ty.

Dlaczego miał(a)bym budować CRM zamiast kupić gotowy?

Najczęściej nie powinien(a)byś, i mówimy ci to my. Gotowe narzędzie jest właściwą odpowiedzią wtedy, gdy twoja praca przypomina założenie, dla którego je zaprojektowano. Budowa staje się uzasadniona w trzech konkretnych sytuacjach: masz fundamentalnie różne typy organizacji, które nie mieszczą się w tym samym zestawie pól; połowa kontaktów pochodzi z systemów automatycznych, które muszą same zapisywać się w karcie; albo potrzebujesz reguł wysyłki, których narzędzie ci nie daje i których nie możesz łamać. Jeśli żadna z tych sytuacji nie zachodzi, mówimy ci, żeby kupić.

Czy możecie połączyć system z CRM-em, którego już używamy?

Tak. Napisaliśmy i uruchomiliśmy konektor dla amoCRM — 12 funkcji serwerowych, z przepływem OAuth, odświeżaniem tokenu, pobieraniem leadów i sprawdzaniem stanu — oraz dla Bitrix24, z OAuth i webhookiem. Dla Zoho CRM mamy udokumentowaną ścieżkę OAuth dla regionów centrów danych. A gdy rzeczywistym źródłem prawdy zespołu jest arkusz kalkulacyjny, mamy dziesięć funkcji dla Google Sheets, od odczytu struktury arkusza po import i aktualizację kontaktów.

Jak konkretnie trafiają połączenia do CRM?

Przez podpisany webhook, wysyłany na końcu połączenia. System pobiera numer telefonu i wyszukuje organizację za pomocą funkcji napisanej od podstaw dla formatów, w jakich numery pojawiają się w danych rzeczywistych — a nie przez porównanie ciągów, które pominęłoby połowę przypadków. Połączenie zapisuje się z transkrypcją, podsumowaniem, sentymentem, adresem nagrania i czasem trwania, powiązane z kartą, a reguła w kodzie może przesunąć lead dalej w lejku na podstawie wyniku połączenia.

Jak upewniacie się, że nie zaczniemy wysyłać spamu?

Przez sześć mechanizmów, które sprawdzają się nawzajem, a nie przez dobrą intencję: godziny wysyłki, listy wykluczeń według typu instytucji, deduplikację po adresie zapisanym małymi literami, pięciodniowy okres chłodzenia dla tego samego adresu, limity dzienne i na jedną serię oraz wyłącznik, który zatrzymuje orchestrator bez drogi obejścia. Poniżej jest konkretny przypadek, który nauczył nas, dlaczego deduplikację trzeba robić po adresie, a nie po organizacji.

Co się dzieje, gdy ktoś prosi o zaprzestanie kontaktu?

Ma to trzy poziomy, wszystkie zabezpieczone tokenem powiązanym z odbiorcą. Wypisanie jednym kliknięciem, bezpośrednio z nagłówka emaila, zgodnie z RFC 8058. Centrum preferencji, gdzie decyzję można też cofnąć. I całkowite usunięcie, które usuwa adres z sześciu tabel i dodaje go do stałej listy blokad — tak, aby import wykonany za sześć miesięcy nie przywrócił go z powrotem. Ostatnia część to ta, którą większość systemów pomija.

Gdzie są przechowywane dane i kto może je zobaczyć?

W bazie PostgreSQL, na infrastrukturze uzgodnionej na początku projektu, z wersjonowanymi migracjami — czyli każda zmiana struktury to plik, a nie ręczna ingerencja. Dostęp jest przez odrębne role, z osobną rolą dla agentów automatycznych, bo system, który zapisuje do bazy, nie powinien mieć uprawnień człowieka. Nie ma otwartej rejestracji i nie ma publicznej powierzchni.

Czy możecie zaimportować naszą starą bazę, razem z duplikatami?

Tak, a właśnie duplikaty są powodem, dla którego import jest tak zbudowany. Plik jest przetwarzany strumieniowo, w partiach po 200 wierszy, z indeksem deduplikacji po numerze podatkowym, emailu i telefonie zbudowanym przed zapisem, plus walidacją adresów: format, jednorazowe domeny, nieprawidłowe wzorce. To, co się nie zgadza, nie jest po cichu odrzucane — jest raportowane, żebyście mogli zdecydować.

Czy gwarantujecie wzrost sprzedaży?

Nie. Możemy zagwarantować, że będzie wiadomo, kto został objęty kontaktem, przez jaki kanał, co zostało powiedziane i co dalej — oraz że system sam się zatrzyma, gdy powinien. Wyniki liczbowe zależą od oferty, rynku i zespołu dzwoniącego, czyli od rzeczy, których nie kontrolujemy. Nie publikujemy procentów poprawy, których nie zmierzyliśmy, ani u nas, ani u kogokolwiek innego.

Na czym opierają się powyższe stwierdzenia (24 źródeł)

24 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Jak pracujemy Wszystkie usługi

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy