E-mail i arkusz są elastyczne. Handlowiec może poprawić nazwę produktu, dopytać o ilość i dopisać wyjątek. Ta elastyczność ma jednak koszt: zamówienie trzeba odczytać, zinterpretować, przepisać, potwierdzić i później odpowiadać na pytania o realizację.
Przeniesienie procesu do portalu nie polega na skopiowaniu arkusza do przeglądarki. Najpierw trzeba oddzielić powtarzalne reguły od wyjątków, ustalić źródła danych i zaprojektować czytelną ścieżkę dla sytuacji, których system nie może rozstrzygnąć automatycznie.
Zmierz, gdzie naprawdę powstaje praca
Przez kilka tygodni sklasyfikuj przychodzące zamówienia i pytania. Zapisuj nie tylko kanał, ale także przyczynę ręcznej obsługi:
- brak jednoznacznego indeksu produktu,
- nieaktualna cena w pliku klienta,
- nietypowa jednostka lub ilość minimalna,
- kilka adresów dostawy,
- konieczność zatwierdzenia przez inną osobę,
- brak stanu lub terminu,
- prośba o powtórzenie wcześniejszego zamówienia,
- pytanie o status i dokumenty.
Taki rejestr pokazuje, które funkcje portalu usuną najwięcej powtarzalnej pracy, a które wyjątki powinny nadal trafiać do człowieka.
Nie automatyzuj nieustalonego procesu
Jeżeli dwie osoby inaczej interpretują ten sam arkusz, portal nie rozwiąże problemu samym formularzem. Wymagane są uzgodnienia dotyczące identyfikatorów, jednostek, cenników, limitów i odpowiedzialności za dane.
Przed wdrożeniem odpowiedz:
- który system potwierdza cenę,
- gdzie sprawdzana jest dostępność,
- kiedy zamówienie staje się wiążące,
- kto rozstrzyga odrzuconą pozycję,
- jak obsłużyć część zamówienia,
- jaki komunikat otrzyma klient przy wyjątku.
Portal powinien jasno odróżniać przyjęcie zgłoszenia od potwierdzenia zamówienia w ERP.
Wybierz dobry proces pilotażowy
Najlepszy pilot jest częsty, powtarzalny i ma ograniczoną liczbę wyjątków. Może obejmować wybraną grupę produktów, klientów albo jeden model zamówienia. Dzięki temu można zweryfikować dane i integrację bez jednoczesnego odwzorowania całego regulaminu sprzedaży.
Przykładowy zakres:
- klient loguje się do swojej organizacji,
- wybiera pozycje z wcześniejszego zamówienia,
- portal sprawdza aktualne warunki,
- klient koryguje ilości i adres,
- zamówienie trafia do integracji,
- ERP potwierdza albo zwraca błąd,
- portal pokazuje wynik i późniejszy status.
Zobacz portal klienta z historią i ponawianiem zamówień →
Dane, których portal potrzebuje
Dla podstawowego procesu potrzebne są co najmniej: kontrahent, użytkownik, produkt, jednostka, cena lub reguła jej pobrania, adres dostawy, zamówienie i status. Każdy obiekt powinien mieć stabilny identyfikator używany również podczas ponowienia żądania.
Jeśli ceny lub stany zmieniają się często, określ dopuszczalny czas ich aktualności. Portal powinien pokazać, czy dana wartość jest informacją bieżącą, ostatnim potwierdzonym stanem czy wymaga weryfikacji po wysłaniu.
Co zrobić z wyjątkami
Nie każdy wyjątek wymaga rozbudowanej reguły w pierwszej wersji. Portal może przekazać sprawę do obsługi wraz z kompletnym kontekstem: klientem, pozycjami, komunikatem ERP i historią prób. Ważne, aby użytkownik wiedział, że sprawa wymaga interwencji i nie wysyłał tego samego zamówienia wielokrotnie.
Lista wyjątków powinna mieć właściciela, priorytet i status. Monitoring techniczny informuje, że integracja nie działa; kolejka operacyjna mówi zespołowi, które zamówienie klienta wymaga działania.
Historia i dokumenty domykają samoobsługę
Po złożeniu zamówienia klient chce wiedzieć, co dzieje się dalej. Jeśli portal kończy się na przyjęciu koszyka, pytania nadal trafiają do handlowca. Dlatego projektuj cały minimalny cykl:
- przyjęcie i potwierdzenie,
- czytelne statusy,
- realizacja częściowa,
- wysyłka lub odbiór,
- dokumenty udostępnione po realizacji,
- możliwość ponowienia zakupu.
Jak mierzyć rezultat pilota
Nie zakładaj z góry konkretnego procentu oszczędności. Zbierz punkt odniesienia przed uruchomieniem i porównaj go z pilotem. Przydatne miary to:
- liczba zamówień obsłużonych portalem,
- odsetek zamówień wymagających interwencji,
- rodzaje najczęstszych wyjątków,
- czas od wysłania do potwierdzenia,
- liczba pytań o status i dokument,
- liczba aktywnych użytkowników organizacji,
- porzucone próby i błędy integracji.
Interpretuj dane razem z zespołem obsługi. Spadek liczby e-maili jest wartościowy tylko wtedy, gdy klient potrafi samodzielnie zakończyć zadanie, a błędy nie przeniosły się do innej kolejki.
Migracja etapami
Nie wyłączaj dotychczasowego kanału pierwszego dnia. Zaproś grupę pilotażową, zbieraj problemy i porównuj zamówienia z ERP. Gdy kryteria odbioru są spełnione, rozszerzaj portal na kolejne segmenty oraz zachęcaj do korzystania z samoobsługi.
E-mail może pozostać kanałem dla wyjątków, ale nie powinien być równoległą, niekontrolowaną ścieżką dla standardowego zamówienia. Jasne reguły kanałów są równie ważne jak technologia.
Przygotuj specyfikację portalu klienta z checklistą wymagań →
