5 критериев, что ваша база знаний работает неэффективно
Как и всё самое прекрасное в этой жизни, выступление про 5 критериев неэффективной базы знаний и способы это исправить попалось мне абсолютно случайно. Анжелика Федько из компании Plesk разложила всё по полочкам, с цифрами и доказательствами 🔥
Делюсь конспектом и ссылкой на видео, приготовьтесь сначала расплакаться от ностальгии или осознания, а потом вдохновиться!
Я вот села вспомнила базы знаний со своих мест работы. В одной компании у техподдержки вообще не было базы знаний. Во второй обе базы знаний (внешнюю и внутреннюю) я создала с нуля, но по теории эффективности из видео, они работали на 20% (1 критерий из 5). В третьей актуальная база знаний была одним из приоритетов всей компании, поэтому работала на 100%.
Хотите проверить, как обстоят дела у вас? Ниже приведены критерии не(!)эффективной базы знаний.
Критерий 1: Сотрудники прокачиваются, получают все новую экспертизу, а время решения вопросов не сокращается.
Ситуация:
- Пришла заявка от клиента, инженер её решил.
- Спустя какое-то время пришла заявка с такой же проблемой, её решил уже другой инженер, но примерно за то же время.
Почему? Потому что как правило, если инженер решает проблему, то документирует решение в своих личных заметках (на этом месте я понимающе вздохнула 😅).
Решение: заставить всех писать в базу знаний
“Это легче сказать, чем сделать!” — мысленно возразите вы. Поэтому давайте рассмотрим, почему же сотрудники этого не делают и как с этим работать. Будет две группы причин, условно разделим их на “не хочу” и “не могу”.
- “Не хочу” = “не вижу выгоды для себя”, потому что написание статей создаёт конфликт с личными целями сотрудника.
Такое бывает в определённых корпоративных культурах, например, если состязательный момент у инженеров поддержки заложен в KPI, и поэтому они не настроены делиться знаниями.
Решение: работа со знаниями должна быть включена в KPI инженера, но не напрямую.
Плохой пример: поощрения за число созданных статей.
Хороший пример: каждая заявка должна заканчиваться статьёй. - “Не могу” = “не знаю”, потому что процесс документирования сложный и/или не понятный.
Здесь на помощь придут внутренние гайды и шаблоны для статей, чтобы вместо статьи не получить сочинение на вольную тему.
А ещё готовый шаблон убирает страх белого листа, так проще начать писать статью с нуля.
Вот примеры хорошей структуры, чтобы создать свои шаблоны: “Question/Answer” и “Symptoms/Cause/Resolution”.
Плюсы подхода “заставить всех писать статьи” (цифры процентов взяты из видео):
- На 16% вырастает скорость решения заявок.
- Заявки закрываются 1 ответом на 40%.
Критерий 2: База знаний растет, количество клиентов увеличивается, а вопросы от них всё те же.
Причина: статьи написаны языком сотрудника, а не клиента.
Решение:
- В поиске по базе знаний должны выпадать симптомы, как их видят клиенты. Например, если клиенту показывается окно с сообщением “error 502”, то он с высокой вероятностью будет искать “error 502” в базе знаний. Он не будет искать по коду ошибки из внутреннего лога, о котором знают только инженеры техподдержки 😅
- Совсем в идеальном случае, когда клиент создаёт заявку в техподдержку, то сразу в форме создания заявки ему надо показывать статьи, которые могут помочь решить проблему. Клиент переходят туда, находит решение и не пишет в поддержку 👍
Плюсы подхода (цифры процентов взяты из видео):
- Как результат, case detection (то самое распознавание своей проблемы и её решение с помощью статьи) вырос на 50%
- Сотрудникам стало интереснее работать, так как однотипные проблемы клиенты могли найти поиском по базе знаний и применить решение из статьи вместо того, чтобы писать в поддержку.
Критерий 3: Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют.
Пример из видео:
- Свеженанятый сотрудник техподдержки месяц обучается у тренеров в специальном отделе, потом приходит в “свой” отдел. Там ему первое время помогают тимлид и специально выделенный наставник (читайте: времени на онбординг тратится ого-го сколько, если просуммировать время всех вовлечённых специалистов).
- Когда этому сотруднику приходит новая заявка, он пытается её решить самостоятельно и, идёт искать в базу знаний только если самостоятельно решить не получается. А надо наоборот!
Решение:
- В обучении новых сотрудников нужен баланс между тренингами по продуктам и тренингами по процессам (по сути: как и когда искать статьи в базе знаний).
- Например, пришла новая заявка → ищем сразу в базе знаний, что там есть по теме → применяем полученное решение → находим новые симптомы проблемы → снова ищем в базе, на этот раз их.
То есть искать по базе знаний надо на каждом этапе решения заявки.
Плюсы подхода:
- Новенькие быстрее обучаются, как диагностировать проблемы.
Критерий 4: Только ограниченный круг людей пишет в базу знаний.
Пример: статьи пишут только “избранные” сотрудники — либо с большой экспертизой, либо с самым хорошим английским.
- Начинаются проблемы приоритезации: какие статьи править сейчас, а какие ещё подождут.
- Отдельные куски базы знаний устаревают быстрее.
- Сотрудники, которые постоянно пишут статьи, меньше работают с заявками и меньше прокачивают экспертизу в решении клиентских проблем.
Решение:
- Вовлекайте всех сотрудников в документирование знаний и написание статей. Супер-знания английского здесь не так важны, как своевременное документирование.
- Нет спроса на знание — нет статьи, не пишите статьи по принципу “авось пригодится клиентам”, описывайте только востребованные вопросы и проблемы.
Плюсы подхода:
- У сотрудников быстрее растёт экспертиза и они в целом довольнее работой (делиться знаниями — круто и интересно).
- Статьи в базе знаний постоянно актуальны.
Критерий номер 5: Ни новые фичи, ни фикс багов не улучшают NPS продукта, либо улучшают его незначительно.
На первый (но только на первый!) взгляд этот критерий не связан с базой знаний. В реальности база знаний даёт информацию про популярные пользовательские сценарии, которые нужны клиентам, но о которых могут не догадываться разработчики.
Например, в топе посещений у вас статья, какие настройки лучше изменить вручную сразу после установки приложения. Если так, то логичнее на своей стороне сделать, чтобы нужные значения автоматически выставлялись во время инсталляции, а не клиенты их правили.
Решение:
- Постоянно анализируйте статьи в базе знаний (у меня стоит напоминалка в календаре, что каждый последний день месяц я смотрю аналитику читаемости статей в Help Center).
- Задача-минимум: добавьте счётчики просмотров к каждой статье, чтобы вычленить самые популярные и читаемые.
- Задача-максимум: убедитесь, что у вас есть техническая возможность сопоставить заявку и статью, и убедиться, что именно эта статья помогла решить вот эту проблему.
Критерий 6, бонусный:
Сотрудники и/или топ-менеджмент не понимают, зачем нужна база знаний.
Ситуация:
- Сотрудники то пишут статьи, то не пишут.
- Топ-менеджмент выделяет всё меньше ресурсов на развитие базы знаний.
Что делать? Необходимо убедить всех людей, что им это нужно:
- Инженеры получают интересные задачи, а не тонут в текучке однотипных вопросов от клиентов.
- Тимлиды получают довольных, не выгоревших от рутинных задач сотрудников.
- Топ-менеджмент получает меньше расходов на рост отдела техподдержки, клиенты сами находят в базе знаний ответы на типовые вопросы, следовательно, можно обойтись меньшим числом сотрудников.
Ну как у вас, много критериев получилось? Будете внедрять подход из презентации у себя? 🙋
Подведём итоги:
- Вовлекайте всех сотрудников в процесс документирования знаний.
- Анализируйте посещаемость статей, не пытайтесь думать за клиентов и писать статьи по принципу “вдруг пригодится”.
- Научите сотрудников работать с базой знаний, это один из ключевых навыков.
- Убедитесь, что все заинтересованные в работе базы знаний люди понимают её важность.
Дополнительные материалы по теме:
Ссылка на видео с выступлением:
