Сегодня хочется поговорить о технической поддержке, а точнее о тонкостях, которые обеспечивают ее работу. Недавно мы закончили проект по организации базы знаний, которая помогает выполнять свою работу техподдержке электронных сервисов крупных порталов. Результаты автоматизации говорят о том, что подобный подход может оказаться полезен и для других проектов, и в этом посте я расскажу о распределении ролей и процессов в созданной информационной системе. Заинтересованные найдут под катом — подробный рассказ о том, как работает база знаний СТП (службы техподдержки) для сервисов портала. А я буду рад любой обратной связи, мнениям и, конечно же, предложениям, как можно еще улучшить работу по поддержанию подобной базы знаний.

Техподдержка — это хорошо. Всех злит (и меня тоже), когда невозможно добиться ответа от сотрудников какого-либо сервиса. Но каждый дополнительный инженер техподдержки требует дополнительной зарплаты. И компании по понятным причинам постоянно стремятся оптимизировать количество операторов, использовать искусственный интеллект, а также как-то обойти стадию длительного обучения для сотрудников таких отделов. 

Один из достаточно эффективных методов такой оптимизации, при котором не страдает пользовательский сервис — это формирование базы знаний (БЗ), причем обязательно актуальной, удобной и постоянно самоулучшающейся. При таком подходе можно надеяться на улучшение качества сервиса и повышение эффективности работы техподдержки и контакт-центров. Именно такую базу мы делали для одного крупного портала.
Учитывая, что сегодня опробованная схема решает поставленные перед ней задачи,
возможно, некоторые практики окажутся полезными для организации вашей СТП.

У базы данных должна быть структура

Чтобы при работе с БЗ не было путаницы, все статьи поделены на блоки в зависимости от направления, в которое поступает вопрос пользователя.

Статьи в блоке А создаются для обработки общих и частных вопросов, которые касаются информации на портале, получения услуг и документов, деятельности филиалов и др. Например, ответ на вопрос о том, где узнать о местах и графике предоставления каких-либо услуг, будет найден как раз в блоке А.

Статьи в блоке Б создаются для вопросов, поступающих непосредственно в СТП. Они  связаны с работой сервисов портала, с контентом на портале, деятельностью представительств организации и др. Например, типичный вопрос этого блока: «Что делать, если не получается авторизоваться на портале?».

Таким образом, мы поддерживаем одну базу данных, но информация в ней не варится в «одном котле», а оказывается четко разделена. Сотрудник, отвечающий за общие вопросы, не будет получать технических ответов, и наоборот.

Разделы упрощают поиск

Практика показала, что разделение по тематикам (классификатор) — очень полезная штука. Для удобного распределения вопросов и последующего нахождения статей по ним мы используем цифровые значения для каждого раздела. Например, знания по вопросам оплаты штрафов по личному транспорту кодируются 1-23-n, где n — порядковый номер статьи в этом разделе (1, 2, 3 и тд). 

Классификаторы базы знаний удобнее всего настраивать в соответствии с уже принятой классификацией вопросов в СТП. Таким образом, любая служба может подключиться к системе, задать удобные древа классификации для своей системы, что в разы облегчает поиск статей.

Чтобы техподдержка работала лучше, кроме классификатора названия и номера в каждой статье предусмотрели четыре вида ответов, которые отличаются некоторыми особенностями, в основном стилистическими:

• Официальный. Используется сотрудниками СТП, отвечающими по электронной почте. Самый полный вариант ответа, который отвечает на поставленный вопрос, дает варианты обходных решений, а также содержит ссылки на инструкции и контактные данные. 

• Вербальный. Используется сотрудниками СТП, отвечающими по телефону. Согласитесь, голосом ссылку проговаривать очень неудобно, поэтому для вербального ответа используется «голосовая навигация» - зайдите туда-то, нажмите там-то. Вся избыточная информация (по сравнению с официальным ответом) отсекается.

• Чат. Самый короткий вариант ответа, содержащий максимально сжатую информацию и ссылки на инструкции. В этом случае главное, чтобы пользователь получил ответ на свой вопрос.

• Бот (автоматический ответ). Это почти точно такой же ответ, как и для чата, но используется не оператором, а роботом, отвечающим на первые вопросы пользователей. Для определения тематики бот использует типовые вопросы — это еще одно поле, которое было решено добавить в информационную систему. В число типовых вопросов попадают те запросы пользователей (реальные или гипотетические), которые можно задать, не зная всей внутренней кухни. Чем больше таких вопросов, тем больше у специально обученного алгоритма найти соответствующую статью как по номеру, названию или ключевым словам.

Статусы статей или жизненный цикл системы

В процессе работы мы убедились в том, что статьям полезно иметь несколько статусов, которые позволяют скрывать недоподготовленные знания, архивировать устаревшие, а также влияют на возможность редактирования. Вот несколько полезных примеров статусов:

1. На подготовке – это статус «рождения статьи». Она не видна для сотрудников СТП и её можно редактировать, дополнять, фактически лепить из нее все, что угодно.

2. На проверке Координатора – следующий шаг в создании, статью всё еще не видно и можно менять. Но переводить её дальше (или обратно) может только Координатор. Статус подходит для более зрелых статей.

3. На согласовании – этот статус мало отличается от предыдущего с точки зрения пользователей, но ответственный уже может утвердить статью, и она попадет в активную часть базы знаний.

