Portal czy aplikacja mobilna do zamówień B2B?

Ten poradnik dotyczy klientów dystrybutora lub producenta, którzy samodzielnie składają kolejne zamówienia. Osoba kupująca po stronie klienta może przygotować koszyk, a jej przełożony zatwierdzić go przed wysłaniem. Pracownik dostawcy obsługuje wyjątki, natomiast operator ERP rozlicza dane i dalszy przebieg zamówienia.

Nie zakładaj, że jedna osoba wykonuje wszystkie te czynności. Zapisz, kto może zobaczyć katalog, cenę, limit lub fakturę, kto zmienić adres dostawy, a kto zatwierdzić zakup. Oddziel też przedstawiciela dostawcy od kupującego. Aplikacja dla handlowców z integracją ERP ma innego użytkownika i nie zastępuje automatycznie kanału samoobsługi klienta.

Responsywny portal pozwala zaprojektować proces zamawiania w przeglądarce dla komputera i telefonu. Warto zacząć od niego, gdy klienci pracują przy biurku, zamawiają z historii lub listy produktów, a instalacja dodatkowego narzędzia nie rozwiązuje konkretnej przeszkody. Sam portal także wymaga sprawdzenia wygody na urządzeniach klientów.

Stopniowo rozbudowywane doświadczenie webowe zachowuje kanał przeglądarkowy i dodaje funkcje dopiero po potwierdzeniu potrzeby. Zespół powinien sprawdzić, czy wybrane funkcje działają w rzeczywistym środowisku użytkownika. Nie zakładaj jednakowej dostępności funkcji na każdej przeglądarce i każdym urządzeniu.

Dedykowana aplikacja mobilna jest kandydatem, gdy zamawianie to częsta czynność wykonywana w określonym otoczeniu, na przykład podczas sprawdzania półki magazynowej. Trzeba wykazać, co aplikacja ma ułatwić względem portalu, oraz uwzględnić instalację, dostęp do kont, aktualizacje i wsparcie. Sama etykieta „mobile” nie dowodzi, że klienci będą z niej korzystać.

Wpisz obserwacje z pracy kupujących, dostępne reguły i brakujące informacje. Tabela nie jest punktacją, w której liczba odpowiedzi „tak” automatycznie uzasadnia aplikację.

Jeśli nie znasz odpowiedzi, przypisz osobę, która ją ustali. Brak danych o instalacji nie oznacza gotowości klientów. Potrzeba skanowania również nie rozstrzyga z góry wyboru technologii.

Kupujący powinien rozumieć, czy zapisuje szkic, wysyła wniosek o akceptację, czy składa zamówienie przyjęte do realizacji. Zespół musi uzgodnić, który system rozstrzyga każdy z tych stanów. Może to być ERP albo inny uzgodniony system obsługi zamówień. Nazwij tę odpowiedzialność zamiast przypisywać ją interfejsowi.

Kontrakt powinien określać:

• Cenę i dostępność: skąd pochodzą, kiedy są sprawdzane oraz co dzieje się po zmianie między dodaniem produktu a potwierdzeniem zamówienia.
• Uprawnienia i zgodę: kto może złożyć zamówienie, kiedy potrzebne jest zatwierdzenie i jak sprawdzana jest aktualność praw konta.
• Powiązanie próby z zamówieniem: jak rozpoznajesz tę samą operację po ponowieniu, aby kolejne kliknięcie lub powrót sieci nie tworzyły niekontrolowanie drugiego zamówienia.
• Wynik nieznany: jak sprawdzić stan, gdy klient nie otrzymał odpowiedzi. Komunikat błędu po stronie telefonu nie dowodzi, że system odrzucił zamówienie.
• Uzgodnienie rozbieżności: kto porównuje stany kanału i systemu zamówień oraz obsługuje przypadek wymagający interwencji.
• Ścieżkę awaryjną: jak klient uzyska pomoc i jak pracownik powiąże zgłoszenie z istniejącą próbą, zamiast nieświadomie wprowadzić ją ponownie.

Przy słabej łączności można rozważyć przygotowanie lokalnego szkicu, ale nie wolno przedstawiać go jako przyjętego zamówienia bez potwierdzenia właściwego systemu. Przed ponowieniem należy rozliczyć nieznany wynik poprzedniej próby. Sposób realizacji wymaga sprawdzenia API i reguł konkretnego produktu.

Szerszy kontekst połączeń systemów opisuje przewodnik integracji B2B z ERP i PIM. Wybór kanału klienta to osobna decyzja od wyboru architektury.

Aplikację warto porównać, gdy znasz powtarzalną czynność wykonywaną poza biurkiem, docelowe urządzenia i ograniczenie obecnej ścieżki. Potrzebujesz także właściciela integracji i wsparcia oraz uzgodnionego sposobu udostępniania aplikacji klientom. Te warunki pozwalają oceniać konkretny zakres, nie obiecują opłacalności.

Portal jest uprawnionym wynikiem, gdy dobrze obsługuje zamawianie z list i historii, użytkownicy nie mają powodu instalować aplikacji albo zespół nie jest gotowy utrzymywać drugiego kanału. Najpierw można poprawić istniejącą ścieżkę i sprawdzić pozostałe problemy. O funkcjach storefrontu przeczytasz w materiale o storefrontach B2B.

Wybierz reprezentatywne zadanie, rozpoznane role, produkty i klientów, którzy zgadzają się uczestniczyć. Przed rozpoczęciem ustal reguły cen, dostępność danych, uprawnienia, system przyjmujący zamówienia oraz osobę obsługującą błędy. Zaplanuj sprawdzenie przerw w łączności i ponowienia tej samej operacji.

Oceń, czy użytkownik kończy zadanie, gdzie potrzebuje pomocy, czy stany są zrozumiałe i czy zamówienia wymagają ręcznych korekt. Porównaj z dotychczasową ścieżką. Zapisz kryteria dalszej decyzji przed startem; ten poradnik nie podaje liczbowych progów sukcesu, budżetu ani czasu realizacji.

Ustal także warunki zatrzymania pilota. Powrót do poprzedniego kanału musi uwzględniać już wysłane lub przyjęte zamówienia, aby nie zgubić operacji ani nie zdublować ich podczas obsługi ręcznej.

To wymyślony scenariusz, nie projekt ani wynik GMI.

Klienci dystrybutora wysyłają listy produktów mailem. Pracownik przepisuje je do ERP, a część zamówień wraca do wyjaśnienia z powodu cen lub adresów. Kupujący zwykle przygotowują listę przy komputerze, a przełożony zatwierdza zakup. W tak opisanej sytuacji pierwszym wariantem do sprawdzenia jest portal z historią, cenami konta i uzgodnioną ścieżką akceptacji. Sam problem ręcznego przepisywania nie uzasadnia aplikacji.

Podczas rozmów pojawia się druga czynność: sprawdzanie braków na półce magazynowej i identyfikacja produktów. Najpierw trzeba sprawdzić to zadanie na sprzęcie użytkowników oraz ocenić wariant webowy. Jeśli pozostanie istotna przeszkoda, można porównać aplikację dla tego zakresu. Jeżeli nie wiadomo, który system potwierdza cenę i przyjmuje zamówienie, pilot transakcyjny wymaga najpierw rozstrzygnięcia tej odpowiedzialności.