Onboarding klienta krok po kroku: scenariusz w CRM i ERP

Onboarding klienta w firmie, która używa jednocześnie CRM i ERP, kończy się sukcesem wtedy, gdy nowy klient nie „wchodzi” w organizację przez przypadkowe drzwi (mail do handlowca, telefon do magazynu, faktura z księgowości), tylko przechodzi przez spójny scenariusz: od decyzji handlowej po pierwsze zamówienie, fakturę i stabilną obsługę. Problem w tym, że onboarding zwykle pęka nie na „dużych” etapach, ale na drobnych detalach: kto ma założyć rekord klienta, skąd biorą się adresy, gdzie zapisane są warunki płatności, kto wysyła jaką wiadomość i dlaczego klient dostał dwa różne maile o tym samym.

Realne pytania, które pojawiają się przed ułożeniem scenariusza są dość przyziemne: kiedy dokładnie zaczynamy onboarding (po podpisie, po PO, po wpłacie)? kto jest „właścicielem” rekordu klienta? co jest źródłem prawdy dla NIP i adresów? gdzie zatwierdzamy warunki handlowe, żeby miały ślad audytowy? jak uniknąć duplikatów? co musi zostać zrobione, żeby klient był gotowy do pierwszego zamówienia bez nocnych narad na komunikatorze?

Niżej jest bazowy scenariusz krok po kroku oraz porównanie trzech najczęstszych wariantów architektury procesu: CRM-driven, ERP-driven i hybryda. Wszystko prowadzone przez pryzmat pułapek, bo one najczęściej kosztują czas, nerwy i reklamację „na start”.

Frazy pomocnicze: onboarding klienta B2B, scenariusz onboardingu w CRM, integracja CRM z ERP, źródło prawdy danych klienta, statusy onboardingu klienta, deduplikacja rekordów klienta, handoff sprzedaż–realizacja, warunki handlowe w ERP, komunikacja transakcyjna CRM/ERP, walidacje danych klienta, klient gotowy do pierwszego zamówienia

Onboarding klienta w firmie z CRM i ERP: co obejmuje i gdzie najczęściej „pęka”

Zakres onboardingu B2B: od decyzji handlowej do stabilnej obsługi

W praktyce onboarding klienta B2B to nie „założenie konta” i wysłanie maila powitalnego. To ciąg działań, które mają doprowadzić do tego, że firma potrafi bezpiecznie i powtarzalnie: przyjąć zamówienie, zrealizować dostawę/usługę, wystawić poprawną fakturę i obsłużyć klienta po sprzedaży (serwis/Customer Success). Jeśli w którymś miejscu proces nie ma właściciela albo brakuje danych, organizacja i tak wykona pracę – tylko że ręcznie i chaotycznie.

Zakres onboardingu zwykle obejmuje: weryfikację danych firmy, konfigurację ról i kontaktów, ustalenie warunków handlowych (płatności, cennik/rabaty, limity), przygotowanie realizacji (adresy, dostawy, wymagania dokumentów), a także przekazanie do opieki posprzedażowej (SLA, kanał zgłoszeń, opiekun). To ostatnie bywa pomijane, a potem „nowy klient” zaczyna od pytania: do kogo mam pisać w sprawie reklamacji? I robi to… do handlowca.

Punkty zapalne: dane, warunki, przekazanie, komunikacja

Najczęstsze pęknięcia scenariusza onboardingu w CRM i ERP to:

• Dane firmy i adresy: kilka wersji nazwy klienta, inny adres faktury w ERP i inny w CRM, kontakt do księgowości zapisany w notatce, a nie w polu.
• Warunki handlowe: rabat ustalony „na mailu”, termin płatności „na gębę”, limit kredytowy niezatwierdzony, ale zamówienie już przyjęte.
• Handoff sprzedaż–realizacja: zespół realizacji dostaje zamówienie bez informacji o oknach dostaw, wymaganiach pakowania czy dokumentach odbioru.
• Komunikacja: CRM wysyła automatyczne potwierdzenie, ERP wysyła swoje, a klient zastanawia się, czy to na pewno ta sama firma.
• Dokumenty i zgody: brak akceptacji warunków, brak wymaganych załączników, chaos w tym, gdzie co trzymamy (CRM, ERP, dysk, załącznik w mailu).

