Problem: firma, która mieszka w skrzynce mailowej

Kluczowa obserwacja z tego wdrożenia: klienci nie wypełniają formularzy. Piszą zwykłe maile — „szukamy zjeżdżalni na piknik 14 czerwca w godzinach 12–17, jaka cena?". Cała sztuka polega na tym, żeby system rozumiał taki język i sam zamieniał go na ustrukturyzowane dane: kontakt, zadanie, termin, listę atrakcji, wycenę. Dokładnie to robi warstwa językowa (LLM) opisana niżej — i robi to równie dobrze na modelu chmurowym, jak i na modelu uruchomionym lokalnie, bez wysyłania korespondencji poza firmę.

Architektura: sześć modułów, jedna baza danych

System nie jest monolitem. Składa się z niezależnych modułów spiętych wspólną bazą danych (otwartoźródłowy CRM Twenty na PostgreSQL). Każdy moduł można wyłączyć, wymienić lub rozbudować bez ruszania pozostałych. Poniższy schemat pokazuje, jak dane płyną przez system — od skrzynki mailowej, przez analizę językową, do bazy, planera i asystenta.

Taka budowa ma jeszcze jedną konsekwencję, ważną dla właściciela firmy: system rośnie razem z biznesem. Fakturowanie, powiadomienia SMS, integracja z kalendarzem zewnętrznym — to kolejne klocki dokładane do istniejącej bazy, a nie przebudowa całości. Więcej o kierunkach rozbudowy na końcu wpisu.

Budowa systemu — moduł po module

Poniżej wszystkie sześć modułów w kolejności, w jakiej „dotykają" danych: od pierwszego odczytu skrzynki, przez bazę, po interfejsy, w których pracuje zespół. Przy każdym module opisujemy co robi, jak jest zbudowany i jak łączy się z resztą systemu.

Wdrożenie nowego CRM-u zwykle rozbija się o jedno pytanie: „kto przepisze te wszystkie dane?". Tutaj — nikt. Bot importu przetwarza archiwum skrzynki (w opisywanym wdrożeniu: ponad tysiąc maili, około 150 unikalnych klientów), grupuje wiadomości w wątki po adresie klienta, odsiewa powiadomienia automatyczne i newslettery, a z pozostałych rozmów model językowy wyciąga ustrukturyzowane dane.

Efekt: pierwszego dnia po wdrożeniu firma ma w CRM komplet kontaktów z pełną historią współpracy — czego ręcznie nie zrobiłby nikt. Import działa wyłącznie na lokalnej kopii skrzynki, w trybie tylko-do-odczytu, i jest idempotentny: można go bezpiecznie przerywać, wznawiać i powtarzać — duplikaty nie powstają, bo rekordy są dopasowywane po adresie e-mail i nazwie.

Drugi bot działa całodobowo i reaguje na każdą nową wiadomość. Z treści maila — pisanego zwykłym, ludzkim językiem, bez żadnych formularzy — model językowy wydobywa trzy warstwy informacji: dane kontaktowe, profil klienta i konkrety rezerwacyjne. Zobacz na żywym przykładzie:

Zasady, na których stoi bot

Sercem systemu jest Twenty — nowoczesny, otwartoźródłowy CRM (alternatywa dla Salesforce i HubSpota) uruchomiony na własnym serwerze firmy, w kontenerach Docker, na bazie PostgreSQL. Interfejs przypomina Notion: czysty, szybki, przyjemny w codziennej pracy.

Najważniejsza cecha z punktu widzenia całej integracji to rozszerzalny model danych: przez API można programowo dokładać własne obiekty, pola i relacje. Z tego korzystają wszystkie pozostałe moduły — rezerwacje, atrakcje, taryfy i pozycje rezerwacji to nasze obiekty dobudowane do CRM-u, a nie funkcje „wciśnięte" w cudzy szablon. Standardowe obiekty (kontakty, firmy, notatki, zadania) zostały z kolei rozszerzone o pola potrzebne w branży eventowej: adres imprezy, typ eventu, typ kontaktu.

Na modelu danych CRM zbudowaliśmy dedykowaną aplikację webową — planer rezerwacji. To operacyjne centrum firmy: tu widać kalendarz imprez, dostępność sprzętu, wyceny i stan płatności. Aplikacja działa w przeglądarce (na laptopie i telefonie) i rozmawia bezpośrednio z bazą CRM — obie strony zawsze widzą te same dane. Cztery zakładki:

Cykl życia rezerwacji: dziesięć statusów (animacja)

Każda rezerwacja przechodzi przez jasno zdefiniowany cykl życia. Na statusy spięta jest logika rozliczeń: zaliczka liczy się jako wpłacona od statusu „Zaplanowane", a event znika z listy „do zapłaty" dopiero po „Opłacone" — celowo nie przy „Zrealizowane", bo zrealizowany nie znaczy opłacony. Dzięki temu kafelki finansowe zawsze mówią prawdę o realnych należnościach.

Cennik taryfowy i automatyczna wycena

Kontrola dostępności — ostrzega, ale nie ubezwłasnowolnia

