Как организовать базу знаний техподдержки, которой реально пользуются

За последние пару лет я прошёл путь от «у нас два Word-файла на Google Drive» до базы в две сотни статей, по которой команда техподдержки ищет ответы AI-поиском. По дороге выяснилось, что почти всё, что пишут про «правильную организацию базы знаний», разбивается об один простой факт: базой пользуется человек, у которого прямо сейчас в чате клиент ждёт ответа. Всё, что не помогает этому человеку за минуту, — не работает, как бы красиво ни выглядело.

Это текст про практику. Что писать, как называть, где брать темы, как не дать базе протухнуть — и почему в какой-то момент структура перестаёт помогать, что бы вы с ней ни делали.

Почему базы знаний умирают

Типовой сценарий: команда решает «нам нужна база знаний», заводит wiki, пишет туда десяток больших обзорных статей — «Всё о печати», «Настройка интеграций», «Работа с личным кабинетом». Через три месяца базой не пользуется никто.

Причина не в лени. Причина в том, что обзорная статья отвечает на вопрос «как это устроено», а у оператора вопрос всегда другой: «у клиента вот такая ошибка, что делать». Чтобы из большой статьи достать ответ на конкретный вопрос, её надо прочитать. На это нет времени — проще спросить коллегу. А раз базой не пользуются, её перестают пополнять. Круг замкнулся.

Одна статья — один случай

Правило, которое поменяло всё: одна статья описывает один конкретный случай. Не «большая инструкция про печать», а «принтер не печатает после смены драйвера на Windows 11». Не «настройка интеграции», а «ошибка 403 при обмене с конкретной системой».

У такого формата три следствия. На статью удобно ссылаться — она и есть ответ, её можно целиком отправить клиенту или коллеге. Её удобно обновлять — правка затрагивает один кейс, а не главу на десять экранов. И её реально написать за десять минут после закрытого тикета, пока детали свежи, — а значит, база пополняется по ходу работы, а не в специально выделенный «день документации», которого никогда не будет.

Внутри статьи мы держим простую структуру: симптом словами клиента → как проверить и диагностировать → решение по шагам → если есть, готовый шаблон ответа клиенту. Последний пункт недооценивают: готовая формулировка, которую можно скопировать в чат, экономит больше времени, чем само решение.

Где брать темы: из тикетов, а не из головы

Не нужно садиться и придумывать, «что бы задокументировать». Список тем уже есть — это ваши обращения. Правило простое: ответили на вопрос второй раз — значит, будет и третий; пишите статью.

Хорошая привычка — раз в неделю-две пробегать закрытые тикеты и выписывать повторы. Ещё лучше, если у вас есть статистика запросов к базе: список вопросов, на которые база не смогла ответить, — это готовый план на написание, отсортированный по реальному спросу, а не по ощущениям.

Актуальность: у базы должен быть хозяин

Самая коварная проблема базы знаний — не пустота, а тихое протухание. У нас был случай, который я до сих пор вспоминаю: типовой шаблон ответа клиенту оказался побит случайной правкой — кто-то зацепил текст и не заметил. Выяснилось это не по жалобе клиента, а когда сотрудники стали переспрашивать друг друга, что этот шаблон вообще значит. Повезло, что это случилось днём, когда было у кого переспросить, а не в ночную смену, где человек один.

Выводы, которые мы из этого сделали. Во-первых, инструмент должен уметь показывать историю правок — в наших исходных Word-файлах она формально была, но пользоваться ей начинаешь только тогда, когда уже поздно. Во-вторых, у базы должен быть человек, который отвечает за ревизию, — не «все понемногу», а конкретный владелец процесса. В-третьих, устаревшая статья хуже отсутствующей: на отсутствующую хотя бы не опираются.

Структура не заменяет поиск

Дальше — момент, ради которого я вообще пишу этот текст. Допустим, вы всё сделали правильно: статьи атомарные, названы понятно, разложены по разделам. У нас так и было — и на паре сотен статей это перестало работать.

Документация жила на пятом уровне вложенности wiki. Чтобы найти ответ, нужно пройти пять-шесть кликов вглубь дерева, понять, что ветка не та, вернуться, попробовать соседнюю. Заголовки честные — но между «принтер не печатает» и «ошибка очереди печати» на глаз разницы нет, а открыть и прочитать — минута. Когда я посчитал, сколько таких минут набегает на команду в день, цифра вышла неприятная: вся она — про поиск информации, которая уже написана.

Штатный поиск wiki проблему не решает, потому что ищет по словам. Оператор спрашивает «клиент не видит кнопку оплаты», а статья называется «отображение элементов после обновления интерфейса» — для лексического поиска это разные вселенные. Человек не обязан угадывать, какими словами написана статья.

Что изменил AI-поиск

Для нашей команды развязкой стал семантический поиск с генерацией ответа: спрашиваешь своими словами — получаешь ответ, собранный из статей базы, с цитатами на источники. Дерево осталось для тех, кто любит навигацию; все остальные просто спрашивают. Про то, как мы к этому пришли — и что не сработало по дороге, включая Telegram-бота, — я подробно писал в истории проекта.

Здесь важна одна деталь, на которую я советую смотреть в любом инструменте такого рода: ответ обязан приходить с цитатами. В техподдержке цена выдуманного ответа слишком высока — оператор должен иметь возможность за один клик проверить, что фраза действительно из вашей документации, а не сгенерирована из воздуха. И честное «в базе нет точного ответа» полезнее гладкого текста ни о чём: это сигнал, что тему пора дописать.

С чего начать в понедельник

Если у вас сегодня «два Word-файла и чат с коллегами», путь примерно такой. Выберите один инструмент хранения — какой угодно, лишь бы с историей правок. Разнесите существующие документы на атомарные статьи — это скучный день работы, но он окупается сразу. Договоритесь о правиле «ответили дважды — пишем статью» и назначьте владельца ревизии. А когда статей станет больше сотни и навигация начнёт есть заметное время — подключайте поиск, который понимает смысл, а не слова: например, Sensei для техподдержки. Попробовать, как это ощущается, можно на демо-базе без регистрации.