Widać tu wspólny mianownik: brak jednoznacznego podziału odpowiedzialności oraz brak „bramki” definiującej, kiedy klient jest gotowy do transakcji. Bez bramki onboarding zamienia się w ruchome piaski – każdy coś zrobił, ale nikt nie wie, czy już można przyjąć pierwsze zamówienie.

Minimalny porządek: jeden właściciel procesu i jedna definicja „gotowy do zamówień”

Da się to uporządkować bez tworzenia biurokratycznego potwora. Potrzebne są dwie decyzje:

• Właściciel onboardingu – rola, nie osoba. Najczęściej: Sales Ops, koordynator obsługi klienta albo backoffice (zależnie od wariantu architektury).
• Bramka „klient gotowy do pierwszego zamówienia” – krótka lista warunków, które muszą być spełnione, żeby ERP przyjęło zamówienie, a księgowość mogła wystawić fakturę bez polowania na dane.

Dodatkowo pomaga rozróżnienie dwóch torów pracy: relacja i aktywności (typowo CRM) oraz transakcje i rozliczenia (typowo ERP). To rozróżnienie jest praktyczne, a nie ideologiczne – czasem CRM musi trzymać „twarde” dane, a czasem ERP musi pokazać status w CRM. Dogmaty zostawmy konkurencji.

Scenariusz krok po kroku (baseline), niezależnie od wariantu architektury

Kroki i handoffy między działami: sprzedaż → realizacja → finanse → serwis

Baseline to scenariusz, który można zaimplementować jako workflow w CRM, jako zadania w ERP albo jako hybrydę. Najpierw uporządkuj kolejność zdarzeń i punktów przekazania:

1) Decyzja startowa: kiedy w ogóle zaczyna się onboarding

Najbardziej niebezpieczny moment to „jesteśmy dogadani, zakładajmy klienta”. Doprecyzuj warunek startu onboardingu. W B2B zwykle jest to jedna z opcji: podpis umowy, akceptacja oferty (mail/klik), otrzymanie zamówienia (PO) albo wpłata zaliczki. Ważne, żeby warunek był jednoznaczny, bo inaczej firma zakłada rekordy „na zapas”, a potem walczy z cmentarzyskiem klientów-widm.

2) Weryfikacja danych i deduplikacja rekordów

Zanim powstanie nowy rekord klienta, trzeba sprawdzić, czy już istnieje. To najtańszy krok w całym onboardingu, a często pomijany – bo „przecież widzę, że to nowa firma”. Tylko że w danych systemowych „Nowa Firma Sp. z o.o.” i „Nowa Firma sp z o o” to dwie różne rzeczy.

Praktyczna deduplikacja opiera się na prostych regułach:

• NIP/VAT-ID + kraj jako główny klucz (jeśli masz ten numer).
• Nazwa + domena e-mail (np. kontakt@domena.pl), jeśli NIP jest nieznany na starcie.
• Podobieństwo nazw i adresów – jako podpowiedź dla użytkownika (nie jako automatyczna decyzja).

Co zrobić, gdy rekord już istnieje? Ustal zasadę: albo aktualizujemy istniejący rekord (z logiem zmian), albo tworzymy „oddział/placówkę” jako osobny adres/encję zależną. Najgorsza opcja to tworzyć duplikat „żeby było szybciej”. To jak wpychanie papieru do szuflady, która już się nie domyka – na chwilę działa, a potem trzeba użyć kolana.

3) Warunki handlowe: co musi być zatwierdzone, zanim przyjmiesz zamówienie

Warunki handlowe to punkt zapalny numer jeden w integracji CRM z ERP. Jeśli rabaty, terminy płatności i limity kredytowe żyją w mailach albo w polu „Notatka”, to onboarding jest tylko dekoracją. W scenariuszu zaplanuj:

