Co zbudować najpierw: zakres pierwszej wersji

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, które zdarzają się dwa razy w roku. Efektem jest 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. Ile pozycji, jakie jednostki, czy klient używa własnych kodów, skąd wie o dostępności, kiedy pyta o cenę, co się dzieje po złożeniu zamówienia, jakich dokumentów 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 je zapisać 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 razem tworzą najmniejszy sensowny zakres. Każda z nich 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, bo cena widoczna publicznie w hurcie to 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, gdzie powstaje realna oszczędność czasu. Trzy mechanizmy załatwiają większość przypadków: stała lista zakupowa klienta z polami na ilości, powtórzenie wcześniejszego zamówienia z możliwością korekty oraz wklejenie lub wgranie pliku z indeksami i ilościami, 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ć. Przy okazji historia jest paliwem dla mechanizmu powtórzenia zamówienia, 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 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ć, że produkt sprzedaje się w opakowaniach po dwanaście sztuk, że karton to sześć takich opakowań, a paleta ma swoją krotność, oraz że zamówienie na dwadzieścia sztuk zaokrągla się w górę do pełnego opakowania. Do tego dochodzi jednostka, w której podana jest cena, i jednostka, w której klient myśli o zamówieniu, bo to nie zawsze 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 ją stosować 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.

Jak wybrać pierwszą grupę klientów

Pierwsza wersja nie rusza dla całego rynku. Rusza dla kilku do kilkunastu kontrahentów, wybranych celowo. Dobry kandydat zamawia często i powtarzalnie, więc szybko zobaczysz, czy mechanizm powtarzania i import z pliku faktycznie działają. Ma uporządkowane warunki, czyli jeden cennik bez ustnych wyjątków dopisywanych przy każdym zamówieniu, bo inaczej będziesz debugować cennik zamiast platformy. Ma po swojej stronie konkretną osobę odpowiedzialną za zamówienia, a nie rozmytą procedurę. I jest z Wami na tyle blisko, że 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 kolejce, 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. Najczęstsze zamówienie jest rozpisane w krokach, na papierze, i zgadza się z tym, co powie handlowiec zapytany bez przygotowania. Dla każdego kroku wiadomo, skąd bierze się dana i który system jest jej właścicielem. 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. 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ł.