База знаний почти всегда создаётся из лучших побуждений: разгрузить поддержку, ускорить онбординг, зафиксировать экспертизу, дать клиентам возможность самообслуживания. Но уже через полгода статей становится больше, а ясности — меньше. Контент устаревает, поиск «не угадывает» формулировки пользователей, новые регламенты расходятся по чатам, а поддержка продолжает отвечать вручную, потому что «в базе знаний всё равно ничего не найдёшь».
Корень проблемы — не в том, что база знаний плохая. Проблема в том, что ею управляют как библиотекой — чем больше библиотечный фонд, тем лучше, так что «давайте просто напишем побольше», а не как продуктом — «давайте измерим ценность и улучшим». Продукт без метрик неизбежно деградирует: у команды нет обратной связи, нет приоритетов, нет способа доказать пользу бизнесу и выбить ресурсы на обновление.
Рулетка спроса на знания
Метрики базы знаний нужны для четырёх вещей:
Доказать ROI: показать экономию времени и денег (меньше обращений, ниже стоимость обработки, выше скорость решения). В расчётах ROI для управления знаниями часто используют связку «сокращение обращений/времени → экономия стоимости обращения» и сопоставляют это с затратами на создание и поддержку контента.
Найти «узкие места»: выявить статьи, которые не решают задачу; темы, ища информацию из которых люди не могут сформулировать запрос; процессы, где контент застревает на согласовании и теряет актуальность ещё до публикации.
Принимать data-driven решения: что писать, что переписывать, что объединять, что архивировать — на основе фактов, а не ощущений.
Создать цикл непрерывного улучшения: план → создание → анализ → оптимизация. Этот цикл критичен, потому что база знаний — живой организм: продукт, политика, тарифы, интерфейсы, регламенты меняются постоянно.
Дальше разберём метрики четырёх уровней.
Использование и охват.
Качество и поиск.
Бизнес-эффект и ROI.
Показатели процесса управления знаниями.
Использование и охват: «а нужна ли нам база знаний?»
Эта группа метрик отвечает на базовый вопрос: где люди ищут информацию? Заходят в базу знаний (БЗ) и читают статьи, делают поисковые запросы с AI или живут «в обход» — через личные сообщения, созвоны и тикеты? Важно: охват — это не про «успешность», это про принятие сотрудниками базы знаний как рабочего инструмента. Если такого принятия нет, то даже лучшие статьи не встроят БЗ в рабочие процессы.
Общее количество просмотров
Просмотры — самый простой индикатор активности: если трафик растёт, значит база знаний хотя бы участвует в пользовательских сценариях. Но есть нюансы:
Просмотры легко «накрутить» внутренними ботами, индексацией, переходами из меню «на всякий случай».
Просмотры не равны пользе: статью могут открывать по 10 раз, потому что она непонятная.
Поэтому просмотры — только входной сигнал: они свидетельствуют о том, что в БЗ идёт какая-то жизнь. Но приносит ли она пользу?
Уникальные посетители
Уникальные посетители показывают ширину охвата: сколько разных людей реально использует БЗ. Это важно, потому что одна и та же динамика просмотров может означать два разных мира:
если это 10% сотрудников, много и часто — поддержка и новички, то для остальных БЗ бесполезна.
если это 90% сотрудников, пусть не каждую минуту — значит БЗ стала стандартным инструментом.
Логичное продолжение отслеживания уникальных посетителей — сегментация их по аудиториям:
сотрудники / клиенты;
новички / опытные;
поддержка / все остальные.
Тогда становится видно, для кого БЗ реально работает.
Популярные и непопулярные статьи
Рейтинг статей по просмотрам — источник быстрых инсайтов.
Популярные статьи показывают частые боли, где обновление даст максимальный эффект.
Непопулярные статьи — либо не нужны, либо их не находят, либо они спрятаны в структуре, либо название не соответствует содержанию.
Важно не делать вывод «непопулярное = удалить». Бывают «редкие, но критичные» статьи: действия при инциденте, юридические инструкции, аварийные регламенты. Их оценивают по другой логике: насколько быстро нужная роль находит статью в нужный момент, и актуальна ли информация.
FCR, связанный с БЗ (закрытие с первого контакта)
FCR (First Contact Resolution) — одна из ключевых метрик поддержки: сколько обращений решаются с первого контакта, без повторных уточнений и эскалаций. Если в процесс поддержки встроена БЗ — агенты отвечают ссылкой на статью, бот предлагает статью до создания тикета, — можно измерять «FCR с использованием БЗ»: какой процент обращений закрывается первой статьёй/первым ответом AI-ассистента.
Почему это важно для БЗ:
FCR напрямую влияет на стоимость поддержки и нагрузку на специалистов саппорта.
FCR чувствителен к качеству знаний: плохая статья часто приводит к повторному обращению.
FCR — это мост между контентом и операционным эффектом, понятный руководителям.
Технически реализация разная: где-то это тег в тикете «решен�� статьёй», где-то — связка через ссылки/макросы, где-то — отчёт в helpdesk. Главное — закрепить определение: что считать «закрыто первой статьёй», а что — нет и закрепить это понятие на уровне внутренних политик организации.
Качество контента и поиск: «Нашли и помогло?»
Если охват — это «люди пришли», то качество — это «люди нашли ответ и решили проблему». В этом показателе у большинства БЗ самые большие провалы: контент вроде есть, но он не находится или не решает задачу.
Эффективность поиска: успешные и нулевые запросы
Search effectiveness — один из самых сильных диагностических блоков. Две метрики особенно полезны:
Процент успешных поисков: пользователь ввёл запрос, открыл релевантную статью или получил AI-summary, прекратил поиск, потому что нашёл нужное.
Процент поисков с нулевым или нерелевантным результатом: запросы, по которым БЗ либо не нашла ничего, либо найденная информация бесполезна. Это почти всегда индикатор «дыры»: либо нет материала, либо он назван другими словами, либо не настроены теги/синонимы.
Как использовать нулевые запросы на практике:
Собрать топ-50/топ-100 запросов с нулевым откликом.
Классифицировать их по причинам: «нет статьи», «есть, но называется иначе», «есть, но не открывается (доступ/права)», «неоднозначность терминов и определений», «пользовательская ошибка», «нерелевантный (устаревший, недостаточный) контент».
Ввести правило: в течение каждой недели/спринта в БЗ закрывается N топовых нулевых запросов — новыми статьями, настройкой прав или переносом информации в доступные п��остранства, тегирование и приведение терминов к глоссарию, переименование в соответствии с содержанием и т.д.
Работа по нулевым запросам — это один из самых быстрых способов «поднять» самообслуживание без написания сотен новых материалов.
Реакции и оценки полезности
Самый банальный, но рабочий инструмент — кнопка «Была ли статья полезна?» и простые лайки/дизлайки. Это прямая обратная связь, особенно ценная, если к оценке собрать комментарии. И вообще не просто собирать оценки, а соединить этот процесс с улучшениями.
Низкая оценка → обязательный комментарий «что было не так?» (по возможности / желанию пользователя).
Низкая оценка + высокий трафик → приоритет №1 на переработку.
Низкая оценка + низкий трафик → сначала понять, нужна ли вообще статья и как в неё попадают.
Важно также учитывать «негативное смещение»: на 20 выражений недовольства в среднем приходится только одна похвала — это работает не только в БЗ, это закон для любого b2c. База знаний — сервис, закрывающий потребность, а его пользователи — клиенты, так что аналогия вполне жизненная. Поэтому оценки полезности лучше интерпретировать в динамике и в связке с другими сигналами — повторные поиски, тикеты по теме и т.д.
Время на странице и глубина просмотра
Эти метрики часто неправильно читают. Долго читали — это не всегда хорошо, быстро закрыли — не всегда плохо.
Долгое время на странице может означать: статья сложная (и это нормально), статья плохо структурирована, много воды, или человек реально выполняет инструкцию по шагам.
Быстрое закрытие может означать: нерелевантно, или наоборот — нашёл ответ в первой строке и ушёл счастливым.
Чтобы метрика стала полезной, её связывают с исходом: была ли повторная попытка поиска, был ли тикет после просмотра, была ли негативная оценка. Тогда получается не «абстрактное время», а сигнал «прочитал и всё равно пошёл в поддержку».
Self-Service Rate и Ticket Deflection: «решили без тикета»
Есть два как бы дублирующих понятия. Self-service rate (%SSR) — частота запросов, решённых без участия поддержки. Русский аналогичный термин — коэффициент самообслуживания. Ticket deflection rate (коэффициент отклонения тикетов) — это процент отказов от оформления тикетов в поддержку, когда клиент нашёл ответ на свой вопрос самостоятельно.
На первый взгляд это одно и то же, но на практике %SSR оценивает возможность пользователя решить вопрос без выхода на сотрудника поддержки и показывает сами факты использования средств самообслуживания — а решил свой вопрос клиент или нет, непонятно. Коэффициент отклонения тикетов — это процент фактически решённых с помощью средств самообслуживания случаев.
И то, и другое — «золотые» метрики для БЗ, прямой эффект: вопрос решён без обращения в поддержку.
Есть несколько подходов к измерению, которые дополняют друг друга.
До тикета: пользователь взаимодействовал с БЗ/порталом, но тикет не создал.
После просмотра: пользователь посмотрел статью, которую нашёл сам, и не создал тикет в течение X часов/дней.
С ботом или AI (Bot / AI deflection): бот или ИИ-ассистент предложил статью, пользователь не попросил оператора.
Важно выбрать метод, который не будет «врать». Например, если положить X равным 24 часам, есть риск не учесть сложные вопросы; если приравнять X к 7 дням — потеряем показатель из-за естественной «необращаемости» части аудитории.
Выявить правильный интервал обычно помогает контрольная группа или сравнение каналов до/после внедрения того или иного средства самообслуживания: БЗ, чат-бот, AI-ассистент и т.п.
Метрики влияния на бизнес и ROI
Если база знаний будет обходится дороже, чем служба поддержки, ни один адекватный управленец не даст добро на её внедрение. БЗ должна экономить деньги, а не быть лишь статьёй затрат с непонятной эффективностью.
Разберёмся с тем, на чём БЗ позволяет выиграть в деньгах.
Снижение нагрузки на поддержку
Как оценить и измерить:
Уменьшение количества обращений в саппорт (повышение %SSR / Ticket Deflection).
Более быстром решении оставшихся обращений (уменьшение AHT).
Более высоком качестве решения с первого раза (увеличение FCR).
AHT (Average Handle Time) — распространённая метрика поддержки, и в практиках управления знаниями часто рассматривают БЗ как инструмент, который снижает AHT за счёт готовых ответов и единых инструкций.
Пример расчёта ROI (упрощённо)
Одна из рабочих моделей:
Считаем, сколько обращений «сэкономили» за период:
Deflected tickets = базовое количество обращений – фактическое количество обращений с поправкой на сезонность и рост базы клиентов.
Умножаем на среднюю стоимость обращения или среднюю маржинальную стоимость времени агента.
Вычитаем затраты на БЗ:
Работа авторов и редакторов, владельцев статей, экспертов на согласовании .
Стоимость платформы/лицензий.
Поддержка структуры, аналитики, обучение.
Качественный ROI: удовлетворённость и удержание
Не всё измеряется рублём напрямую. БЗ часто даёт «качественный» эффект:
Рост CSAT/NPS: пользователи быстрее получают ответ, меньше тратят усилий. В кейсах внедрения систем управления знаниями встречается связь создания пользовательских сервисов самообслуживания, основанных на БЗ, с улучшением показателей обслуживания и восприятия сервиса.
Рост ESAT/eNPS (удовлетворённость сотрудников): поддержке проще работать, новички быстрее проходят онбординг, всем работается лучше, когда меньше хаоса.
Снижение текучки кадров: когда у поддержки есть понятные знания и меньше «адского ручного труда», выгорание ниже, удовлетворение от работы выше, смысла уходить на другую работу меньше. Обычно бывает так, но всё зависит от нюансов конкретной компании.
Важно: для доказательства корреляции нужны данные. Часто делают простой анализ: сравнивают CSAT до/после внедрения БЗ / улучшения БЗ / внедрения сервисов самообслуживания на «топовых» темах.
Метрики управления знаниями: «как устроено производство контента»
База знаний — это не то, что можно один раз сделать и забыть на всю оставшуюся жизнь. Она должна меняться, когда меняются реалии — не только то, что в ней описано, но и то, что ещё не описано, когда меняются способы взаимодействия, внедряются новые сервисы и интерфейс��. Все изменения внутри и снаружи компании, которые влияют на сущности БЗ, должны оперативно находить отражение в статьях и их структуре, в новых курсах и тестах, в новых способах получения информации. Модификация знаний и управление ими должно быть встроено в стандартные бизнес-процессы компании, а не быть отдельной «нагрузкой».
Свежесть и актуальность
Базовый показатель — доля статей, пересмотренных/обновлённых за последние 6–12 месяцев. Это можно превратить в понятное правило:
Для критичных процессов — ревизия раз в 3–6 месяцев.
Для справочного контента — раз в 12 месяцев.
Для «одноразовых» объявлений — автоархив через N дней.
Смысл простой: доверие к БЗ исчезает после 2–3 случаев, когда статья привела к ошибке. Поэтому актуальность — не бюрократия, а защита репутации БЗ.
Статусы редакционного цикла и «узкие места»
Полезно видеть, сколько материалов находится в разных статусах.
Черновик (автор пишет).
На проверке (редактор/эксперт).
На согласовании (юристы/безопасность/владельцы процесса).
Устарело (требует обновления).
Архив (не используется, но хранится для истории).
Метрика здесь — не «больше публикаций», а «время прохождения цикла» и «где застревает». Если у вас 50 статей на согласовании по 3 недели, вы знаете проблему: не хватает SLA на ревью или владельцев процесса.
Вклад команд и авторов
БЗ становится сильной, когда знания распределены по владельцам разделов:
Поддержка отвечает за пользовательские сценарии и частые вопросы.
Продакты — за «как работает» и изменения.
Разработка — за инциденты, диагностику.
HR — за онбординг и внутренние политики.
Юристы/безопасность — за комплаенс и чувствительные процедуры.
Метрика вклада помогает увидеть перекосы: если наполнением и модификацией занимается один-два из перечисленных игроков, знания будут однобокими, эффективность БЗ будет падать. Но не стоит забывать и о циклах изменений — у поддержки, продактов и разработки цикл гораздо короче, чем у HR и юристов с безопасниками.
Как внедрять метрики: практический план
Чтобы не утонуть в десятках показателей, начните с минимального набора и постепенно усложняйте.
Шаг 1. Зафиксируйте цели и аудитории
Пример целей:
Для клиентской БЗ: снижение обращений и рост %SSR.
Для внутренней БЗ: ускорение онбординга, снижение количества вопросов в чатах, сокращение AHT у внутренней поддержки — разумеется, по наличию и возможности измерения.
Сразу определите аудитории и их сценарии: новичок, эксперт, агент поддержки, клиент, партнёр.
Шаг 2. Определите 4–6 ключевых метрик
Пример списка ключевых метрик:
Охват: уникальные посетители, просмотры.
Поиск: процент нулевых запросов, процент успешных поисков.
Качество: оценки полезности, доля статей с низкой оценкой.
Эффект: процент SSR, FCR, AHT.
Процесс: доля обновлённых статей, время в статусах «на согласовании».
Шаг 3. Договоритесь о методологии
Главный риск — «рисовать» цифры. Поэтому заранее фиксируют:
Что считается успешным поиском.
Какой тикет считается решённым самостоятельно / deflected.
В каком окне времени связывать просмотр статьи и создание тикета — тот самый X.
Как исключать «служебный» трафик (боты, тесты, индексация).
Шаг 4. Привяжите метрики к регулярным действиям
Метрика должна запускать процесс:
Высокий процент нулевых запросов → еженедельный разбор и закрытие топа.
Статья с высоким трафиком и низкой полезностью → обязательная переработка в ближайший спринт.
Много материалов на согласовании → пересмотр SLA/ответственных.
Где и как отслеживать: аналитика в TEAMLY
На практике лучше всего работают метрики, которые собираются «сами» — через встроенную аналитику той платформы, где живёт контент, и через интеграции с сервис-деском.
Чтобы аналитика реально помогала (а не была «красивым отчётом»), стоит проверить, что на платформе доступны: статистика по статьям и пространствам, анализ поисковых запросов, а также разрезы по аудиториям/ролям — это базовая основа для метрик охвата и поиска.
Аналитика в TEAMLY позволяет не только собрать цифры для отчёта, но и выявить наиболее активных читателей и писателей, оценить вклад авторов.
Если дополнительно связать БЗ с поддержкой (тикеты/чат), становится возможным честнее считать deflection, AHT и FCR, которые обычно используют как ключевые показатели эффективности сервисных команд.
Много — не значит «хорошо»
Эффективная база знаний — это не «много букв», а измеримый продукт, который снижает нагрузку на поддержку и ускоряет решение задач. Начните с охвата и поиска, затем переходите к проценту SSR /deflected tickets, FCR и AHT — именно эти показатели чаще всего переводят очевидную для пользователей и администраторов пользу базы знаний на язык бизнеса.