• ustalenie cennika/rabatów (kto zatwierdza i gdzie to ma ślad),
• ustalenie terminu płatności i ewentualnych zabezpieczeń (np. przedpłata dla nowego klienta),
• jeśli dotyczy: limit kredytowy i zasady blokady zamówień,
• zasady dostaw/Incoterms albo inne ustalenia logistyczne.

Pułapka: handlowiec obiecuje termin płatności „na start”, bo chce domknąć deal, a backoffice musi to potem odkręcać. Rozwiązanie jest proste: wprowadź etap „warunki zatwierdzone” jako bramkę. Bez niej nie ma statusu „gotowy do zamówień”.

4) Konfiguracja realizacji: adresy, preferencje, wymagania operacyjne

To etap, który często jest traktowany jak „dopiszemy później”. Tyle że później jest wtedy, gdy kierowca stoi pod złym magazynem albo paczka wraca, bo zabrakło numeru osoby do odbioru. Minimum operacyjne to: adres faktury, adresy dostaw (czasem kilka), kontakty operacyjne, preferencje dokumentów (np. WZ/CMR, protokoły), oraz informacje o oknach dostaw, jeśli klient tego wymaga.

5) Przekazanie do opieki i serwisu: „co obiecaliśmy” w jednym miejscu

Handoff do serwisu/CS/obsługi nie polega na wysłaniu wiadomości „to nowy klient, zajmijcie się”. Potrzebny jest pakiet przekazania: opiekun, ustalone SLA, preferowany kanał kontaktu, ustalenia szczególne (np. eskalacje), a także „niepisane” oczekiwania klienta, które w praktyce decydują o retencji. Tę część najłatwiej utrzymać w CRM, bo tam żyją aktywności i komunikacja.

Minimalny zestaw statusów onboardingu (i co znaczą operacyjnie)

Statusy mają sens tylko wtedy, gdy oznaczają konkretne konsekwencje operacyjne (np. można/nie można założyć zamówienia). Minimalny zestaw, który zwykle wystarcza, wygląda tak:

• Nowy – do weryfikacji (rekord utworzony, ale dane niezweryfikowane, możliwe duplikaty).
• Dane zweryfikowane (NIP, adres faktury, kontakty; deduplikacja zakończona).
• Warunki handlowe zatwierdzone (termin płatności, rabaty/cennik, ewentualny limit; jest ślad zatwierdzenia).
• Konto aktywne w ERP (klient istnieje w ERP w formie, która pozwala na dokumenty i rozliczenia).
• Gotowy do zamówień (spełnione warunki bramki; można przyjąć pierwsze zamówienie bez ręcznych obejść).
• Pierwsze zamówienie zrealizowane (moment, w którym wychodzą ukryte problemy; warto go mierzyć).

Pułapka: status „Aktywny” oznacza co innego dla sprzedaży i co innego dla księgowości. Wprowadź krótkie definicje statusów w procesie (np. w opisie etapu lub dokumentacji). To oszczędza dziesiątki mikrosporów typu „ale przecież jest aktywny”.

Walidacje i blokady, które ratują proces (bez formularza-karnego)

Walidacje są jak pasy bezpieczeństwa: niewygodne tylko do pierwszego hamowania. Klucz to rozróżnić walidacje krytyczne (blokują przejście) i miękkie (tworzą zadanie do uzupełnienia).

Blokady krytyczne: bez tego nie ma pierwszego zamówienia

• NIP/VAT-ID lub inny identyfikator wymagany do faktury (zależnie od kraju i polityki).
• Adres faktury (wraz z krajem, kodem pocztowym, miastem).
• Osoba do rozliczeń (kontakt do faktur/płatności; mail, czasem telefon).
• Zaakceptowane warunki handlowe (co najmniej termin płatności; rabaty jeśli są niestandardowe).

Walidacje „miękkie”: ważne, ale nie zawsze krytyczne na start

