6 причин, почему ваша база знаний не работает, и что с этим делать
Окей, все согласились, что база знаний нужна и даже начали её вести. Со стороны вроде бы все хорошо, только при внедрении обязательно возникают проблемы, которые с берега не были видны. У вас есть два пути: забить и объявить всё это ерундой, либо понять, почему не получается и исправить это. Предлагаем пойти по второму.
Для лучшего понимания мы подготовили примеры с базами знаний для внутреннего и внешнего пользования (сотрудники и клиенты). Статью делали по материалам очень хорошего доклада.
База знаний не облегчает жизнь
Пример с внутренней базой: сотрудники читают базу знаний, но скорость принятия решений не меняется.
Пример с внешней базой: клиенты пытаются решить проблему с помощью раздела с вопросами, но в итоге все равно пишут в техподдержку.
Это может произойти по нескольким причинам:
Нужных статей нет, потому что их никто не написал.
Статьи написаны, но таким языком, что ничего не понятно.
- Не все специалисты понимают, как писать мануалы и Q&A.
Чтобы решить эту проблему, стоит привлечь всех сотрудников к написанию мануалов и инструкций для базы знаний.
Чтобы отсечь аргумент “я не понимаю, как это писать, я лучше работой займусь”, необходимо подготовить либо готовый шаблон для статей, либо подробную инструкцию.
Что ещё поможет:
использование скриншотов;
стандартные схемы написания, разработанные с учетом целевого подразделения;
- помощь редактора — пусть сотрудники пишут, как могут, а редактор наводит красоту.
При таком подходе скорость решения проблем растет на 10%. А у техподдержки происходит более быстрое (на 40%) закрытие заявки одним ответом.
Компания растет, а вопросы возникают одни и те же
Пример с внутренней базой: на второй день работы каждый новичок не может зайти в свой ЛК из-за особенностей системы безопасности - приходится идти к сисадмину.
Пример с внешней базой: клиент видит на экране “Error 502”, а в базе знаний решение проблемы прячется за заголовком “Прокси-сервер получил неверный ответ восходящего сервера”. Разумеется, он звонит в саппорт.
С одной стороны, это может свидетельствовать о проблеме, не касающейся базы знаний — её надо просто решить.
Либо же здесь происходит конфликт языка разработчиков и простых людей.
База знаний не обязательно должна быть похожа на википедию, в некоторых случаях можно сделать всплывающие подсказки или поп-апы с подсказками. Так можно в моменте решить до 50% проблем без привлечения техподдержки.
Вы сделали крутые онбординги, но новички всё равно буксуют на старте
Пример с внутренней базой: новичок, получая новую задачу, гуглит, спрашивает о коллег, изобретает велосипед и только потом пытается искать в базе знаний.
Пример с внешней базой: по сути, то же самое, только вот так теряться может и пользователь, и новичок в техподдержке.
Вы же сами проводили собеседования, проверяли тестовое задание и уже несколько дней/недель работаете с этим человеком. Не может же он так тупить! Но если это происходит, вспомните: вы ему вообще объяснили, как работает ваша база знаний?
В период адаптации новеньких важно не только сказать, что у вас есть база знаний, но и показать, как с ней работать. Не все интуитивно это понимают. Поэтому подготовьте инструкцию, как выделять симптомы проблемы и искать решение в базе.
Что дает такой подход:
сотрудник учится не только техническим знаниям, но и получает навык по диагностике проблемы;
новичок лучше ориентируется в базе, а в последствии сможет её улучшать.
Статьи в базу знаний пишут специальные люди
Примеры для внутренней и внешней базы: мануалы по решению технических проблем написали программисты, насытив терминами, словами на английском и т.д., так что их трудно понимать неэксперту. Или наоборот, наняли литературных редакторов, которые написали красиво, но упустили много профессиональных моментов, так что проблему все равно невозможно решить.
Мы уже сказали выше, что к написанию статей базы знаний удобно привлекать всех сотрудников: узнал о проблеме → нашел решение → описал все это в мануале. Всё это без отрыва от производства.
Если открывать для этого отдельную должность, это значит:
- найм новых сотрудников или перераспределение обязанностей;
- потеря экспертизы для авторов статей;
- проблема выгорания от однообразной работы;
- проблема приоритизации: какие статьи писать первыми.
Но это не значит, что и без того загруженным сотрудникам надо навалить обязанности по написанию талмудов.
Руководитель обязан обеспечить полное выполнение всех работ и своевременное написание инструкций.
Практика показывает, что такое разнообразие улучшает настроение сотрудников на 30% и не приводит к выгоранию.
Вы не работаете со статистикой по статьям
Пример для внутренней базы: некоторые статьи супер популярны, а другими пользуются раз в год.
Пример для внешней базы: идеи новых фичей берутся откуда угодно, кроме базы знаний.
Ради эксперимента поставьте счетчик просмотров статей в вашей базе знаний. Это дает огромный рывок для отслеживания багов. Цифры могут дать почву для раскрутки новых фичей продукта и исправления существующих ошибок.
У нас ведь нет задачи, чтобы клиент обращался в базу знаний. Нам надо, чтобы он пользовался продуктом. А если какая-то статья пользуется огромным спросом, значит, у многих возникают проблемы именно по этому вопросу. Тогда надо либо проблему решить, либо перевести статью в формат, например, подсказки, чтобы человеку не приходилось искать ответы в базе знаний или в техподдержке.
В конце концов, самые популярные статьи можно превратить в те же всплывающие подсказки, чтобы сервис стал более удобным для клиентов и сотрудников.
Люди не совсем понимают, зачем вообще нужна база знаний
Пример для внутренней базы: начальство и сотрудники не осознают ценность базы, поэтому забивают на неё.
Пример для внешней базы: клиенты вообще не знают про базу знаний или думают, что она помогает хуже, чем живой человек из техподдержки.
На самом деле в этой проблеме все идет сверху: не понимает начальство - не понимают сотрудники - все вместе относятся поверхностно.
Поэтому, если база не приносит результата, убедитесь, что вся цепочка пользователей понимает её функции.
В конечном счете база знаний:
вносит разнообразие в рутинную работу — для рядовых сотрудников;
- уменьшает текучку и улучшает настроение в коллективе — для тимлидов;
- предотвращает рост штата при росте числа клиентов — для топов.
Подведем итоги
Для эффективной работы с базой знаний необходимо:
Научить сотрудников работать с базой (искать инструкции, писать новые статьи, предлагать улучшения).
Вовлечь всех сотрудников в работу (обеспечьте их необходимыми инструкциями и шаблонами с самого начала работы).
- Записывайте все новые знаний, с которыми сталкиваетесь - пусть это станет частью корпоративной культуры.
- Убедитесь, что все люди понимают важность базы знаний.
- Анализируйте статистику по просмотрам, чтобы оперативно находить идеи по улучшению сервиса.
Надеемся, наша статья дала ответы на ваши вопросы, почему не удается сделать базу знаний полноценным инструментом бизнеса. Какие проблемы с ведением БЗ вы могли бы добавить в этот список?
У нас интересный кейс. Почти для каждой статьи в базу знаний приходится проходить путь, предоставляя себя пользователем. Так вот при таком проходе очень часто появляется понимание того, что тут или там нужно внести какие-то доработки, или же вообще исправить баг.
Так что наполнение базы знаний может быть полезно не только для сотрудников и клиентов, но и для продукта в целом.
О, слушайте, у вас такая идея классная! Я тоже считаю, что это реально очень интересная мысль: представить себя на месте пользователя и посмотреть на свой продукт.
И когда пишешь для базы знаний, это в каком-то смысле проще сделать, потому что когда долго что-то пилишь - взгляд замыливается.
Такой вопрос: а как вы у себя эту идею реализовали среди своих сотрудников?
Блок про специальных людей - не совсем понятно, кто в итоге должен писать статьи (т.к. если это сотрудник, решающий проблему, то он = эксперту со специфическими терминами) и какой объем времени уделять для написания статей оптимально
Спасибо за вопрос. Это может быть либо технический писатель, у которого есть и технические знания, и навыки работы с текстом. Но если нет возможности его нанимать или сфера другая, не ИТ, то писать статьи для клиентов могут и джуны. С одной стороны, они могут изложить это более понятно для клиентов, с другой - они сами растут. Пообщался с сеньором - написал статью - уже запомнил информацию.
По времени: по опыту написать статью с нуля да ещё и со скринами за полчаса нереально. Но тут выручает шаблон. Перечислил пункты или наводящие вопросы - уже не сидишь над пустым листом, а просто пишешь. Так можно минут за 40, если вся информация есть. Если без шаблона - то можно и 8 часов сидеть и ничего не написать.