Analizy zmian w platformach, komentarze do roadmap producentów, krótsze opinie z perspektywy praktyka. Publikuję nieregularnie - kiedy temat tego wymaga.
Wszystko w sklepie B2B jest zaprojektowane, żeby powiedzieć klientowi „tak". Jest dokładnie jedno miejsce, w którym system mówi „nie" - blokada za przekroczony limit kredytowy. I dlatego to nie jest decyzja e-commerce.
Model danych sklepu B2C opisuje twoją firmę: twoje produkty, twoje kategorie, twoje ceny. Model sklepu B2B musi opisać coś, nad czym nie masz żadnej kontroli - wewnętrzną strukturę firmy twojego klienta. A ta bywa inna u każdego z nich i zmienia się bez uprzedzenia.
Sklep stoi, działa, ma wszystkie funkcje. Adopcja jest niska, bo handlowcy dalej przyjmują zamówienia telefonicznie i nie kierują klientów do systemu. Nazywa się to oporem wobec zmiany. Jest to racjonalna reakcja na źle zaprojektowany bodziec.
Koszt PIM-a jest jedną liczbą w ofercie i widzą go wszyscy. Koszt braku PIM-a jest rozsiany po pięciu działach, nie ma własnej pozycji w budżecie i nikt go nigdy nie zsumował. Dlatego porównanie wychodzi zawsze tak samo - i zwykle błędnie.
Migracja jest wyceniana jak transport: mamy dane tu, chcemy je tam, policzmy godziny. Rachunek się nie zgadza, bo stary model danych nie jest opisem rzeczywistości - jest zapisem kompromisów podjętych pięć lat temu przez ludzi, którzy już tu nie pracują.
W harmonogramie UAT ma dwa tygodnie i wygląda na formalność - klient kliknie, zgłosi literówki, podpiszemy. W rzeczywistości to pierwszy moment, w którym prawdziwe dane spotykają model zaprojektowany trzy miesiące wcześniej na podstawie rozmów. I zwykle się nie zgadzają.
Typowe SLA mówi: sklep dostępny 99,9%, reakcja w cztery godziny. Zamówienia nie trafiają do ERP-a od wczoraj, ale sklep działa i pokazuje ładne potwierdzenia. Formalnie SLA jest dotrzymane. Realnie firma nie sprzedaje.
Klient B2C przegląda. Klient B2B wykonuje zadanie - to samo, które wykonał miesiąc temu i wykona za miesiąc. Ta jedna różnica przewraca do góry nogami wszystko, czego uczą poradniki o UX sklepów.
Projekty PIM rzadko przewracają się na technologii. Przewracają się na pytaniu, na które nikt nie chce odpowiedzieć w obecności całego zarządu: kto ma prawo zmienić opis produktu i czyja wersja wygrywa, gdy dwie osoby zmienią go tego samego popołudnia.
Headless jest dobrą odpowiedzią. Problem w tym, że odpowiada na pytanie „jak obsłużyć wiele frontów z jednego backendu", a większość sklepów B2B tego pytania nie zadaje - bo ma jeden front i będzie miała jeden front. Wtedy zostaje sam koszt.
Dokumentacja każdej globalnej platformy opisuje integrację z ERP tak, jakby po drugiej stronie było REST API z webhookami, sandboxem i nielimitowanym dostępem. W polskim B2B po drugiej stronie jest Subiekt ze Sferą, Comarch albo enova. To nie jest gorszy świat - to jest inny świat, którego te platformy nie widzą.
MVP zakłada, że możesz wybrać, co jest minimalne. W B2C to prawda - użytkownik przyjdzie z ciekawości i wybaczy braki. W B2B minimalny zakres definiuje twój klient i jest nienegocjowalny, bo on ma już działający sposób kupowania: telefon do handlowca.
Dodanie cache zajmuje popołudnie i natychmiast widać efekt - listing ładuje się dwa razy szybciej, wszyscy zadowoleni. Zaprojektowanie unieważniania zajmuje tydzień i nie widać po nim nic. Dlatego pierwsze robi się zawsze, a drugie prawie nigdy.
Sklep wysyła zamówienie do ERP-a. ERP nie odpowiada w ciągu trzydziestu sekund. I teraz pytanie, na które trzeba odpowiedzieć w kodzie, a nie na spotkaniu: dokument powstał czy nie? Bez jednego pola w modelu danych poprawnej odpowiedzi nie ma.
Na wybór platformy idą miesiące, warsztaty i tabele porównawcze. Na decyzję o tym, czy sklep rozmawia z ERP-em synchronicznie czy przez kolejkę, idzie zwykle jedno zdanie w dokumentacji technicznej. A to ta druga decyzja przesądza, czy w piątek o 17 sklep stoi.
Liczba SKU jest najczęściej podawaną i najmniej użyteczną miarą wielkości sklepu. Katalog 50 tysięcy produktów w B2C bywa prostszy niż katalog 3 tysięcy w B2B. Skala nie mieszka w liczbie wierszy - mieszka w liczbie kombinacji.
Nikt nie zarabia na tym, że zostajesz. Dlatego argumenty przeciw migracji rzadko padają na spotkaniu z agencją - nie ze złej woli, tylko dlatego, że firma od migracji widzi problemy, które migracja rozwiązuje. Pięć sytuacji, w których migracja jest najdroższym sposobem na nierozwiązanie problemu.
„Nasz ERP ma API" to zdanie, po którym zbyt wiele wycen idzie w dół. Istnienie API nie mówi nic o tym, czy da się na nim zbudować sklep - mówi tylko, że istnieje dokument z listą endpointów. Sześć pytań, które oddzielają projekt sześciotygodniowy od sześciomiesięcznego.
Pomysł pojawia się w każdym projekcie i zawsze brzmi rozsądnie: „przeliczanie ceny przez ERP przy każdym produkcie jest wolne, przenieśmy część logiki do sklepu". To nie jest optymalizacja. To decyzja o tym, że za pół roku ktoś będzie ręcznie wystawiał korekty.
„Synchronizacja ma działać w czasie rzeczywistym" pada na każdym pierwszym spotkaniu i prawie nigdy nie jest wymaganiem. Jest skrótem myślowym, pod którym siedzą cztery różne rzeczy - a każda z nich ma inną cenę i inne rozwiązanie. Rozbicie tego skrótu to zwykle pierwsza rzecz, która ratuje budżet projektu.
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.
Pierwsze słowo na nowym blogu. Tu zbieram wnioski z wdrożeń e-commerce B2B - bez marketingowego lukru i bez listy "TOP 10 wtyczek do Shopify".