Сегодня хочется поговорить о технической поддержке, а точнее о тонкостях, которые обеспечивают ее работу. Недавно мы закончили проект по организации базы знаний, которая помогает выполнять свою работу техподдержке официального портала Мэра Москвы, приложения Моя Москва и других электронных сервисов Правительства Москвы. Результаты автоматизации говорят о том, что подобный подход может оказаться полезен и для других проектов, и в этом посте я расскажу о распределении ролей и процессов в созданной информационной системе. Заинтересованные найдут под катом подробный рассказ о том, как работает база знаний СТП (службы техподдержки) сервисов для москвичей MOS.ru. А я буду рад любой обратной связи, мнениям и, конечно же, предложениям, как можно еще улучшить работу по поддержанию подобной базы знаний.
Техподдержка — это хорошо. Всех злит (и меня тоже), когда невозможно добиться ответа от сотрудников какого-либо сервиса. Кажется, что они ушли искать ответ в картотеке — такой же как на картинке сверху. Но на самом деле обычно проблема в нехватке свободных рук. Каждый дополнительный инженер техподдержки требует дополнительной зарплаты. И компании по понятным причинам постоянно стремятся оптимизировать количество операторов, использовать искусственный интеллект, а также как-то обойти стадию длительного обучения для сотрудников таких отделов.
Один из достаточно эффективных методов такой оптимизации, при котором не страдает пользовательский сервис — это формирование базы знаний (БЗ), причем обязательно актуальной, удобной и постоянно самоулучшающейся. При таком подходе можно надеяться на улучшение качества сервиса и повышение эффективности работы техподдержки и контакт-центров. Именно такую базу мы делали для портала mos.ru и приложения “Моя Москва”. Учитывая, что сегодня опробованная схема решает поставленные перед ней задачи, возможно, некоторые практики окажутся полезными для организации вашей СТП.
У базы данных должна быть структура
Чтобы при работе с БЗ не было путаницы, все статьи поделены на блоки в зависимости от направления, в которое поступает вопрос пользователя.
Статьи в блоке А (по сервисам Ответы.Мэйл и Яндекс.Кью) создаются для обработки общих и частных вопросов, которые касаются информации на портале mos.ru, получения государственных услуг и документов, деятельности ОИВ. Например, ответ на вопрос “Как получить гражданство РФ?” будет найден как раз в блоке А.
Статьи в блоке Б создаются для вопросов, поступающих непосредственно в СТП. Они связаны с работой сервисов портала mos.ru, с контентом на портале, деятельностью ОИВ, работой мобильного приложения «Моя Москва», получением государственных услуг и документов. Например, типичный вопрос этого блока: “Что делать, если не получается авторизоваться в приложении?”.
Таким образом, мы поддерживаем одну базу данных, но информация в ней не варится в “одном котле”, а оказывается четко разделена. Сотрудник, отвечающий за общие вопросы, не будет получать технических ответов, и наоборот.
Разделы упрощают поиск
Практика показала, что разделение по тематикам (классификатор) — очень полезная штука. Для удобного распределения вопросов и последующего нахождения статей по ним мы используем цифровые значения для каждого раздела. Например, знания по вопросам о штрафах по личному транспорту кодируются 2.143.1.n, где n — порядковый номер статьи в этом разделе (1, 2, 3 и тд).
Классификаторы базы знаний удобнее всего настраивать в соответствии с уже принятой классификацией вопросов в СТП. Таким образом, любая служба может подключиться к системе, задать удобные древа классификации для своей системы, что в разы облегчает поиск статей.
Чтобы техподдержка работала лучше кроме классификатора названия и номера в каждой статье предусмотрели четыре вида ответов, которые отличаются некоторыми особенностями, в основном стилистическими:
Официальный. Используется сотрудниками СТП, отвечающими по электронной почте. Самый полный вариант ответа, который отвечает на поставленный вопрос, дает варианты обходных решений, а также содержит ссылки на инструкции и контактные данные.
Вербальный. Используется сотрудниками СТП, отвечающими по телефону. Согласитесь, голосом ссылку проговаривать очень неудобно, поэтому для вербального ответа используется «голосовая навигация» - зайдите туда-то, нажмите там-то. Вся избыточная информация (по сравнению с официальным ответом) отсекается.
Чат. Самый короткий вариант ответа, содержащий максимально сжатую информацию и ссылки на инструкции. В этом случае главное, чтобы пользователь получил ответ на свой вопрос
Бот (автоматический ответ). Это почти точно такой же ответ, как и для чата, но используется не оператором, а роботом, отвечающим на первые вопросы пользователей. Для определения тематики бот использует типовые вопросы — это еще одно поле, которое было решено добавить в информационную систему. В число типовых вопросов попадают те запросы пользователей (реальные или гипотетические), которые можно задать, не зная всей внутренней кухни. Чем больше таких вопросов, тем больше у специально обученного алгоритма найти соответствующую статью как по номеру, названию или ключевым словам.
Статусы статей или жизненный цикл системы
В процессе работы мы убедились в том, что статьям полезно иметь несколько статусов, которые позволяют скрывать недоподготовленные знания, архивировать устаревшие, а также влияют на возможность редактирования. Вот несколько полезных примеров статусов:
На подготовке – это статус «рождения статьи». Она не видна для сотрудников СТП и её можно редактировать, дополнять, фактически лепить из нее все, что угодно.
На проверке Координатора – следующий шаг в создании, статью всё еще не видно и можно менять. Но переводить её дальше (или обратно) может только Координатор. Статус подходит для более зрелых статей.
На согласовании – этот статус мало отличается от предыдущего с точки зрения пользователей, но ответственный уже может утвердить статью, и она попадет в активную часть базы знаний.
Актуально/опубликовано – статью видят операторы СТП, и вносить в нее изменения можно только переведя в статус «На подготовке»
Устаревшая/архивирована – статью не видно и нельзя менять. Она не будет появляться в даже в поиске. Её можно вернуть на подготовку, если ответственное лицо решит актуализировать информацию.
Как статьи появляются в базе?
Для того чтобы дополнить базу знаний, необходимо запустить процесс добавления новых статей. Для этого могут быть разные причины и разные сценарии. Но на проекте mos.ru мы определили два основных триггера для создания статей:
Добавлен новый функционал или произошли изменения, по которым у пользователей с большой вероятностью возникнут вопросы.
Например, когда ожидался запуск розыгрыша автомобилей после вакцинации, к моменту релиза в БЗ были подготовлены и внесены ответы, которые позволили операторам колл-центра и СТП успешно отвечать на вопросы в первый день розыгрыша (и даже немного раньше). Если бы операторы составляли их самостоятельно, на обработку одного обращения могло уйти более часа. Использование АИС УЗ сократило время обработки до нескольких минут.
Поступил общий вопрос от пользователя, который скорее всего повторится в будущем.
Тут тоже возникает немало типичных ситуаций. С началом учебного года начали поступать обращения от родителей о проблемах с отображением детей в электронном дневнике МЭШ. Анализ поступающих обращений показал, что большинство родителей не до конца понимают процесс добавления ребенка в систему (это делается через школу), поэтому было создано знание, описывающее процесс подачи заявления и сведения, необходимые СТП для решения проблемы (если она есть).
Таким образом удалось закрывать более 40% обращений сразу, а также наладить коммуникацию СТП/Пользователь и ускорить процесс обработки обращений по заданной теме.
Роли сотрудников в системе
Чтобы в базе знаний не было хаоса, создавать, редактировать, удалять и публиковать статьи должна зависеть от роли пользователя. На нашем проекте таких ролей получилось 4 (хотя, наверное, могут быть и другие варианты. Если у вас иначе, расскажите в комментариях):
Оператор – может только создавать статьи (заполнять все поля);
Редактор – может создавать статьи, вносить изменения в подготовленное знание и передавать Координатору;
Координатор – может намного больше: менять статусы статьи, вносить изменения и так далее. Единственное, чего он не может – опубликовать статью. Этим занимается…
Утверждающий – он может ВСЕ. Ave!
Схемы работы выглядят следующим образом:
Упрощенная (Редактор и Утверждающий)
Расширенная (Оператор, Редактор, Координатор, Утверждающий)
Поддержание актуальности информации в БЗ
При работе с любой базой знаний важно понимать, что следить за актуальностью обязательно. Если этого не делать, то весь смысл проекта теряется.
Если говорить про проект, на предмете которого мы сегодня все это рассматриваем, то актуальность знаний была даже важнее, поскольку отвечать нужно было от лица Мэра и Правительства Москвы (как минимум по мнению пользователей). А поэтому любое несоответствие информации в ответе чревато не только справедливым гневом пользователя, но и юридическими последствиями.
Как не допустить потери актуальности знаний? Для этого мы проводим несколько регламентных работ, предотвращающих ошибки:
Ежеквартальные. Каждые три месяца проверяется ВСЯ БЗ, каждая статья. Для выполнения большого объема работы привлекаются старшие специалисты, операторы и так далее.
Еженедельные. Редакторы mos.ru присылают изменения в инструкциях за недельный период. Наш специалист проводит проверку имеющихся по тематике статей.
По событиям. К любому релизу нового функционала (или обновления уже имеющегося) проводится проверка знаний по соответствующему функционалу.
Ежедневные. Операторы СТП следят за тем, что они отвечают и какие ответы им предлагает система. В случае несоответствия они могут исправить информацию самостоятельно и сообщить об этом Координатору. После проверки происходит публикация отредактированной информации.
Взаимодействие с другими СТП
Иногда доступ к базе знаний нужен несколькими СТП. А это значит, что операторам нужно предоставить соответствующий доступ. И разные сотрудники должны видеть сразу все блоки или только «свои».
Но у такой организации работы есть свои плюсы и минусы. Например, для поддержания общности базы необходимо придерживаться единого формата и стиля оформления статей. На сверки знаний уходят дополнительные ресурсы, но зато появляется возможность формирования действительно единой базы данных.
Еще один интересный момент — иногда неактуализированная информация теряется в процессе работы над статьей большого количества людей. Но коллеги из смежных СТП обнаруживают “подвисшие” статьи, наталкиваясь на них в поиске. Такая взаимопомощь оказалась очень полезной, и для ускорения процесса актуализации мы ввели систему маршрутизации обращений по своим блокам базы знаний. Благодаря этому оператор-коллега или его начальник могут сообщить нам об ошибке в статье или о не доведенных до конца наработках, просто написав на электронную почту. Мы, в свою очередь, можем поступить так же.
Работа продолжается
Вообще работа с базами знаний и средствами их автоматизации, наверное, никогда не заканчивается. Все время нужно что-то поправлять, дополнять и улучшать. Но та схема, о которой я рассказал в этом посте, уже позволяет оптимизировать работу техподдержки. А дальнейшие работы по автоматизации процессов должны помочь в объединении базы знаний для всего ДИТ Правительства Москвы, а также помогают формировать лучшие практики по работе с обращениями пользователей.
Будет очень здорово, если вы поделитесь своим опытом и интересными ситуациями в работе с базами знаний и службами техподдержки в своей или чужой компании (например, у заказчика). Может быть наши ноу-хау помогут вам, а наши помогут нам сделать работу со знаниями еще эффективнее.
