Hurtownia może mieć prosty katalog produktów i bardzo złożony sposób sprzedaży. Ten sam towar ma inną cenę dla różnych kontrahentów, zamówienie składa pracownik oddziału, a dostawa trafia pod adres, którego nie ma na fakturze. Portal B2B powinien rozumieć te zależności. Przeniesienie katalogu do przeglądarki nie wystarczy, jeśli handlowiec nadal musi poprawiać niemal każde zamówienie po telefonicznej rozmowie z klientem.
Najpierw przejdźcie przez kilka typów zamówień: zwykłe, wymagające zatwierdzenia i takie, którego nie da się zrealizować w całości. Zapiszcie, co klient może wybrać sam, a co wymaga decyzji firmy. To pozwala określić rolę portalu w pracy handlowca. Narzędzie może odciążyć powtarzalne czynności, nie musi natomiast udawać, że negocjacje i wyjątkowe warunki da się zawsze zamknąć w jednym przycisku „kup”.
Cennik jest informacją przypisaną do relacji
Przed projektowaniem listy produktów ustalcie, skąd pochodzi cena i kiedy obowiązuje. Czy portal pokazuje kwotę z systemu handlowego, wynik reguły rabatowej czy indywidualną ofertę? Co wydarzy się, gdy cena zmieni się między dodaniem produktu do koszyka a zatwierdzeniem zamówienia? Odpowiedź powinna wynikać z zasad sprzedaży. Technologia może je wykonać, ale nie powinna wybierać ich przypadkiem podczas wdrażania integracji.
Te ustalenia prowadzą bezpośrednio do źródła prawdy dla danych. Potrzebny jest właściciel cennika, identyfikator kontrahenta oraz sposób powiązania oddziałów klienta. Jeśli organizacja działa w kilku lokalizacjach, przyda się również podejście opisane w tekście o systemie dla wielu oddziałów. Klient nie powinien otrzymywać dostępu do cudzych warunków tylko dlatego, że ktoś wpisał podobną nazwę firmy.
Dostępność produktu wymaga jasnego znaczenia
„Dostępne” może oznaczać stan fizyczny, stan pomniejszony o rezerwacje albo możliwość sprowadzenia towaru. Portal powinien używać komunikatu odpowiadającego rzeczywistym zobowiązaniom hurtowni. Jeżeli potwierdzenie terminu wymaga kontaktu, pokażcie to przed wysłaniem zamówienia. W przeciwnym razie automatyzacja przeniesie pracę z przyjmowania zamówień na wyjaśnianie rozczarowań. Katalog z zielonymi znacznikami nie jest jeszcze wiarygodną informacją o możliwości realizacji.
Zastanówcie się także nad zamówieniem częściowym, zamiennikiem i brakiem jednej pozycji. Klient może chcieć poczekać na komplet albo odebrać towar w kilku dostawach. Aplikacja potrzebuje informacji o decyzji, a magazyn musi ją odczytać w swoim obiegu. Przy projektowaniu połączenia portalu z systemami firmy warto więc przejść całą ścieżkę realizacji, zamiast kończyć analizę na momencie zapisania koszyka.
Po zakupie może pojawić się osobny proces zwrotu towaru do dostawcy i potwierdzenia przyjętej ilości.
Konto klienta może mieć więcej niż jednego użytkownika
W jednej organizacji ktoś przygotowuje zamówienie, ktoś je zatwierdza, a jeszcze ktoś sprawdza dokumenty. Warto ustalić te role i granice dostępu. Nie każdy użytkownik potrzebuje prawa do zmiany danych rozliczeniowych lub przeglądania wszystkich oddziałów. Czytelny podział pomaga też handlowcowi, bo wiadomo, kto może podjąć decyzję przy nietypowym zamówieniu. Wspólne hasło krążące między pracownikami nie rozwiązuje tego problemu; raczej skutecznie zaciera historię.
Historia powinna obejmować stan sprawy oraz uzgodnione zmiany. Klient potrzebuje odnaleźć potwierdzenie, dokument i kontakt do właściwej osoby. Firma potrzebuje zobaczyć, dlaczego zamówienie utknęło. Tak zebrane informacje mogą później zasilać dashboard sprzedaży, lecz najpierw muszą mieć spójne definicje. Liczba utworzonych koszyków nie jest automatycznie liczbą przyjętych zamówień, a złożenie zamówienia nie musi oznaczać jego realizacji.
Pierwszy etap odbierz na zamówieniach, nie na widokach
Warto ułatwić także ponowienie wcześniejszego zamówienia, ale bez bezmyślnego kopiowania dawnych warunków. Portal powinien ponownie sprawdzić aktualną ofertę, dostępność i uprawnienia użytkownika. Klient zyskuje krótszą ścieżkę, a firma nie musi później wyjaśniać, dlaczego stara cena lub wycofany produkt pojawiły się w nowym zleceniu. To dobry przykład funkcji, która wygląda prosto, lecz potrzebuje jasno opisanych reguł.
Do odbioru portalu przygotujcie konta z różnymi uprawnieniami, cennikami i warunkami dostawy. Sprawdźcie zwykły zakup, brak towaru, zmianę ceny i niedostępność połączenia. Ważne jest, czy informacja przechodzi do realizacji oraz czy można wyjaśnić nieudany przypadek. Piękna karta produktu nie wynagrodzi sytuacji, w której kontrahent otrzyma potwierdzenie, a magazyn nie zobaczy żadnego zlecenia.
Zanim porównacie wyceny aplikacji, ustalcie, które zależności mają wejść do pierwszego etapu. Można zacząć od wybranej grupy klientów lub produktów, pod warunkiem że obsługiwana ścieżka jest kompletna. Archifutura pomaga projektować portale i aplikacje dla firm wokół tych reguł. Dobry portal B2B daje klientowi samodzielność tam, gdzie ma ona sens, a zespołowi pozostawia jasną kontrolę nad sprawami wymagającymi decyzji.
