Archifutura / Aeneia

Projektowanie aplikacji

Baza pytań dla obsługi klienta: jak aktualizować odpowiedzi po zmianie usługi

Jak przygotować i utrzymać bazę pytań klientów? Sprawdź źródła odpowiedzi, odpowiedzialność za treść i aktualizację po zmianie usługi.

Tworzyliśmy rozwiązania dla

  • L'Oréal
  • Garnier
  • Netflix
  • Carrefour
  • Warner Bros. Discovery
  • Biedronka
  • HBO Max
  • Wolt
  • Żabka
  • COSRX
  • Mixa
  • Ambasada Chin w Polsce

Doświadczenie Aeneia, firmy stojącej za Archifutura.

Klient pyta, jak zmienić termin usługi. Na stronie widzi odpowiedź przygotowaną kilka miesięcy wcześniej, ale konsultant podaje inne zasady. Obie informacje mogły być kiedyś poprawne. Problem powstał wtedy, gdy zmienił się proces, a nikt nie sprawdził miejsc, w których odpowiedź była opublikowana.

Baza pytań dla obsługi klienta powinna pomagać znaleźć aktualną i zrozumiałą informację. Wymaga nie tylko listy pytań, lecz także właściciela odpowiedzi, źródła, sposobu przeglądu i procedury wycofania treści. Jeśli firma korzysta z kilku kanałów, warto ustalić, gdzie powstaje obowiązująca wersja oraz jak zmiany trafiają do pozostałych miejsc.

Jeżeli planujesz uporządkowanie bazy wiedzy, wyślij brief z opisem odbiorców, kanałów i przykładem pytania, na które dziś trudno znaleźć spójną odpowiedź. Nie przesyłaj danych klientów ani poufnych rozmów. Wystarczy fikcyjny scenariusz i informacja, kto odpowiada za aktualne zasady usługi.

Wybierz pytania z pracy zespołu

Wyobraźmy sobie firmę usługową, której klienci pytają o przygotowanie do wizyty, zmianę terminu i sposób otrzymania dokumentów. Konsultanci znają odpowiedzi, lecz część ustaleń znajduje się w wiadomościach, a część w instrukcji dla nowego pracownika. To przykład projektowy, nie opis konkretnej firmy. Zanim powstanie strona z FAQ, warto sprawdzić, jakie pytania rzeczywiście wracają i w jakim kontekście są zadawane.

Zespół może przejrzeć zgłoszenia, rozmowy z konsultantami i pytania zadawane podczas wdrożenia klienta. Trzeba przy tym określić zakres dostępu oraz usunąć zbędne dane osobowe z materiału wykorzystywanego do pracy redakcyjnej. Celem nie jest opublikowanie cudzej wiadomości, lecz rozpoznanie problemu, który odpowiedź ma wyjaśnić.

Jedno pytanie zapisane w systemie może obejmować kilka różnych sytuacji. „Jak zmienić termin?” wymaga doprecyzowania, czy chodzi o wizytę już potwierdzoną, propozycję terminu czy usługę realizowaną przez partnera. Jeśli zasady się różnią, odpowiedź powinna pomóc rozpoznać właściwy przypadek. Nie trzeba zmuszać użytkownika do znajomości wewnętrznych nazw procesów, aby mógł znaleźć pomoc.

O drodze pojedynczego pytania od zgłoszenia do odpowiedzi piszemy w artykule o automatyzacji obsługi zapytań klientów. Baza odpowiedzi jest osobnym elementem: powinna wspierać pracownika i klienta także wtedy, gdy konkretna sprawa nie została jeszcze utworzona.

Ustal źródło i właściciela odpowiedzi

Każda ważna odpowiedź powinna mieć źródło oraz osobę, która potrafi potwierdzić jej poprawność. Może to być właściciel usługi, zespół operacyjny lub inna uprawniona osoba. Redaktor odpowiada za zrozumiały tekst, ale nie musi samodzielnie rozstrzygać zasad realizacji. Rozdzielenie tych ról ułatwia aktualizację, kiedy zmienia się proces.

