Многим знакома ситуация: в компании есть база знаний, которая на практике не работает. Внешние и внутренние пользователи не находят нужную информацию, а руководство не понимает, зачем вообще инвестировали в этот инструмент.
Так происходит, потому что команда не следит за эффективностью базы. Или другой вариант — ответственного назначили, но один человек не успевает контролировать метрики. В статье рассказали о моделях ответственности за базу знаний: кто и какие показатели собирает, как выстроить процесс без дублирования ролей.
Командная модель распределения ответственности — оптимальный вариант
В базе знаний накапливается опыт компании, а от полноты и точности материалов зависит нагрузка на техподдержку, удовлетворенность пользователей и затраты бизнеса. Показатели эффективности для этих сфер различаются, поэтому и ответственность за метрики не стоит сводить к одной роли. Иначе есть риск, что фокус внимания сместится в одну сторону.
Если за эффективностью базы следит только техподдержка, материалы оптимизируют под оператора, но они могут оказаться неудобными для внешнего пользователя. Если поручить контроль техписателям, контент будет качественным, но бизнес-показатели никто не посчитает. Рабочая модель ответственности за метрики — командная, где у каждой роли свои задачи. Разберем, кто и какие показатели отслеживает ↓
Руководитель поддержки или Customer Success Manager
Отвечает за операционную эффективность базы знаний: нагрузку на операторов, скорость решений и к��чество сервиса. Для руководителя поддержки важно, чтобы контент снижал когнитивную нагрузку на агентов, сокращал время обработки запросов и повышал удовлетворенность клиентов.
Какие метрики контролирует:
Deflection Rate — коэффициент предотвращенных обращений. Это процент пользователей, которые получили ответы в базе и не создали тикет.
CSAT (Customer Satisfaction Score) — показывает удовлетворенность клиента взаимодействием с поддержкой.
CES (Customer Effort Score) — измеряет, сколько усилий потребовалось клиенту для решения проблемы: как долго искал ответ, сколько статей открыл.
Тимлид или старший специалист поддержки
Зона ответственности этой роли — оперативный анализ. Тимлид первым обнаруживает, что база знаний работает не так, как задумано. Информация поступает от операторов: «в инструкциях этого нет», «статьи по теме устарели», «каждый раз объясняю одно и то же, потому что клиенты не могут найти ответ».
Какие метрики контролирует:
Поиски с нулевым результатом (Zero-Result Searches) — количество запросов, по которым пользователь не нашел статьи.
Частые переходы из базы в чат — пользователь открыл страницу, не смог самостоятельно разобраться в вопросе и обратился в поддержку.
Обратная связь от агентов — комментарии к статьям, внутренние замечания и вопросы по работе с базой знаний.
Технический писатель или контент-менеджер
Его фокус внимания направлен на качество контента. Задача техписателя не просто создавать статьи, а делать знания доступными: понятными, структурирова��ными, актуальными. Показатели этого специалиста — про восприятие и вовлеченность.
Какие метрики контролирует:
Рейтинги статей — как пользователи оценивают полезность материала.
Глубина просмотра — сколько страниц одной статьи прокрутил пользователь.
Время на странице — сколько минут пользователь провел в статье.
Комментарии — указания на устаревшую или неполную информацию.
Менеджер по продукту
Он воспринимает базу знаний как часть продукта, поэтому оценивает пользовательский путь и UX (пользовательский опыт). Для роли важно, насколько внешним клиентам удобно работать с базой — это напрямую влияет на лояльность к продукту в целом.
Какие метрики контролирует:
Переходы из продукта в базу и обратно — сколько пользователей кликают на кнопку поиска по базе из интерфейса, открывают статьи из контекстных подсказок, возвращаются в продукт после чтения.
Обращения по конкретным фичам — количество тикетов, связанных с определенной функцией продукта.
Специалисты по данным: дата-аналитик и BI-аналитик
Анализируют сложные взаимосвязи и инсайты. Ключевая задача — объединить разные источники данных в единую аналитическую среду: например, связать метрики базы знаний с CRM-системой и продуктовой аналитикой.
Какие метрики контролируют:
Отсутствие тикетов после поиска — пользователь прочитал статью и не создал запрос в течение контрольного времени.
Корреляция просмотров и тикетов — если количество просмотров растет, а число тикетов по этим же вопросам падает, контент работает эффективно.
Общая эффективность статьи (Article Efficiency Score) — комплексная метрика оценивает рейтинг, глубину просмотра, отсутствие тикета или перехода в чат.
Руководитель направления: CIO (Chief Information Officer) и COO (Chief Operating Officer)
Это роли на уровне стратегического контроля. Руководители направления оценивают сводные отчеты и ключевые бизнес-метрики для принятия управленческих решений.
Какие метрики контролируют:
ROI (Return on Investment) — показатель возврата инвестиций. Отвечает на вопрос «Окупятся ли вложения в базу знаний?»
SSR (Self-Service Rate) — какая доля пользователей решила проблему без участия оператора.
TTR (Time to Resolution) — время решения тикета от первого обращения до закрытия вопроса.
Скорость онбординга новых агентов — как база знаний сокращает время адаптации новичка, а вместе с ним и затраты компании на онбординг.
Просто отслеживать показатели недостаточно, базу знаний нужно постоянно совершенствовать. Поэтому в командной модели важно отладить цепочку взаимодействий между ролями. Например так: поддержка заявляет о проблемах, техписатель улучшает контент, менеджер по продукту смотрит на реакции пользователей, а руководитель анализирует, как все это влияет на окупаемость базы.
Knowledge Manager или менеджер знаний — идеальная роль ответственного за базу знаний
В крупных компаниях ответственность за базу знаний переходит на новый уровень — появляется отдельная должность для контроля за метриками. Такого специалиста называют «Knowledge Manager» или «менеджер знаний». Это владелец процесса, который отслеживает динамику и взаимосвязи между показателями.
Что делает менеджер знаний:
Связывает базу знаний с бизнес-целями. Для этого ставит задачи с измеримыми результатами: «Сократить нагрузку на поддержку на 20% за счет оптимизации контента», «Внедрить интеллектуальный поиск и снизить среднее время ответа до 5 минут».
Интерпретирует данные. Собирает метрики и на их основании делает выводы. Если много переходов из статьи в чат, значит, статья не закрывает вопрос пользователя. Если участились поиски без результата, нужно создать новый контент — в базе нет релевантных статей.
Инициирует улучшения. Предлагает, как сделать базу знаний более эффективной. Например, редактирует сложные материалы, дополняет текст фотографиями и видеороликами, внедряет единые шаблоны статей.
Главная задача менеджера знаний — координировать работу специалистов. Контроль за метриками представляет собой процесс на стыке ролей. Knowledge Manager помогает операторам поддержки, менеджерам продукта, техписателям и аналитикам эффективно взаимодействовать. Он выступает связующим звеном и превращает базу знаний в гибкий и управляемый инструмент.
Поясним на примере. Контент-менеджер посчитал, что пользователи проводят в статье 50 секунд — это хорошо или плохо? Может быть, текст непонятный или, наоборот, решение вопроса есть в самом начале материала. В первом случае нужна доработка от техписателя, а во втором — изменения не требуются. Менеджер знаний оценивает связанные метрики: наличие или отсутствие тикетов и переходов из статьи в чат. И уже на основании этих данных делает вывод о качестве статьи и необходимой доработке.
Как выбрать модель распределения ответственности
Универсального решения нет: выбор зависит от размера команды, зрелости процессов и вклада базы знаний в лояльность клиентов. Вот три популярные модели с привязкой к масштабам бизнеса ↓
Стартап или малая команда. Ответственность, как правило, лежит на одном человеке: например, тимлиде или техписателе. Специалист отслеживает все доступные метрики. Это нормально в начале бизнеса, когда база знаний не обширная, а обращений относительно мало.
Средний бизнес. С ростом компании продукты усложняются, появляются новые направления, растет количество тикетов. Ответственность за метрики распределяется между коллегами. Подойдет командная модель, когда кросс-функциональная группа из разных ролей собирает аналитику и принимает решения.
Крупная компания. Коллегам из разных направлений требуется координатор для контроля за метриками. Управление знаниями вырастает в отдельную должност�� — «Knowledge Manager». Процесс выстраивается по цепочке: точечные метрики и аналитика данных по ролям → менеджмент знаний и сводные отчеты → стратегические решения от руководителя.
Как внедрить и распределить ответственность за базу знаний — пошаговый план
Составили инструкцию, которую можно взять за основу и адаптировать под вашу команду. В качестве примера разберем распределение ответственности за базу знаний в службе техподдержки.
Шаг 1: Оцените текущее состояние аналитики. Выясните, какие метрики коллеги уже собирают, кто их смотрит и делаются ли какие-то выводы по итогам.
Составьте список метрик, которые отслеживают разные роли. Узнайте, что происходит с данными — формируются отчеты, информация попадает к руководителю или показатели остаются в архиве без пользы. Если данные применяют, то как именно и с каким результатом.
Шаг 2: Поставьте стратегическую цель. Определите, что нужно изменить с помощью базы знаний. Не стоит пытаться усовершенствовать все сразу, а лучше сосредоточиться на одном-трех ключевых направлениях. Допустим, руководитель поддержки хочет снизить нагрузку на операторов и ускорить онбординг новичков.
Шаг 3: Назначьте ответственного. Если стратегические цели из разных областей, ответственных может быть несколько. В нашем примере руководитель поддержки может взять ответственность за базу знаний на себя или делегировать старшему специалисту.
Шаг 4: Разработайте форму отчета. Выберите от трех до пяти ключевых метрик, которые ответственный будет собирать раз в неделю или месяц — в зависимости от объема задач. Снижение нагрузки на техподдержку можно оценить по показателям:
Deflection Rate — коэффициент предотвращенных обращений;
Self-Service Rate — доля пользователей, решивших проблему без участия оператора;
частота переходов из статей в чат — сколько раз пользователи обращались к оператору после чтения статьи.
Шаг 5: Создайте совет экспертов. Соберите команду, которая будет периодически встречаться, обсуждать отчет и помогать ответственному оценивать прогресс и корректировать дальнейшую работу. Руководитель поддержки может позвать в совет экспертов контент-менеджера и продакта, а сводный отчет по метрикам передавать руководителю направления.
Шаг 6: Закрепите успех. Внесите ответственность за метрики базы знаний в должностные инструкции, не забудьте про премию за новые задачи 🙂. Когда бизнес масштабируется, рассмотрите вариант с наймом менеджера знаний на отдельную должность.
Как отслеживать метрики базы знаний: инструменты для совместной работы
При работе с метриками важно, чтобы показатели и коммуникация экспертов собирались в единой среде. Тогда процесс становится прозрачным для всех ролей, решения проще фиксировать, а договоренности не теряются в чатах.
В TEAMLY удобно отслеживать метрики базы знаний — на платформе есть специальный модуль «Аналитика». Он показывает, с какими темами и форматами контента пользователи взаимодействуют часто, а какие разделы нужно актуализировать. Примеры доступных отчетов:
Аналитика статьи — когда материал обновляли последний раз, сколько просмотров, лайков и комментариев собрала страница.
Поисковые запросы — по каким темам пользователи ищут контент, сколько человек искали статьи на определенную тематику.
Участники пространств — насколько активно пользователь взаимодействует с базой: как часто оставляет комментарии, читает, пишет и редактирует статьи.
Подведем итоги
Контроль метрик базы знаний — это не разовый отчет для руководителя, а непрерывный процесс. Данные собирают и анализируют, затем на их основе принимают и внедряют управленческие решения. В конце оценивают результат и корректируют действия, если цель не достигнута.
Такая работа часто не под силу одному сотруднику, особенно если у него уже есть другие задачи. Поэтому идеальный ответственный за базу — это Knowledge Manager или менеджер знаний на отдельной должности. Он выступает владельцем процесса и координирует экспертов. В результате разрозненные метрики превращаются в инструмент постоянного улучшения базы знаний.
