Historia zamówień jest jedną z pierwszych funkcji, o które proszą klienci B2B. Pozwala odnaleźć kupowane wcześniej produkty, sprawdzić realizację i pobrać dokument bez angażowania opiekuna handlowego. Technicznie nie jest jednak tylko tabelą z ERP.
Trzeba połączyć zamówienia z właściwą organizacją, przetłumaczyć statusy, kontrolować dostęp do dokumentów i jasno komunikować aktualność danych. Błąd w którymkolwiek z tych obszarów może pokazać użytkownikowi niepełną informację albo — co gorsza — dane innego kontrahenta.
Zacznij od pytań kierowanych do obsługi
Przed projektem ekranów zbierz rzeczywiste pytania z e-maili, rozmów i zgłoszeń. Zwykle dotyczą one kilku tematów:
- czy zamówienie zostało przyjęte,
- kiedy nastąpi wysyłka lub odbiór,
- które pozycje zrealizowano częściowo,
- jakie produkty klient kupował wcześniej,
- gdzie znaleźć fakturę, WZ lub potwierdzenie,
- czy wcześniejsze zamówienie można szybko powtórzyć.
Ta lista pomaga ustalić MVP. Jeżeli głównym problemem jest status i dokument, nie trzeba od razu budować kompletnego katalogu e-commerce.
Jaki zakres historii pokazać
„Wszystkie zamówienia klienta” brzmi prosto, ale wymaga doprecyzowania. Klient może mieć kilka numerów w ERP, wiele oddziałów albo historię przeniesioną ze starszego systemu. Ustal:
- okres udostępnianej historii,
- rodzaje dokumentów uznawanych za zamówienie,
- sposób łączenia konta portalu z kontrahentem,
- widoczność zamówień między oddziałami,
- obsługę korekt, anulowania i realizacji częściowej,
- zasady prezentacji danych archiwalnych.
W pilocie bezpieczniej jest rozpocząć od jednego, dobrze zidentyfikowanego segmentu klientów i ograniczonego okresu. Rozszerzenie zakresu po testach jest prostsze niż wycofywanie błędnie udostępnionych danych.
Status zrozumiały poza firmą
ERP może przechowywać wiele kodów technicznych i etapów wewnętrznych. Klient nie potrzebuje każdego z nich. Potrzebuje odpowiedzi, co dzieje się z jego zamówieniem i czy musi podjąć działanie.
Przygotuj mapowanie statusów, na przykład:
- przyjęte do weryfikacji,
- potwierdzone,
- w realizacji,
- częściowo zrealizowane,
- wysłane lub gotowe do odbioru,
- zakończone albo anulowane.
Przy statusie pokaż czas ostatniej synchronizacji. Gdy ERP jest chwilowo niedostępny, portal nie powinien udawać, że widoczny stan jest bieżący. Dla operacji zapisujących, takich jak ponowne zamówienie, można zastosować status „oczekuje na potwierdzenie” i przekazać wynik po przetworzeniu.
Dokument to zasób wymagający autoryzacji
Faktura lub WZ nie powinny być publicznym plikiem chronionym wyłącznie trudnym do odgadnięcia adresem. Przy każdej próbie pobrania system powinien sprawdzić:
- zalogowanego użytkownika,
- organizację i oddział,
- rolę uprawniającą do danego typu dokumentu,
- powiązanie dokumentu z zamówieniem klienta,
- aktualny stan konta i uprawnień.
Warto rejestrować pobranie dokumentów istotnych finansowo oraz zmiany uprawnień. Zakres logowania i retencję trzeba dopasować do ryzyka i zasad obowiązujących w firmie.
Ponowienie zamówienia nie jest kopią jeden do jednego
Historia naturalnie prowadzi do funkcji „zamów ponownie”. Portal może przenieść wcześniejsze pozycje do koszyka, ale przed zatwierdzeniem powinien sprawdzić aktualne dane:
- czy indeks nadal jest aktywny,
- czy zmieniła się jednostka lub minimalna ilość,
- jaka cena i rabat obowiązują dzisiaj,
- czy produkt jest dostępny,
- czy istnieje zamiennik,
- czy klient ma prawo zamówić do wybranego oddziału.
Różnice należy pokazać przed wysłaniem. Automatyczne odtworzenie dawnych warunków może prowadzić do błędnego oczekiwania klienta.
Integracja: odczyt, pamięć podręczna czy synchronizacja
Sposób dostępu do ERP zależy od możliwości systemu i wymaganego czasu odpowiedzi. Portal może pobierać dane na żądanie, utrzymywać kontrolowaną kopię potrzebnych rekordów albo łączyć oba podejścia.
Niezależnie od wariantu potrzebne są:
- stabilne identyfikatory zamówień i kontrahentów,
- walidacja danych wejściowych,
- odporność na duplikaty,
- kolejka i ponowne próby,
- monitoring opóźnień,
- procedura obsługi rekordu, którego nie udało się przetworzyć.
Przeczytaj o architekturze portalu B2B z ERP →
Scenariusze testowe przed pilotem
Nie ograniczaj testów do poprawnie zalogowanego klienta. Sprawdź także:
- bezpośredni adres zamówienia innej organizacji,
- próbę pobrania cudzego dokumentu,
- użytkownika po odebraniu roli,
- klienta powiązanego z kilkoma oddziałami,
- zamówienie bez dokumentu lub statusu,
- niedostępność ERP,
- powtórzone żądanie ponowienia,
- zmianę ceny i wycofany produkt.
Do pilota zaproś klientów o różnych modelach pracy. Ich zadaniem nie jest tylko znalezienie błędów, lecz również ocena, czy opis statusów i układ historii odpowiadają pytaniom, które rzeczywiście chcą rozwiązać.
Co powinno znaleźć się w MVP
Rozsądny pierwszy zakres to logowanie, konto organizacji, lista i szczegóły zamówień, zrozumiały status, czas aktualizacji oraz jeden lub dwa typy dokumentów. Ponowienie można dodać, gdy katalog, ceny i dostępność dają się wiarygodnie zweryfikować.
Tak zaprojektowana historia nie kopiuje całego ERP do przeglądarki. Jest kontrolowanym widokiem procesu klienta — z jasnym źródłem danych, uprawnieniami i zachowaniem w sytuacji błędu.