Przy odpowiedzi zapiszcie, do jakiej usługi i grupy odbiorców się odnosi. Jeśli zasady zależą od umowy lub kanału zakupu, trzeba to jasno zaznaczyć. Nie warto tworzyć jednego uniwersalnego zdania, które brzmi pewnie, ale pomija wyjątki potrzebne klientowi. Jednocześnie nie każda odpowiedź musi zawierać całą wewnętrzną instrukcję. Ważne, aby prowadziła do właściwego działania.

Zadbajcie o możliwość dotarcia do źródła przez osoby uprawnione. Pracownik obsługi może potrzebować bardziej szczegółowej procedury niż klient odwiedzający stronę. Dostęp do dokumentu wewnętrznego nie powinien być automatycznie przekazywany odbiorcy zewnętrznemu. W artykule o uprawnieniach do dokumentów omawiamy tę granicę przy systemach korzystających z firmowej wiedzy.

Przy wielu systemach ustalcie, gdzie znajduje się odpowiedź źródłowa, a gdzie jej kopie. Portal klienta, panel konsultanta i strona publiczna mogą korzystać z różnych form prezentacji. Zespół powinien wiedzieć, jak aktualizacja dociera do każdego miejsca oraz kto sprawdza rezultat. O odpowiedzialności za dane piszemy w artykule o źródłach danych w integracji systemów.

Pisz pod pytanie, nie pod nazwę działu

Klient szuka odpowiedzi na własny problem. Może wpisać „nie mogę znaleźć potwierdzenia”, choć w organizacji temat nazywa się „obsługa dokumentów transakcyjnych”. Nazwa kategorii powinna pomagać odnaleźć właściwą informację. Zespół może zachować wewnętrzne oznaczenia w zapleczu, ale nie powinien wymagać od odbiorcy znajomości struktury firmy.

Odpowiedź dobrze zaczynać od czynności lub warunku potrzebnego w danej sytuacji. Jeśli użytkownik może sam sprawdzić status, pokażcie, gdzie to zrobić. Jeśli potrzebuje kontaktu z obsługą, wyjaśnijcie, jakie informacje pomogą znaleźć sprawę. Unikajcie zapewnień o terminach lub możliwościach, których nikt nie potwierdził w aktualnym procesie.

Przygotujcie krótką wersję odpowiedzi i dostęp do szczegółów wtedy, gdy są potrzebne. W prostym przypadku użytkownik nie musi czytać kilku ekranów o wszystkich wyjątkach. Przy bardziej złożonej sprawie powinien móc rozpoznać ograniczenia i dalszą drogę. Warto przetestować, czy odbiorca rozumie odpowiedź bez dodatkowego tłumaczenia przez jej autora.

Zespół może przygotować kilka wariantów pytania prowadzących do tej samej informacji, o ile opisują tę samą potrzebę. Nie trzeba tworzyć osobnej strony dla każdej drobnej odmiany zdania. Ważniejsze jest, aby wyszukiwanie lub nawigacja pomagały znaleźć odpowiedź, a aktualizacja jednej zasady nie wymagała poprawiania kilkunastu niespójnych kopii.

Zaplanuj wersję i przegląd

Przy każdej odpowiedzi przydatna jest informacja o stanie: robocza, zatwierdzona, wymagająca przeglądu albo wycofana. Nazwy zależą od sposobu pracy zespołu. Właściciel powinien wiedzieć, kto może zaproponować zmianę, kto sprawdza treść i kiedy nowa wersja trafia do użytkowników. Ważne jest również zachowanie związku z wcześniejszą wersją, jeśli pomaga wyjaśnić zgłoszenie klienta.

