Dane w CRM nadają się pod automatyzacje i AI wtedy, gdy dla każdego pola wiadomo, kto je wypełnia, co znaczą jego wartości i czy wolno je nadpisać. Kompletność jest drugim warunkiem, nie pierwszym. Baza wypełniona w 95 procentach, w której dwóch handlowców wpisuje to samo źródło leada pod dwiema różnymi nazwami, zatrzyma automatyzację równie skutecznie jak pusta.
Poniżej masz sześć rzeczy, które sprawdzam w danych przed podłączeniem czegokolwiek, katalog awarii, które widziałem na realnych wdrożeniach Pipedrive'a, i jedną regułę odwrotną do tego, co zwykle słyszysz o porządkowaniu CRM-u. Jeśli dopiero zastanawiasz się, czy Twój system w ogóle działa, zacznij od audytu wdrożonego CRM-a, a wróć tutaj po rozstrzygnięciu tamtych dziewięciu punktów.
W skrócie:
Jakość danych w CRM to stopień, w jakim rekordy dają się przetworzyć bez udziału człowieka, który zna kontekst. Klasyczne definicje mówią o kompletności, poprawności, spójności i aktualności, i wszystkie cztery są prawdziwe. Tylko że przy raporcie dla managera brak jednego pola oznacza gorszą liczbę, a przy automatyzacji oznacza, że reguła się nie uruchomi dla tego rekordu i nikt się o tym nie dowie.
To jest cała różnica między rozmową o danych sprzed pięciu lat a dzisiejszą. Dopóki dane czytał człowiek, niespójność kosztowała sekundę zastanowienia. Handlowiec patrzył na „polecenie" w jednym rekordzie i „poleceni" w drugim i wiedział, że to jedno i to samo. Automat tego nie wie i nie zgłasza przy tym błędu. Po prostu nie wykonuje się dla połowy bazy.
Warstwy wymagań rozpisałem w tekście o audycie wdrożonego CRM-a: raport potrzebuje kompletnych pól, automatyzacja dokłada jedno źródło prawdy dla każdego pola, agent AI dokłada spisane reguły procesu. Tutaj schodzę o poziom niżej, do pojedynczych pól i do tego, jak je policzyć.
Sprawdzam po kolei: źródło prawdy dla pola, spójność wartości, duplikaty, kompletność pól decyzyjnych, historię etapów i dat oraz zgody. Każdy z tych punktów da się policzyć filtrem albo raportem w Pipedrive, bez eksportu do arkusza.
| Co sprawdzam | Jak to policzysz w CRM-ie | Kiedy to jest problem |
|---|---|---|
| Jedno źródło prawdy dla pola | Dla każdego pola wypisz, kto je wypełnia: człowiek, automatyzacja, integracja czy AI | Gdy dwa mechanizmy piszą do tego samego pola. Nadpisują się nawzajem i nikt tego nie widzi |
| Spójność wartości | Zrób raport grupujący po polu i policz unikalne wartości | Gdy wartości jest więcej niż realnych kategorii. Cztery źródła leadów i dziewiętnaście wpisanych wartości to niespójność |
| Duplikaty | Filtr po nazwie firmy i po NIP-ie osobno, potem po domenie e-mail | Gdy ta sama firma ma dwa rekordy z różnym opiekunem. Scalenie nie rozwiązuje sprawy, bo zostaje pytanie, kto ją prowadzi |
| Kompletność pól decyzyjnych | Filtr „pole jest puste" na każdym polu, na którym opiera się warunek albo raport | Gdy pusta jest choćby jedna otwarta szansa. Ten rekord wypada z automatyzacji w całości |
| Historia etapów i dat | Raport konwersji między etapami i rozkład czasu w etapie | Gdy szanse przeskakują etapy albo stoją w jednym po kilkaset dni. Prognoza liczona z takiego lejka jest zmyślona |
| Zgody i podstawa kontaktu | Filtr po polu zgody na całej bazie kontaktów | Gdy nie wiesz, skąd rekord się wziął i czy wolno do niego napisać. Automatyczna sekwencja rozsyła to ryzyko od razu do wszystkich |
Kolejność nie jest przypadkowa. Pierwsze trzy punkty dotyczą struktury i trzeba je rozstrzygnąć raz. Trzy kolejne dotyczą zawartości i wracają co kwartał, bo baza żyje.
Przy duplikatach warto od razu włączyć dociąganie danych rejestrowych po numerze NIP z CEIDG i REGON. Nazwa firmy zapisuje się wtedy jednym sposobem, więc filtr ma co porównywać, a NIP staje się identyfikatorem, po którym duplikat widać przed importem. Pokazuję to na konkretnej branży przy CRM dla biura rachunkowego.
Najczęściej wykłada się punkt pierwszy, a wygląda najniewinniej. W jednej firmie, którą audytowałem, integracja dodająca firmy z narzędzia do rozpoznawania ruchu na stronie potrafiła nadpisać nazwę organizacji wpisaną wcześniej ręcznie przez handlowca. Po zmianie nazwy w źródle integracja przestawała rozpoznawać istniejący rekord i zakładała drugi. Nikt nie zgłaszał tego jako błędu przez kilka miesięcy, bo osobno każdy z tych rekordów wyglądał poprawnie.
To jest lista z realnych wdrożeń, nie z artykułu o dobrych praktykach. Każdy punkt widziałem w Pipedrive u klienta i każdy zatrzymał coś konkretnego.
Wspólny mianownik jest jeden: żaden z tych rekordów nie wygląda na uszkodzony. Dane, które nie nadają się pod automatyzacje, wyglądają dokładnie tak samo jak te, które się nadają, i dlatego nikt tego nie zgłasza, dopóki ktoś nie spróbuje na nich czegoś uruchomić.
Zwykle słyszysz, żeby zamienić pola tekstowe na listy wyboru, bo tylko z list da się raportować. Przez lata była to dobra rada. Od kiedy dane z CRM-u czyta też model, przestała być słuszna w całości i warto to rozdzielić.
Listą wyboru ma być pole, na którym opiera się warunek w automatyzacji albo oś w raporcie. Etap, typ klienta, powód straty, segment. Tu swoboda kosztuje, bo automatyzacja porównuje ciągi znaków i „Cena" to dla niej co innego niż „cena za wysoka".
Polem tekstowym może zostać to, co jest wypowiedzią klienta albo okolicznością. Deklarowane źródło leada jest u mnie polem tekstowym i zostaje tekstem, bo odpowiedź bywa konkretnym zapytaniem wpisanym w wyszukiwarkę albo nazwiskiem osoby, która poleciła. Zamiana tego na listę z pięcioma pozycjami wyrzuca dokładnie tę część informacji, która jest coś warta. Model czytający sto takich odpowiedzi wyciągnie z nich wzorzec, którego żadna lista wyboru by nie pokazała, bo listę ktoś musiałby wymyślić z góry.
Nie oznacza to, że da się zostawić bałagan i liczyć, że AI go posprząta. Granica biegnie po roli pola, nie po jego wygodzie:
Rozdzielenie pola na dwa jest najczęstszą poprawką, jaką robię na wdrożeniach. Lista wyrzuca to, co w odpowiedzi bywa najcenniejsze: zapytanie z wyszukiwarki albo nazwisko osoby polecającej.
Osobno stoi firmowy slang. Klienci mówią mi to regularnie: wewnętrzne skróty i nazwy własne obniżają jakość automatycznych podsumowań, bo model nie wie, co znaczy skrót, którego używacie od dziesięciu lat. Tego nie naprawia się strukturą pól, tylko słownikiem pojęć w kontekście firmy dla AI.
Przy każdym polu zapisz jedną z czterech odpowiedzi: człowiek, automatyzacja, integracja albo AI. Trzy zdania na pole wystarczą. To jest najtańsza rzecz z całej listy i jednocześnie ta, której prawie nikt nie ma zrobionej.
Powód jest praktyczny. Dopóki pola wypełniali wyłącznie ludzie, pytanie „kto to wpisał" miało odpowiedź w historii zmian rekordu i nikomu nie było potrzebne wcześniej. Teraz do tych samych pól pisze automatyzacja w Pipedrive, scenariusz w n8n, integracja z formularzem i coraz częściej model. Bez tej listy nie da się odpowiedzieć na pytanie, czy agent AI może zmienić dane pole, a to jest pierwsze pytanie, które pada przy jego podłączaniu.
Dopóki pole wypełniał wyłącznie człowiek, pytanie o źródło prawdy nie było potrzebne. Przy czterech piszących dwa z nich nadpisują się nawzajem i nie zostawiają po tym śladu.
Druga rzecz, którą ta lista rozstrzyga, to co się stanie przy zmianie etapu. Zmiana etapu w Pipedrive potrafi założyć zadanie, wysłać maila do klienta i powiadomić zespół. Jeśli agent przesunie szansę, nie wiedząc o tym, wyjdą maile, o których nie wiesz. Opisałem to szerzej przy wdrożeniu agenta AI w firmie, bo tam ten problem jest głównym tematem.
Przy przenoszeniu starych danych do CRM-u system zapisuje datę, w której rekord został dodany, a nie datę, w której coś się naprawdę wydarzyło. Po imporcie stu szans sprzed dwóch lat wszystkie mają datę wczorajszą. Raport konwersji za ostatni miesiąc wygląda po tym jak najlepszy miesiąc w historii firmy.
To samo dotyczy historii zmian etapów. Eksport z poprzedniego systemu często jej nie zawiera, więc nawet jeśli daty utworzenia uda się przenieść w osobnym polu, ścieżka szansy przez lejek nie odtworzy się już nigdy. Widziałem taki eksport, w którym nie było dat zmian statusów, i nie dało się z tego policzyć ani jednego wskaźnika czasowego. Co można przenieść, a czego nie warto, rozpisałem osobno w tekście o migracji z Excela do CRM-u.
Praktyczna konsekwencja dla tego tematu jest taka, że przy ocenie gotowości danych liczy się osobno baza dzisiejsza i osobno historia. Automatyzacje działają na dzisiejszej. Prognozy, wskaźniki i wszystko, co miałby policzyć model, działa na historii, a ta bywa nie do naprawienia. Lepiej powiedzieć to na początku projektu niż po trzech miesiącach.
Nawet komplet czystych pól nie wystarczy, bo najważniejszej części CRM-u nie ma w CRM-ie. Model podłączony przez API zobaczy, że masz listę wyboru „Etap" z wartościami Lead, Szansa i Klient. Nie zobaczy, co powoduje, że lead staje się szansą, bo tego nigdzie w systemie nie ma. Ta wiedza siedzi w głowach handlowców i w Twojej.
Do dopisania obok danych są cztery rzeczy:
Mam na to jedną obserwację z ostatniego roku, która zmieniła mi kolejność pracy przy projektach. AI wdraża średnią. Jeżeli podłączysz model do CRM-u bez tych reguł, dostaniesz odpowiedzi z rynkowej średniej zamiast z zasad Twojej firmy, i będą brzmiały sensownie. To jest gorszy wynik niż brak odpowiedzi, bo błędu nikt nie zauważy.
Weź trzy pola, na których opiera się dowolny raport, który naprawdę czytasz. Zwykle to będzie etap, źródło leada i powód straty.
Jeśli w punkcie pierwszym wyjdzie Ci więcej wartości niż kategorii, masz problem ze spójnością i to jest najtańsza rzecz do naprawienia. Jeśli w punkcie trzecim odpowiedź nie zgadza się z historią zmian, nie masz jednego źródła prawdy i żadna automatyzacja na tym polu nie będzie przewidywalna.
Pół godziny roboty, a wynik mówi, czy rozmowa o AI ma dziś sens, czy jest o kwartał za wcześnie.
Nie da się podać jednej liczby, bo zakres zależy od tego, ile pól i ile rekordów obejmuje. Da się natomiast podać, jak to rozkładam i za co odpowiadam.
| Krok | Co się dzieje | Czas |
|---|---|---|
| Ocena gotowości danych | Przegląd struktury pól, spójności wartości, duplikatów i historii. Wynik to lista problemów z priorytetami | Element audytu CRM, dwa tygodnie |
| Rozstrzygnięcia | Ustalenie źródła prawdy dla pól, które zostają, i decyzja, które pola znikają | Dwa warsztaty z zespołem |
| Porządkowanie | Scalanie duplikatów, ujednolicenie wartości, uzupełnienie pól decyzyjnych | Zależy od wielkości bazy, liczę osobno |
| Utrzymanie | Kwartalny przegląd tych samych sześciu punktów | Pół dnia na kwartał |
Ocena gotowości danych pod automatyzacje i AI jest stałym punktem audytu CRM-a, który kosztuje 3900 zł netto i trwa około dwóch tygodni, z trzema warsztatami online. Nie jest osobną usługą i celowo, bo firma, która wyda pieniądze na AI przy pustych polach decyzyjnych, kupi sobie szybsze generowanie nieprawdy. Samego czyszczenia danych audyt nie obejmuje. Nazywa problemy i wycenia naprawę. Ceny na wrzesień 2026.
Jeśli pytanie brzmi nie „czy CRM działa", tylko „czy dane udźwigną AI w sprzedaży", tamtą stronę obsługuje audyt pod AI za 6000 zł netto, a kwota wchodzi w całości w cenę wdrożenia.
Wdrażam Pipedrive'a na co dzień i mam za sobą ponad 50 wdrożeń. Ocena gotowości danych jest u mnie osobnym punktem zakresu, a nie akapitem w raporcie. Katalog awarii wyżej pochodzi z rozmów wdrożeniowych z ostatnich dwóch lat, nie z listy dobrych praktyk, i dlatego jest tak nierówny. Prawdziwe awarie nie układają się w ładne kategorie.
Druga rzecz, która daje mi widok z obu stron: prowadzę wdrożenia po stronie sprzedaży w Pipedrive i po stronie realizacji w Asanie. Granica między tymi systemami jest miejscem, w którym niekompletne dane kosztują najwięcej, bo realizacja zaczyna od ponownego ustalania, co właściwie zostało sprzedane. Co konkretnie ginie na tej granicy, rozpisałem przy przekazaniu wygranej szansy z Pipedrive do Asany.
Na tych samych projektach ta sama wiedza o procesie musiała powstawać trzy razy, jako instrukcja dla handlowców, opis dla agenta i konfiguracja CRM-u. Zrobiłem z tego jeden system, w którym pisze się raz. Opisałem go w tekście o kontekście firmy dla AI, razem z linkiem do repozytorium.
Jeśli masz Pipedrive'a i nie wiesz, czy dane udźwigną automatyzacje, zrób najpierw ćwiczenie z trzema polami wyżej. Zajmie pół godziny i rozstrzygnie, czy w ogóle jest o czym rozmawiać.
Jeśli wynik wyjdzie zły, a chcesz wiedzieć, co dokładnie naprawić i w jakiej kolejności, to jest treść audytu CRM-a. Jeśli zaczynasz od zera i chcesz, żeby struktura pól od początku nadawała się pod automatyzacje, to część wdrożenia Pipedrive'a. Kiedy nie wiesz, które z dwóch, napisz do mnie i rozstrzygniemy to w pół godziny.
O autorze
Wdrażam CRM, AI w sprzedaży i automatyzacje w firmach.
Jakość danych w CRM to stopień, w jakim rekordy dają się przetworzyć bez człowieka, który zna kontekst. Klasycznie mierzy się ją kompletnością, poprawnością, spójnością i aktualnością. Przy automatyzacjach najważniejsza jest spójność, bo brak jednego pola widać w raporcie, a niespójna wartość po cichu wyłącza regułę dla części bazy.
Zrób raport grupujący po każdym polu, na którym opiera się warunek albo raport, i porównaj liczbę unikalnych wartości z liczbą realnych kategorii. Potem ustaw na tych samych polach filtr „pole jest puste" i policz otwarte szanse, które wypadają. Na koniec sprawdź duplikaty osobno po nazwie firmy i po NIP-ie. Trzy filtry wystarczą na pierwszą ocenę.
Częściowo i nie tam, gdzie się tego oczekuje. Model poradzi sobie z tekstem pisanym swobodnie, na przykład z notatkami i opisami. Nie poradzi sobie z tym, że nie wie, kiedy lead staje się szansą, bo tego w danych nie ma w żadnej postaci. Bałagan w polach decyzyjnych przekłada się przy tym wprost na odpowiedzi, które brzmią pewnie i są nieprawdziwe.
Te, na których opiera się warunek uruchamiający regułę, i te, które są osią raportu: etap szansy, właściciel, wartość, powód straty, źródło leada i typ klienta. Dla każdego z nich musi być ustalone, kto je wypełnia i kiedy. Pola opisowe mogą zostać tekstem i zwykle powinny.
Za wartość w polu odpowiada ten, kto ją wpisuje, ale za zasady odpowiada jedna osoba i musi być wskazana z imienia. Bez tego każdy handlowiec wprowadza dane po swojemu i żadna z tych wersji nie jest błędna. W małych firmach to zwykle szef sprzedaży albo administrator CRM-u, nie dział IT.
Trzeba uporządkować pola, na których AI ma podejmować decyzje, i spisać reguły procesu. Całej bazy porządkować nie trzeba i szkoda na to czasu. Zacznij od jednego zastosowania, sprawdź, których pól ono dotyka, i uporządkuj te.
Raz na kwartał dla zawartości: duplikaty, kompletność pól decyzyjnych, wartości spoza listy. Strukturę pól przeglądaj przy każdej większej zmianie w procesie sprzedaży i za każdym razem, gdy dokładasz integrację, bo to ona najczęściej zaczyna pisać do pola, które miał wypełniać człowiek.
Raz w tygodniu dostaniesz bezpłatnie, jedno gotowe rozwiązanie, jak skutecznie wykorzystać nowoczesne technologie w sprzedaży B2B.
Zapisując się, zamawiasz newsletter Wellbiz sp. z o.o. i zgadzasz się na otrzymywanie e-maili z poradami i ofertami. Wypiszesz się jednym kliknięciem. Link jest w każdej wiadomości. Regulamin newslettera, Polityka prywatności