• brak numeru telefonu do kontaktu operacyjnego,
• brak preferencji dostawy/odbioru,
• brak numeru telefonu do kontaktu operacyjnego,
• brak preferencji dostawy/odbioru,
• brak danych osoby technicznej/IT do integracji (jeśli jest EDI/API),
• brak zgód i ustawień komunikacji (newsletter, faktury elektroniczne),
• niekompletne informacje o oddziałach/punktach dostaw (gdy klient ma ich kilka).

Miękkie walidacje najlepiej działają jako „dług” z terminem spłaty: proces może iść dalej, ale system tworzy zadanie z właścicielem i datą. Bez tego „uzupełnimy później” zamienia się w „odkopiemy, jak będzie pożar” — a pożar zwykle zaczyna się od prozaicznych rzeczy typu brak numeru rampy albo faktura do złej spółki.

Dobrą praktyką jest też rozdzielenie pól na „wymagane do pierwszego zamówienia” i „wymagane do bezbolesnej obsługi w skali”. Te drugie nie muszą blokować startu, ale powinny blokować przejście na status „Pierwsze zamówienie zrealizowane” albo „Konto w pełni aktywne”. Dzięki temu onboarding nie staje się formularzem-karnym, a jednocześnie firma nie hoduje zaległości, które potem obciążają serwis i finanse.

Jeśli w procesie pojawiają się obejścia typu „wpisz 0000, żeby przeszło”, to nie jest problem użytkowników, tylko projektu walidacji. Lepiej dopuścić kontrolowany wyjątek (np. pole „Brak NIP — uzasadnienie” z obowiązkową akceptacją finansów) niż udawać, że wyjątki nie istnieją. Wyjątki i tak przyjdą, tylko wtedy w przebraniu.

Trzy warianty onboardingu w CRM i ERP — różnice, plusy/minusy, ryzyka

Wariant A: CRM prowadzi onboarding, ERP dostaje „gotowego klienta”

To najczęstszy układ w firmach, gdzie CRM jest centrum pracy sprzedaży i opieki, a ERP ma być przede wszystkim źródłem dokumentów i rozliczeń. Workflow onboardingu (statusy, zadania, bramki) żyje w CRM, a do ERP trafia klient dopiero po spełnieniu warunków „gotowy do zamówień”.

Plusy: użytkownicy mają jeden „kokpit” do pracy z klientem; łatwo utrzymać handoffy, aktywności i historię ustaleń; mniejsza liczba kont tworzonych w ERP „na zapas”. Ryzyka: jeśli integracja jest słaba, w ERP pojawi się klient bez części kluczowych atrybutów (albo z inną strukturą adresów), a ktoś będzie to ręcznie dopinał; druga pułapka to rozjechanie definicji pól (np. „adres korespondencyjny” w CRM = „adres dostawy” w ERP — klasyk).

Ten wariant działa najlepiej, gdy z góry ustalisz mapowanie danych i minimalny kontrakt: jakie pola muszą być uzupełnione w CRM, żeby ERP zaakceptowało import, oraz które atrybuty są „tylko w ERP” (np. konta księgowe) i kto je uzupełnia. Bez tego CRM staje się magazynem intencji, a ERP magazynem frustracji.

Wariant B: ERP prowadzi onboarding, CRM tylko „podgląda” status

Tu klient jest zakładany i walidowany w ERP, a CRM dostaje informację zwrotną: status onboardingu, numer klienta, ewentualnie blokady (np. brak akceptacji limitu). CRM pełni rolę „warstwy relacyjnej”, ale nie jest miejscem decyzyjnym procesu.

Plusy: finanse i logistyka mają kontrolę nad tym, co jest prawdą systemową; mniej konfliktów typu „w CRM jest X, w ERP jest Y”; łatwiej utrzymać spójność danych księgowych. Ryzyka: onboarding zaczyna przypominać zgłoszenie do urzędu (nie zawsze wina ERP, ale odczucie użytkowników bywa bezlitosne); sprzedaż traci tempo, jeśli ERP wymaga kompletu danych zanim w ogóle da się ruszyć. Pojawia się też zjawisko „shadow CRM” w mailach i notatkach, bo handlowiec i tak musi gdzieś trzymać ustalenia.

