CRM (system do prowadzenia klientów i szans sprzedaży) bywa pusty nie dlatego, że brakuje mu funkcji, tylko dlatego, że wpis powstaje dopiero wtedy, gdy handlowiec znajdzie na niego czas. Najczęściej nie znajduje go od razu po rozmowie, a później pamięta mniej. Dlatego zanim kupicie nowy „CRM z AI”, warto nazwać problem dokładnie: to jest problem zapisu, nie oprogramowania. System z modelem językowym (programem AI, który czyta i pisze tekst), który nie dostaje treści rozmów i maili, będzie tak samo pusty jak obecny.
Rozwiązanie, które opisuję w tym tekście, jest proste do sformułowania: po każdym wątku mailowym i każdej rozmowie system przygotowuje propozycję wpisu, a handlowiec ją zatwierdza, poprawia albo odrzuca. Na stronie o AI w dziale sprzedaży to jeden punkt na liście; tutaj rozpisujemy ten punkt w całości: skąd brać treść, jak wygląda dobry wpis, których pól model nie powinien zgadywać, jak zmierzyć efekt i kiedy wystarczy asystent wbudowany w CRM, który już macie.
Automatyzacja CRM bez AI: co załatwia reguła w samym systemie
Hasło „automatyzacja CRM” często oznacza coś, do czego model językowy nie jest potrzebny. Zmiana etapu po wysłaniu oferty według ustalonej przez Was zasady, przypomnienie o szansie bez ruchu, przypisanie zapytania do handlowca według regionu, zadanie utworzone po wygraniu szansy — to reguły, które popularne systemy CRM mają wbudowane i które działają przewidywalnie, bo za każdym razem robią to samo.
Jeżeli Wasz problem mieści się na tej liście, zacznijcie od ustawienia reguł w obecnym systemie. Model przydaje się dopiero tam, gdzie trzeba przeczytać tekst pisany swobodnie przez ludzi — wątek mailowy, notatkę z rozmowy, opis w formularzu — i zamienić go na pola w CRM. Tekst w stałym formacie, na przykład zgłoszenie z generatora ofert, zwykle da się rozłożyć regułą. To jest ta część automatyzacji CRM, o której dalej piszemy.
Skąd brać treść wpisu: wątki mailowe, notatki z rozmów i formularze
Treść wpisu ma trzy źródła i warto je rozpisać osobno, bo każde ma inne ograniczenia.
- Wątek mailowy z klientem. Najlepsze źródło, bo ustalenia są tam zapisane słowami klienta, z datą i nadawcą. Warunek: system musi mieć dostęp do korespondencji z klientami — tylko do wątków z adresami kontaktów, które są już w CRM, albo do kopii korespondencji zapisanej w CRM, a nie do całej skrzynki handlowca. Maile prywatne i te niezwiązane ze sprzedażą nie powinny w ogóle trafiać do modelu.
- Notatka po rozmowie. Kilka zdań wpisanych lub podyktowanych przez handlowca zaraz po telefonie albo spotkaniu. To źródło nie wymaga nagrywania, a model robi z niego uporządkowany wpis zamiast handlowca.
- Formularz na stronie. Zapytanie od nowego klienta: dane kontaktowe są w osobnych polach, a opis potrzeby w wolnym tekście, który model może rozłożyć na pola.
Transkrypcja nagranej rozmowy (jej tekstowy zapis) to wariant drugiego źródła, a nie osobna kategoria — i dziedziczy wszystkie obowiązki związane z nagrywaniem. Nie powtarzamy tu podstaw prawnych; opisaliśmy je na stronie o voicebocie, w części „Nagrania rozmów to dane osobowe”, oraz w tekście o RODO (ogólnym rozporządzeniu o ochronie danych) przy wdrożeniu modeli językowych, w części o podstawie prawnej. Dla projektu wpisów do CRM z tamtych zasad wynikają trzy rzeczy do zbudowania: treść informacji dla rozmówcy, że rozmowa jest nagrywana i w jakim celu; ustalony okres przechowywania nagrań i transkrypcji, po którym są usuwane; oraz wpis, który zawiera tylko pola potrzebne do sprzedaży, a nie całą rozmowę skopiowaną do notatki.
Anatomia proponowanego wpisu
Dobra propozycja wpisu to nie streszczenie rozmowy. Streszczenie się czyta; wpis zmienia pola w CRM, więc każde pole musi dać się sprawdzić w kilka sekund. Proponujemy taki układ:
- Kontakt i firma — kto pisał albo z kim była rozmowa, dopasowany do istniejącego kontaktu w CRM albo oznaczony jako nowy.
- Źródło — odnośnik do wątku, notatki albo formularza, z którego powstał wpis.
- Co ustalono — dwa, trzy zdania, bez ocen i bez szczegółów, których nie ma w źródle.
- Następny krok z datą — kto, co i do kiedy; jeżeli daty w źródle nie ma, pole zostaje puste z dopiskiem „brak terminu”, a nie z datą wymyśloną przez model.
- Otwarte pytania — to, o co klient zapytał, a na co nikt jeszcze nie odpowiedział.
- Cytat przy każdym polu — fragment źródła, z którego pole odczytano, żeby handlowiec nie musiał otwierać całego wątku.
Handlowiec ma trzy przyciski: zatwierdź, popraw, odrzuć. Każda decyzja jest zapisywana, bo z tych zapisów powstaje ocena, czy system działa (o tym niżej). Jak zaprojektować samo zatwierdzanie — co musi zobaczyć osoba zatwierdzająca, w jakim terminie i kiedy można poluzować nadzór — opisaliśmy w tekście o zatwierdzaniu przez człowieka (human in the loop).
Które pola model wypełnia, a których nie zgaduje
To jest najważniejsza tabela w tym tekście. Dzieli pola wpisu na trzy klasy według tego, skąd pochodzi ich wartość, a nie według tego, jak dobrze radzi sobie dany model.
| Klasa pola | Przykłady | Co robi system | Co robi handlowiec |
|---|---|---|---|
| Wartość jest zapisana w źródle | kontakt, data rozmowy, co ustalono, następny krok i jego termin, pytania klienta | wypełnia pole i dołącza cytat ze źródła | sprawdza i zatwierdza |
| Wartość jest w źródle, ale wymaga interpretacji | zastrzeżenia klienta, wspomniany konkurent, kto decyduje po stronie klienta | proponuje wartość oznaczoną do sprawdzenia, z cytatem | decyduje, czy interpretacja jest trafna |
| Wartość to decyzja, a nie fakt | wartość szansy, prawdopodobieństwo wygranej, zmiana etapu, rabat | nie wypełnia; może zacytować kwotę z maila w notatce, ze wskazaniem źródła | wpisuje sam albo zostawia bez zmian |
Reguła, która porządkuje trzecią klasę: wszystko, co zasila prognozę sprzedaży albo ocenę szans, wpisuje człowiek — niezależnie od klasy, do której pole należałoby z innych powodów, i niezależnie od wyników pilotażu. Jeżeli klient podał w mailu swój budżet, to jest informacja warta zapisania w notatce — ale wartość szansy to decyzja handlowca o tym, co realnie sprzeda. Model, który wypełniałby ją z maili, wpisywałby do prognozy liczby, za którymi nikt nie stoi.
Druga klasa jest najciekawsza w pilotażu. To, jak dokładnie handlowiec musi sprawdzać pola takie jak „wspomniany konkurent”, rozstrzyga się na Waszych danych, z dziennika zatwierdzeń, a nie z góry. Klasa pola się przy tym nie zmienia: interpretacja pozostaje interpretacją, nawet gdy jest często trafna.
Dwie liczby higieny CRM, które policzycie dziś
Zanim cokolwiek wdrożycie, zapiszcie dwie liczby. Sprawdźcie, czy Wasz CRM pozwala policzyć je filtrem — do żadnej z nich nie potrzeba integracji.
- Odsetek otwartych szans z następnym krokiem z datą. Filtr: otwarte szanse, które mają zaplanowane działanie (zadanie, spotkanie, telefon) z datą dzisiejszą lub późniejszą. Podzielcie ich liczbę przez liczbę wszystkich otwartych szans. Szansa bez następnego kroku to zwykle szansa, o której nikt nie pamięta.
- Szanse bez kontaktu. Filtr: otwarte szanse, w których od N dni nie było kontaktu z klientem ani działania sprzedażowego. Liczbę dni ustalcie sami, według długości Waszego cyklu sprzedaży, i nie zmieniajcie jej później. Sam wpis dodany przez system ani zaplanowane zadanie nie są kontaktem, a wpis uzupełniony wstecz liczy się z datą rozmowy, a nie z datą zapisu. Zapiszcie, ile jest takich szans.
Nie podajemy wartości, które „powinny” wyjść, bo zależą od branży, długości cyklu i tego, jak Wasz zespół korzysta z CRM. Liczy się zmiana względem własnego punktu wyjścia: ten sam filtr przed pilotażem i po nim. Obie liczby pokazują porządek w CRM — czy ustalenia i następne kroki naprawdę do niego trafiają. Nie mierzą tego, czy system dobrze czyta maile i notatki (to pokazuje dziennik pilotażu opisany niżej), ani tego, czy handlowcy częściej kontaktują się z klientami: lepszy zapis może też ujawnić szanse, w których od dawna nic się nie dzieje.
AI w CRM: asystent wbudowany czy integracja z systemem, który już macie
Część systemów CRM ma już asystentów, którzy robią coś podobnego. Zanim zlecicie integrację, sprawdźcie, co dokładnie robią — nie według strony z cennikiem, tylko według dokumentacji. Poniżej to, co opisują dokumentacje trzech systemów CRM, w stanie na 12 października 2026 roku. To nie jest ranking i nie porównujemy cen; dostępność zależy od planu i może się zmienić.
| System i funkcja | Z czego korzysta | Co przygotowuje | Czy ktoś zatwierdza przed zapisem |
|---|---|---|---|
| HubSpot, karta postępu szansy („deal progression”, wersja beta; Sales Hub i Service Hub w planach Professional i Enterprise) | maile, notatki oraz transkrypcje rozmów i spotkań zapisane w HubSpot; wymaga włączonego nagrywania i transkrypcji oraz notatnika HubSpot (Notetaker) albo połączenia z Zoom, Microsoft Teams lub Google Meet; handlowcy muszą mieć skrzynkę pocztową podłączoną do HubSpot | propozycje zmian pól szansy (na zrzucie w dokumentacji m.in. kwota i następny krok) oraz zalecane działania | każdą propozycję się akceptuje albo odrzuca; jest też przycisk „zatwierdź wszystkie”, a w ustawieniach można włączyć aktualizacje automatyczne |
| Bitrix24, CoPilot w CRM | nagrania rozmów telefonicznych (od 10 sekund do godziny) i czaty zapisane przy potencjalnych klientach i szansach (w Bitrix24: leady i deale) oraz maile zapisane w CRM — w leadach i szansach domyślnie przetwarza automatycznie pierwszy przychodzący mail, a w ustawieniach można wybrać przetwarzanie ręczne albo automatyczne przetwarzanie wszystkich maili przychodzących, wychodzących lub obu rodzajów; w kontaktach i firmach tylko ręcznie | transkrypcja, streszczenie, wypełnienie pól w formularzu CRM | puste pola wypełnia od razu i oznacza; gdy pole ma już wartość, proponuje zmianę do potwierdzenia |
| Livespace, sugestie AI i podsumowania notatek | notatki i połączenia; dokumentacja zaznacza, że sugestie nie działają dla e-maili | propozycje zadań z wypełnionym tytułem i datą, podsumowania długich notatek | według Livespace AI tylko dodaje informacje i wyłącznie po zatwierdzeniu; nie zmienia ani nie usuwa istniejących danych |
Z tej tabeli wynikają dwie praktyczne obserwacje. Po pierwsze, asystenci różnią się tym, czy zmieniają pola bez pytania: Bitrix24 wypełnia puste pola od razu, HubSpot czeka na akceptację, ale pozwala włączyć automat, a Livespace deklaruje, że niczego nie zapisuje bez zatwierdzenia. Po drugie, różnią się źródłami: HubSpot i Bitrix24 czytają maile i rozmowy zapisane w CRM (HubSpot także notatki, Bitrix24 także czaty), a sugestie Livespace wykorzystują notatki i rozmowy, ale nie maile. Sprawdźcie też, gdzie trafia treść — Livespace pisze na przykład, że treść notatek wysyła przez API (interfejs wymiany danych między systemami) do OpenAI i że nie służy ona do trenowania modeli.
Asystent wbudowany wystarczy, gdy spełnione są trzy warunki: korzystacie z jednego CRM, maile i rozmowy handlowców i tak przez niego przechodzą, a jego ustawienia pozwalają zatwierdzać zmiany w tych polach, na których Wam zależy, i wyłączyć zmiany w polach z trzeciej klasy oraz w każdym polu, które zasila prognozę albo ocenę szans. Aktualizacje automatyczne, które niektóre systemy oferują, to możliwość, a nie zalecenie — w pierwszej wersji zostawcie je wyłączone. Wtedy integracja nie ma uzasadnienia.
Integracja AI z CRM, który już macie, ma sens w pozostałych przypadkach: gdy poczta albo telefony są poza systemem, gdy wpis wymaga danych z kilku miejsc (na przykład statusu zamówienia z systemu ERP, czyli programu do zamówień, magazynu i faktur), gdy Wasz CRM nie ma takiego asystenta albo gdy chcecie zasady „żadne pole bez decyzji człowieka”, której gotowa funkcja nie daje. Jak technicznie połączyć się z popularnymi systemami CRM, opisaliśmy w tekście o integracji AI z ERP i CRM, a ogólną regułę wyboru między gotowym narzędziem a projektem — w tekście o tym, jak wdrożyć AI w firmie.
Co zapisuje pilotaż wdrożenia AI w CRM
Pilotaż ma odpowiedzieć na jedno pytanie: czy tabela klas pól powyżej sprawdza się na Waszych danych. Dlatego zapisuje się decyzje, a nie tylko to, czy system działa.
- Dla każdego wpisu: źródło (mail, notatka, formularz, transkrypcja), czas od końca rozmowy albo ostatniego maila do zatwierdzenia i decyzja: przyjęty bez zmian, poprawiony albo odrzucony.
- Dla każdego pola: czy przyjęte bez zmian, poprawione (z rodzajem poprawki, na przykład inna data albo inny kontakt), odrzucone przez handlowca, czy pozostawione puste, bo w źródle nie było danych.
- Dla odrzuconych wpisów: powód w kilku słowach — zły kontakt, wątek niezwiązany ze sprzedażą, wpis niepotrzebny.
- Pominięcia: wpisy, które handlowiec dodał ręcznie, bo system ich nie zaproponował.
Dziennik zawiera dane klientów, więc zapisujcie w nim tylko to, co potrzebne do oceny — rodzaj poprawki zamiast pełnej treści — i usuńcie go po zakończeniu pilotażu, w ustalonym terminie.
Pole, które handlowcy często poprawiają, wymaga poprawy w tym, jak system je odczytuje, albo staranniejszego sprawdzania. Pole z pierwszej lub drugiej klasy przyjmowane bez zmian przez dłuższy czas może zyskać lżejszy nadzór — nigdy pole z trzeciej klasy ani żadne pole, które zasila prognozę albo ocenę szans — ale to decyzja podejmowana na danych, według reguł z tekstu o zatwierdzaniu przez człowieka. Uprawnienia systemu i zapis jego działań w Waszych systemach to osobny temat, opisany w tekście agent AI a chatbot. Etapy samego pilotażu opisujemy w metodyce wdrożenia.
Kiedy nie automatyzować wpisów w CRM — i czego tu celowo nie ma
Nie zaczynajcie, jeżeli prawdziwym problemem jest to, że nikt do CRM nie zagląda. Automatyczne wpisy wypełnią system, którego nadal nikt nie czyta. Najpierw trzeba ustalić, kto i w jakim celu korzysta z CRM — na przykład czy kierownik sprzedaży prowadzi na nim cotygodniowy przegląd szans. Nie zaczynajcie też, gdy rozmów jest tak mało, że ręczny wpis to chwila pracy, albo gdy asystent wbudowany w Wasz CRM obsługuje już Wasze źródła.
W tym tekście celowo nie ma oceny szans (lead scoring) ani automatycznych serii wiadomości do klientów. Ocenę szans pomijamy, bo najpierw trzeba mieć wiarygodne dane w CRM, a pusty CRM ich nie ma — dlatego zaczynamy od zapisu. Ponowny kontakt z klientem (follow-up) występuje tu tylko jako pole „następny krok” w istniejącej szansie: system może przygotować szkic odpowiedzi w trwającym wątku tylko wtedy, gdy z klientem ustalono już następny krok. Szkic zawsze wysyła handlowiec. Automatów do zimnych maili nie budujemy w ogóle; dlaczego, piszemy na stronie czego nie robimy.
Jeżeli po policzeniu dwóch liczb widzicie, że problemem jest zapis, a nie sam CRM, w ploch.ai budujemy dokładnie to: propozycje wpisów z maili i rozmów do zatwierdzenia, w systemie, który już macie. Szerzej o tym, które procesy nadają się do automatyzacji AI, piszemy na osobnej stronie, a o tym, co składa się na koszt takiego projektu — w tekście o tym, ile kosztuje wdrożenie AI. Gdy wpisy mają nie tylko powstawać, ale też uruchamiać działania w innych systemach, to już projekt agenta AI.
Źródła i stan na 12 października 2026 roku
- HubSpot — „Move deals forward with deal progression” — funkcja w wersji beta, plany Sales Hub i Service Hub Professional i Enterprise; korzysta z zapisanych maili, notatek i transkrypcji, proponuje zmiany pól szansy do akceptacji lub odrzucenia, z opcją „zatwierdź wszystkie” i aktualizacji automatycznych; odczyt 12 października 2026 r.
- Bitrix24 — „CoPilot in CRM: Call transcription and automatic field updates” — transkrypcja, streszczenie i wypełnianie pustych pól z nagrań rozmów; propozycja zmiany do potwierdzenia, gdy pole ma już wartość; aktualizacja strony 5 października 2026 r.; odczyt 12 października 2026 r.
- Bitrix24 — „CoPilot in CRM: Transcribe call recordings and analyze chats” i „CoPilot in CRM: How to process an email” — czaty i maile jako źródła; puste pola wypełniane automatycznie, zmiana wypełnionych do potwierdzenia; domyślnie przetwarzany pierwszy przychodzący mail w leadzie lub szansie; odczyt 12 października 2026 r.
- Livespace — „AI w CRM” — deklaracja, że AI tylko dodaje informacje i wyłącznie po zatwierdzeniu; odczyt 12 października 2026 r.
- Livespace — „Asystent AI w Livespace” — sugestie AI z notatek i połączeń, niedostępne dla e-maili; podsumowania notatek dłuższych niż 200 znaków; treść notatek wysyłana przez API do OpenAI i niewykorzystywana do trenowania modeli; odczyt 12 października 2026 r.