Как понять, что база знаний работает

В отчёте база знаний выросла с 12 до 48 статей. На планёрке это удобно показать: было мало, стало много. Все поработали.

Через час оператор снова отвечает на то же самое: «Где посмотреть статус заказа?», «Как перенести запись?», «Почему не проходит оплата?». Статей стало больше, а смена не стала легче.

Так бывает, когда базу знаний меряют как склад: сколько полок заполнено. Но клиенту всё равно, сколько у вас статей. Работает база или нет, видно по другому признаку: какие вопросы перестали приходить в поддержку.

Количество статей легко растёт и плохо объясняет пользу

Число статей — приятная метрика, потому что она управляемая. Можно поставить задачу: написать пять материалов за неделю. Можно закрыть квартал: было 30, стало 80. Можно показать прогресс руководителю.

Проблема в том, что эта цифра почти ничего не говорит о клиенте.

В базе может быть 80 статей, но половина из них отвечает на вопросы, которые никто не задаёт. Ещё часть написана языком регламента: формально всё верно, но клиент не понимает, что нажать сейчас. Ещё десять материалов лежат в разделе, куда невозможно попасть из продукта или чата.

Обратная ситуация тоже нормальна: в базе всего 15 статей, зато они закрывают самые частые вопросы недели. Оператору не нужно в десятый раз объяснять, как восстановить доступ или где взять акт. Клиент находит ответ до обращения.

Поэтому «сколько у нас статей» годится только как инвентаризация. Это как считать количество шаблонов ответов и делать вывод, что поддержка стала лучше. Может, стала. А может, команда просто накопила текст.

Если база только начинается, лучше не строить оглавление на будущее, а взять вопросы, которые уже приходят. Мы отдельно разбирали, почему первые материалы стоит выбирать из десяти вопросов этой недели, а не из фантазии о полной энциклопедии продукта.

Рабочая метрика начинается с вопроса, а не со статьи

Чтобы понять, работает ли база знаний, сначала нужно выбрать не статью, а тип вопроса.

Не «статья про оплату», а «клиент оплатил, но заказ не изменил статус». Не «раздел про доставку», а «клиент не понимает, где трек-номер». Не «FAQ по личному кабинету», а «не приходит письмо для входа».

Тогда появляется простая проверка: сколько таких обращений было до статьи и сколько стало после того, как статью добавили в нужное место.

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

Для маленькой команды хватит грубой таблицы раз в неделю:

• тип вопроса;
• сколько таких обращений пришло;
• сколько всего было обращений за тот же период;
• где клиент мог увидеть ответ до обращения;
• что оператору пришлось дописать вручную.

Последний пункт часто важнее первых трёх. Если клиент всё равно пишет, но уже с более точным вопросом, база частично сработала. Например, раньше приходило: «Что с заказом?» После статьи приходит: «Трек-номер есть, но он два дня не обновляется». Это уже другой разговор. Статья сняла первый слой неопределённости.

А если после публикации ничего не меняется, причин обычно несколько. Статью не видно. Заголовок не похож на вопрос клиента. В тексте есть ответ, но он спрятан в середине. Или сам вопрос нельзя закрыть текстом: клиенту нужно действие, доступ, перенос, проверка платежа.

Исчезнувший вопрос не всегда победа

Самая опасная ошибка — радоваться любому снижению обращений. Вопросов стало меньше, но почему?

Один вариант хороший: клиент нашёл ответ и сделал всё сам. Он не написал в поддержку, потому что ему не понадобилось.

Другой вариант плохой: клиент не нашёл, куда писать. Форма сломалась, чат спрятали, письмо ушло в спам, раздел помощи открывается только после входа, а проблема как раз со входом. В отчёте красиво, в реальности клиент ушёл злым.

Поэтому снижение вопроса нужно проверять соседними сигналами.

Если вопросов по возврату стало меньше, но выросли злые письма в почту — база не решила проблему. Она, возможно, закрыла удобный вход в диалог. Если вопросов про оплату стало меньше, но стало больше незавершённых заказов — тоже рано праздновать.

Ещё один сигнал — поведение оператора. Если он продолжает отправлять статью и тут же дописывает три абзаца объяснений, статья не работает как самостоятельный ответ. Она стала приложением к ручному ответу.

Это не провал. Это материал для правки. В такие моменты не нужно заводить новую статью рядом. Лучше открыть старую и посмотреть, чего в ней не хватает: первого короткого ответа, условий, исключений, скриншота, человеческого заголовка. Для таких случаев есть отдельный разбор про то, когда пора обновлять статью, чтобы не чинить базу наугад.

Хорошая база уменьшает не всю поддержку, а лишнюю поддержку

База знаний не обязана убирать все обращения. И не должна.

Есть вопросы, где клиенту нужен человек. Спорная ситуация, деньги, конфликт, персональные данные, исключение из правил. Статья может подготовить клиента: какие данные прислать, какие условия есть, почему ответ не мгновенный. Но решение всё равно останется у команды.

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

Например, статья может закрыть:

• где скачать закрывающие документы;
• как изменить пароль;
• какие данные нужны для возврата;
• как перенести запись, если до неё больше суток;
• почему письмо может не прийти и что проверить сначала.

А вот эти обращения база может только сократить по длине, но не убрать полностью:

• «верните деньги, заказ уже отправлен»;
• «не могу войти, потому что потерял доступ к почте»;
• «перенесите запись на время, которого нет в расписании»;
• «счёт оплачен, но в кабинете этого не видно».

Здесь статья полезна, если клиент приходит подготовленным. Он уже знает, какие данные назвать, какие ограничения есть, чего ждать дальше. Оператор не тратит первые три реплики на расстановку декораций.

Так база знаний работает вместе с поддержкой, а не вместо неё. Она снимает повторяемое, объясняет правила и оставляет людям то, где действительно нужен человек.

Долю вопросов нужно смотреть по темам, а не одним общим числом

Общая метрика «обращений стало меньше» слишком грубая. Она смешивает сезонность, релизы, рекламу, сбои, отпуск менеджера и новую статью про доставку.

База знаний живёт темами. Поэтому и оценивать её нужно по темам.

Допустим, вы добавили статью «Как получить акт». Через неделю не надо смотреть всю поддержку целиком. Надо смотреть обращения про акты. Приходят ли они так же часто. Что именно спрашивают. Отправляют ли операторы ссылку без пояснений или каждый раз дописывают: «А если у вас ИП, то…»

Если добавили статью про ошибку входа, смотрите вопросы про вход. Если переписали материал про возврат, смотрите возвраты. Иначе эффект потеряется в общем шуме.

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

Зато через месяц появляется разговор не про ощущения.

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

Это и есть нормальная работа с базой знаний: не писать бесконечно, а смотреть, какие вопросы вытащили из очереди, какие изменили форму, а какие остались на месте.

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

В DeskAI обращения из чата на сайте, почты, Telegram, MAX, форм и публичного API собираются в одну ленту. База знаний публикуется как центр помощи и открывается внутри чата, а в аналитике видны нагрузка по агентам и каналам, пиковые часы, время первого ответа и решения. Это помогает смотреть на вопросы в контексте нагрузки, а не оценивать базу только по числу написанных статей.