Wariant C: Hybryda z jedną „kartą klienta” i dwoma torami pracy

Hybryda działa tak: CRM prowadzi pracę relacyjną (sprzedaż, komunikacja, zadania, pakiet przekazania), a ERP prowadzi część „twardą” (identyfikacja klienta, rozliczenia, blokady finansowe, warunki płatności). Żeby to nie skończyło się dwoma prawdami, potrzebujesz jednego rekordu nadrzędnego i jasnych zasad synchronizacji.

Najczęściej układ wygląda następująco:

• w CRM powstaje rekord klienta (często jeszcze jako „prospekt”),
• po weryfikacji danych i minimalnych ustaleń CRM wysyła do ERP zlecenie założenia kontrahenta (albo tworzy kontrahenta automatycznie),
• ERP odsyła numer klienta i statusy „twarde” (np. blokada kredytowa, akceptacja terminu płatności),
• w CRM nadal toczy się onboarding komunikacyjny: ustalenia operacyjne, kontakty, opiekun, SLA.

Plusy: sprzedaż ma tempo i narzędzia do pracy, finanse mają kontrolę nad ryzykiem i dokumentami; łatwiej utrzymać spójność, bo każdy system robi to, do czego jest stworzony. Minusy: więcej decyzji projektowych: mapowanie pól, konflikty aktualizacji, zasady „co wygrywa”. Ryzyka: jeśli nie zdefiniujesz momentu „zamrożenia” danych, zaczyna się festiwal: w CRM poprawiono adres, ERP został po staremu, a kurier jedzie na wycieczkę krajoznawczą.

Hybryda ma sens, gdy onboarding obejmuje kilka działów i naprawdę chcesz mieć kontrolowane bramki, ale bez wymuszania, żeby handlowiec wklepywał w ERP wszystko „na start”.

Wariant D: „Case-driven” — onboarding jako zgłoszenie/teczka, a nie etap w lejku

Ten wariant jest niedoceniany, a bywa najpraktyczniejszy. Zamiast wciskać onboarding w pipeline sprzedażowy albo w kartotekę kontrahenta, tworzysz sprawę/onboarding case (w CRM, systemie ticketowym lub module workflow), do której podpinasz zadania, dokumenty i decyzje. Klient jako rekord może istnieć równolegle, ale to „teczka” jest sercem procesu.

Plusy: świetnie się skaluje na wyjątki (nietypowe umowy, wielu decydentów, EDI, wiele lokalizacji); łatwo widać, kto trzyma piłkę; prosto domknąć checklistę i mieć audyt. Minusy: wymaga dyscypliny: ludzie muszą pracować „w sprawie”, a nie w mailach. Ryzyka: jeśli case nie ma bramek połączonych z ERP, stanie się tylko ładnym dziennikiem wydarzeń, a blokady i tak wyjdą przy pierwszej fakturze.

To podejście pasuje szczególnie tam, gdzie onboarding to nie tylko „załóż kartę klienta”, ale też wdrożenie techniczne, szkolenie użytkowników, uzgodnienia prawne czy zgody marketingowe. Jednym słowem: gdy klient wymaga więcej niż NIP i adres.

Punkty zapalne w każdym wariancie: gdzie proces najczęściej pęka

Niezależnie od architektury, awarie w onboardingu zwykle dzieją się w tych samych miejscach. Różnica polega na tym, czy wybuchają w CRM, w ERP, czy w głowach ludzi (to trzecie bywa najdroższe).

1) Duplikaty: „ten sam klient, trzy nazwy, pięć adresów”

Duplikaty to nie tylko problem porządku — to problem rozliczeń, limitów, raportowania i serwisu. Klasyczny scenariusz: handlowiec zakłada „ABC Sp. z o.o.”, księgowość ma „ABC Spółka z ograniczoną odpowiedzialnością”, magazyn widzi jeszcze „ABC (oddział)”. Potem zdziwienie, że płatności się nie zgadzają.

Zabezpieczenia, które realnie działają:

• jeden identyfikator do wyszukiwania (NIP/VAT-ID, a jeśli go nie ma: inny numer + powód braku),
• deduplikacja na wejściu: zanim powstanie nowy rekord, użytkownik musi „odkliknąć”, że sprawdził podobne firmy,
• rola właściciela danych (Data Steward w praktyce: ktoś z backoffice, kto rozstrzyga spory),
• zasada nazewnictwa (np. nazwa rejestrowa + marka handlowa jako osobne pole, zamiast kreatywności w jednym).

2) Konflikty „źródła prawdy”: kto może zmieniać co i kiedy

Nie wystarczy napisać w dokumencie „ERP jest masterem”. Trzeba jeszcze ustalić, co to znaczy w codziennej pracy, bo inaczej masterem zostaje ten, kto głośniej krzyczy.

Praktyczny podział, który zwykle ogranicza chaos:

• dane rejestrowe, podatkowe, warunki płatności, blokady — master w ERP,
• kontakty, role kontaktów, historia komunikacji, opiekun, ustalenia miękkie — master w CRM,
• adresy dostaw — zależnie od modelu: jeśli wpływają na dokumenty WZ/faktury, często ERP; jeśli to „preferencje operacyjne” (np. okna dostaw, instrukcje), CRM + synchronizacja wybranych pól.

Najważniejsza rzecz: zdefiniuj moment zamrożenia dla danych krytycznych. Przykład: po statusie „Konto aktywne w ERP” zmiany adresu faktury idą tylko przez ERP (z zadaniem/akceptacją), a CRM tylko podgląda. Bez tego integracja zrobi z adresów ping-ponga.

3) Warunki handlowe bez śladu: „ustaliliśmy na callu”

Warunki muszą mieć ślad decyzji. Nie chodzi o biurokrację, tylko o to, żeby po trzech miesiącach nikt nie szukał wątku w Teamsach, który „na pewno gdzieś był”.

Dwie proste techniki:

• warunki niestandardowe (rabat, termin płatności, limit) mają pole + właściciela + status akceptacji,
• jeśli decyzja jest „na wyjątek”, dopisz uzasadnienie i osobę zatwierdzającą (to wcale nie musi być wielki workflow).

Subtelny test jakości: jeśli nowa osoba w zespole nie potrafi wyjaśnić „dlaczego ten klient ma takie warunki” w 30 sekund, to ślad jest za słaby.

4) Przekazanie do realizacji bez kontekstu: „sprzedane, teraz róbcie”

Tu rodzą się reklamacje „na start”. Realizacja nie potrzebuje epopei, ale potrzebuje konkretów. Minimalny pakiet przekazania powinien być ustandaryzowany i możliwy do wyciągnięcia w 2 kliknięciach:

• co klient kupuje i w jakim wariancie (SKU/usługa + ograniczenia),
• kto podejmuje decyzje po stronie klienta (zakupy vs operacje vs finanse),
• jak wygląda dostawa/odbiór w praktyce (okna, awizacje, dokumenty),
• co jest „czerwone” (np. zakaz częściowych dostaw, wymagane protokoły).

Jeśli te informacje zostają w głowie handlowca, onboarding kończy się w momencie, gdy handlowiec ma urlop. A urlopy mają to do siebie, że lubią wypadać wtedy, gdy firma jest najbardziej zajęta.

Porównanie wariantów: szybka tabela i kryteria wyboru

Kryteria wyboru, które oszczędzają nerwy (i integracje)

Zamiast wybierać wariant „bo tak mamy od lat”, przejdź przez kilka pytań kontrolnych. Odpowiedzi zwykle same wskazują, gdzie powinien być ster procesu.

