Michał Stefaniak · 2026-03-28

W Intum mamy bazę wiedzy z ponad 200 wpisami. Helpdesk z AI sugestiami odpowiedzi. Helplinki - ikonki pomocy przy każdym elemencie interfejsu, z tooltipem i linkiem do dokumentacji.

Nie zaczęliśmy od tego. Zaczęliśmy od tego że klienci pisali te same pytania w kółko. Jak dodać użytkownika. Jak zmienić uprawnienia. Jak wystawić fakturę. Kilkanaście ticketów dziennie z identycznymi pytaniami.

Baza wiedzy to nie jest “fajny dodatek”. To narzędzie które realnie zmniejsza liczbę zgłoszeń do supportu.

Po co firmie baza wiedzy

Klient ma problem o 22:00. Support nie pracuje. Klient pisze maila, czeka do rana, denerwuje się. Albo - wchodzi na stronę pomocy, wpisuje pytanie, dostaje odpowiedź w 10 sekund. Sam. Bez czekania.

Badania Zendesk (2024) mówią że 67% klientów woli samodzielnie znaleźć odpowiedź niż kontaktować się z supportem. To nie jest zaskoczenie - nikt nie lubi czekać.

Z perspektywy firmy: każde zgłoszenie do supportu kosztuje czas agenta. Jeśli 30% zgłoszeń to pytania na które odpowiedź jest w dokumentacji - baza wiedzy oszczędza 30% czasu zespołu. Na 100 zgłoszeń dziennie to 30 mniej do obsługi.

Jak zbudować dobrą bazę wiedzy

Nie zaczynaj od struktury. Zaczynaj od pytań. Weź 50 ostatnich ticketów z helpdesku i wypisz pytania. To są Twoje pierwsze wpisy.

Pogrupuj pytania w kategorie - ale nie więcej niż 8-10 kategorii na start. Zbyt rozbudowana struktura zniechęca. Klient wchodzi, widzi 30 kategorii i zamyka stronę.

Każdy wpis powinien odpowiadać na jedno pytanie. Nie rób wpisów “Wszystko o fakturach” na 5000 słów. Zrób 10 wpisów po 300 słów: “Jak wystawić fakturę”, “Jak dodać rabat”, “Jak zmienić numer faktury”. Konkretne pytanie, konkretna odpowiedź.

Pisz jak do współpracownika, nie jak instrukcję obsługi pralki. “Wejdź w Ustawienia, kliknij Użytkownicy, dodaj nowego” - nie “W celu dodania użytkownika należy przejść do sekcji administracyjnej systemu”.

Wyszukiwanie - najważniejsza funkcja

Jeśli baza wiedzy nie ma dobrego wyszukiwania - nikt z niej nie skorzysta. Klient nie będzie przeglądał 200 wpisów szukając odpowiedzi. Wpisze pytanie i oczekuje wyniku.

Standardowe wyszukiwanie pełnotekstowe (LIKE w SQL) to minimum. Ale nie daje dobrych wyników dla pytań w naturalnym języku. Klient pisze “nie mogę zalogować się do systemu” a wpis nazywa się “Resetowanie hasła”.

Dlatego dodaliśmy wyszukiwanie semantyczne. Baza wiedzy jest zindeksowana w vector database. Wyszukiwarka rozumie znaczenie pytania, nie tylko dopasowuje słowa. “Nie mogę się zalogować” trafia do wpisu “Resetowanie hasła” mimo że nie ma wspólnych słów.

To zmienia użyteczność bazy z “przydatna jeśli trafisz na właściwą kategorię” na “wpisujesz pytanie, dostajesz odpowiedź”.

Helplinki - pomoc w kontekście

Baza wiedzy to jedna strona z wpisami. Ale klient nie zawsze wie że powinien tam zajrzeć. Szczególnie kiedy jest w środku pracy i natknie się na element którego nie rozumie.

Helplinki rozwiązują ten problem. To ikonki znaku zapytania przy elementach interfejsu. Klikasz - pojawia się tooltip z krótkim opisem i linkiem “czytaj więcej” do wpisu w bazie wiedzy.

