Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Baza wiedzy to jedna z niewielu sekcji serwisu, którą da się uzasadnić bez odwoływania się do pozycji w wynikach. Nawet gdyby nie przyniosła ani jednej wizyty z wyszukiwarki, odciąża obsługę klienta i skraca czas odpowiedzi na te same pytania.
Dlatego traktuję ją inaczej niż blog. Blog jest projektem marketingu i żyje z pomysłów. Centrum pomocy jest projektem obsługi klienta, żyje z tego, o co ludzie faktycznie pytają, i po roku ma zwykle więcej wejść z wyszukiwarki niż połowa wpisów blogowych razem.
Poniżej opisuję, jak podchodzę do budowy takiej sekcji: skąd biorę tematy, jak układam adresy, co uznaję za dobry artykuł pomocy i dlaczego większość baz wiedzy umiera w drugim roku życia.
Pierwszy powód jest kosztowy. Jeśli obsługa odpowiada dwadzieścia razy w tygodniu na to samo pytanie o wymianę filtra, ten tekst i tak jest już napisany — tylko za każdym razem od nowa, w oknie czatu, i nikt poza jednym klientem go nie widzi.
Drugi powód dotyczy wyszukiwarki. Zapytania serwisowe mają zupełnie inny język niż zapytania sprzedażowe. Nie „najlepszy ekspres do kawy”, ale „ekspres nie nabiera wody” albo „jak odkamienić”. Strona kategorii ani karta produktu nie odpowiedzą na to sensownie, a blog nie zejdzie do takiego poziomu szczegółu.
Trzeci powód, najtrudniejszy do zmierzenia, dotyczy zaufania. Firma, która publicznie opisuje, co może się zepsuć i jak to naprawić, wygląda inaczej niż firma, która publikuje tylko obietnice. Nie mam na to danych z kampanii, ale wiem, do których serwisów sam wracam po zakupie.
I powód praktyczny, o którym warto pamiętać w reklamie: artykuły pomocy są świetnymi stronami docelowymi dla remarketingu i kampanii posprzedażowych, a nie tylko dla ruchu organicznego.
Nigdy z burzy mózgów. Kolejność źródeł jest u mnie zawsze taka sama.
To ostatnie źródło daje efekt natychmiast i w dwie strony: zapytania idą do listy wykluczeń w kampaniach, a jednocześnie stają się listą tematów do napisania.
Z tak zebranej listy odrzucam wszystko, na co odpowiedź brzmi „zadzwoń do nas”. Artykuł pomocy, który nie pomaga, jest gorszy niż jego brak.
Trzymam bazę wiedzy w jednym katalogu we własnej domenie. Zewnętrzna platforma na subdomenie jest wygodniejsza wdrożeniowo i regularnie kończy się tym, że cały ten ruch nie pracuje dla serwisu głównego, a spójność techniczna zostaje na łasce dostawcy.
Poziomy trzymam płaskie: sekcja i artykuł, bez czteropoziomowych zagnieżdżeń. Nazwy sekcji piszę językiem klienta, nie działu — „zwroty i wymiana”, nie „logistyka zwrotna”.
Trzy rzeczy techniczne, które regularnie widzę zepsute w tym typie sekcji:
Zaczyna się od odpowiedzi. Nie od wstępu o tym, jak ważna jest konserwacja urządzenia — od jednego akapitu, który rozwiązuje problem albo mówi, czego będzie potrzeba.
Potem idą kroki, w kolejności wykonywania, z numeracją, jeden krok na jedną czynność. Jeśli krok wymaga warunku („dotyczy modeli sprzed 2023 roku”), warunek stoi na początku kroku, nie na końcu artykułu.
Dalej sekcja z tym, co zrobić, jeśli to nie pomogło — i tu jest miejsce na kontakt. Wcześniej nie.
Kilka reguł redakcyjnych, których pilnuję w tego rodzaju treściach: jeden temat na artykuł, tytuł dokładnie taki, jakim ludzie nazywają problem, komunikaty błędów przepisane dosłownie razem z numerami, żadnych ozdobników. Artykuł pomocy jest instrukcją, nie tekstem sprzedażowym — próba wciśnięcia w niego oferty psuje jedno i drugie.
Do tego dochodzi rzecz, którą podpowiada obsługa, a nie SEO: napisz, ile to zajmie i czego potrzeba. Zdanie „potrzebujesz szczypiec i dziesięciu minut” oszczędza połowę zgłoszeń.
Tu muszę ostudzić oczekiwania, bo w tej sprawie krąży dużo nieaktualnych porad.
Znaczniki FAQ przez lata dawały rozbudowany wynik z rozwijanymi pytaniami. Od sierpnia 2023 Google ograniczył ich wyświetlanie w praktyce do serwisów rządowych i medycznych, a znaczniki instrukcji krok po kroku straciły swoje osobne wyniki. Dodanie ich dzisiaj do bazy wiedzy nie da tego, co obiecują poradniki z 2022 roku.
Nie znaczy to, że dane strukturalne są bezużyteczne. Warto opisać produkt, opinie, dane organizacji i politykę zwrotów — bo te typy nadal mają realne zastosowanie. Ale nie oczekuję od nich wpływu na to, czy artykuł pomocy trafi do wyróżnionego fragmentu.
O to decyduje raczej sposób napisania treści: krótkie akapity odpowiadające na pytanie, tabele z parametrami, listy kroków. Nudna robota redakcyjna wygrywa tu ze znacznikami.
Typowy cykl życia wygląda tak: kwartał zapału, sześćdziesiąt artykułów, potem cisza. Po dwóch latach połowa treści opisuje panel, którego już nie ma, i procedurę zwrotów zmienioną dwa razy w międzyczasie.
Dlatego przy planowaniu ustalam nie tylko, kto pisze, ale kto przegląda. Ustawiam przypomnienie raz na pół roku dla artykułów o produktach i raz na rok dla pozostałych. Do każdego artykułu dopisuję właściciela po stronie klienta — imiennie, nie działowo.
Sygnały, które mówią mi, że artykuł wymaga uwagi: spadek klikalności w Search Console przy utrzymanej liczbie wyświetleń, wzrost zgłoszeń do obsługi na temat, który jest już opisany, oraz wewnętrzne wyszukiwania kończące się bez kliknięcia.
Data ostatniej aktualizacji widoczna dla użytkownika jest w tego rodzaju treściach uczciwsza niż data publikacji. Ale wstawiam ją tylko wtedy, gdy naprawdę ktoś ten tekst przejrzał — samo podmienianie daty w szablonie to zabawa w pozory.
Na koniec zastrzeżenie, bo słowo „autorytet” bywa używane jako zaklęcie. Nie istnieje wskaźnik autorytetu w Google, a liczby o takiej nazwie w narzędziach zewnętrznych są ocenami tych narzędzi, nie danymi od wyszukiwarki.
To, co realnie daje dobre centrum pomocy, jest bardziej przyziemne. Serwis zaczyna pokrywać zapytania z całego cyklu życia klienta, a nie tylko z momentu zakupu. Zdobywa naturalne odnośniki z forów i grup, bo ludzie linkują do instrukcji, gdy komuś odpowiadają — na oferty nie linkuje nikt. I daje treści, które da się pokazać jako dowód znajomości tematu.
Z mojego doświadczenia to jedna z niewielu inwestycji w treść, która nie traci wartości po zmianie algorytmu, bo nie jest zbudowana pod algorytm. Warunek jest jeden i mało romantyczny: musi ją pisać ktoś, kto zna produkt i rozmawia z klientami.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |