Sklep B2B to nie jest B2C z logowaniem
Prawie każdy projekt B2B, który wykłada się w połowie, zaczyna od tego samego założenia: „to w zasadzie ten sam sklep, tylko klient się loguje i widzi swoje ceny". Założenie jest wygodne, bo pozwala wycenić projekt jak B2C. Pęka w czterech miejscach naraz - i żadne z nich nie jest problemem frontendu.
Spis treści (5)
Cena przestaje być cechą produktu
W B2C cena jest atrybutem produktu. Leży obok nazwy i zdjęcia, zmienia się rzadko, a promocja to druga liczba obok pierwszej.
W B2B cena jest funkcją dwóch argumentów: produktu i kupującego. Ten sam indeks kosztuje inaczej dla trzech kontrahentów, a czasem inaczej dla tego samego kontrahenta w zależności od ilości w koszyku. Do tego dochodzą progi ilościowe, rabaty na grupę towarową, ceny kontraktowe negocjowane na rok i promocje, które nakładają się na to wszystko w określonej kolejności.
Konsekwencja jest architektoniczna, nie kosmetyczna: nie możesz zcache'ować ceny per produkt. Klucz cache to co najmniej para (kontrahent, indeks), a przy progach ilościowych także koszyk. Sklep, który zaprojektowano wokół założenia „cena leży w bazie obok produktu", trzeba w tym miejscu rozebrać.
Więcej o tym, jak ten model wygląda w praktyce, jest w tekście o cennikach kontraktowych.
Stan magazynowy przestaje być liczbą
W B2C wystarczy „jest / nie ma". Ewentualnie „ostatnie 3 sztuki", żeby popchnąć decyzję.
Klient B2B pyta o coś zupełnie innego: ile mogę dostać do czwartku i ile z tego jest z magazynu w Łodzi. Interesuje go stan dostępny po odjęciu rezerwacji, towar w drodze z datą dostawy, podział na magazyny i to, czy jego zamówienie na 400 sztuk zostanie zrealizowane w całości, czy rozbite na dwie dostawy.
„Dostępność" przestaje być polem w bazie, a staje się wynikiem obliczenia na danych z kilku systemów. I to obliczenia, które musi być spójne z tym, co za dwie godziny powie handlowiec przez telefon.
Zamówienie przestaje być koszykiem
Koszyk B2C ma jedną ścieżkę: dodaj, zapłać, koniec. Stan zamówienia zmienia się liniowo.
W B2B zamówienie bywa dokumentem, który negocjujesz. Klient wrzuca 40 pozycji, prosi o ofertę, dostaje ją z inną ceną, akceptuje 35 pozycji, jego przełożony musi zatwierdzić kwotę powyżej progu, a dział finansowy blokuje całość, bo przekroczony jest limit kredytowy. Dopiero potem powstaje zamówienie.
Żaden z tych kroków nie jest wyjątkiem od reguły. To jest reguła w połowie polskiego B2B - i to jest powód, dla którego platformy B2C obudowane rabatami nie dowożą. Nie mają gdzie zapisać stanu „oferta wysłana, czekamy na akceptację po stronie klienta".
Kupujący przestaje być osobą
To jest różnica, którą najłatwiej przeoczyć na etapie wyceny, a najdrożej naprawić po starcie.
W B2C konto to osoba. W B2B konto to firma, a wewnątrz niej ludzie z różnymi uprawnieniami: zaopatrzeniowiec, który tylko składa koszyk, kierownik, który akceptuje do 50 tys. zł, centrala, która widzi zamówienia wszystkich oddziałów. Do tego oddziały mają osobne adresy dostawy, ale wspólny limit kredytowy i wspólny cennik.
Model danych, w którym „user ma zamówienia", nie ma tu czego reprezentować. Potrzebujesz organizacji, ról, hierarchii i osobnego pojęcia adresu dostawy. Rozwijam to w tekście o multi-account i strukturze organizacji.
Co z tego wynika dla wyceny
Wszystkie cztery różnice mają jedną wspólną cechę: żadnej z nich nie widać na makiecie. Makieta sklepu B2B wygląda jak makieta sklepu B2C - jest katalog, jest koszyk, jest przycisk. Dlatego wycena robiona po makiecie jest zawsze za niska, a rozmowa o „drugim etapie" zaczyna się w trzecim miesiącu.
Praktyczny test, zanim podpiszesz cokolwiek: weź trzech swoich najtrudniejszych klientów i opisz ich pełną ścieżkę zakupową - od tego, kto składa zamówienie, po to, kto je zatwierdza i skąd bierze się cena na fakturze. Jeśli ta ścieżka nie mieści się w standardowym modelu platformy, właśnie znalazłeś prawdziwy zakres projektu. Reszta to katalog i przycisk.
To samo ćwiczenie jest zresztą najlepszym filtrem przy wyborze platformy - bo pytanie nie brzmi „która platforma jest lepsza", tylko „ile z niej będę nadpisywać".
O autorze
Jakub Owsianka
Architekt rozwiązania silnika platform B2B. Zaczynał po stronie biznesu (własne sklepy), potem deweloper, dziś projektuje wdrożenia dla sklepów z katalogami w dziesiątkach tysięcy SKU. W ostatnich latach wdrożył AI-development w zespole i funkcjonalności oparte o AI bezpośrednio w silniku sklepu.
Czytaj dalej w temacie wydajności
Wszystkie wpisyMasz pytanie do tego artykułu?
Dodatkowy kontekst, problem z własnym wdrożeniem, druga opinia - napisz wprost. Odpowiadam osobiście w 1-2 dni robocze.