Przykład: przy polu “SLA” w ustawieniach helpdesku jest helplink. Klikasz - tooltip wyjaśnia co to SLA i jak je ustawić. Link prowadzi do pełnego wpisu z przykładami.

Technicznie: helplink to span z atrybutem data-helplink i kluczem. Komponent Svelte na stronie znajduje wszystkie helplinki, pobiera treść z API bazy wiedzy i renderuje tooltopy. Dodanie helplinku to jedna linijka w szablonie widoku.

Na naszym panelu mamy helplinki przy praktycznie każdej sekcji ustawień. Kilkadziesiąt ikonek pomocy, każda powiązana z wpisem KB. Jeśli wpis jeszcze nie istnieje - helplink automatycznie tworzy placeholder i czeka na uzupełnienie treści.

AI w bazie wiedzy

Szukanie odpowiedzi to jedno. Ale co jeśli klient pisze do supportu pytanie na które odpowiedź jest w KB?

Agent supportu dostaje sugestię - system sprawdza bazę wiedzy i proponuje gotową odpowiedź z odpowiedniego wpisu. Agent weryfikuje, ewentualnie dostosowuje i wysyła. Zamiast pisać od zera - kopiuje z bazy.

Chatbot na stronie robi to samo automatycznie. Klient pisze pytanie, chatbot szuka w bazie wiedzy, odpowiada cytatem z wpisu. Jeśli nie znajdzie odpowiedzi - przekazuje do agenta.

To nie zastępuje ludzi w supportcie. To oszczędza im czas na powtarzalnych pytaniach żeby mogli skupić się na trudniejszych sprawach.

Format treści

Piszemy wpisy w Markdown. Nagłówki h2 dzielą wpis na sekcje. Listy punktowane dla kroków. Bloki kodu dla ścieżek w systemie i przykładów. Bez HTML - edytor WYSIWYG obsługuje Markdown natywnie.

Każdy wpis ma pole content (treść dla klienta) i opcjonalnie content_api (dokumentacja techniczna dla programistów). Nie mieszamy tych dwóch perspektyw w jednym tekście.

Tagi pomagają w wyszukiwaniu. Kategorie grupują wpisy tematycznie. Statusy (roboczy, opublikowany) kontrolują widoczność - możesz napisać draft i opublikować go kiedy jest gotowy.

Wielojęzyczność

Baza wiedzy Fakturowni istnieje w 7 językach - polski, angielski, hiszpański, ukraiński, czeski, niemiecki, słowacki. Każdy język to osobna baza z własnymi wpisami i kategoriami.

Nie tłumaczymy 1:1. Wpis po polsku o KSeF nie ma sensu w wersji hiszpańskiej. Każda wersja językowa ma treści dopasowane do rynku.

Mierzenie efektów

Śledzenie wpływu bazy wiedzy na support:

• View count per wpis - które tematy są popularne (i które wymagają poprawy, bo klienci dalej piszą tickety)
• Deflection rate - ile procent klientów znalazło odpowiedź samodzielnie zamiast pisać do supportu
• Wyszukiwania bez wyników - te frazy to kolejne wpisy do napisania
• Komentarze i oceny - czy wpis był pomocny

Nie mierz sukcesu bazy wiedzy liczbą wpisów. 50 dobrych wpisów odpowiadających na realne pytania jest lepsze niż 500 wpisów których nikt nie czyta.

Od czego zacząć

Nie próbuj zbudować kompletnej bazy wiedzy w jeden tydzień. Zacznij od 10 wpisów na najczęściej zadawane pytania. Opublikuj. Poczekaj tydzień. Sprawdź jakie pytania dalej przychodzą do supportu. Napisz kolejne 10 wpisów.

Po miesiącu masz 40 wpisów które odpowiadają na 80% powtarzalnych pytań. To więcej niż wystarczy na start.

Baza wiedzy to proces ciągły - nie projekt z datą zakończenia.