Dlaczego temat duplikatów w kartotekach klientów jest krytyczny
Rzeczywiste skutki duplikatów: od błędnych faktur po utratę klienta
Duplikaty kartotek klientów w CRM i ERP wydają się drobną niedoskonałością bazy, dopóki nie przełożą się na realne zdarzenia: podwójne faktury, pomylone adresy dostaw, nieaktualne warunki handlowe. Wystarczy, że ta sama firma ma w systemie trzy konta: jedno założone przez handlowca, drugie przez księgowość, trzecie powstałe automatycznie z zamówienia internetowego. Każde z innymi warunkami cenowymi i innym opiekunem. Z perspektywy klienta to jeden partner, z perspektywy systemu – trzy niespójne rekordy.
Efekt? Klient dostaje fakturę na starą nazwę albo adres, inni pracownicy nie widzą pełnej historii współpracy, a rozmowy handlowe zaczynają się od nerwowego: „My już z Państwem współpracujemy…”. Dodatkowo pojawia się ryzyko formalne: błędne dane na dokumentach, problemy przy kontroli podatkowej, wydłużone wyjaśnianie rozbieżności. Przy większej skali działalności takie przypadki przestają być incydentem, a stają się codziennością.
W firmach B2C duplikaty objawiają się innymi problemami: kilka kont na ten sam adres e-mail lub numer telefonu powoduje bałagan w historii zamówień, trudności w obsłudze reklamacji i zwrotów, a także nieprzyjemne sytuacje, gdy klient musi po raz kolejny „opowiadać swoją historię”, bo konsultant patrzy w złą kartotekę. Gdy pojawia się spór lub reklamacja, brak jednego, spójnego widoku klienta działa na niekorzyść firmy.
Jak duplikaty zabijają automatyzację i raportowanie
Automatyczne tworzenie kartotek klientów ma sens wyłącznie wtedy, gdy dane są spójne. Duplikaty powodują, że raporty sprzedażowe przestają odpowiadać rzeczywistości. Ten sam klient B2B może być liczony jako kilku różnych kontrahentów, co przeinacza statystyki: liczby aktywnych klientów, wartości sprzedaży na klienta, udziału w rynku. Systemy BI zaczynają generować „kolorowe wykresy z błędnymi wnioskami”.
Duży problem pojawia się przy segmentacji i kampaniach marketingowych. Jeżeli jeden klient występuje w bazie kilka razy, może otrzymać tę samą kampanię newsletterową lub SMS dwukrotnie. Po pierwsze, psuje to doświadczenie odbiorcy, po drugie – fałszuje wyniki kampanii (open rate, CTR, konwersje). Algorytmy marketing automation, które bazują na historii zachowań i zakupów, są karmione rozproszonymi danymi, przez co ich decyzje (np. scoring leadów, rekomendacje produktów) stają się mniej trafne.
Automatyzacja procesów w ERP również cierpi. Workflow zatwierdzania rabatów, limitów kredytowych czy blokad windykacyjnych może przypisać „zielone światło” jednemu rekordowi, a zignorować inny, który w praktyce opisuje tę samą firmę. W efekcie klient, który powinien być zablokowany z powodu przeterminowanych płatności, składa zamówienia na „świeżą” kartotekę i system je przyjmuje, bo nie widzi pełnego obrazu.
Różne działy, różne potrzeby – jeden problem
Duplikaty klientów dotykają każdego działu w inny sposób. Dział sprzedaży traci czas na szukanie „właściwej” kartoteki, nie jest pewien, gdzie dopisać notatki, zmiany warunków handlowych czy ustalenia z negocjacji. Zdarza się, że dwóch handlowców prowadzi rozmowy z tym samym klientem, nie wiedząc o sobie nawzajem, bo każdy pracuje na innym rekordzie. Tak rodzą się konflikty o prowizje, nieporozumienia i rozmyta odpowiedzialność za relację.
Księgowość i finanse mierzą się z innym skutkiem duplikatów: rozbiciem sald, rozjazdem rozrachunków, trudnościami w przypisywaniu płatności do właściwych faktur. To generuje dodatkową pracę przy uzgadnianiu kont, prowadzi do błędnych wezwań do zapłaty, a czasem do windykowania klienta, który w rzeczywistości już wszystko uregulował, tylko płatność została zaksięgowana na „innej” kartotece.
Logistyka i obsługa klienta odczuwają to przy realizacji wysyłek i serwisu. Dwa różne adresy dostawy dla tego samego magazynu klienta, zapisane w dwóch kartotekach, mogą skutkować wysyłką pod zły adres lub zamieszaniem przy serwisie gwarancyjnym. Dział wsparcia technicznego nie widzi pełnej historii zgłoszeń, jeżeli część trafiła do innej kartoteki.
Koszt ręcznego sprzątania baz danych
Gdy problem duplikatów narasta, pojawia się konieczność ręcznego czyszczenia bazy. To żmudna, mało wdzięczna praca, którą zwykle wykonują analitycy, administratorzy CRM lub osoby z działu IT. Polega na wyszukiwaniu podobnych kartotek, porównywaniu danych, scalaniu historii, a często także na konsultacjach z handlowcami, kto tak naprawdę obsługuje danego klienta. To nie jest jednorazowy projekt, a raczej syzyfowa praca, jeśli proces tworzenia nowych klientów nie jest uporządkowany.
Do tego dochodzi ukryty koszt codziennego „polowania” na właściwą kartotekę. Każde 30 sekund spędzone na szukaniu klienta w CRM lub ERP, każda pomyłka przy wyborze nie tego rekordu, to realna strata czasu. W skali roku, przy kilkudziesięciu osobach pracujących na systemie, wychodzi na to, że firma opłaca dodatkowy etat tylko po to, by ktoś walczył z bałaganem, który da się ograniczyć automatyzacją i sensownymi regułami tworzenia kartotek.
Z czego biorą się duplikaty w CRM i ERP
Ręczne zakładanie klientów bez jasnych zasad i kontroli
Najczęstsze źródło duplikatów to ręczne tworzenie kart klientów przez handlowców, pracowników biura obsługi czy księgowość. Jeśli nie ma jasnych reguł, co jest „klientem” w rozumieniu systemu, każdy zakłada rekord po swojemu. Jeden tworzy osobne konto dla każdej osoby kontaktowej, inny dla każdego oddziału, jeszcze inny dla każdej umowy lub projektu. Brak standardu szybko prowadzi do chaosu.
Drugim problemem jest brak kontroli przy wprowadzaniu nowej kartoteki. Użytkownik wpisuje nazwę firmy, adres, może NIP, ale system nie podpowiada istniejących podobnych rekordów. Nie ma obowiązku wyszukania klienta przed założeniem nowego konta, nikt nie blokuje tworzenia kolejnego wpisu z tym samym NIP-em. Przy dużej rotacji pracowników sprzedaży lub obsługi takie sytuacje dzieją się każdego dnia.
Na to nakłada się presja czasu. Gdy klient dzwoni z pilnym zamówieniem, a system nie pozwala szybko znaleźć jego kartoteki (np. z powodu literówki lub innego sposobu zapisu nazwy), wielu pracowników wybiera „szybkie rozwiązanie”: tworzy nowego klienta, żeby nie wstrzymywać transakcji. Problem jest przesuwany w czasie – zamiast jednego nieaktualnego rekordu powstają dwa, oba nie do końca poprawne.
Integracje „każdy z każdym” bez wspólnej logiki
Nowoczesne środowisko IT w firmach to wiele systemów, które wymieniają dane: e‑commerce, marketplace’y, systemy billingowe, aplikacje mobilne, formularze leadowe, systemy ticketowe, narzędzia marketing automation. Każde z nich może tworzyć klientów automatycznie na swój sposób, z innym zestawem pól i innymi regułami. Jeśli integracje nie są spięte jedną, spójną logiką tworzenia i deduplikacji klientów, ERP i CRM stają się „odkurzaczem”, który wciąga powielone dane z wielu źródeł.
Typowy przykład: sklep internetowy tworzy klienta po adresie e‑mail, marketplace po numerze telefonu, system billingowy po numerze umowy, a CRM po nazwie firmy i NIP. Jeżeli te systemy nie porównują swoich rekordów według ustalonego klucza, każdy z nich będzie przekazywał własne kartoteki, a ERP lub CRM będzie je traktował jako nowe. Z czasem ilość duplikatów rośnie wykładniczo, szczególnie przy sprzedaży wielokanałowej.
Dodatkowym źródłem problemów są „szybkie integracje” typu import CSV lub jednorazowe migracje. Dane przenoszone z jednego systemu do drugiego często nie przechodzą pełnej deduplikacji i standaryzacji. W efekcie nowy system jest zasilany zbiorem rekordów, w których ten sam klient występuje wielokrotnie, czasem w zupełnie różnych formach pisowni. Automatyczne tworzenie kartotek na bieżąco nie zadziała dobrze, jeśli startuje z bazy pełnej błędów.
Różne formaty danych i błędy literowe
Duplikaty rodzą się także wtedy, gdy dane są zapisywane w różnych formatach. Raz „Firma XYZ sp. z o.o.”, innym razem „XYZ Spółka z o.o.”, jeszcze gdzie indziej „XYZ sp z oo” albo tylko „XYZ”. Podobnie z adresami: „ul. Jana Pawła II”, „Jana Pawła II”, „al. Jana Pawła 2” – dla człowieka oczywiste, dla prostego algorytmu wyszukiwania to już zupełnie inne wpisy. Jeśli system opiera deduplikację wyłącznie na dokładnym dopasowaniu nazw czy adresów, nawet drobna różnica powoduje, że duplikat przechodzi niezauważony.
Dochodzi do tego zwykły błąd ludzki: literówki, pomyłki w NIP (np. zamiana cyfr), brak polskich znaków, skróty stosowane według własnego uznania. Bez mechanizmów fuzzy matching (dopasowania przybliżonego) i standaryzacji takie zapisy tworzą osobne, niepowiązane rekordy. W skali tysięcy klientów liczba takich „prawie takich samych” kartotek potrafi zaskoczyć.
Równoległa praca wielu handlowców i oddziałów
W firmach z kilkoma oddziałami, terenową siecią handlowców lub strukturą międzynarodową duplikaty klientów są niemal nieuniknione, jeśli nie ma wspólnego widoku klienta. Każdy oddział zakłada swoich klientów w ERP lub CRM, często z lokalnymi oznaczeniami, skrótami czy dopiskami. Jeśli system nie wymusza centralnego klucza identyfikującego (np. NIP, REGON, numer VAT UE), szybko powstaje kilka lub kilkanaście kartotek dla tej samej grupy kapitałowej czy nawet dokładnie tej samej spółki.
Równoległa praca wielu osób powoduje też wyścig: dwóch handlowców dodaje tego samego nowego klienta niemal w tym samym czasie, zanim którykolwiek z nich zdąży zsynchronizować dane czy zapisać rekord. W systemach bez blokad i natychmiastowej walidacji powstają dwie prawie identyczne kartoteki. Jeśli dodatkowo CRM i ERP synchronizują się asynchronicznie, duplikat może rozlać się po kilku modułach, zanim ktokolwiek go zauważy.
Źródło: Pexels | Autor: Lukas Blazek
Podstawy porządnej kartoteki klienta – co musi być zdefiniowane
Minimalny zestaw pól identyfikujących klienta B2B i B2C
Automatyczne tworzenie kart klientów bez dobrze zdefiniowanego zestawu pól prowadzi do pozornej automatyzacji. Kluczowe jest rozróżnienie dwóch podstawowych typów klientów: B2B (firmy) i B2C (osoby fizyczne). Dla każdego z nich inny zestaw atrybutów naprawdę identyfikuje rekord.
Dla klientów B2B minimalny zestaw to zazwyczaj:
NIP (lub odpowiednik zagraniczny: numer VAT UE) jako główny identyfikator podatkowy,
pełna nazwa firmy (zgodna z rejestrem, ale dopuszczalne krótsze pole „nazwa skrócona”),
adres siedziby (ulica, numer, kod pocztowy, miasto, kraj),
forma prawna (spółka z o.o., działalność gospodarcza, SA itd.),
co najmniej jedna osoba kontaktowa (imię, nazwisko, e‑mail, telefon) – może być w osobnej strukturze,
identyfikator w systemie (wewnętrzny kod klienta, niekoniecznie widoczny dla użytkowników).
Dla klientów B2C (osób fizycznych) sytuacja jest inna. Zwykle nie ma NIP, a ważniejszy jest zestaw:
imię i nazwisko,
adres dostawy / korespondencyjny,
adres e‑mail jako główny identyfikator komunikacyjny,
numer telefonu (często drugi klucz identyfikujący),
data urodzenia lub PESEL – tylko tam, gdzie jest to uzasadnione i prawnie dopuszczalne.
Minimalny zestaw pól powinien być jasno udokumentowany i wbudowany w system w postaci pól obowiązkowych, walidacji i reguł tworzenia kartotek. Dzięki temu każdy nowy rekord spełnia podstawowe kryteria identyfikacji, a automatyczna deduplikacja ma z czego korzystać.
Co realnie identyfikuje firmę i osobę – wybór klucza głównego
Teoretycznie każdy rekord w CRM czy ERP ma unikalny numer ID. Z punktu widzenia integracji to on jest technicznym kluczem głównym. Biznesowo jednak potrzebny jest bardziej „ludzki” identyfikator, który pozwoli rozpoznać, że dwie kartoteki opisują tę samą jednostkę. W przypadku firm najczęściej najlepszym kandydatem jest NIP (w Polsce) lub numer VAT UE w transakcjach międzynarodowych.
NIP ma jednak ograniczenia: nie każdy podmiot go posiada (np. niektóre organizacje, zagraniczne firmy niebędące płatnikami VAT w Polsce), zdarzają się też błędy przy jego wprowadzaniu. Dlatego w dobrze zaprojektowanej kartotece klienta warto mieć klucz złożony, np. NIP + kraj + typ podmiotu albo nazwa + adres + kraj w przypadku braku NIP. Takie kombinacje poprawiają szanse wykrycia duplikatów w różnych scenariuszach.
U osób fizycznych sytuacja jest bardziej złożona. E‑mail jest dobrym identyfikatorem w e‑commerce, ale łatwo go zmienić. Numer telefonu również, jednak bywa współdzielony (np. numer rodzinny). PESEL lub inne numery identyfikacyjne są wrażliwe prawnie i nie zawsze można je przetwarzać. Dlatego przy klientach B2C częściej stosuje się zestaw kilku pól (imię, nazwisko, e‑mail, telefon, adres) i buduje się reguły podobieństwa zamiast jednego „świętego” klucza.
Hierarchia danych klienta i rozdzielenie encji
Żeby automatyczne tworzenie kartotek miało sens, sam „klient” nie może być jednym, płaskim rekordem. Dane trzeba rozdzielić na kilka powiązanych ze sobą encji. Inaczej system zacznie dublować całe kartoteki tam, gdzie w rzeczywistości zmienił się tylko adres dostawy czy osoba kontaktowa.
W praktyce najczęściej sprawdza się podział na:
podmiot gospodarczy / osoba – główna jednostka: firma jako byt prawny lub osoba fizyczna,
lokalizacje – oddziały, magazyny, punkty sprzedaży, adresy dostaw,
osoby kontaktowe – pracownicy po stronie klienta, użytkownicy końcowi, pełnomocnicy,
konta rozliczeniowe – dane do faktury, warunki handlowe, waluta, terminy płatności,
identyfikatory zewnętrzne – numery w systemach partnerów, marketplace’ach, portalach B2B.
Przykład z życia: ten sam klient B2B ma centralę w Warszawie, trzy magazyny w różnych miastach, a zakupy robią cztery osoby z różnych działów. Jeśli każda kombinacja „osoba + adres” jest tworzona jako osobna kartoteka klienta, deduplikacja staje się koszmarem. Jeżeli natomiast system rozumie, że istnieje jedna firma, kilka lokalizacji i wiele kontaktów przypisanych do jednego bytu prawnego, nowe rekordy można automatycznie podczepiać pod istniejącą strukturę zamiast tworzyć kolejnego „klienta”.
Atrybuty, które pomagają w deduplikacji
Niektóre pola w kartotece, choć wydają się drugorzędne, są kapitalne do wykrywania duplikatów. Chodzi zwłaszcza o dane, które rzadko zmieniają się jednocześnie w wielu systemach.
Warto rozważyć wprowadzenie i konsekwentne uzupełnianie takich atrybutów jak:
domena e‑mail (np. @firma.pl) – pozwala zestawić wiele kontaktów pod jednym bytem,
adres strony www – często stabilniejszy niż nazwa skrócona,
kod branży (PKD/NACE) – nie służy bezpośrednio jako klucz, ale pomaga odsiać fałszywe trafienia,
data pierwszego i ostatniego kontaktu – przy scalaniu duplikatów pomaga ustalić, który rekord jest „główny”,
status klienta (prospekt, aktywny, zarchiwizowany) – inne zasady deduplikacji dla leadów, inne dla aktywnych kontrahentów.
Dobrze opisany rekord daje algorytmom znacznie większą szansę na poprawne powiązanie danych z różnych źródeł. Jednocześnie użytkownikom łatwiej ocenić, czy mają przed sobą „tego właściwego” klienta, czy bliźniaczo podobny, ale jednak inny podmiot.
Projektowanie workflow automatycznego zakładania klienta krok po kroku
Wejścia do procesu: skąd biorą się nowi klienci
Pierwszy krok to nazwanie wszystkich miejsc, w których w ogóle pojawia się potrzeba założenia klienta. W większości firm lista jest dłuższa, niż się początkowo wydaje.
Najczęstsze „wejścia” to m.in.:
formularze na stronie www (zapytania ofertowe, rejestracja konta, newsletter),
sklepy internetowe i aplikacje mobilne,
systemy sprzedaży stacjonarnej (POS, terminale w salonach),
importy z kampanii marketingowych i wydarzeń (targi, webinary),
ręczne dodawanie przez handlowców w CRM,
automatyczne tworzenie klientów w ERP przy pierwszym dokumencie (faktura, zamówienie, paragon imienny).
Każde takie źródło powinno przechodzić przez ten sam trzon logiki: walidację, wyszukiwanie potencjalnych duplikatów, decyzję o podpięciu do istniejącej kartoteki lub utworzeniu nowej. Jeśli jedno z wejść „idzie na skróty”, to właśnie ono będzie produkować większość bałaganu.
Standardowy scenariusz tworzenia klienta
Przejrzysty workflow można opisać w kilku konsekwentnych krokach. Niezależnie od technologii, sekwencja jest podobna:
Przechwycenie danych wejściowych – wszystko, co podał użytkownik (człowiek lub inny system): nazwa, NIP, e‑mail, telefon, adres.
Wstępna walidacja techniczna – sprawdzenie poprawności formatów: długość NIP, poprawność numeru VAT UE, struktura e‑maila, kodu pocztowego, numeru telefonu.
Standaryzacja wstępna – oczyszczenie danych z typowych „śmieci”: zbędne spacje, wielkie litery, rozwinięcie popularnych skrótów (np. „sp z oo” → „sp. z o.o.”), ujednolicenie formatu telefonu.
Wyszukiwanie w istniejącej bazie – najpierw po twardych kluczach (NIP, VAT UE, PESEL), potem po miękkich (e‑mail, domena, nazwa + adres) z wykorzystaniem dopasowania przybliżonego.
Ocena podobieństwa – obliczenie „wyniku podobieństwa” na podstawie kilku kryteriów i porównanie z progami decyzyjnymi.
Decyzja systemu:
jeśli znaleziono jednoznaczne dopasowanie – podpięcie nowego zdarzenia (zamówienia, zgłoszenia) do istniejącej kartoteki,
jeśli brak dopasowań – utworzenie nowego klienta,
jeśli jest kilka prawdopodobnych dopasowań – skierowanie do ręcznego rozstrzygnięcia lub oznaczenie jako „potencjalny duplikat”.
Wzbogacenie danych – po utworzeniu lub wybraniu klienta, automatyczne dociągnięcie informacji z rejestrów zewnętrznych (np. GUS, VIES) i nadanie identyfikatorów wewnętrznych.
Ten schemat nie musi być widoczny dla użytkownika końcowego w całej złożoności. Ważne, by był zaimplementowany spójnie we wszystkich kanałach, nawet jeśli w jednym miejscu kroki łączą się w jeden ekran, a w innym dzieją się „w tle”.
Punkty decyzyjne i progi ryzyka
Automatyzacja nie oznacza, że system ma podejmować wszystkie decyzje w ciemno. W praktyce pomocne jest wprowadzenie kilku poziomów zaufania do dopasowania.
Typowy podział to:
pewne dopasowanie – identyczny NIP lub VAT UE, poprawny kraj, brak rozbieżności w nazwie powyżej określonego progu; system może działać całkowicie automatycznie,
prawdopodobne dopasowanie – wysoki wynik podobieństwa (np. 85–95%), ale różnice w nazwie lub adresie; system podpowiada istniejącą kartotekę i zachęca użytkownika do potwierdzenia,
niejednoznaczne dopasowanie – kilka rekordów o podobnym poziomie podobieństwa; wymagane ręczne rozstrzygnięcie lub przekazanie do „kolejki duplikatów”,
brak dopasowania – nic nie przekracza ustalonego progu; zakładany jest nowy klient.
Warto też rozdzielić progi dla różnych typów klientów. W B2B, przy pełnych danych rejestrowych, próg dla automatycznych decyzji może być wysoki, a przy B2C w e‑commerce – nieco niższy, bo adresy i nazwiska częściej bywają wpisywane niedokładnie.
Obsługa wyjątków i sytuacji granicznych
Każdy proces ma swoje „dziury w systemie”. Chodzi np. o klientów bez NIP (fundacje, jednostki budżetowe), klientów zagranicznych z niepełnymi danymi czy sytuacje, gdy dane podane przez użytkownika rażąco odbiegają od informacji z rejestrów publicznych.
Dobrze, żeby workflow przewidywał między innymi:
tryb warunkowy – tymczasowy klient z ograniczonymi możliwościami (np. mniejsze limity, brak fakturowania), który po weryfikacji może zostać „podniesiony” do pełnego rekordu,
flagi ostrzegawcze – oznaczenie rekordu jako „do weryfikacji” lub „podejrzenie duplikatu”, widoczne dla innych użytkowników,
scenariusz dla kont technicznych – np. „Gość sklepu internetowego” czy „klient incydentalny”, które nie powinny tworzyć tysięcy odrębnych kartotek w ERP.
Te reguły najlepiej przygotowywać razem z działami sprzedaży, księgowości i obsługi klienta. Każdy zespół widzi inne ryzyka i dzięki temu łatwiej zbudować proces, który jest nie tylko „czysty” technicznie, ale też używalny w codziennej pracy.
Reguły rozpoznawania duplikatów – od prostych do zaawansowanych
Proste reguły oparte na kluczach twardych
Na początek przydają się banalne, ale skuteczne reguły. One „łapią” większość oczywistych duplikatów, zanim trzeba będzie sięgać po bardziej wyrafinowane algorytmy.
Podstawowe przykłady:
unikalność NIP / VAT UE – jeden numer podatkowy = jeden podmiot gospodarczy w systemie nadrzędnym,
unikalność PESEL (tam, gdzie można go legalnie przetwarzać) – jeden numer = jedna osoba,
unikalność e‑maila w danym kontekście – np. w sklepie internetowym jeden e‑mail może mieć tylko jedno konto klienta,
unikalność kombinacji pól – np. nazwa + kod pocztowy + numer budynku dla B2B bez NIP.
Takie reguły warto wbudować w system jako twarde ograniczenia: próba zapisania drugiego klienta z tym samym NIP powinna skutkować komunikatem i podpowiedzią istniejącego rekordu, a nie cichym utworzeniem duplikatu.
Dopasowanie przybliżone nazw i adresów
W realnych danych sama dokładna zgodność tekstu rzadko wystarcza. Potrzebne są metody, które „widzą”, że „XYZ sp z oo” i „XYZ Spółka z o.o.” to prawdopodobnie ta sama firma, mimo innego zapisu.
Do najczęściej stosowanych technik należą:
algorytmy odległości edycyjnej (np. Levenshteina) – liczą, ile liter trzeba zmienić, by jedno słowo zamienić w drugie,
normalizacja znaków – porównywanie po zamianie polskich liter na odpowiedniki bez ogonków, usunięciu spacji, kropek i przecinków,
ignorowanie typowych sufiksów – „sp. z o.o.”, „S.A.”, „Spółka Akcyjna” często można pominąć w porównaniu, bo nie wnoszą informacji o samej nazwie,
porównywanie tokenów – zamiast całego ciągu tekstu system porównuje pojedyncze słowa, np. „Zakłady Produkcyjne Alfa” vs „Alfa Zakłady Prod.”.
W praktyce korzysta się z kombinacji tych metod. Nazwa i adres mogą być przeliczone na ustandaryzowaną formę, a dopiero potem porównywane przy użyciu algorytmu podobieństwa. To znacząco zmniejsza liczbę fałszywych niedopasowań.
Reguły złożone: kilka sygnałów naraz
Duplikat rzadko zdradza się jednym polem. O wiele lepiej działają reguły, które łączą wiele sygnałów i na tej podstawie przypisują rekordowi „wynik podobieństwa”.
Przykładowa, prosta reguła złożona dla B2B może wyglądać tak:
NIP identyczny → +70 punktów,
podobieństwo nazwy (po normalizacji) > 90% → +20 punktów,
kod pocztowy identyczny → +5 punktów,
miasto identyczne → +5 punktów.
Jeśli suma przekroczy np. 80 punktów, rekord uznawany jest za ten sam podmiot. Przy niższym wyniku system może poprosić o decyzję użytkownika lub oznaczyć rekord do późniejszej analizy.
Dla B2C zestaw pól będzie inny – większy nacisk na e‑mail, telefon, imię i nazwisko, datę urodzenia czy powtarzające się adresy dostaw. Schemat myślenia pozostaje ten sam: nie ufa się jednemu polu w 100%, tylko patrzy na kombinację kilku cech.
Uczenie się na podstawie wcześniejszych decyzji
Jeśli liczba klientów idzie w dziesiątki tysięcy lub więcej, ręczne dopisywanie wyjątków prędzej czy później stanie się nie do ogarnięcia. Tu z pomocą mogą przyjść metody inspirowane uczeniem maszynowym – nawet w prostym wydaniu.
Podstawowy pomysł jest taki: każda decyzja użytkownika (scalił rekordy czy jednak odrzucił propozycję połączenia) jest zapisywana jako przykład. Na tej podstawie algorytm może z czasem dostrajać wagi poszczególnych pól i progi podobieństwa. W efekcie system uczy się, że:
w branży e‑commerce adres e‑mail jest kluczowy, a literówki w nazwisku są częste,
w segmencie dużych korporacji wiele firm ma bardzo podobne nazwy i adresy (park biurowy), więc NIP jest absolutnie rozstrzygający,
dla klientów zagranicznych warto bardziej ufać domenie e‑mail i stronie www niż adresowi pocztowemu.
Źródło: Pexels | Autor: Yan Krukau
Integracja CRM i ERP: jedno „źródło prawdy” dla danych klienta
Nawet najlepiej zaprojektowane reguły antyduplikacyjne przestają działać, gdy każda aplikacja trzyma „swoją” wersję klienta. Prawdziwy porządek zaczyna się dopiero wtedy, gdy firma ustali, gdzie leży główne źródło danych o kontrahencie i jak pozostałe systemy mają z niego korzystać.
System wiodący i systemy podrzędne
Podstawowa decyzja brzmi: który system jest „mistrzem” danych klienta, a które są jego „konsumentami”. Typowy scenariusz:
ERP jako źródło prawdy – wszystkie dane rejestrowe (NIP, adres fakturowania, status podatkowy) są utrzymywane w ERP, a CRM, system e‑commerce czy platforma serwisowa tylko je odczytują,
CRM jako źródło prawdy – przy podejściu silnie sprzedażowym pełne dane o relacjach i strukturze organizacyjnej klienta przechowywane są w CRM, a do ERP trafia tylko „twardy” wycinek potrzebny do fakturowania.
W praktyce spotyka się model mieszany: ERP pilnuje tego, co jest ważne dla księgowości i raportów finansowych, a CRM rozwija profil klienta o kontakty, leady, preferencje i historię komunikacji. Kluczowe jest jasne opisanie, które pola są wiodące po której stronie i kto może je zmieniać.
Uzgodniony model danych klienta
Bez wspólnego modelu danych integracja sprowadza się do „tłumaczenia z jednego żargonu na drugi” przy każdym interfejsie. Przyda się kilka prostych uzgodnień:
jednoznaczny identyfikator klienta – wewnętrzny numer kontrahenta, który jest taki sam w CRM, ERP i innych systemach,
ten sam podział na typy klientów – np. firma, osoba fizyczna prowadząca działalność, konsument, partner, dostawca,
zestaw pól obowiązkowych – minimalny komplet danych, który musi być dostępny we wszystkich systemach (np. nazwa, NIP, kraj, status aktywny/nieaktywny),
konsekwentne słowniki – te same kody krajów, formy prawne, segmenty branżowe, żeby nie mieć sytuacji, że w CRM klient jest „PL”, a w ERP „POL”.
Dobrym testem modelu jest proste pytanie: czy da się jednoznacznie zidentyfikować klienta, mając tylko dane z jednego systemu? Jeśli odpowiedź brzmi „to zależy”, model wymaga doprecyzowania.
Synchronizacja i kolejność tworzenia klienta
Problemy z duplikatami bardzo często wynikają z tego, że klient powstaje „najpierw tam, gdzie jest wygodniej”. Handlowiec dodaje go w CRM, magazyn w WMS, księgowa w ERP – i po kilku miesiącach mamy trzy różne rekordy dotyczące tej samej firmy.
Żeby temu zapobiec, trzeba ustalić:
gdzie klient powstaje jako pierwszy – np. tylko w CRM lub tylko w ERP,
jak szybko informacja rozchodzi się do pozostałych systemów – synchronicznie (od razu) czy wsadowo (np. co godzinę),
jakie są zasady odrzucania duplikatów podczas synchronizacji – np. ERP nie przyjmie nowego klienta, jeśli NIP już istnieje, tylko zgłosi błąd i wskaże istniejący rekord.
Im bliżej czasu rzeczywistego odbywa się synchronizacja, tym mniejsze ryzyko, że dwóch użytkowników równolegle „założy” tego samego klienta w różnych aplikacjach.
Mechanizmy rozstrzygania konfliktów
Konflikty danych pojawią się zawsze: ktoś zmieni adres w CRM, ktoś inny w ERP, a po integracji ten sam klient ma dwa różne miasta. Rozwiązaniem nie jest zakaz aktualizacji, tylko jasne reguły, kto kogo nadpisuje.
Przykładowe podejścia:
priorytet systemu – dane adresowe zawsze wygrywają z ERP, a dane o osobach kontaktowych z CRM,
priorytet czasu – nowsza zmiana (z dokładnym timestampem) nadpisuje starszą,
priorytet pola – dla wybranych pól (np. NIP, status VAT) edycja dozwolona jest tylko w jednym systemie; pozostałe mogą być aktualizowane z obu stron.
Przy większej skali przydają się dzienniki zmian, w których można sprawdzić, kto i kiedy wprowadził modyfikację. Pozwala to wychwycić błędne integracje oraz nawyki użytkowników prowadzące do powstawania rozjazdów.
Automatyczne sprawdzanie klienta w rejestrach zewnętrznych
Publiczne i komercyjne rejestry potrafią zdziałać cuda przy walce z duplikatami. Dają dodatkowy punkt odniesienia: jeśli NIP, nazwa i adres w systemie różnią się istotnie od danych w GUS czy VIES, szansa na bałagan rośnie.
Powiązanie kartoteki z rejestrami publicznymi
Przy klientach firmowych rozsądnym standardem staje się automatyczne zapytanie do oficjalnych baz już na etapie zakładania rekordu. Najczęściej wykorzystywane są:
GUS / KRS – potwierdzenie istnienia firmy, nazwy rejestrowej, adresu siedziby, formy prawnej,
VIES – weryfikacja aktywności numeru VAT UE i kraju, z którym numer jest związany,
rejestry dłużników czy listy sankcyjne – z perspektywy duplikatów mniej istotne, ale ważne z punktu widzenia ryzyka biznesowego.
Połączenie z tymi bazami może działać w dwóch trybach: interaktywnym (użytkownik wpisuje NIP, system podpowiada nazwę i adres) oraz wsadowym (cykliczne odświeżanie już istniejących rekordów).
Minimalizacja błędów ludzkich przy wprowadzaniu danych
Im mniej pól użytkownik musi wypełniać ręcznie, tym lepiej. Gdy system sam dociąga dane po numerze NIP, rośnie spójność kartotek, a pole do literówek się kurczy. Taki mechanizm można wesprzeć prostymi zasadami:
po wpisaniu NIP i kraju system blokuje edycję niektórych pól lub wymaga uzasadnienia zmiany (np. nazwy firmy),
przy próbie wprowadzenia innego adresu niż w rejestrze system wyświetla porównanie „obok siebie” i prosi o wybór jednej z wersji,
częste adresy korespondencyjne (np. centra biurowe) można oferować z podpowiedzi mapowych, co zmniejsza wachlarz wariantów zapisu.
Realny efekt bywa prosty: po wdrożeniu słownika adresów i podpowiedzi z GUS liczba nowych duplikatów spada często bez skomplikowanych algorytmów podobieństwa.
Weryfikacja okresowa i monitoring zmian
Firmy zmieniają nazwy, adresy, status VAT, czasem są wykreślane z rejestrów. Jeśli kartoteka ma pozostać aktualna, potrzebny jest mechanizm okresowej kontroli:
np. raz w miesiącu system sprawdza aktywnych klientów w GUS/VIES i oznacza tych, których status się zmienił,
nowe dane nie są od razu nadpisywane, lecz trafiają do kolejki propozycji aktualizacji, gdzie operator decyduje, czy je przyjąć,
zmiany statusów (np. utrata aktywnego VAT UE) mogą automatycznie blokować określone operacje (sprzedaż z odwrotnym obciążeniem, fakturowanie w transakcjach międzynarodowych).
Taka weryfikacja nie tylko poprawia jakość danych, ale również ułatwia identyfikację martwych kartotek i duplikatów, które „wiszą” bez aktualnych odpowiedników w rejestrach.
Źródło: Pexels | Autor: Markus Spiske
Standaryzacja i normalizacja danych klientów
Duplikaty rodzą się nie tylko z powielania tych samych rekordów, lecz także z chaosu zapisu. Ta sama firma może mieć w systemie pięć wariantów nazwy i trzy wersje tego samego adresu. Normalizacja danych sprawia, że algorytm dopasowania ma prostsze zadanie, a raporty stają się czytelniejsze.
Ujednolicenie nazw i form prawnych
Podstawowym krokiem jest wprowadzenie reguł zapisu nazw klientów. Mogą być proste, ale muszą być spójne. Przykładowo:
formy prawne typu „spółka z ograniczoną odpowiedzialnością”, „sp. z o.o.”, „Spółka z o. o.” są redukowane do jednego skrótu,
wielkie litery stosuje się tylko na początku słów, reszta według słowników,
zbędne elementy marketingowe (np. „Grupa X”, „Holding Y”) są traktowane jako dodatkowe pola, nie jako część bazowej nazwy rejestrowej.
W praktyce przydaje się pole „nazwa rejestrowa” (taka jak w GUS/KRS) i „nazwa skrócona” (używana na dokumentach i w codziennej pracy). Oba są powiązane, ale poddane różnym regułom.
Normalizacja adresów
Adres to jedno z najbardziej problematycznych pól. Ludzie różnie zapisują ulice, numery budynków, skróty. Bez standaryzacji algorytm podobieństwa widzi „różne” adresy, choć chodzi o to samo miejsce.
Pomagają tutaj:
słowniki ulic i miejscowości – najlepiej z oficjalnych źródeł (np. rejestry państwowe),
automatyczne rozwijanie skrótów – „ul.” → „ulica”, „al.” → „aleja”, albo odwrotnie, do ustalonej formy,
rozdzielenie pola „numer” na część budynku i lokalu – np. „12A/5” → osobne pola, zamiast jednego ciągu tekstu,
trzymanie kodów pocztowych w jednym formacie – np. zawsze „NN-NNN” zamiast dowolnej kombinacji cyfr i spacji.
Bardzo praktyczne jest też rozdzielenie adresu na typy: siedziba prawna, adres do korespondencji, adres dostawy. Zmniejsza to liczbę nieporozumień i fałszywych podejrzeń o duplikat, gdy klient ma kilka lokalizacji.
Formatowanie danych kontaktowych
Telefony i e‑maile to pola, na których algorytmy potykają się wyjątkowo często. Po kilku latach eksploatacji systemu można trafić na numery bez prefiksów krajowych, z ukośnikami, spacjami i różnymi znakami rozdzielającymi.
Przydatne reguły to między innymi:
zapisywanie numerów w formatcie E.164 (np. +48…) wewnętrznie, a pokazywanie ich użytkownikom w przyjaźniejszej postaci,
czyszczenie numerów z zbędnych znaków przy zapisie (spacje, kropki, myślniki), a dopiero później estetyczne ich formatowanie do wyświetlania,
walidacja e‑maila według prostych zasad (jeden znak „@”, brak spacji, rozsądne domeny) plus opcjonalne sprawdzenie MX (czy domena ma rekordy pocztowe).
Dla dużych baz B2C sens ma też normalizacja imion i nazwisk (np. usuwanie przypadkowych wielkich liter w środku słowa), ale tu trzeba działać ostrożnie, żeby nie zniszczyć poprawnych, rzadko spotykanych form.
Automatyczne „odśmiecanie” danych
Normalizacja nie musi się kończyć na walidacji przy wprowadzaniu. W wielu organizacjach sprawdza się okresowe „odśmiecanie” danych:
wsadowe poprawianie formatów numerów telefonów i kodów pocztowych,
usuwanie powtarzających się spacji, nietypowych znaków i emotikon z nazw klientów,
uzupełnianie brakujących pól na podstawie zewnętrznych źródeł (np. dopisanie miasta po kodzie pocztowym).
Takie operacje dobrze jest wykonywać etapami, na ograniczonych wycinkach bazy, z możliwością wycofania zmian. Kilka małych, dobrze udokumentowanych kroków przyniesie lepszy efekt niż jeden „wielki refaktoring” całej bazy w weekend.
Kiedy pozwolić na ręczne tworzenie klienta, a kiedy blokować
Pełna automatyzacja brzmi kusząco, ale organizacje, które całkowicie zakazały ręcznego zakładania klientów, zwykle po chwili wracają do kompromisów. Czasem trzeba zareagować szybko, zanim dane w rejestrach się zaktualizują, albo obsłużyć niestandardową sytuację.
Role i uprawnienia a tworzenie kartotek
Najsensowniejszym podejściem jest powiązanie możliwości tworzenia klientów z rolą użytkownika. Nie każdy w firmie musi mieć ten sam poziom swobody.
Użytkownicy liniowi (sprzedawcy, konsultanci) – mogą zakładać tylko wstępne rekordy (np. „lead” lub „klient warunkowy”), z ograniczoną liczbą pól i bez wpływu na ERP,
Superużytkownicy / opiekunowie danych – mają prawo tworzenia pełnych klientów, edycji kluczowych pól (NIP, kraj, forma prawna) i scalania duplikatów,
Administratorzy systemów – dodatkowo mogą korygować sytuacje wyjątkowe (np. błąd integracji, złe zaczytanie danych z zewnętrznego systemu).
Dobrze zdefiniowane role ograniczają z jednej strony nadprodukcję klientów, z drugiej – nie blokują biznesu przy nietypowych przypadkach.
Scenariusze, w których ręczne tworzenie jest konieczne
Najważniejsze punkty
Duplikaty kartotek klientów nie są drobną niedoskonałością, lecz źródłem realnych problemów: błędnych faktur, pomyłek adresowych, chaosu w warunkach handlowych i nerwowych rozmów z klientami, który „już przecież współpracuje z firmą”.
Brak jednego, spójnego widoku klienta uderza szczególnie w firmy B2B i B2C: rozbita historia współpracy, zamówień, reklamacji i płatności utrudnia obsługę, zwiększa liczbę pomyłek i pogarsza doświadczenie klienta przy każdym kontakcie z firmą.
Duplikaty zniekształcają raportowanie i analitykę: jeden klient liczony jest jako kilku kontrahentów, co fałszuje statystyki sprzedaży, segmentację, wyniki kampanii marketingowych i decyzje algorytmów marketing automation czy systemów BI.
Automatyzacja w ERP i CRM traci sens przy niespójnych danych: workflows rabatowe, limity kredytowe czy blokady windykacyjne mogą omijać „właściwą” kartotekę, dopuszczając ryzykowne transakcje z klientami, którzy powinni być zablokowani.
Różne działy firmy odczuwają skutki duplikatów inaczej – sprzedaż traci czas i wchodzi w konflikty o prowizje, księgowość walczy z rozbiciem sald i błędnymi wezwaniami do zapłaty, a logistyka i serwis zmagają się z wysyłkami pod zły adres i niepełną historią zgłoszeń.
Ręczne „sprzątanie” bazy bez uporządkowanego procesu tworzenia kartotek to praca syzyfowa: angażuje drogie zasoby (analityków, administratorów, IT) i generuje stały, ukryty koszt codziennego szukania właściwego rekordu w CRM lub ERP.
