CRM dla firmy B2B – jak zaprojektować proces zamiast tabeli kontaktów

CRM dla firmy B2B projektuje się od procesu i modelu danych, a nie od ekranów: najpierw ustala się, jakie obiekty biznesowe istnieją (firma, oddział, osoba, szansa, oferta, zadanie), jak przechodzą przez etapy sprzedaży, kto może co z nimi robić i jakie decyzje mają wspierać raporty. Dopiero z tego wynikają formularze i widoki. Jeśli ta kolejność zostanie odwrócona, powstaje ładna tabela kontaktów, do której handlowcy przestają zaglądać po miesiącu. Poniżej opisujemy, jak przeprowadzić warsztat projektowy, po którym wiadomo, co budować.

Przygotowanie warsztatu

Warsztat najlepiej podzielić na dwie–trzy sesje po kilka godzin. Przed pierwszą sesją zbierz materiał, który pokaże, jak sprzedaż wygląda naprawdę:

• kilka przykładowych ofert z ostatnich miesięcy, w tym jedną wygraną i jedną przegraną,
• arkusze, w których handlowcy dziś śledzą szanse,
• raporty, które zarząd dostaje co tydzień lub co miesiąc,
• listę systemów, z których CRM będzie korzystał (ERP, sklep, formularze na stronie).

Na warsztacie pracujemy na tablicy lub wspólnym dokumencie, a każdą decyzję zapisujemy od razu. Wynikiem ma być model, który programista może przełożyć na bazę danych, a handlowiec rozpoznać jako swój proces.

Sesja 1: encje, czyli z czego składa się sprzedaż

Zaczynamy od rzeczowników. Typowy zestaw dla B2B:

• Firma – kontrahent z NIP-em, danymi rejestrowymi, segmentem i opiekunem. Pytanie kontrolne: czy obsługujecie grupy kapitałowe? Jeśli tak, firma potrzebuje relacji „spółka matka – spółka zależna”.
• Oddział / lokalizacja – adres dostawy, magazyn, zakład. Wielu klientów B2B zamawia do kilku lokalizacji, a decyzje zapadają w centrali. Bez tej encji adresy lądują w notatkach.
• Osoba – kontakt z rolą (decydent, zakupowiec, użytkownik techniczny, księgowość). Ta sama osoba może zmienić firmę, więc historia relacji powinna być przypisana do niej, a nie wyłącznie do kontrahenta.
• Szansa sprzedaży – potencjalna transakcja: przedmiot, szacowana wartość, etap, termin decyzji, źródło, przyczyna przegranej.
• Oferta – konkretny dokument z pozycjami, cenami, warunkami i numerem wersji. Jedna szansa może mieć kilka ofert.
• Zadanie i aktywność – telefon, spotkanie, mail, przypomnienie. Zadanie ma termin i właściciela, aktywność jest zapisem tego, co się wydarzyło.
• Produkt / pozycja cennika – zwykle nie tworzony w CRM, lecz pobierany z ERP lub PIM.

Dla każdej encji zapisujemy: pola obowiązkowe, źródło danych (wpisywane w CRM czy pobierane z innego systemu) i relacje. Prosta notacja wystarcza, np. „Firma 1–N Oddział”, „Szansa 1–N Oferta”, „Osoba N–M Szansa (z rolą)”.

Typowy błąd na tym etapie to przenoszenie struktury arkusza wprost do systemu: jedna tabela „klienci” z kolumnami „kontakt 1”, „kontakt 2”, „adres dostawy 3”. Warsztat ma właśnie rozbić taki arkusz na obiekty.

Sesja 2: etapy i reguły przejść

Kiedy wiemy, z czego składa się sprzedaż, opisujemy, jak szansa przez nią przechodzi. Dla każdego etapu ustalamy:

1. Nazwę i kryterium wejścia – sprawdzalny fakt, np. „rozpoznano potrzebę i osobę decyzyjną”, „wysłano ofertę”, „klient potwierdził budżet”.
2. Wymagane dane – czego nie da się pominąć, żeby przejść dalej, np. oferta nie może przejść do etapu „negocjacje” bez przypisanej osoby decyzyjnej.
3. Automatyczne działania – co system robi sam: tworzy zadanie follow-up po wysłaniu oferty, powiadamia kierownika o rabacie powyżej progu.
4. Wyjścia – wygrana (co dalej: zamówienie, przekazanie do realizacji) i przegrana (obowiązkowa przyczyna z listy).

