Kiedy oddaję klientowi stronę, sklep albo system, nie chcę, żeby cała wiedza o jego działaniu została tylko w mojej głowie. Produkt jest przecież dla klienta i jego zespołu. To oni będą z niego korzystać w zwykły poniedziałek, podczas urlopu właściciela i wtedy, gdy pojawi się nietypowe zamówienie.
Dlatego przy bardziej rozbudowanych wdrożeniach powstaje osobna dokumentacja użytkownika. Nie jest to uniwersalna instrukcja WordPressa ani plik opisujący każdy przycisk. To baza wiedzy przygotowana pod konkretną firmę, jej proces i osoby, które będą z niego korzystać.
Nie chodzi o to, żeby klient już nigdy nie musiał do mnie dzwonić. Chodzi o to, żeby telefon był wyborem, a nie jedynym sposobem na wykonanie najprostszej czynności.
Instrukcja powinna opisywać prawdziwy dzień pracy
Najłatwiej przygotować dokumentację, która wygląda poprawnie, ale niewiele daje. Można opisać menu, zakładki i pola formularza. Tylko że użytkownik zwykle nie zastanawia się, gdzie znajduje się przycisk. Zastanawia się, co ma zrobić w konkretnej sytuacji.
- Czy to zamówienie jest już opłacone?
- Czy zmiana statusu wyśle wiadomość do klienta?
- Gdzie poprawić cenę, żeby synchronizacja jej nie nadpisała?
- Co sprawdzić, jeśli produkt nie pojawia się w wyszukiwarce?
- Kiedy można działać samodzielnie, a kiedy lepiej się zatrzymać?
Dobra dokumentacja zaczyna się właśnie od tych pytań. Powinna prowadzić przez decyzje, a nie tylko przez ekrany.
Zamów Lokalnie: ważniejsza jest decyzja niż kliknięcie
W systemie Zamów Lokalnie przygotowaliśmy instrukcję dla Cukierni Jagódka. System obsługuje wybór terminu i punktu odbioru, zamówienia, płatności, wiadomości e-mail oraz statusy widoczne dla klienta.
Samo pokazanie panelu nie wystarczyłoby. Najważniejsza wiedza dotyczy codziennego procesu:
- mail informuje, że wydarzyło się coś nowego,
- panel jest źródłem prawdy o zamówieniu,
- zamówienia nie należy realizować bez potwierdzonej płatności,
- status
Zrealizowanemożna ustawić dopiero wtedy, gdy zamówienie faktycznie jest gotowe do odbioru.
W instrukcji są screeny, pełny przebieg zamówienia, opis wiadomości e-mail, checklista i sytuacje awaryjne. Jest też krótka karta A4, którą można wydrukować i trzymać przy stanowisku pracy.
Szczególnie ważny jest moment zmiany statusu. Wybranie Zrealizowane, zapisanie statusu i potwierdzenie operacji powoduje wysłanie wiadomości do klienta. Dokumentacja nie mówi więc tylko, gdzie kliknąć. Wyjaśnia również skutek tej decyzji.
Dzięki temu osoba obsługująca zamówienia nie musi pamiętać wszystkiego po jednym szkoleniu. Może wrócić do instrukcji dokładnie wtedy, gdy pojawia się wątpliwość.
DAGMAR: kilka połączonych systemów, jedno miejsce z wiedzą
W sklepie internetowym DAGMAR wyzwanie jest inne. WooCommerce łączy się z Base.com i Subiektem, do tego dochodzą płatności, wysyłka, dane techniczne produktów oraz wyszukiwarka części według marki, modelu i rocznika samochodu.
Tutaj błąd nie musi wynikać z braku umiejętności. Czasem wystarczy poprawić właściwą informację w niewłaściwym systemie.
Dlatego już na początku dokumentacji znajduje się prosty podział:
- Base.com i Subiekt odpowiadają za dane handlowe, między innymi cenę i stan magazynowy,
- WooCommerce odpowiada za prezentację produktu, zdjęcia, opisy, SEO i dane techniczne,
- jeśli nie wiadomo, skąd pochodzi dana informacja, najpierw sprawdzamy synchronizację i nie zmieniamy jej w ciemno.
Dokumentacja zawiera też checklistę nowego produktu. Pracownik może po kolei sprawdzić SKU, kategorię, zdjęcia, dopasowanie do pojazdu, wagę paczki, sposób dostawy i płatność. Zamiast liczyć na pamięć, ma powtarzalny proces.
Całość działa jako osobna, chroniona hasłem strona z wyszukiwarką. Wiedza nie ginie w załączniku sprzed kilku miesięcy i można ją aktualizować razem z rozwojem sklepu.
Co powinna zawierać dokumentacja przygotowana dla klienta
Zakres zależy od produktu, ale najczęściej przygotowuję kilka warstw:
- Szybki start z najważniejszymi zasadami i codziennym procesem.
- Instrukcje krok po kroku ze screenami prawdziwego systemu.
- Reguły decyzyjne, które pokazują nie tylko jak wykonać akcję, ale też kiedy ją wykonać.
- Checklisty dla powtarzalnych zadań i kontroli jakości.
- Sytuacje awaryjne z opisem, co sprawdzić przed wprowadzeniem zmian.
- Krótki materiał do wydruku dla osób, które nie pracują cały dzień przy komputerze.
Dokumentacja powinna też jasno określać swój zakres. Nie ma udawać procedury operacyjnej całej firmy, jeśli opisuje tylko system. Ma pomóc użytkownikowi tam, gdzie technologia spotyka się z jego codzienną pracą.
Niezależność nie oznacza, że zostajesz sam
Dokumentacja nie zastępuje wsparcia. Sprawia natomiast, że klient nie jest uzależniony od dostępności jednej osoby i nie musi czekać z każdą drobną decyzją.
Ma to znaczenie również później. Do zespołu może dołączyć nowy pracownik. Osoba przeszkolona podczas wdrożenia może zmienić stanowisko. System może dostać nowe funkcje. Dobrze przygotowana baza wiedzy pozwala przekazać nie tylko dostęp do narzędzia, ale też sposób rozsądnego korzystania z niego.
Jeśli po wdrożeniu dostajesz tylko login i informację, że wszystko już działa, technicznie projekt może być skończony. Z perspektywy codziennej pracy często dopiero zaczyna się najważniejszy etap.
System jest Twój. Wiedza o nim również powinna być Twoja.
Jeśli planujesz nową stronę, sklep lub bardziej rozbudowany system, zobacz, jak tworzymy strony internetowe. Możesz też opowiedzieć nam o swoim projekcie, a wspólnie ustalimy nie tylko, co trzeba zbudować, ale też jak później wygodnie z tego korzystać.