Pytanie jest proste. Odpowiedź wymaga trzech osób
Wyobraźmy sobie dostawcę współpracującego z firmami mającymi kilka oddziałów. Osoba z zakupów pyta o termin zamówienia, księgowość prosi o dokument, a pracownik oddziału zgłasza zmianę adresu dostawy. Wszystkie wiadomości trafiają do jednego opiekuna, choć każda dotyczy innego fragmentu tej samej sprawy.
Opiekun potrafi odpowiedzieć, ale najpierw szuka informacji w systemie i dopytuje realizację. Klient czeka nie dlatego, że sytuacja jest trudna, lecz dlatego, że potrzebna informacja znajduje się po drugiej stronie telefonu. Portal ma usunąć tę zależność, nie przenieść na klienta pracy całego zespołu.
Co zatrzymuje pracę?
Punkt wyjścia
Dane dostępne, ale niezrozumiałe
Wewnętrzny status „etap 4” nie mówi klientowi, co dzieje się z zamówieniem. Pokazanie surowych danych z ERP nie tworzy jeszcze dobrej obsługi.
Dokument dla niewłaściwej osoby
W jednej organizacji pracują zakupy, księgowość i oddziały. Wspólne konto utrudnia kontrolę dostępu i ustalenie, kto zaakceptował zmianę.
Wiadomość bez kontekstu
Zgłoszenie „proszę poprawić dostawę” nie wskazuje zamówienia ani zakresu zmiany. Zespół zaczyna rozmowę od pytań, na które portal mógłby już znać odpowiedź.
Projekt zaczyna się od pytań, które klient zadaje najczęściej
Układamy pierwszą wersję wokół kilku zadań: sprawdzenia zamówienia, pobrania dokumentu, zgłoszenia uwagi i odnalezienia osoby kontaktowej. Każdy widok wyjaśnia, co wiadomo, czego brakuje i czy klient musi coś zrobić.
Dane pobieramy z ustalonego źródła, a przy statusie pokazujemy czas aktualizacji. Jeżeli integracja jest chwilowo niedostępna, portal informuje o tym wprost. Nie zamienia starej informacji w obietnicę aktualnego terminu.
Tak może wyglądać nowy obieg
Zaproś właściwe osoby
Konto należy do konkretnej osoby i organizacji. Ustalamy, kto może zapraszać współpracowników oraz jakie zamówienia, oddziały i dokumenty udostępnia każda rola.
Pokaż sytuację w języku klienta
Lista zamówień prezentuje rozpoznawalny numer, etap, termin i najbliższą czynność. Szczegóły wyjaśniają różnicę między terminem planowanym a potwierdzonym i pokazują historię zmian.
Dołącz dokument do sprawy
Dokumenty mają typ, datę i wersję. Klient pobiera właściwy plik z zamówienia, zamiast przeszukiwać ogólny katalog lub prosić opiekuna o ponowne przesłanie.
Przekaż pytanie z pełnym kontekstem
Zgłoszenie zawiera powiązanie z zamówieniem i temat. Wewnętrzna kolejka pokazuje odpowiedzialną osobę, a klient widzi potwierdzenie przyjęcia oraz kolejne odpowiedzi w jednym wątku.
Dostęp to reguły biznesowe, nie tylko ekran logowania
Dwie osoby używające tego samego portalu nie powinny automatycznie widzieć tych samych danych. Projektujemy granice organizacji, oddziałów i ról, a uprawnienia sprawdzamy również po stronie serwera. Zaproszenie nowego użytkownika i odebranie dostępu osobie odchodzącej z firmy są pełnoprawnymi elementami procesu, nie zadaniami do wykonania poza systemem.
- Zakupy mogą przeglądać zamówienia swojej organizacji.
- Księgowość może mieć dostęp do dokumentów rozliczeniowych bez prawa zmiany dostawy.
- Administrator klienta zarządza użytkownikami wyłącznie w uzgodnionym zakresie.
Samoobsługa nie może kończyć się ślepą uliczką
Klient czasem potrzebuje pilnej rozmowy, a czasem nie znajdzie dokumentu, ponieważ sprawa jeszcze nie została zsynchronizowana. Dlatego widok bez danych wyjaśnia możliwą przyczynę i podaje następny krok. Powiadomienia wysyłamy o istotnych zmianach, a nie o każdej operacji technicznej. Na telefonie najważniejsze zadania pozostają dostępne bez przewijania szerokiej tabeli.
Zacznijmy od jednego działającego fragmentu.
Pierwszy etap może być portalem tylko do odczytu dla wybranej grupy klientów: zamówienia, statusy i dokumenty plus formularz zgłoszenia. Tak sprawdzimy jakość danych i zrozumiałość interfejsu, zanim dopuścimy zmiany zamówień, indywidualne cenniki lub samodzielne składanie zleceń. Pilotaż wymaga opiekuna po stronie firmy i uzgodnionej grupy użytkowników.
Po czym poznamy, że jest lepiej?
To plan pomiaru, nie obietnica wyniku. Punkt odniesienia ustalamy przed wdrożeniem.
Powtarzalne pytania do opiekuna
Porównujemy rodzaje kontaktów przed i po uruchomieniu portalu. Sprawdzamy zwłaszcza pytania o status i ponowne przesłanie dokumentu, z uwzględnieniem liczby aktywnych zamówień.
Samodzielne wykonanie zadania
Podczas testów obserwujemy, czy klient potrafi znaleźć konkretny dokument i sprawdzić termin. Liczba założonych kont nie pokazuje, czy portal jest użyteczny.
Aktualność informacji
Kontrolujemy opóźnienia synchronizacji i przypadki niezgodności z systemem źródłowym. To ważniejsze niż atrakcyjny dashboard pokazujący dane, którym użytkownik nie może zaufać.
Pytania, które warto zadać
Czy portal B2B musi być sklepem internetowym?
Nie. Może służyć obsłudze już istniejących zamówień i wymianie dokumentów. Koszyk, płatności i katalog produktów dodajemy wtedy, gdy odpowiadają sposobowi współpracy z klientami, a nie dlatego, że zwykle występują w systemach B2B.
Czy klient musi instalować aplikację?
Portal może działać w przeglądarce na komputerze i telefonie. Przy projektowaniu sprawdzamy konkretne zadania mobilne, takie jak sprawdzenie dostawy czy pobranie dokumentu. Powiadomienia i ewentualny tryb aplikacji dobieramy do rzeczywistych potrzeb użytkowników.