Przykładowy przepływ dla firmy dystrybucyjnej: zapytanie → kwalifikacja → oferta wysłana → negocjacje → decyzja. Po wygranej system tworzy zamówienie w ERP albo zadanie dla działu obsługi. Po przegranej zapisuje przyczynę i proponuje przypomnienie za kilka miesięcy.

Warto też osobno opisać procesy poza lejkiem nowych transakcji: odnowienia umów, cykliczne zamówienia, reklamacje. Często to one generują większość pracy handlowca, a w CRM projektowanym tylko pod „nową sprzedaż” nie mają miejsca.

Sesja 3: role, uprawnienia i raporty

Role i uprawnienia

Wypisujemy role, a nie osoby: handlowiec, kierownik regionu, dyrektor sprzedaży, obsługa zamówień, marketing, administrator. Dla każdej roli określamy w prostej macierzy:

• zakres danych – tylko własni klienci, klienci regionu, wszyscy,
• operacje – podgląd, edycja, akceptacja rabatu, zmiana opiekuna, eksport,
• pola wrażliwe – marże, ceny zakupu, notatki kierownicze.

Szczególną uwagę warto poświęcić eksportowi danych i zmianie opiekuna klienta. To operacje, które przy odejściu pracownika mają duże znaczenie, a w wielu systemach są dostępne dla każdego.

Raporty

Raporty projektujemy od pytań, na które mają odpowiadać, np.: „Ile ofert czeka na decyzję klienta dłużej niż dwa tygodnie?”, „Z jakich powodów przegrywamy w danym segmencie?”, „Którzy klienci nie zamawiali od kwartału?”. Każde pytanie weryfikujemy z modelem danych: jeśli brakuje pola lub relacji, żeby na nie odpowiedzieć, wracamy do sesji 1. To najlepszy test, czy model jest kompletny.

Integracje w modelu – krótko, ale od razu

Na warsztacie nie projektujemy szczegółów integracji, ale dla każdego pola ustalamy system nadrzędny. Dane kontrahenta i ceny najczęściej pochodzą z ERP, leady z formularzy strony, statusy zamówień z systemu B2B. Zapisanie tego od razu zapobiega sytuacji, w której ten sam adres jest edytowany w dwóch miejscach.

Test modelu na jednym przypadku

Na koniec ostatniej sesji przechodzimy przez model jedną prawdziwą transakcję z ostatnich miesięcy, krok po kroku:

1. Zapytanie przychodzi przez formularz na stronie – powstaje lead, system rozpoznaje po NIP-ie istniejącą firmę i przypisuje ją do opiekuna.
2. Handlowiec kwalifikuje zapytanie – tworzy szansę, dodaje dwie osoby kontaktowe z rolami „decydent” i „zakupowiec” oraz oddział, do którego ma trafić dostawa.
3. Powstaje oferta z cenami pobranymi z ERP; rabat powyżej progu uruchamia akceptację kierownika.
4. Klient prosi o zmianę ilości – powstaje druga wersja oferty, pierwsza zostaje w historii.
5. Po wygranej szansa zamyka się, a do ERP trafia zamówienie z numerem oferty.

Każde miejsce, w którym zespół mówi „tu zwykle robimy to w arkuszu”, oznacza brakujący element modelu. Lepiej odkryć go na tablicy niż po wdrożeniu.

Wynik warsztatu

Po warsztacie powinny powstać:

• diagram encji z relacjami i listą pól,
• opis etapów z kryteriami, wymaganymi danymi i automatyzacjami,
• macierz ról i uprawnień,
• lista raportów z pytaniami biznesowymi,
• tabela źródeł danych dla kluczowych pól,
• lista otwartych kwestii do decyzji.

Te materiały wystarczą, żeby przygotować specyfikację i wycenę – jak spisać ją w formie wymagań i user stories, opisujemy w poradniku jak opisać wymagania do aplikacji webowej. Przydają się też wtedy, gdy wciąż ważysz, czy postawić na gotowe narzędzie – model danych jest najlepszym materiałem do pilotażu gotowego CRM.

Następny krok

Zbierz trzy przykładowe oferty, aktualny arkusz szans i ostatni raport sprzedaży, a potem spróbuj rozpisać na nich encje opisane wyżej. Jeśli chcesz przeprowadzić pełny warsztat z zespołem, który projektuje i buduje CRM dla B2B, skontaktuj się z nami – zaczniemy od sesji o encjach i etapach sprzedaży.