4. Актуально/опубликовано – статью видят операторы СТП, и вносить в нее изменения можно только переведя в статус «На подготовке»

5. Устаревшая/архивирована – статью не видно и нельзя менять. Она не будет появляться в даже в поиске. Её можно вернуть на подготовку, если ответственное лицо решит актуализировать информацию.

Как статьи появляются в базе?

Для того чтобы дополнить базу знаний, необходимо запустить процесс добавления новых статей. Для этого могут быть разные причины и разные сценарии. Но на нашем проекте мы определили два основных триггера для создания статей:

• Добавлен новый функционал или произошли изменения, по которым у пользователей с большой вероятностью возникнут вопросы.

Например, когда ожидался запуск сервиса по предоставлению новой услуги для пользователей, к моменту релиза в БЗ были подготовлены и внесены ответы, которые позволили операторам колл-центра и СТП успешно отвечать на вопросы в день запуска в прод этой услуги (и даже немного раньше). Если бы операторы составляли их самостоятельно, на обработку одного обращения могло уйти более часа. Использование системы управления знаниями сократило время обработки до нескольких минут.

• Поступил общий вопрос от пользователя, который скорее всего повторится в будущем.

Тут тоже возникает немало типичных ситуаций. Это могут быть вопросы, связанные с особенностями функционирования портала (например графиком приема обращений) или порядка оповещений пользователей о событиях. Поэтому на основании анализа обращений по подобным вопросам, были сформированы знания, описывающее порядок работы портала и получения от пользователя сведений, необходимых СТП для решения проблемы (если она есть).

Таким образом удалось закрывать более 40% обращений сразу, а также наладить коммуникацию СТП/Пользователь и ускорить процесс обработки обращений по заданной теме.

Роли сотрудников в системе

Чтобы в базе знаний не было хаоса, создавать, редактировать, удалять и публиковать статьи должна зависеть от роли пользователя. На нашем проекте таких ролей получилось 4 (хотя, наверное, могут быть и другие варианты. Если у вас иначе, расскажите в комментариях):

• Оператор – может только создавать статьи (заполнять все поля);

• Редактор – может создавать статьи, вносить изменения в подготовленное знание и передавать Координатору;

• Координатор – может намного больше: менять статусы статьи, вносить изменения и так далее. Единственное, чего он не может – опубликовать статью.
  Этим занимается…

• Утверждающий – он может ВСЕ. Ave!

Схемы работы выглядят следующим образом:

Поддержание актуальности информации в БЗ

При работе с любой базой знаний важно понимать, что следить за актуальностью обязательно. Если этого не делать, то весь смысл проекта теряется.

Как не допустить потери актуальности знаний? Для этого мы проводим несколько регламентных работ, предотвращающих ошибки:

Ежеквартальные. Каждые три месяца проверяется ВСЯ БЗ, каждая статья. Для выполнения большого объема работы привлекаются старшие специалисты, операторы и так далее.

Еженедельные. Редакторы портала присылают изменения, которые были в контенте портала за недельный период. Наш специалист проводит проверку имеющихся по тематике статей.

По событиям. К любому релизу нового функционала (или обновления уже имеющегося) проводится проверка знаний по соответствующему функционалу.

Ежедневные. Операторы СТП следят за тем, что они отвечают и какие ответы им предлагает система. В случае несоответствия они могут исправить информацию самостоятельно и сообщить об этом Координатору. После проверки происходит  публикация отредактированной информации.

Взаимодействие с другими СТП

Иногда доступ к базе знаний нужен несколькими командам СТП. А это значит, что операторам этих команд нужно предоставить соответствующий доступ. И разные сотрудники должны видеть сразу все блоки или только «свои».

Но у такой организации работы есть свои плюсы и минусы. Например, для поддержания общности базы необходимо придерживаться единого формата и стиля оформления статей. На сверки знаний уходят дополнительные ресурсы, но при этом у них появляется возможность формирования действительно единой базы данных.

Еще один интересный момент — иногда неактуализированная информация теряется в процессе работы над статьей большого количества людей. Но коллеги из смежных СТП обнаруживают «подвисшие» статьи, наталкиваясь на них в поиске. Такая взаимопомощь оказалась очень полезной, и для ускорения процесса актуализации мы ввели систему маршрутизации обращений по своим блокам базы знаний. Благодаря этому оператор-коллега или его начальник могут сообщить нам об ошибке в статье или о не доведенных до конца наработках, просто написав на электронную почту. Мы, в свою очередь, можем поступить так же.

Работа продолжается

Вообще работа с базами знаний и средствами их автоматизации, наверное, никогда не заканчивается. Все время нужно что-то поправлять, дополнять и улучшать. Но та схема, о которой я рассказал в этом посте, уже позволяет оптимизировать работу техподдержки. А дальнейшие работы по автоматизации процессов должны помочь в объединении баз знаний разных команд СТП, а также помогают формировать лучшие практики по работе с обращениями пользователей.

Будет очень здорово, если вы поделитесь своим опытом и интересными ситуациями в работе с базами знаний и службами техподдержки в своей или чужой компании (например, у заказчика). Может быть наши ноу-хау помогут вам, а наши помогут нам сделать работу со знаниями еще эффективнее.