System B2B dla firmy produkcyjnej musi obsłużyć rzeczy, których zwykła platforma handlowa nie przewiduje: sieć dealerów i dystrybutorów z różnymi uprawnieniami, produkty konfigurowane pod klienta, obszerną dokumentację techniczną i zamówienia, które uruchamiają produkcję zamiast zdejmować towar z półki. Poniżej opisujemy te cztery obszary, bo to one decydują, czy portal producenta faktycznie odciąży zespół sprzedaży i obsługi. Ogólne różnice między platformą B2B a zwykłym sklepem opisujemy osobno we wpisie System B2B a sklep internetowy.
Obszar 1: dealerzy, dystrybutorzy i klienci końcowi
Producent rzadko sprzedaje tylko bezpośrednio. Zwykle ma kilka kanałów: dystrybutorów krajowych, dealerów regionalnych, instalatorów, klientów kluczowych obsługiwanych bezpośrednio. Każdy z nich ma inne warunki i potrzeby.
System B2B powinien odwzorować tę strukturę:
- hierarchia kont – producent, partner (dealer lub dystrybutor), a opcjonalnie także klient końcowy partnera,
- różne cenniki i warunki dla poszczególnych kanałów, bez ujawniania ich między partnerami,
- zamawianie w imieniu klienta końcowego – dealer składa zamówienie z danymi odbiorcy, co przydaje się przy dostawach bezpośrednich, gwarancji i serwisie,
- obszary i wyłączności – jeśli partner ma przypisany region lub grupę produktów, portal może to respektować przy widoczności oferty lub przydziale zapytań,
- materiały dla partnerów – cenniki detaliczne, zdjęcia, opisy marketingowe, szkolenia i instrukcje montażu.
Kluczowe pytanie projektowe brzmi: kto jest właścicielem relacji z klientem końcowym i jakie dane o nim producent powinien widzieć. Warto je rozstrzygnąć z działem sprzedaży, zanim powstanie model danych.
Obszar 2: produkty konfigurowalne
Wielu producentów sprzedaje wyroby, które powstają dopiero po wyborze parametrów: wymiarów, materiału, koloru, wyposażenia, wykonania specjalnego. Katalog z wariantami przestaje wtedy wystarczać, bo kombinacji jest za dużo, a część z nich jest technicznie niemożliwa.
Co powinien umieć portal w takim przypadku:
- Prowadzić użytkownika krok po kroku – najpierw decyzje, które zawężają kolejne opcje.
- Pilnować reguł – np. dana opcja jest dostępna tylko przy określonym wymiarze albo wyklucza inną. Reguły powinny być utrzymywane przez dział techniczny w panelu, a nie zaszyte w kodzie.
- Wyliczać cenę i orientacyjny termin na podstawie wybranych opcji.
- Tworzyć jednoznaczny opis zamówienia – kod konfiguracji lub indeks, który zrozumie ERP i planowanie produkcji.
- Zapisywać konfiguracje – żeby dealer mógł je wysłać klientowi do akceptacji albo zamówić ponownie.
- Obsługiwać wyjątki – gdy klient potrzebuje czegoś spoza reguł, portal powinien pozwolić wysłać zapytanie do działu technicznego zamiast blokować rozmowę.
Częsty błąd to budowanie konfiguratora jako atrakcyjnego wizualnie modułu marketingowego, który nie przekazuje wyniku do ERP. Wtedy handlowiec i tak przepisuje zamówienie ręcznie, a portal staje się dodatkowym miejscem na pomyłki.
Obszar 3: dokumentacja techniczna
Klient producenta kupuje nie tylko produkt, ale też informację o nim: karty techniczne, rysunki, instrukcje montażu i obsługi, deklaracje zgodności, certyfikaty, karty charakterystyki, a coraz częściej dane pod cyfrowy paszport produktu. W portalu B2B warto zadbać o:
- powiązanie dokumentu z produktem i wersją – klient powinien pobrać dokument obowiązujący dla wyrobu, który kupił, a nie najnowszy,
- dokumenty do zamówienia – np. certyfikat partii lub protokół odbioru dołączony do konkretnej dostawy,
- wersje językowe dla partnerów zagranicznych,
- różne poziomy dostępu – część dokumentów jest publiczna, część tylko dla partnerów, a część tylko dla serwisu,
- jedno źródło – portal wyświetla dokumenty z systemu, w którym są utrzymywane, zamiast przechowywać kopie wgrywane ręcznie.
Kiedy danych produktowych i dokumentów jest dużo, pojawia się pytanie, gdzie je trzymać – w ERP, w PIM czy w DPPC. Role tych systemów porównujemy w artykule PIM, ERP i DPPC – kiedy potrzebujesz każdego systemu.
Obszar 4: zamówienia realizowane pod produkcję
W handlu zamówienie zdejmuje towar z magazynu. U producenta często uruchamia pracę: zakup materiału, zaplanowanie zlecenia, wykonanie i kontrolę jakości. To zmienia wymagania wobec portalu:
- termin orientacyjny i potwierdzony – portal pokazuje termin wynikający z reguł, a po przyjęciu zamówienia przez planowanie – termin potwierdzony,
- statusy produkcyjne – przyjęte, w planie, w produkcji, gotowe do wysyłki, wysłane; bez szczegółów, które nic nie mówią klientowi,
- realizacje częściowe – dostawa w kilku partiach, każda z własnym dokumentem,
- zmiany po złożeniu – do którego momentu klient może zmienić zamówienie i kto to zatwierdza,
- zamówienia ramowe i harmonogramy – klient zamawia większą ilość z podziałem na dostawy w czasie,
- zapytania ofertowe – dla ilości i wykonań, których nie da się wycenić automatycznie.
Dane o statusach pochodzą z ERP lub systemu produkcyjnego, więc już na etapie projektu trzeba ustalić, które zdarzenia są dostępne i jak często można je odświeżać.
Jak te obszary łączą się w architekturze
Portal B2B producenta to zwykle warstwa, która korzysta z kilku źródeł:
- ERP – kontrahenci, ceny, stany wyrobów gotowych, zamówienia, dokumenty sprzedaży,
- system produkcyjny lub planowania – terminy i statusy zleceń,
- PIM lub DPPC – dane techniczne, opisy, dokumenty, zdjęcia,
- CRM – relacje z partnerami, zapytania, opiekun handlowy.
Dobrze zaprojektowany backend oddziela logikę portalu od konkretnych systemów, tak aby wymiana jednego z nich nie wymagała przebudowy całej platformy. Tak podchodzimy do projektów w usłudze platformy B2B i CRM. Jak wybrać partnera, który rozumie realia zakładu, opisujemy we wpisie o software house dla firm produkcyjnych.
Typowe błędy w portalach producentów
- Jeden cennik dla wszystkich kanałów – dealer widzi ceny dystrybutora albo odwrotnie, co psuje relacje handlowe.
- Statusy przepisywane ręcznie – ktoś w biurze aktualizuje je w portalu, więc po kilku tygodniach przestają być wiarygodne.
- Dokumenty bez wersji – klient pobiera nową instrukcję do starszego wyrobu.
- Konfigurator bez reguł technicznych – portal przyjmuje zamówienia, których nie da się wyprodukować, i każde trzeba weryfikować telefonicznie.
- Brak miejsca na wyjątki – nietypowe zapytania nie mają ścieżki, więc wracają do maila.
Od którego obszaru zacząć
Nie trzeba budować wszystkiego naraz. W praktyce najczęściej sprawdzają się dwa punkty startu:
- Portal dla partnerów z dokumentacją i statusami – szybko odciąża obsługę klienta od pytań „gdzie jest moje zamówienie” i „proszę o certyfikat”.
- Zamawianie z konfiguracją dla jednej grupy produktów – pozwala sprawdzić reguły i przepływ do ERP na ograniczonym zakresie.
Wybór zależy od tego, gdzie dziś Twój zespół traci najwięcej czasu.
Następny krok
Weź jedną grupę produktów i opisz dla niej: kto ją kupuje (kanały), jakie opcje można wybrać, jakie dokumenty są do niej potrzebne i jak wygląda droga zamówienia do produkcji. Ta jedna strona wystarczy, żeby ocenić zakres pierwszego etapu portalu. Jeśli chcesz ją przeanalizować razem z nami, skontaktuj się z nami.
Najczęstsze pytania
Czy dealer może w portalu B2B producenta obsługiwać własnych klientów?
Może, jeśli system przewiduje taki poziom struktury: producent, dealer i klient końcowy. Dealer składa wtedy zamówienia w imieniu swoich odbiorców, a producent widzi, dla kogo powstaje produkt, co ułatwia gwarancję i serwis.
Jak pokazać w portalu termin realizacji produktu robionego na zamówienie?
Najbezpieczniej pokazywać termin wynikający z reguł – np. czasu produkcji dla danej grupy wyrobów – jako orientacyjny, a potwierdzony termin dopiero po przyjęciu zamówienia przez planowanie. Klient powinien widzieć w portalu obie informacje i moment, w którym termin się zmienił.
Czy konfigurator produktu musi być częścią systemu B2B?
Nie zawsze. Przy kilku opcjach wystarczą warianty w katalogu. Konfigurator ma sens, gdy kombinacji jest dużo, a część z nich jest technicznie niedozwolona – wtedy reguły muszą pilnować poprawności zamówienia.
Skąd portal B2B producenta ma brać dokumentację techniczną?
Z jednego miejsca, w którym dokumenty mają wersje i daty ważności – może to być PIM, DPPC albo system dokumentacji. Portal tylko je wyświetla i łączy z produktem oraz zamówieniem, zamiast przechowywać własne kopie.
Jak przełożyć ten temat na projekt
W JiraSoft patrzymy na takie zagadnienia przez pryzmat realnego systemu: danych, backendu, integracji API, procesów B2B, widoczności w Google oraz przygotowania treści pod odpowiedzi AI. Dlatego artykuł jest punktem wyjścia do rozmowy o konkretnym workflow, a nie tylko ogólną notatką technologiczną.