• Co jest największym kosztem błędu? Jeśli faktury i limity — naturalnie ciągnie do ERP-driven albo hybrydy. Jeśli utrata tempa i chaos komunikacji — CRM-driven lub case-driven.
• Kto faktycznie wykonuje większość kroków? Jeśli backoffice zakłada, waliduje i blokuje — ERP jako sterownik jest logiczny. Jeśli sprzedaż/CS robi 80% pracy — ster w CRM.
• Ile wyjątków ma onboarding? Im więcej wyjątków (wiele lokalizacji, EDI, niestandardowe umowy), tym lepiej działa case-driven albo hybryda z osobnym „onboarding case”.
• Czy masz dojrzałą deduplikację i ownera danych? Jeśli nie, warianty z szybkim tworzeniem rekordów (CRM-driven) wymagają mocniejszych bramek, inaczej duplikaty zaleją ERP.
• Jak szybko musisz przyjąć pierwsze zamówienie? Jeśli „wczoraj”, blokujące walidacje w ERP bez wyjątków będą tarciem. Lepiej kontrolowane wyjątki i bramki etapowe.

Rekomendacja praktyczna: jak wybrać bez wielkiej rewolucji

Najbezpieczniejsza ścieżka w wielu firmach B2B to hybryda, ale nie „wszystko synchronizujemy ze wszystkim”, tylko z prostą zasadą: CRM prowadzi pracę i kompletność kontaktowo-operacyjną, ERP jest strażnikiem warunków płatności, blokad i kartoteki do dokumentów. Do tego jedna bramka wspólna dla obu światów: status „Gotowy do zamówień” nadawany dopiero, gdy ERP potwierdzi, że klient jest możliwy do rozliczenia.

Kolejny rozsądny krok to spisanie krótkiego „kontraktu danych” (jedna strona):

• które pola są master w CRM, a które w ERP,
• jak wygląda mapowanie adresów (faktury vs dostawy vs korespondencja),
• co blokuje przejście przez bramkę i kto może nadać wyjątek,
• jakie statusy wracają z ERP do CRM (minimum: numer klienta, blokada, akceptacja warunków).

To nie jest dokument dla audytora, tylko instrukcja, dzięki której onboarding przestaje zależeć od tego, kto akurat „pamięta jak było ostatnio”.

Najczęściej zadawane pytania (FAQ)

Kiedy zaczyna się onboarding klienta B2B w CRM i ERP?

Start powinien mieć jeden, twardy warunek — inaczej szybko uzbierasz „klientów-widm”, których nikt nie pamięta, skąd się wzięli. W B2B najczęściej onboarding uruchamia: podpis umowy, akceptacja oferty (mail/klik), otrzymanie zamówienia (PO) albo wpłata zaliczki.

Wybierz jeden wariant jako standard, a wyjątki opisz jasno (np. „VIP może po akceptacji oferty, reszta po PO”). Dzięki temu workflow nie odpala się „bo handlowiec już czuje, że to pewne”.

Kto powinien być właścicielem onboardingu klienta (CRM/ERP)?

Najlepiej, żeby właścicielem była rola, nie konkretna osoba: Sales Ops, koordynator obsługi klienta albo backoffice. Chodzi o to, by ktoś pilnował kolejności kroków, kompletności danych i bramek, zamiast zostawiać proces w rękach „kto akurat ma chwilę”.

Sprzedaż może inicjować onboarding, ale domknięcie i „gotowość do zamówień” zwykle wymagają pracy między działami (realizacja, finanse, serwis). Bez właściciela kończy się to ruchem wahadłowym maili i pytaniem: „kto to miał zrobić?”.

Co powinno być „źródłem prawdy” dla danych klienta: CRM czy ERP?

To zależy od tego, gdzie dane są później używane jako „twarde” w transakcjach. Dane rozliczeniowe (NIP/VAT-ID, adres faktury, warunki płatności, limity) bardzo często powinny mieć jedno miejsce decyzyjne i audyt — w praktyce bywa to ERP albo kontrolowany moduł w CRM, ale tylko jeden.

Najgorszy wariant to dwa równoległe źródła prawdy, bo wtedy da się mieć jednocześnie „poprawny” adres w CRM i „poprawny” adres w ERP, a paczka i faktura pojadą każdy w swoją stronę.

Jak uniknąć duplikatów klientów w CRM i ERP (deduplikacja)?