Zmiana usługi powinna uruchamiać przegląd powiązanych odpowiedzi. Przykładowo zmiana sposobu umawiania wizyty może dotyczyć instrukcji na stronie, tekstu używanego przez konsultanta i wiadomości wysyłanej po zgłoszeniu. Lista zależności pomaga sprawdzić wszystkie miejsca. Bez niej zespół łatwo poprawi najczęściej odwiedzaną stronę, zostawiając starszy tekst w automatycznej wiadomości.

Nie każda treść wymaga tego samego terminu przeglądu. Informacja zależna od często zmieniającego się procesu może potrzebować innego rytmu niż opis stałej funkcji aplikacji. Właściciel powinien ustalić go na podstawie rzeczywistych zmian oraz ryzyka błędu. Samo wpisanie daty do kalendarza nie zapewnia aktualności, jeśli nikt nie ma obowiązku wykonać kontroli.

Gdy odpowiedź jest nieaktualna, zespół potrzebuje sposobu jej wycofania lub zastąpienia. Użytkownik nie powinien trafiać na tekst, który sugeruje możliwość wykonania nieistniejącej czynności. Jeśli nowa zasada nie została jeszcze potwierdzona, lepiej skierować do właściwego kanału pomocy niż publikować domysł. Zapiszcie również, kto podejmuje decyzję o powrocie treści do publikacji.

Zadbaj o wyszukiwanie i kontekst

Użytkownik może szukać odpowiedzi po nazwie usługi, czynności albo komunikacie, który zobaczył w aplikacji. Sprawdźcie, jakie określenia pojawiają się w zgłoszeniach i czy prowadzą do właściwej treści. Warto uwzględnić naturalne odmiany słów oraz pytania z brakującym kontekstem. Mechanizm powinien też wyraźnie pokazywać, gdy nie znalazł odpowiedzi.

Jeśli wyszukiwarka zwraca kilka podobnych wyników, tytuł i krótki opis powinny pomóc rozpoznać różnicę. Dwa artykuły nazwane „zmiana terminu” mogą dotyczyć różnych usług albo etapów realizacji. Dodatkowa informacja w tytule lub opisie często ułatwia wybór bardziej niż rozbudowany filtr, którego znaczenia użytkownik nie zna.

Przy połączeniu bazy z asystentem AI należy zachować źródło odpowiedzi oraz kontrolę dostępu. System nie powinien przedstawiać informacji z nieaktualnego dokumentu jako obowiązującej tylko dlatego, że dobrze pasuje do pytania. W artykule o asystencie AI do firmowej wiedzy opisujemy znaczenie odpowiedzi prowadzącej do źródła. Przy reklamacji zespół powinien dodatkowo oddzielić roboczy szkic odpowiedzi od decyzji firmy.

Jeśli asystent nie znajduje odpowiedzi albo materiały są sprzeczne, proces powinien przewidzieć przekazanie sprawy do pracownika. Użytkownik potrzebuje informacji, co może zrobić dalej. Nie każdy brak w bazie jest problemem modelu; czasem organizacja nie uzgodniła jeszcze odpowiedzi albo przechowuje ją w miejscu niedostępnym dla danego procesu.

Sprawdź treść na rzeczywistych zadaniach

Przygotujcie fikcyjne scenariusze oparte na pytaniach klientów. Poproście uczestnika o znalezienie odpowiedzi i wykonanie kolejnego kroku. Następnie sprawdźcie, jak rozumie warunki, czy zauważa wyjątek oraz czy wie, kiedy potrzebny jest kontakt z obsługą. Nie podpowiadajcie od razu, gdzie znajduje się właściwy artykuł.

W próbie powinna uczestniczyć również osoba z zespołu obsługi, która sprawdzi zgodność tekstu z aktualną procedurą. Jeśli odpowiedź odsyła do formularza lub innego systemu, test powinien objąć całą ścieżkę. Dobry tekst nie pomoże, gdy przycisk prowadzi do niewłaściwej usługi albo formularz wymaga informacji, której użytkownik nie ma.

