Projektujemy platformy B2B jako system sprzedaży, a nie zwykły sklep z hasłem. Łączymy logowanie partnerów, zamknięty katalog, indywidualne warunki handlowe, szybkie zamawianie, eksport zamówień do ERP i procesy, które ograniczają ręczną pracę handlowców.
Budujemy B2B jako uporządkowany system: dostęp tylko dla partnerów, właściwe ceny po zalogowaniu, szybkie składanie zamówień, kontrolę stanów, eksport danych i jasne statusy obsługi po stronie firmy.
Zakres można rozwijać etapami: od sklepu B2B z logowaniem, przez indywidualne rabaty i cenniki, po eksport zamówień do ERP. Przykład takiego kierunku pokazuje case Sportina B2B.
Ustalamy, czy niezalogowany użytkownik widzi tylko ekran logowania, katalog bez cen, czy pełną ofertę z ograniczeniami. Dostęp B2B powinien chronić ceny, stany, pliki produktowe i warunki handlowe przed publicznym ruchem.
Platforma musi pokazać klientowi właściwy cennik, rabat, limit, minimum logistyczne i sposób dostawy. Nie chodzi o jeden procent zniżki, tylko o kontrolę zasad sprzedaży dla różnych grup i kont.
Zamówienie B2B powinno trafiać do ERP, BaseLinkera, CSV, XLSX albo panelu handlowca w stabilnym formacie: z pozycjami, SKU, EAN, ilościami, adresem, NIP, statusem i informacją o kliencie.
„Platforma B2B" nie jest jednym produktem. Producent planujący kolekcję, importer obsługujący kilka marek, dystrybutor z katalogiem wielu dostawców i hurtownia z domówieniami mają inny proces zamówienia — i z tego wynikają inne moduły, nie z listy funkcji dostawcy oprogramowania.
Sprzedaż przez sieć partnerów i sklepów. Osią systemu jest preorder na kolekcję lub serię produkcyjną: partner zamawia przed produkcją, a firma potrzebuje sumy zamówień jako danych wejściowych do planu. Domówienia z bieżącego stanu to osobny proces, nie ten sam koszyk.
Przedstawiciel kilku marek, każda z własną polityką cenową i własnym kalendarzem dostaw. Partner musi widzieć nie tylko stan na magazynie, ale też towar w drodze i datę dostępności — inaczej zamawia to, czego nie ma, albo rezygnuje z tego, co przyjdzie za dwa tygodnie.
Duży katalog od wielu producentów, ceny zakupu i marże różne per grupa partnerów, dostępność częściowo u dostawców. Kluczowe jest jedno źródło prawdy o stanie i cenie oraz to, żeby import katalogu nie nadpisywał ustalonych warunków handlowych.
Powtarzalne domówienia tych samych pozycji. Liczy się szybkość: zamawianie po kodach, import koszyka z arkusza, ponowienie poprzedniego zamówienia, jednostki sprzedaży i opakowania zbiorcze, progi cenowe oraz limit kupiecki widoczny przed złożeniem zamówienia.
Największe ryzyko w B2B nie leży w samym formularzu logowania. Problem zaczyna się wtedy, gdy ceny, rabaty, stany, warianty, minimum zamówienia i eksport nie mają jasnego źródła danych. Dlatego projekt zaczynamy od mapy procesu, a nie od dokładania kolejnych modułów.
Wdrożenie nie musi od razu obejmować całego systemu enterprise. Najpierw wybieramy moduły, które zdejmują największą ręczną pracę z zespołu sprzedaży.
Konta klientów, role, grupy, ukryte ceny, widoczność kategorii i blokada dostępu dla gości. To fundament, który decyduje, kto widzi ofertę i na jakich warunkach.
Rabat per klient, grupa cenowa, cena katalogowa, cena po zalogowaniu, progi zamówień, minimum logistyczne i rozdzielenie cen netto/brutto w zależności od procesu firmy.
Produkty, warianty, rozmiary, stany własne i dostawcy, tabela wariantów, import koszyka z CSV oraz szybkie dodawanie po SKU bez przeklikiwania każdej karty produktu.
CSV, XLSX, REST API lub BaseLinker jako pośrednik. Ważne są mapowania pól, statusy, logi, ochrona przed duplikacją i możliwość ponowienia błędnego eksportu.
Stany, ceny, produkty, zdjęcia, opisy, zamówienia i kontrahenci mogą płynąć między ERP, sklepem, BaseLinkerem i plikami XML/CSV — ale tylko z walidacją i raportowaniem błędów.
Testy zamówień, kont, rabatów, eksportu, indeksacji, maili i statusów. Platforma B2B musi przejść scenariusze handlowca i klienta, nie tylko test „czy strona się otwiera”.
Dlatego projektujemy ją wokół realnego zamówienia: kto kupuje, co widzi, po jakiej cenie, jak szybko dodaje warianty i gdzie trafia finalny dokument.
Zaczynamy od MVP, które daje efekt operacyjny, a później dokładamy kolejne integracje. Taki model utrzymuje projekt w ryzach i pozwala rozwijać B2B etapami.
Opisujemy typy klientów, role handlowców, sposób składania zamówień, rabaty, ograniczenia katalogu, źródła danych i systemy, które muszą wymieniać informacje.
Wybieramy najkrótszy sensowny zakres: logowanie, katalog, ceny, koszyk, zamówienie i eksport. Odkładamy dodatki, które nie zdejmują pracy z zespołu.
Porządkujemy SKU, EAN, warianty, stany, cenniki, konta klientów oraz format zamówienia, zanim podłączymy ERP, BaseLinkera lub cykliczne importy.
Sprawdzamy logowanie, ceny, dostępność, koszyk, statusy, eksport i błędy na realnych produktach oraz przykładowych klientach B2B.
To nie jest wybór między lepszym i gorszym. Gotowy system jest szybszy i tańszy na starcie, dopóki Twój proces sprzedaży mieści się w jego modelu. Koszt pojawia się w miejscu, w którym trzeba go wygiąć — i wtedy zwykle jest wyższy niż koszt zbudowania tej części od początku.
| Kryterium | Gotowa platforma (SaaS/moduł) | Platforma na Twoim silniku |
|---|---|---|
| Czas do pierwszego zamówienia | krótszy — konfiguracja zamiast budowy | dłuższy — zależny od zakresu MVP i stanu danych |
| Standardowe ceny per grupa klienta | w standardzie | w standardzie |
| Cennik indywidualny per kontrahent | zależy od planu | bez ograniczeń modelu |
| Preorder oddzielony od domówienia | rzadko obsługiwane | projektowane jako dwa procesy |
| Import zamówienia z arkusza partnera | zależy od dostawcy | format dopasowany do partnerów |
| Format zamówienia wychodzącego do ERP | predefiniowany | dokładnie taki, jaki przyjmuje ERP |
| Stan z magazynu i towar w drodze | zwykle jedno pole stanu | wiele źródeł dostępności |
| Koszt miesięczny | abonament rosnący ze skalą | hosting i opieka techniczna |
| Koszt zmiany procesu po roku | zależny od roadmapy dostawcy | po Twojej stronie |
| Wyjście z rozwiązania | eksport danych, front od nowa | front od nowa, dane i logika zostają |
Silnik dobieramy po mapie procesu, nie odwrotnie. Magento jest najczęstszym wyborem przy rozbudowanym B2B, bo grupy klientów i ceny per kontrahent ma natywnie — ale nie jest odpowiedzią na każdy przypadek.
Grupy klientów, ceny progowe, wiele magazynów (MSI) i rozbudowane API są natywne w Magento Open Source. Konta firmowe i wspólne katalogi z cenami per kontrahent są natywne w Adobe Commerce B2B — w Open Source wymagają architektury, rozszerzeń albo własnych modułów. Wybór przy dużym katalogu i integracji z ERP; koszt to wymagająca infrastruktura i opieka techniczna.
Sensowny, gdy B2B jest rozszerzeniem sprzedaży detalicznej, katalog jest umiarkowany, a logika cen sprowadza się do grup i progów. Pełna kontrola nad kodem i checkoutem, ale mechanizmy B2B trzeba dobudować i utrzymywać.
Wybór wtedy, gdy partner nie kupuje z katalogu, a pracuje na danych: preordery na macierzy rozmiarów, limity, plany dostaw, pliki. Portal działa obok sklepu i korzysta z tych samych danych przez API, zamiast dublować katalog.
Najbliższy przykład tego modelu w naszym portfolio to platforma B2B Sportina na Magento. Projekt powstał w dwóch etapach: najpierw osobna warstwa komunikacji dla partnerów handlowych, oddzielona od sklepu detalicznego, potem platforma zamówień z logowaniem. Każdy moduł wchodził osobno, na działającym środowisku — bez wstrzymywania sprzedaży partnerskiej.
W case study nie podajemy liczby partnerów, liczby zamówień ani wartości sprzedaży — to dane klienta, nie nasze. Opisujemy natomiast decyzje techniczne i granice zakresu.
Opisz model sprzedaży, typy klientów, katalog, cenniki i sposób obsługi zamówień. Ustalimy, czy najlepiej zacząć od logowania, cenników, szybkiego zamawiania czy eksportu do ERP.