Dla wybranego dnia system buduje mapę zajętości: która atrakcja jest już zarezerwowana i przez jaki event (rezerwacje anulowane nie blokują sprzętu). Zajęte atrakcje spadają na dół listy i dostają czerwoną plakietkę, ale pozostają klikalne — to świadoma decyzja projektowa. System ostrzega o konflikcie, lecz nie zabrania: dwie imprezy w tym samym dniu bywają obsługiwalne logistycznie, np. jedna rano, druga wieczorem. Decyzję podejmuje człowiek, system dostarcza pełną informację.

Drobiazgi, które decydują o codziennej wygodzie

Najciekawsza automatyzacja spina moduły w całość i robi rzecz zaskakująco trudną: zamienia rozmowę w strukturę. Gdy zadanie w CRM osiąga status „Zaplanowane", osobna usługa (pracująca w pętli, cykl co 60 sekund) pobiera całą korespondencję z danym klientem — obie strony rozmowy, ułożone chronologicznie — i prosi model językowy o wyciągnięcie ostatecznych ustaleń.

Dlaczego „ostateczne ustalenia" to klucz

W prawdziwych negocjacjach klient najpierw pyta o trzy atrakcje, potem z jednej rezygnuje, potem zmienia godzinę. Rezerwacja ma odzwierciedlać finał rozmowy, nie jej historię — dlatego model dostaje cały wątek z jawną regułą, że późniejsze maile nadpisują wcześniejsze. Z wyniku powstaje kompletny wpis: nazwa, data, godziny, lokalizacja, cena, zaliczka oraz pozycje atrakcji dopasowane do katalogu.

Dwukierunkowa synchronizacja statusów

Zespół pracuje w dwóch narzędziach: handlowo w CRM (zadania), operacyjnie w planerze (rezerwacje). Oba mają ten sam słownik dziesięciu statusów, a synchronizator dba, żeby zawsze mówiły to samo: zmiana statusu w planerze w ciągu minuty pojawia się na zadaniu w CRM — i odwrotnie. Przy rozbieżności wygrywa nowsza zmiana, a pusty status nigdy nie nadpisuje niepustego. Każdy pracuje w narzędziu, które woli, a dane są zawsze spójne.

Całość spina asystent czatowy zbudowany na Open WebUI — otwartoźródłowym interfejsie czatu, który można uruchomić z modelem lokalnym. Dedykowane narzędzie daje modelowi kontrolowany dostęp do skrzynki, CRM-u i planera, a użytkownik po prostu rozmawia. Rzeczy, które wymagały otwarcia trzech systemów i kilkunastu kliknięć, załatwia jedno zdanie na czacie.

Co potrafi asystent

Asystent ma też dostęp do firmowej bazy wiedzy (cenniki, zasady, FAQ), więc odpowiada w kontekście realnej oferty. Ważne: to nie zastępuje planera ani CRM-u — to trzeci, najszybszy sposób dostępu do tych samych danych.

Gdzie lądują dane — model relacji w bazie

Siłą systemu jest to, że wszystkie moduły piszą i czytają z jednego, relacyjnego modelu danych. Najważniejsze obiekty i powiązania:

Relacje: rezerwacja wskazuje na kontakt, firmę i zadanie, z którego powstała — pełna ścieżka od maila do imprezy jest odtwarzalna. Powiązanie „rezerwacja ↔ atrakcje" realizuje obiekt pośredniczący (pozycja rezerwacji), który przy okazji niesie taryfę i cenę konkretnej pozycji — czyli rzeczy, które nie są cechą ani rezerwacji, ani atrakcji, tylko ich związku. Dzięki temu jedno zapytanie o dzień zwraca komplet: kto, gdzie, jakie atrakcje, za ile i na jakim etapie rozliczenia.

Bezpieczeństwo: nic nie wystaje do internetu

System pracuje na serwerze, do którego żadna usługa nie jest wystawiona publicznie. To nie deklaracja marketingowa, tylko konkretny zestaw zasad architektonicznych:

Jakość wykonania: zasady, które trzymają system w ryzach

Dwa miesiące pracy nad tym projektem to nie tylko funkcje — to również inżynierska dyscyplina, dzięki której system można bezpiecznie rozwijać latami. Kilka reguł, które odróżniają go od „skryptu, który kiedyś działał":

Dla kogo jest taki system

Opisane wdrożenie powstało dla wypożyczalni atrakcji eventowych, ale architektura — dwa boty, otwarty CRM, dedykowany panel, most LLM i asystent czatowy — przenosi się na każdą branżę, w której klienci piszą maile, a firma planuje zasoby w czasie. Zmienia się słownik (zamiast „atrakcji" — mieszkania, ekipy, sale, pojazdy), ale nie mechanika.

System, który rośnie razem z firmą

To nie jest zamknięte pudełko — ten system nie ma „wersji pudełkowej". Całość, od pól w bazie, przez logikę botów, po wygląd planera, jest w pełni modyfikowalna, bo każda firma ma inny proces. Rolą wdrożenia nie jest wciśnięcie firmy w cudzy schemat, tylko odwzorowanie jej rzeczywistego obiegu informacji: z maili, przez bazę, do kalendarza i rozliczeń. Kierunki rozbudowy, na które architektura jest gotowa już dziś: