Kluczowe wnioski
- Pierwsza wersja ma obsłużyć najczęstsze zamówienie najlepszego klienta od początku do końca, bez ratowania się mailem, a nie każdy możliwy przypadek z ostatnich pięciu lat.
- Sześć elementów minimum: konto z przypisanymi warunkami, katalog z cenami po zalogowaniu, szybkie zamawianie, historia zamówień i dokumentów, statusy realizacji, jednostki i opakowania zbiorcze.
- Konfiguratory, wielopoziomowe akceptacje, struktury wielooddziałowe i aplikacja mobilna to zwykle dobre funkcje w złym momencie. Obsłuż te przypadki poza systemem i wróć do nich po starcie.
- Pierwszą grupę klientów wybierasz po powtarzalności zamówień i porządku w warunkach, a nie po wielkości obrotu. Kilku do kilkunastu kontrahentów wystarczy, żeby zobaczyć, co nie działa.
Diagnoza z poprzedniego rozdziału daje listę problemów i cztery zapisane odpowiedzi. Teraz trzeba z nich wyciąć zakres, czyli zdecydować, co powstaje najpierw. To moment, w którym najczęściej wykoleja się cały projekt, i rzadko z powodów technicznych.
Wykoleja się dlatego, że zespół próbuje odwzorować w systemie wszystko, co dziś robi handlowiec, razem z wyjątkami zdarzającymi się dwa razy w roku. Efekt: zakres, którego nie da się domknąć, i portal zamówień B2B, który wchodzi na produkcję o rok później, niż powinien, w wersji nadal niegotowej.
Zasada zakresu: najczęstsze zamówienie najlepszego klienta
Weź kilku klientów z pierwszej dziesiątki i rozpisz krok po kroku, jak wygląda ich typowe zamówienie. Nie to najbardziej skomplikowane, tylko to, które powtarza się co tydzień albo co dwa tygodnie. Rozpisz je w punktach:
- Zawartość: ile pozycji ma zamówienie i w jakich jednostkach.
- Kody: czy klient posługuje się własnymi indeksami, czy Waszymi.
- Dostępność: skąd dziś wie, czy towar jest na stanie.
- Cena: w którym momencie o nią pyta i kogo.
- Po złożeniu: co dzieje się z zamówieniem i jakich dokumentów klient potrzebuje na koniec.
Ten jeden scenariusz jest miarą zakresu pierwszej wersji: ma zadziałać w całości, od zalogowania do faktury, bez ratowania się telefonem czy mailem w środku.
Kryterium akceptacji jest równie proste i warto zapisać je jednym zdaniem: klient składa swoje typowe zamówienie sam, a zamówienie trafia do systemu firmy bez przepisywania przez człowieka. Wszystko, co nie jest potrzebne do tego zdania, jest kandydatem do odłożenia.
Wyjątki nie znikają, tylko zostają przy handlowcu, tak jak dotąd, i to jest w porządku. Pierwsza wersja sklepu B2B nie ma zlikwidować obsługi ręcznej, tylko zdjąć z niej powtarzalny wolumen. Ta różnica decyduje o tym, czy projekt kończy się startem, czy kolejną rundą analizy.
Sześć elementów pierwszej wersji
Poniższe sześć rzeczy tworzy razem najmniejszy sensowny zakres. Każda obsługuje konkretny krok z rozpisanego scenariusza, żadna nie jest dodatkiem na później. Jeżeli któraś wypadnie, klient w połowie procesu i tak sięgnie po telefon, a wtedy cała reszta traci sens.
Konto klienta z przypisanymi warunkami
Podstawa całej konstrukcji: klient loguje się i jest rozpoznawany jako konkretny kontrahent, a nie jako anonimowy odwiedzający. Do konta przypisane są jego cennik, waluta, sposób i termin płatności, adresy dostawy oraz opiekun handlowy.
W pierwszej wersji wystarczy prosty wariant: kilku użytkowników po stronie klienta widzi to samo i ma te same uprawnienia. Rozdzielanie ról, budżetów i widoczności między osobami w firmie klienta to potrzeba realna, ale rzadka na starcie, a potrafi podwoić czas budowy.
Katalog z cenami widocznymi po zalogowaniu
Katalog w hurcie działa inaczej niż w detalu. Klient nie przegląda, tylko szuka konkretu, więc najważniejsze jest wyszukiwanie po indeksie, kodzie EAN i po własnym kodzie klienta, jeśli takie kody u Was funkcjonują. Filtry mają odpowiadać parametrom technicznym, a nie inspiracjom.
Ceny pokazujesz po zalogowaniu i zawsze te przypisane do konta. Cena widoczna publicznie to w hurcie zwykle problem handlowy, a cena niezgodna z ustaleniami to problem większy. Zdjęcia są mile widziane, ale kompletne dane i jednostki są ważniejsze.
Szybkie zamawianie: lista zakupowa, powtórzenie, import z pliku
To jest serce pierwszej wersji i miejsce, w którym powstaje realna oszczędność czasu. Trzy mechanizmy załatwiają większość przypadków:
- Stała lista zakupowa: asortyment tego klienta z polami na ilości, gotowy do wypełnienia.
- Powtórzenie zamówienia: wcześniejsze zamówienie jako punkt wyjścia, z możliwością korekty.
- Import z pliku: wklejenie lub wgranie listy indeksów i ilości, najczęściej prosto z arkusza, w którym klient i tak układa zapotrzebowanie.
Przy imporcie zadbaj o mapowanie kodów własnych klienta i o czytelny raport pozycji, których system nie rozpoznał. To ten raport decyduje, czy klient spróbuje drugi raz.
Historia zamówień i dokumentów
Klient musi znaleźć u siebie to, o co dziś pyta biuro: zamówienia z ostatnich miesięcy, faktury i dokumenty magazynowe do pobrania, wyszukiwanie po numerze, dacie i indeksie.
To jedyny element z tej szóstki, który odciąża nie handlowca, lecz administrację, i zwykle najszybciej to widać. Historia jest przy okazji paliwem dla mechanizmu powtarzania zamówień, więc te dwie funkcje warto planować razem, a nie jako osobne pozycje na liście.
Statusy realizacji
Pytanie „co z moim zamówieniem” jest, zaraz po pytaniu o dostępność, drugim najczęstszym powodem kontaktu. Pokaż status w krokach, które naprawdę istnieją w Waszym procesie i które umiecie odczytać z systemu: przyjęte, w kompletacji, wysłane z numerem przesyłki, zafakturowane.
Nie wymyślaj statusów, których nie ma w danych, i nie obiecuj precyzji, której nie utrzymacie. Status pokazywany raz na dobę, ale zgodny z rzeczywistością, jest lepszy niż status aktualizowany na żywo, któremu klient przestaje ufać po pierwszej rozbieżności.
Jednostki i opakowania zbiorcze
Najczęstsze źródło wpadek przy wdrożeniach i element, którego nie da się odłożyć. System musi rozumieć trzy rzeczy:
- Krotności opakowań: produkt sprzedaje się w opakowaniach po dwanaście sztuk, karton to sześć takich opakowań, a paleta ma swoją krotność.
- Zaokrąglanie w górę: zamówienie na dwadzieścia sztuk zamienia się w pełne opakowania.
- Dwie jednostki naraz: ta, w której podana jest cena, i ta, w której klient myśli o zamówieniu, bo to nie zawsze jest to samo.
Wypisz te reguły przed budową, na papierze, dla każdej grupy asortymentu.
Sześć elementów wygląda skromnie i o to chodzi. Razem tworzą zamkniętą ścieżkę: klient loguje się, znajduje swoje pozycje po swoich kodach, widzi swoją cenę i dostępność, zamawia w prawidłowych jednostkach, sprawdza status i pobiera fakturę. Tak wygląda zakres, który zwykle domykamy w pierwszym etapie projektu i opisaliśmy go szerzej przy usłudze portal zamówień B2B.
Co świadomie zostawić na później
Odkładanie funkcji nie polega na tym, że o nich zapominasz. Polega na tym, że zapisujesz je na liście razem ze sposobem obsługi poza systemem, a wracasz po starcie, gdy będziesz mieć dane o rzeczywistym użyciu zamiast domysłów. Cztery obszary odkładamy w większości projektów:
- Konfiguratory i wyceny na żądanie. Produkty konfigurowalne wymagają spisanych reguł zależności, których zwykle nikt wcześniej nie spisał. Do czasu ich uporządkowania te zamówienia obsługuje handlowiec, tak jak dziś.
- Wielopoziomowe akceptacje po stronie klienta. Ścieżka zamawiający, przełożony, budżet i limity per użytkownik to osobny projekt. Na start jedno konto zamawia, a wewnętrzne zatwierdzanie zostaje procesem klienta, poza Waszym systemem.
- Rozbudowane struktury organizacyjne. Centrala z filiami, wspólny limit dzielony na oddziały, osobne cenniki per oddział. W pierwszej wersji wystarczy jeden kontrahent z kilkoma adresami dostawy.
- Aplikacja mobilna. Dobrze działający widok w przeglądarce na telefonie obsługuje magazyniera z listą i przedstawiciela w terenie. Aplikacja natywna to osobny produkt, z własnym utrzymaniem i własnym cyklem wydawniczym.
Do tej listy dochodzą zwykle rozbudowane promocje, zestawy i gratisy progowe oraz samoobsługowa rejestracja nowych kontrahentów z weryfikacją i przyznawaniem warunków.
Reguła odrzucania jest jedna i warto stosować ją bez wyjątków: jeżeli funkcja obsługuje przypadek, który zdarza się kilka razy w miesiącu, a jego brak da się obsłużyć telefonem albo mailem, to nie jest funkcja pierwszej wersji.
Każdy wyjątek dopisany do pierwszej wersji przesuwa dzień, w którym pierwszy klient złoży zamówienie sam. A dopiero od tego dnia zaczynacie uczyć się z prawdziwych danych, zamiast zgadywać na spotkaniach. Dlatego wyjątki zapisujcie na liście, a nie w zakresie, i wracajcie do niej po kilku tygodniach realnego użycia. Zwykle połowa pozycji okazuje się wtedy niepotrzebna, a jedna, o której nikt nie pomyślał, okazuje się pilna.
Jak wybrać pierwszą grupę klientów
Pierwsza wersja nie rusza dla całego rynku. Rusza dla kilku do kilkunastu kontrahentów, wybranych celowo. Dobrego kandydata poznasz po czterech cechach:
- Zamawia często i powtarzalnie: szybko zobaczysz, czy powtarzanie zamówień i import z pliku faktycznie działają.
- Ma uporządkowane warunki: jeden cennik, bez ustnych wyjątków dopisywanych przy każdym zamówieniu. Inaczej zamiast platformy będziesz debugować cennik.
- Ma konkretną osobę od zamówień: kogoś, kto odpowiada za zakupy, a nie rozmytą procedurę.
- Jest z Wami blisko: powie wprost, co go irytuje, zamiast po cichu wrócić do maila.
Świadomie omijaj dwa skrajne przypadki. Największego klienta, przy którym każdy błąd jest kosztowny, a rozmowa o testowaniu niezręczna, zapraszasz w drugiej kolejności, gdy proces jest już przewidywalny. Klienta zamawiającego raz na kwartał też zostaw na potem, bo nie zbierzesz od niego wystarczająco dużo obserwacji, żeby cokolwiek poprawić.
Handlowiec opiekujący się wybraną grupą powinien wiedzieć, że jego rola na tym etapie się nie kończy, tylko zmienia: to on jest pierwszą linią wsparcia i to on wychwyci rzeczy, których nie widać w logach.
Kiedy zakres jest domknięty
Zakres jest gotowy do wyceny i budowy, gdy prawdziwe są cztery zdania:
- Scenariusz jest rozpisany: najczęstsze zamówienie masz na papierze, w krokach, i zgadza się z tym, co powie handlowiec zapytany bez przygotowania.
- Dane mają właściciela: dla każdego kroku wiadomo, skąd bierze się dana i który system za nią odpowiada.
- Wyjątki mają obejście: każda pozycja z listy odłożonej na później ma zapisany sposób obsługi poza systemem, więc nikt nie odkryje jej w panice tydzień po starcie.
- Pilotaż ma adresatów: pierwsza grupa klientów jest wskazana z nazwy, razem z osobą, która się z nimi skontaktuje.
Jeżeli któreś zdanie nie jest prawdziwe, brakującym elementem prawie zawsze okazuje się to samo: nie wiadomo dokładnie, skąd bierze się cena dla konkretnego klienta w konkretnym momencie. To najtrudniejsza część całego przedsięwzięcia i jednocześnie ta, która najbardziej odróżnia sprzedaż hurtową od detalicznej. O modelowaniu cenników, rabatów i warunków handlowych jest następny rozdział.
Pytania
Czy pierwsza wersja musi mieć płatności online?
W hurcie zwykle nie. Dominującym modelem jest przelew z odroczonym terminem w ramach limitu kupieckiego, więc platforma ma przede wszystkim pokazać warunki płatności przypisane do konta i wystawić właściwe dokumenty. Płatność online bywa przydatna dla nowych kontrahentów bez historii i dla zamówień poza limitem, ale to funkcja, którą spokojnie dokładasz później, gdy zobaczysz, jak często taki przypadek naprawdę występuje.
Co zrobić z klientami, którzy przysyłają zamówienia w arkuszu z własnymi kodami?
To argument za importem koszyka z pliku, a nie przeciwko niemu. Klient dalej pracuje w swoim arkuszu, a platforma przyjmuje ten plik, mapuje jego kody na Wasze indeksy i pokazuje raport pozycji, których nie rozpoznała. Jeśli jednak tak zamawia jeden klient na trzydziestu, zostaw go przy handlowcu i wróć do tematu po starcie, kiedy będziesz mieć porównanie z rzeczywistym użyciem pozostałych funkcji.
Ile powinna trwać budowa pierwszej wersji?
Zamiast pytać o czas, ustal punkt odcięcia zakresu, bo to zakres decyduje o kalendarzu, a nie odwrotnie. Pierwsza wersja opisana w tym rozdziale jest projektem liczonym w tygodniach, pod warunkiem że warunki handlowe są uporządkowane, a dane produktowe i stany mają jedno źródło prawdy. Gdy któregoś z tych warunków brakuje, dłużej trwa właśnie ta praca, nie budowa interfejsu, i lepiej zaplanować ją osobno, niż udawać, że rozwiąże się po drodze.