Deduplikację trzeba włączyć zanim powstanie nowy rekord, nie po fakcie. Najprostsze reguły, które działają w większości firm, to połączenie kilku kluczy i podpowiedzi dla użytkownika.

• NIP/VAT-ID + kraj jako główny identyfikator (jeśli jest dostępny).
• Nazwa firmy + domena e-mail (np. @domena.pl), gdy NIP jest nieznany na starcie.
• Podobieństwo nazw/adresów jako sugestia, a nie automatyczna decyzja.

Gdy rekord już istnieje, ustal zasadę: aktualizujemy istniejący (z logiem zmian) albo tworzymy oddział/placówkę jako osobną encję adresową. Duplikat „żeby było szybciej” zwykle wraca w postaci reklamacji lub korekty faktury.

Co musi być zatwierdzone, zanim klient dostanie status „gotowy do pierwszego zamówienia”?

Status „gotowy do zamówień” powinien być bramką, nie życzeniem. Minimalny zestaw obejmuje dane do faktury, komplet adresów dostaw (jeśli dotyczy), kontakty operacyjne oraz zatwierdzone warunki handlowe — tak, zatwierdzone, a nie „ustalone na mailu”.

W praktyce lista kontrolna często wygląda tak:

• zweryfikowany NIP/VAT-ID i nazwa firmy,
• adres faktury + wymagane adresy dostaw,
• termin płatności, cennik/rabaty, ewentualny limit kredytowy,
• ustalenia logistyczne (np. okna dostaw, wymagane dokumenty),
• jasny kanał obsługi po sprzedaży (serwis/SLA, opiekun).

Gdzie trzymać warunki handlowe: w CRM czy w ERP?

Warunki handlowe są newralgiczne, bo dotykają realizacji i rozliczeń. Jeśli rabat, termin płatności czy limit kredytowy da się zmienić „w notatce”, to prędzej czy później ktoś przyjmie zamówienie na warunkach, których finanse nie akceptują.

Najbezpieczniej jest trzymać je tam, gdzie mają ślad audytowy i gdzie realnie blokują/odblokowują transakcje (często ERP), a w CRM pokazywać status i uzgodnione wartości. Klucz to jedna ścieżka zatwierdzeń i jedna wersja prawdy, żeby klient nie dostał dwóch sprzecznych odpowiedzi w zależności od tego, kogo zapyta.

Jak ogarnąć komunikację, gdy i CRM, i ERP wysyłają maile do klienta?

Najpierw ustal, który system odpowiada za komunikację transakcyjną w danym momencie procesu. Inaczej klient dostanie dwa potwierdzenia tego samego (a potem zadzwoni, czy to phishing — i trudno mu się dziwić).

Pomaga prosta macierz: dla każdego typu wiadomości (potwierdzenie zamówienia, status dostawy, faktura, zgłoszenia serwisowe) wybierz jeden system wysyłający, a drugi niech co najwyżej loguje zdarzenie lub pokazuje status. Kolejny rozsądny krok to spisanie tego jako reguł w workflow, żeby nie zależało to od pamięci użytkowników i „kto dziś klikał automatyzacje”.

Źródła informacji

• ISO 9001:2015 Quality management systems — Requirements. International Organization for Standardization (ISO) (2015) – Podejście procesowe, odpowiedzialności, nadzór nad zmianami i dokumentacją.
• ISO 8000-8:2015 Data quality — Part 8: Information and data quality: Concepts and measuring. International Organization for Standardization (ISO) (2015) – Pojęcia jakości danych, kryteria i pomiar; przydatne dla walidacji danych klienta.
• DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition). DAMA International (2017) – Zarządzanie danymi, MDM, „single source of truth”, jakość i governance.
• Master Data Management and Data Governance. IBM Redbooks – MDM, źródło prawdy, integracje systemów i praktyki unikania duplikatów.
• Customer Relationship Management: Concepts and Technologies (3rd Edition). Elsevier (Morgan Kaufmann) (2011) – Podstawy CRM, procesy sprzedaż–obsługa, automatyzacja i komunikacja z klientem.