O projektowaniu takich prób piszemy w artykule o testowaniu prototypu z użytkownikami. Przy odbiorze warto zapisać oczekiwany wynik dla każdego scenariusza i osobę, która potwierdzi poprawność zasad. Artykuł o kryteriach odbioru pomaga uporządkować te ustalenia.

Wykorzystaj zgłoszenia do dalszych poprawek

Po publikacji obserwujcie pytania, na które konsultanci nadal odpowiadają ręcznie, oraz miejsca, w których użytkownicy przerywają poszukiwanie. Samo otwarcie odpowiedzi nie dowodzi, że pomogła. Przydatne są konkretne uwagi, informacje o dalszym kontakcie i rozmowa z zespołem, który obsługuje podobne sprawy.

Gdy pojawia się powtarzający problem, sprawdźcie, czy przyczyną jest brak treści, niewłaściwa nazwa, nieaktualna instrukcja czy trudność w samej usłudze. Nie każdą niedogodność da się naprawić nowym artykułem. Czasem potrzebna jest zmiana formularza lub wyjaśnienie decyzji w procesie. W artykule o wdrożeniu AI i pracy zespołu zwracamy uwagę na podobną potrzebę przypisania odpowiedzialności za dalsze działania.

Baza powinna być dostępna także wtedy, gdy użytkownik korzysta z klawiatury albo technologii wspomagającej. Sprawdźcie nazwy odnośników, kolejność nawigacji i to, czy rozwijana odpowiedź daje się otworzyć bez myszy. Materiały W3C dotyczące WCAG pomagają uporządkować wymagania dostępności. Ich zastosowanie należy sprawdzić na rzeczywistym interfejsie, a nie wyłącznie na projekcie graficznym.

Przy przekazywaniu treści między zespołami ustalcie również, kto może wycofać odpowiedź w sytuacji pilnej. Osoba obsługująca zgłoszenie powinna wiedzieć, jak wskazać nieaktualną informację i do kogo skierować prośbę o sprawdzenie. Jeśli nowa treść wymaga zatwierdzenia przez właściciela procesu, kolejka powinna pokazywać jej stan i osobę odpowiedzialną za następny krok.

W przypadku kilku wersji językowych zmiana źródłowej odpowiedzi wymaga sprawdzenia pozostałych. Sama podmiana daty w jednej wersji nie potwierdza poprawności opisanej procedury. Warto zachować powiązanie między tłumaczeniami oraz informację, która wersja oczekuje przeglądu. Użytkownik powinien wiedzieć, gdzie uzyskać pomoc, jeśli odpowiedź w wybranym języku nie jest dostępna.

Warto zapisać także sposób zgłoszenia błędu przez osobę korzystającą z odpowiedzi. Krótki sygnał powinien trafić do zespołu, który może sprawdzić treść i wskazać termin kolejnego kroku.

Przed rozszerzeniem bazy na kolejne usługi warto sprawdzić, czy istnieją właściciele odpowiedzi i droga aktualizacji. Mały zestaw utrzymywanych informacji może być bardziej użyteczny niż duża lista tekstów bez potwierdzonego źródła. W oprogramowaniu na zamówienie zaplanowanie tej odpowiedzialności pomaga połączyć treść z rzeczywistym działaniem usługi.

Źródła i dokumentacja

Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.

Kiedy potrzebujesz spojrzeć szerzej

Projekt nie kończy się na kodzie.

Twój proces, Twój zakres

Sprawdźmy, co ma powstać w Twojej firmie.

Nie potrzebujesz gotowej specyfikacji. Opisz zadanie, obecne narzędzia i to, co dziś wymaga ręcznej pracy.

Opisz swój projekt

Narzędzia i integracje, z których korzystamy

  • Google
  • OpenAI
  • Microsoft
  • Stripe
  • Anthropic
  • Linear

Dobór technologii i dostępnych połączeń ustalamy dla konkretnego projektu.