Как запустить базу знаний для службы поддержки
12 мин читать
Меня зовут Вера Потехина. Я курирую базу знаний в ITSM 365. Сейчас она включает 71 раздел, 500 статей и постоянно пополняется новыми материалами.
Казалось бы, администрирование столь объемного хранилища должно отнимать много времени. На самом деле трачу на это всего два часа в неделю – 5% от своего рабочего времени. Полный цикл подготовки одного материала в среднем занимает 2-3 часа.
К таким цифрам пришли не сразу. Мы написали регламенты, выстроили процесс обновления контента, немного доработали ИТ-систему. В статье расскажу, как запустили и развиваем нашу базу знаний (БЗ), из каких этапов состояла эта работа и какие получили результаты.
Первичное наполнение базы знаний
Чтобы ускорить запуск, мы решили не изобретать велосипед. Использовали реализованное в «коробочной» конфигурации нашего облачного сервиса деление базы знаний на внутреннюю и внешнюю, а также максимально задействовали накопившийся контент. Не обошлось без улучшений. Вот как команда ITSM 365 внедряла базу знаний.
Создали укрупненные разделы. Излишняя детализация на старте могла затянуть процесс и привести к путанице. Поэтому сперва выделили самые крупные тематические блоки. Когда часть разделов разрослась, разбили их на несколько новых. Со временем становилось легче понять, какие темы внутри существующих блоков стоит сгруппировать отдельно.
Перенесли в онлайн-хранилище имеющиеся материалы. Еще до внедрения базы знаний в команде накопился внушительный багаж полезных инструкций, справочного и обучающего контента. Правда, все это было разбросано по разным гугл-документам, облачным хранилищам и рабочим компьютерам. Часть важной информации вовсе находилась исключительно в головах специалистов и передавалась только устно.
Первым делом мы собрали все имеющиеся материалы и знания, провели аудит, немного доработали и опубликовали. Так развитию БЗ был дан «низкий старт», и не пришлось начинать с нуля.
Связали между собой статьи внутренней и внешней базы знаний. Это упростило выполнение работ, в которых параллельно участвуют специалисты поддержки и пользователи. Например, у нас есть настройка оповещений клиентских команд в Телеграм-боте. Во внешнюю БЗ положили подробную инструкцию для клиентов, как самостоятельно добавить бота. А во внутреннем материале для технических специалистов описали перенос роботизированного помощника на клиентский стенд в ИТ-системе. Из второго контента можно быстро перейти в связанную внешнюю инструкцию и при необходимости порекомендовать ее клиенту.
Распределение ролей и отладка процессов
Мы постарались максимально формализовать работу с онлайн-хранилищем. Кроме того, выполнили ряд дополнительных настроек в реализованной в service desk системе базе знаний, чтобы все члены команды понимали, как распределяются зоны ответственности. Вот что сделали.
Разработали регламент подготовки материалов. В нем прописали участников и этапы создания контента. Основные роли – это куратор БЗ, тимлиды, авторы статей и тестировщики описанных решений.
Что касается этапов процесса, то они таковы:
- планирование материала;
- постановка задачи;
- написание материала;
- передача на тестирование;
- тестирование материалов;
- прием куратором;
- публикация материала.
По каждому этапу сформулировали задачи участников. Например, я как куратор собираю пожелания от команды, назначаю авторов статей и сроки их выхода. Также доношу до экспертов дедлайны, предоставляю различные вводные. На этапе приема контента дополнительно редактирую материал.
Со своей стороны, автор статьи отвечает за подготовку текста и скриншотов, а также передачу на тестирование. Входит в перечень задач и поиск нужного тестировщика. Наконец, автор размещает контент в БЗ, выбирает нужный раздел и проставляет теги. В зоне ответственности тестировщика – практическая проверка получившейся инструкции на триал-стенде системы и дополнительная вычитка материала на предмет ясности формулировок.
Еще добавили в регламент лайфхаки по применению функциональности базы знаний в ИТ-системе. Например, что стоит порекомендовать в качестве интересной темы для публикации по итогам выполнения заявки и какой инструмент для этого использовать.
Наладили планирование материалов в ИТ-системе. Раньше статьи планировали в гугл-документах. Теперь это автоматизировали в ITSM 365. Я создаю в системе задачу на подготовку материала, после чего ее берет в работу специалист поддержки, у которого есть время и знания в предметной области, чтобы ее написать.
Автор не только пишет статью, но и ставит подзадачи на тестирование и вычитку контента. Весь процесс курируется в единой цифровой среде, для каждого шага назначаются исполнители и дедлайны.
Настроили историю изменений контента. Бывает, что автор контента больше не работает в компании или переключился на другую тематику. Тогда важно понимать, к кому обращаться за уточнениями по содержанию материала. Для этого в истории изменений фиксируется, кто из специалистов последним вносил корректировки и актуализировал статью.
Подготовка материалов
Реализованный в нашей базе знаний редактор RTF предоставляет широкую свободу действий при работе с текстом. Чтобы унифицировать правила подготовки и оформления контента, мы создали редполитику и зарегламентировали другие действия.
Разместили в базе знаний инструкцию по написанию статей. В ней отражена наша редполитика и указано, какие аспекты обязательно должны затрагиваться в материалах базы знаний. Это бизнес-ценности предложенного решения, принципы работы, пошаговые настройки и т.д.
Разъясняются в инструкции и правила оформления примечаний, добавления ссылок и скриншотов в материалах. Регламентируются даже такие «мелочи», как выбор шрифтов, вид заголовков и подзаголовков. Подобная общая инструкция помогает авторам найти ответы на все вопросы и готовить качественные материалы.
Интегрировали базу знаний с Telegraph. В этом текстовом сервисе создаем большинство материалов. При помощи Telegraph стандартизировали оформление контента. Например, сервис не позволяет вставлять скриншоты и иллюстрации между пунктами нумерованного списка, т.к. это ухудшает читабельность статей. Исключаются и другие отхождения от корпоративных стандартов, в частности, использование разных форматов заголовков.
Прикладываем файлы к статьям. Такая функция очень удобна при работе как с внутренними, так и с внешними материалами. Например, чтобы применить какой-либо скрипт, специалисту поддержки не нужно копировать его из текста: достаточно скачать файл из вложения. Пользователь же может получить нужный файл по ссылке, которая размещается прямо в статье.
Адаптация системы поиска под бизнес-процессы
В изначальной конфигурации нашей ИТ-системы реализованы поиск статей БЗ по названиям, а также связь материалов с услугами, что позволяет «подтягивать» прямо в заявки ссылки на полезные инструкции. Многие службы поддержки вполне обходятся такими базовыми возможностями. Команда ITSM 365 этим не ограничилась и адаптировала поисковую систему БЗ под свои внутренние процессы.
Ввели синонимы для поиска. Необязательно помнить точное название статьи. Достаточно ввести в поиске одно из ключевых слов, которое относится к тематике материала. Например, инструкцию по интеграции ИТ-системы с Телеграм-ботом находим по запросам Телеграм, Telegram, TG и даже Телега. В ходе работы мы постоянно расширяем логику поиска новыми синонимами.
Реализовали добавление статей в раздел «Избранное». Опция позволяет добавить полезные для специалистов и пользователей материалы в специальный раздел в своем личном кабинете в ИТ-системе. Такие статьи всегда будут под рукой.
Настроили теги для материалов. Это еще один уровень сортировки контента. Так, по тегу «Интеграции с внешними системами» быстро находим материалы, которые касаются взаимодействия ITSM 365 c другими продуктами. Отдельные теги создаем под каждый новый релиз, определенные виды работ и настройки.
Актуализация базы знаний
Онлайн-хранилище нужно пополнять новыми статьями и удалять неактуальные. Первую задачу зачастую берут на себя сами специалисты поддержки. Если кому-то из них постоянно задают похожие вопросы, проще подготовить ответы в БЗ, чем повторять пользователям одно и то же. Специалист поддержки обращается с идеей статьи ко мне как к куратору БЗ. Далее я ставлю соответствующую задачу, формулирую цели публикации. Отслеживание неактуального контента также лежит на мне и всех членах команды поддержки. Помогают актуализировать онлайн-хранилище и возможности ИТ-системы. Расскажу подробнее, как это используем.
Предлагаем темы новых публикаций по итогам выполнения задач. Для этого в форме заявки предусмотрен чек-бокс «Претендент на статью БЗ». Специалист поддержки устанавливает его при закрытии заявки, если считает, что проблему или примененное решение нужно зафиксировать в БЗ. Дополнительно потребуется указать, внешняя это будет статья или внутренняя, для какого раздела она подходит. Сориентироваться в предложенных коллегами темах помогает автоматический отчет, где агрегируются заявки, по которым был проставлен такой чек-бокс.
Сохраняем старые статьи. Некоторые внешние материалы теряют свою актуальность для большинства пользователей, но кому-то еще могут пригодиться. Например, определенная функция ранее реализовывалась через отдельный скрипт, но после нового релиза системы вошла в базовые возможности. Такая статья скрывается и убирается из поиска. Специалистам же она по-прежнему доступна, поскольку скрипт продолжают применять отдельные текущие клиенты.
Информирование об изменениях в базе знаний
Желательно, чтобы участники процесса актуализации БЗ вовремя узнавали о важных изменениях. Поэтому в ITSM 365 мы настроили уведомления ответственных за разделы о добавлении нового контента. Ответственные за статьи автоматически получают оповещения о редактировании.
Что касается информирования всех остальных пользователей и специалистов, то здесь лучше соблюсти баланс. Некоторым полезно отслеживать только новые материалы. С другой стороны, не всегда стоит рассылать массовые оповещения о новинках в БЗ всем сотрудникам компании или клиентам, ведь многие воспримут это как спам. Мы решили эту проблему так.
Позволили пользователям и специалистам следить за обновлениями без лишних напоминаний от системы. Создали раздел «Новые статьи за последние 30 дней». Он добавлен как во внешней, так и во внутренней БЗ. Перейти в него можно прямо из личного кабинета ИТ-системы.
При необходимости настраиваем подписки на разделы базы знаний. Об изменениях в разделе оперативно информируются лишь те, кому это важно. Остальные не получают ненужных уведомлений.
Аналитика по базе знаний
В базовой конфигурации ИТ-системы каждой статье можно поставить оценку по пятибалльной шкале. Средняя оценка по материалу дает понимание, как часто к нему обращаются и насколько он полезен. Мы в команде ITSM 365 анализируем эффективность контента БЗ по другим аспектам.
Отслеживаем добавление материалов в раздел «Избранное». В любой оценке присутствует доля субъективности: понравилась статья или нет. В избранное же добавляются материалы, которые по-настоящему помогают специалистам или пользователям в решении проблем.
Мониторим связанные с материалами заявки. Отслеживаем, при решении каких обращений специалисты поддержки поделились теми или иными статьями. Это показывает степень востребованности контента. К тому же становится проще понять, с какими проблемами на практике сталкиваются пользователи и как развивать описанную в материале функциональность ИТ-системы.
Описанный в статье опыт команды ITSM 365 по управлению знаниями пригодится и другим службам поддержки. Наш подход легко адаптировать под нужные процессы, а значит получится выстроить работу с базой знаний так, как это необходимо компании. Проще сориентироваться на этом непростом пути и не забыть ничего важного вам поможет пошаговый чек-лист.
Хотите узнать, как быстро запустить удобную базу знаний в service desk системе? Попробуйте облачный сервис ITSM 365.