Комментарии 3
Если я правильно понял, база знаний у вас нарабатывается в основном на основе обращений клиентов в техподдержку? Но до внедрения базы знаний ваши инженеры уже имели возможность искать похожие заявки за предыдущие периоды? И заявки эти и так уже уже были написаны «языком клиентов», причём без всякой суеты с вашей стороны. И действия по конкретной заявке у вас в той или иной форме наверняка документировались.
Непонятно… теперь инженеры должны получить заявку, поискать ее в базе, в случае ее уникальности подогнать ее под некий шаблон оформления, занести описание проблемы в базу, не забыв при этом наступить на горло своей «технической скиллованности», описать решение «в картинках». Затем выполнить заявку, задокументировав проведённые работы. Причём последнее действие выполняется в любом случае.
Дополнительную работу - вижу. Откуда берётся, как вы изящно выразились, «бенефит», да ещё с заметными невооружённым глазом процентами - не вижу. Или инженеры искать похожие заявки и не пытались раньше, а сразу начинали гуглить где угодно, но не в своём сервисдеске?
Также мы столкнулись с тем, что работа со статьями должна быть оценена, то есть включена в личный KPI сотрудника. KPI необходимо тщательно проработать. Например, нельзя ставить цели на количество созданных статей, потому что ее легко похачить, создав кучу дубликатов, которые никому не будут нужны. Гораздо эффективнее ставить цель, что каждая заявка должна заканчиваться статьей.
Тоже туманно звучит… Количество статей в качестве цели можно «похачить» созданием кучи дубликатов, а вот статья по каждой заявке - это что, гарантия от дубликатов?
Очень интересно, спасибо, что поделились своим опытом. Как уже было написано в комментарии выше, возникает вопрос: если не секрет, почему базу знаний наполняет тех.поддержка у вас? Это у них не так много работы по тикетам и есть время писать тексты (а я знаю, что нормально написать текст, ещё и со скринами - не полчаса)? Или в целях экономии на штате технических писателей или другим причинам? Очень интересно 👀
Со стороны своего же опыта развития базы знаний и документации в крупной компании, разрабатывающей решения для видеосвязи, изложу некоторые мысли. При этом у нас база знаний - отдельная сущность, а документация - отдельная. Документация по продуктам подробно описывает решения, их возможности, и ряд вопросов, поднятых в статье, покрываются грамотно написанной документацией (например, не надо делать статью о настройке программы, если об этом подробно написано в документации). А база знаний описывает задачи, какие-то модели применения продуктов в тех или иных ситуациях. И отдельно описывает детально в картинках "для новичков" какие-то важные основные моменты, которые клиенты могут полениться читать в документации (такое, к сожалению, есть, и надо подстраиваться). И наполнением базы знаний занимается выделенный отдел технических писателей.
И на практике (ранее я работал в другой компании разработчиком и сам описывал наше ПО) получается, что если нет тех.писателей, то тратят время на составление текстов тех.поддержка и/или разработчики, но делают это не так качественно и понятно, как мог бы писатель с айти-навыками. То есть КПД создания и описания продукта повышается при разделении задач.
Критерий № 1. Сотрудники прокачиваются, получают новую экспертизу, а время решения вопросов не сокращается.
Тут я совершенно согласен, и на самом деле как бы ни была организована работа с базой знаний, её цель для бизнеса - сократить затраты времени на решение повторяющихся запросов от клиентов. Уже как следствие будут частые заходы, прокачка сайта по SEO, любовь и доверие к компании, которая пишет понятные инструкции, и т.п.
Но при наличии выделенного отдела тех.писателей обе причины нивелируются, т.к. они делают свою работу, изучая и описывая продукт, и имеют для этого необходимые технические знания и умение общаться с разработчиками с одной стороны, и умение грамотно составлять тексты - с другой.
Запросы же на появление новых статей приходят исключительно от тех.поддержки или (в меньшей степени) возникают при выходе крупных обновлений продукта, когда надо описать интересный кейс применения свежей фичи. Тут важно взаимодействие и доверие в профессиональном плане между отделами.
Критерий №2. База знаний растет, количество клиентов увеличивается, а вопросы от них все те же.
Опять же, технический специалист (из тех.поддержки или разработчик) далеко не всегда является хорошим тех.писателем и может написать понятный и полезный связный текст. Указанная в данном критерии проблема грамотно решается выделенными писателями.
Критерий №3. Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют.
Тут речь уже больше про ознакомление с существующими статьями новых сотрудников компании. И тут есть несколько подходов. Например, составить список частых проблем со ссылками на соответствующие статьи. Но это время и как-то выглядит не продуктивно. Другой подход, полезный для клиентов и коллег - структурировать базу знаний по разделам и разнести по ним статьи. Это значительно ускорит поиск, и в большинстве случаев даже не понадобится искать что-то по сайту по ключевым словам.
Критерий №4. Только ограниченный круг людей пишет в базу знаний.
Тут сказать нечего - у нас это отдел тех.писателей, у нас есть необходимые скиллы и время для этого.
Критерий №5. Ни новые фичи, ни фикс багов не улучшают NPS (Net Promoter Score) продукта, либо улучшают незначительно.
В нашей компании практикуются вебинары с открытым обсуждением продуктов, чтобы получить от клиентов обратную связь и улучшить наши решения. Также у нас по всем каналам внешнего общения с ними (почта, обращения в тех.поддержку, Телеграм-канал) происходит сбор пожеланий, их анализ на адекватность и количество запросов, и внедрение в дальнейшем в продукт тех, которые являются действительно хорошими. Средства связи в 21 веке позволяют удобно собирать и обрабатывать такие запросы, и все довольны.
Критерий №6. Сотрудники либо топ-менеджмент не понимают, зачем нужна база знаний
Опять же, частный случай, если есть отдел тех.писателей, то компания уже ясно понимает, зачем он нужен 😊
"И на практике, что если нет тех.писателей, то тратят время на составление текстов тех.поддержка и/или разработчики, но делают это не так качественно и понятно, как мог бы писатель с айти-навыками".
Как писатель получает информацию, что написать в KB: откуда узнаёт, какие вопросы требуют срочного освещения в KB, если у него нет связи с пользователями, и он не сидит в техподдержке?
Я вижу вариант, что сотрудник ТП тогда формирует какой-то черновик статьи по паре кейсов, указывает симптомы, решение и ссылку на тикет для деталей и скринов, и передаёт техписателям, чтобы довели до ума и оформили уже для публики.
PS Кто у вас ведёт вебинары по продуктам, какие платформы используете?
Пять критериев неэффективной базы знаний и как всё исправить