Przez pięć miesięcy przepisywaliśmy bazę wiedzy średniej wielkości firmy SaaS z sektora HR tak, aby modele językowe (ChatGPT, Perplexity, Gemini i Google AI Overviews) odpowiadały na pytania o produkt cytując jego własną dokumentację, a nie fora, agregatory recenzji i strony konkurencji. Ten case bazy wiedzy pod AI opisuje punkt startu, decyzje redakcyjne, koszty i mierzalne efekty: od udziału cytowań po liczbę zgłoszeń do wsparcia.
W skrócie
- Punkt startu: 214 artykułów pomocy, z których 61% odpowiadało na pytania, których nikt nie zadawał, a 38 najczęstszych pytań użytkowników nie miało własnej strony.
- Zbiór 1 240 realnych pytań z czatu, e-maili i wyszukiwarki w help center stał się szkieletem nowej struktury: 96 artykułów zamiast 214.
- Udział odpowiedzi AI cytujących dokumentację producenta wzrósł z 18% do 57% w panelu 120 pytań testowych.
- Zgłoszenia do wsparcia typu „jak to zrobić” spadły o 23% przy rosnącej liczbie klientów.
- Koszt: około 410 godzin pracy zespołu (redakcja, produkt, wdrożenie), bez wydatków na nowe narzędzia.
Stan wyjściowy dokumentacji: dużo stron, mało odpowiedzi
Baza wiedzy powstawała przez sześć lat jako odbicie kolejnych wydań produktu, nie jako odpowiedź na pytania użytkowników. Efekt: 214 artykułów, z czego 130 opisywało ekrany i przyciski („Zakładka Ustawienia zawiera…”), a tylko 84 odpowiadało na jakiekolwiek zadanie („jak wyeksportować listę urlopów do pliku CSV”).
W testach przeprowadzonych przed projektem zadaliśmy czterem asystentom AI 120 pytań o produkt: ceny, limity planów, integracje, procedury. Dokumentacja producenta pojawiła się jako źródło w 18% odpowiedzi. Resztę cytowań zgarnęły recenzje na portalach porównawczych (31%), wątki na forach HR (22%) i artykuły konkurencji, która odpowiadała na pytania o cudzy produkt we własnych poradnikach porównawczych (14%). W 15% przypadków model odpowiadał z pamięci, bez żadnego źródła, często błędnie.
Diagnoza była podobna do tej, którą opisaliśmy w case study o architekturze bazy wiedzy cytowanej przez AI: treść istniała, ale w formie, której model nie potrafił dopasować do pytania. Tutaj skala problemu była jednak większa, bo dokumentacja nie miała nawet spójnego nazewnictwa funkcji.
Zbiór pytań użytkowników jako punkt startu
Zamiast poprawiać istniejące artykuły, zaczęliśmy od zbudowania korpusu pytań. Źródła: 9 miesięcy logów z czatu wsparcia, e-maile z formularza kontaktowego, zapytania wpisywane w wyszukiwarkę help center oraz frazy z Google Search Console zawierające nazwę produktu. Po deduplikacji i połączeniu wariantów zostało 1 240 unikalnych pytań, które zgrupowaliśmy w 96 tematów.
Każdemu tematowi przypisaliśmy trzy wartości: liczbę wystąpień, koszt dla wsparcia (średni czas obsługi zgłoszenia) i status w dokumentacji. Trzydzieści osiem tematów z pierwszej setki nie miało własnego artykułu; odpowiedź istniała najwyżej jako akapit w tekście o czymś innym. To one poszły do produkcji jako pierwsze.
- Zebranie i normalizacja pytań (3 tygodnie, 1 analityk).
- Grupowanie w tematy i wycena kosztu wsparcia (2 tygodnie).
- Mapowanie tematów na istniejące artykuły: zachowaj, połącz, przepisz, usuń (1 tydzień).
- Produkcja treści w kolejności od najdroższych tematów dla wsparcia (14 tygodni).
Nowa struktura artykułów pomocy
Każdy z 96 artykułów dostaliśmy w jednym, sztywnym szablonie. Tytuł to pytanie lub zadanie w formie, jakiej użyliby klienci („Jak ustawić limit urlopu dla pracownika na część etatu”), a nie nazwa ekranu. Pierwszy akapit odpowiada w dwóch lub trzech zdaniach, bez wstępu. Dopiero potem następują kroki, warunki brzegowe i powiązane ograniczenia planu.
Ta zasada „odpowiedź najpierw” ma praktyczne uzasadnienie: systemy RAG (retrieval-augmented generation) dzielą stronę na fragmenty i wybierają te, które najlepiej pasują do pytania. Fragment, który zaczyna się od odpowiedzi, wygrywa z fragmentem zaczynającym się od „W tym artykule dowiesz się”. Mechanizm ten opisuje m.in. hasło o RAG w Wikipedii.
| Element | Przed przebudową | Po przebudowie |
|---|---|---|
| Liczba artykułów | 214 | 96 |
| Tytuły w formie pytania lub zadania | 39% | 100% |
| Odpowiedź w pierwszym akapicie | 12% | 100% |
| Mediana długości artykułu | 310 słów | 620 słów |
| Artykuły z sekcją ograniczeń planu | 7 | 96 |
| Spójne nazwy funkcji (jedno nazewnictwo) | nie | tak, słownik 140 terminów |
Konsolidacja z 214 do 96 stron budziła opór w zespole produktowym, który obawiał się utraty ruchu z Google. Obawa się nie potwierdziła: po ustawieniu przekierowań 301 ruch organiczny do help center wzrósł w piątym miesiącu o 9% względem okresu bazowego, bo połączone artykuły zaczęły rankować na dłuższe zapytania.
Dane produktowe: ceny, limity, integracje
Największa pojedyncza zmiana dotyczyła danych twardych. Przed projektem ceny i limity planów istniały wyłącznie na stronie sprzedażowej, w grafice i w interaktywnym kalkulatorze renderowanym w JavaScript. Modele językowe nie odczytywały tych wartości i podawały ceny sprzed dwóch lat, zaczerpnięte z recenzji.
Stworzyliśmy trzy artykuły referencyjne w zwykłym HTML: tabelę planów z cenami netto i brutto, tabelę limitów (użytkownicy, pracownicy, przestrzeń, liczba wywołań API) oraz listę 27 integracji z opisem, co dokładnie się synchronizuje. Każdy artykuł ma widoczną datę ostatniej aktualizacji i jedno zdanie o zasadach zmiany cen. Właściciel produktu dostał obowiązek aktualizacji tych trzech stron w dniu każdej zmiany cennika.
W badaniu po pięciu miesiącach odpowiedzi o ceny, które wcześniej były błędne w 62% przypadków, okazały się zgodne z aktualnym cennikiem w 84%. Pozostałe błędy dotyczyły głównie odpowiedzi z pamięci modelu, bez pobrania źródła, na które nie mamy wpływu.
Efekty w odpowiedziach modeli
Pomiar prowadziliśmy na stałym panelu 120 pytań, zadawanych raz w miesiącu w ChatGPT z włączonym wyszukiwaniem, Perplexity, Gemini oraz sprawdzanych w Google AI Overviews. Rejestrowaliśmy, czy dokumentacja producenta pojawiła się jako źródło i czy odpowiedź była merytorycznie poprawna.
| Wskaźnik (panel 120 pytań) | Miesiąc 0 | Miesiąc 3 | Miesiąc 5 |
|---|---|---|---|
| Odpowiedzi z cytowaniem dokumentacji producenta | 18% | 41% | 57% |
| Odpowiedzi cytujące konkurencję | 14% | 8% | 5% |
| Odpowiedzi merytorycznie poprawne | 54% | 71% | 81% |
| Pytania o ceny z aktualną kwotą | 38% | 69% | 84% |
Najszybciej zareagowało Perplexity: już w drugim miesiącu cytowało nowe artykuły w większości pytań proceduralnych, co pokrywa się z obserwacjami z naszego case study o wzroście cytowań w Perplexity po przebudowie FAQ. Google AI Overviews potrzebowało około 10 tygodni, a Gemini było najbardziej zachowawcze i do końca projektu w części pytań wracało do portali recenzenckich.
Warto podkreślić, czego nie zmierzyliśmy: nie potrafimy oddzielić wpływu treści od zwykłego upływu czasu i ponownego indeksowania. Nie mieliśmy też grupy kontrolnej. Wyniki traktujemy jako silną korelację po interwencji, nie jako dowód przyczynowy.
Wpływ na zgłoszenia do wsparcia
Drugi efekt był bardziej namacalny dla zarządu. Liczba zgłoszeń sklasyfikowanych jako „jak to zrobić” spadła z średnio 1 180 do 910 miesięcznie (o 23%), mimo że liczba aktywnych kont wzrosła w tym czasie o 11%. Zgłoszenia o błędy i problemy techniczne nie zmieniły się istotnie, co zgadza się z intuicją: dokumentacja pomaga w obsłudze, nie naprawia awarii.
Zespół wsparcia zaczął też sam korzystać z nowych artykułów jako gotowych odpowiedzi. Udział zgłoszeń zamykanych jedną wiadomością z linkiem wzrósł z 31% do 48%. Średni czas pierwszej odpowiedzi skrócił się z 3 godzin 40 minut do 2 godzin 15 minut, choć na ten wskaźnik wpłynęło także zatrudnienie jednej osoby.
Koszt i nakład pracy
Projekt nie wymagał nowych narzędzi. Help center działało na dotychczasowej platformie, a pomiar cytowań prowadziliśmy ręcznie w arkuszu. Cały koszt to czas ludzi.
- Analityk (korpus pytań, grupowanie, pomiar): około 120 godzin.
- Redaktor techniczny (96 artykułów, słownik terminów): około 210 godzin.
- Właściciel produktu (weryfikacja merytoryczna, dane cenowe): około 50 godzin.
- Wdrożenie (przekierowania, szablon, oznaczenie dat): około 30 godzin.
Razem około 410 godzin w pięć miesięcy, czyli mniej niż jeden pełny etat. Dla porównania: 270 zgłoszeń mniej miesięcznie przy średnim koszcie obsługi 9 minut to około 40 godzin pracy wsparcia oszczędzanych co miesiąc, więc nakład zwraca się w niecały rok, nawet bez liczenia efektu sprzedażowego z poprawnych odpowiedzi AI o cenach.
Najczęstsze błędy przy podobnych projektach
Pierwszy błąd to poprawianie istniejących artykułów bez korpusu pytań: zespół udoskonala teksty, których nikt nie szuka. Drugi to zostawienie cen i limitów w grafikach, kalkulatorach i plikach PDF, gdzie żaden model ich nie odczyta. Trzeci to brak właściciela aktualizacji: strona referencyjna z ceną sprzed roku szkodzi bardziej niż jej brak, bo model cytuje ją z pełnym przekonaniem.
Czwarty błąd dotyczy pomiaru. Jednorazowe sprawdzenie kilku pytań w ChatGPT nic nie mówi; potrzebny jest stały panel pytań, ten sam zestaw narzędzi i powtarzalny harmonogram. Inne przykłady z tej kategorii zebraliśmy w przeglądzie case studies marketingu cyfrowego.
FAQ: case baza wiedzy AI
Ile artykułów powinna mieć baza wiedzy, żeby AI ją cytowało?
Liczba nie ma znaczenia, znaczenie ma pokrycie realnych pytań. W tym projekcie 96 artykułów odpowiadających na pytania z korpusu 1 240 zapytań działało lepiej niż wcześniejsze 214 opisów ekranów. Zacznijcie od pierwszych 30–40 najczęstszych i najdroższych dla wsparcia tematów.
Jak szybko widać efekty w odpowiedziach modeli?
Perplexity zaczęło cytować nowe artykuły po 4–6 tygodniach, Google AI Overviews po około 10 tygodniach, Gemini najpóźniej. Pełny efekt w panelu testowym przyszedł w piątym miesiącu. Warunek: strony muszą być zaindeksowane i dostępne bez logowania, w zwykłym HTML.
Czy trzeba było wdrażać dane strukturalne schema.org?
W tym projekcie ograniczyliśmy się do podstawowego typu Article z datą modyfikacji i autorem. Największą różnicę zrobiła treść: odpowiedź w pierwszym akapicie, tabele z cenami i limitami w HTML oraz spójne nazewnictwo. Schema traktujemy jako uzupełnienie, nie jako główny czynnik.
Jak mierzyć cytowania w AI bez drogich narzędzi?
Stały panel pytań (tu 120), ta sama lista narzędzi, jedna osoba zadająca pytania raz w miesiącu i arkusz z trzema kolumnami: czy cytowano dokumentację, kogo cytowano zamiast niej, czy odpowiedź jest poprawna. Nakład to około 6 godzin miesięcznie. Nie oddziela to efektu treści od upływu czasu, ale wystarcza do decyzji.
Czy konsolidacja artykułów nie zaszkodzi ruchowi z Google?
Przy poprawnych przekierowaniach 301 i połączeniu treści w dłuższe, kompletne artykuły ruch organiczny do help center wzrósł o 9% w piątym miesiącu. Spadek jest możliwy w pierwszych tygodniach po zmianie adresów, dlatego warto konsolidować partiami, a nie wszystko naraz.
Co dalej
Kolejny etap to automatyzacja pomiaru cytowań i objęcie korpusem pytań również wersji anglojęzycznej produktu. Jeśli planujecie podobny projekt, punktem wyjścia jest zawsze korpus realnych pytań, a nie audyt istniejących stron; szczegóły warstwy technicznej opisuje wspomniane wyżej case o architekturze bazy wiedzy pod AI.