Перейти к содержанию

Техника 6.2: Технологии и инструментарий

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

Консорциум разработал программу сертификации, чтобы помочь в процессе выбора инструмента. Программные продукты становятся "Рекомендованными" для внедрения KCS по следующим критериям:

  • Поддерживает работу со своей базой знаний или интегрируется с третьим ПО
  • Наличие внутренней поисковой системы для расширенного поиска по заданным параметрам
  • Предоставляет возможность связывать статьи с заявками
  • Управляет атрибутами статей (статус, аудитория)
  • Предоставляет анализ поведения клиентов в поисковой системе
  • Предоставляет аналитику и отчеты

Список рекомендованного программного обеспечения можно посмотреть здесь.

Интеграция с CRM, мессенджерами и другими инструментами

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

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

Ни одна организация поддержки, внедрившая KCS, не начинала с «идеального» программного продукта и пользовательского интерфейса. Такой уровень интеграции не следует рассматривать как необходимое требование для старта, однако это рекомендуется запланировать и постепенно внедрять, чтобы сотрудники видели постоянное улучшение уровня интеграции.

Блок-схема ниже предлагается в качестве примера того, как может выглядеть рабочий процесс решения тикета.

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

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

Критерии дизайна рабочего процесса

  • Унифицируйте инструменты управления заявками, знаниями и взаимодействия с экспертами
  • Сделайте процесс интуитивно понятным для сотрудников
  • Сведите к минимуму переключение между экранами — создайте «единую панель управления» или «одностраничный интерфейс», обладающий функциями.
  • Объедините в одно место информацию о клиенте, его лицензиях, финансовую информацию (MRR/ARR), прошлые тикеты, уровень его удовлетворенности и т.д.

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

Пять вещей, влияющих на поведение сотрудников:

  • Функциональность ПО - удобство, простота, навигация, интеграция
  • Инструмент оценки и метрики производительности сотрудников
  • Признание коллег, экспертов, карьерный рост
  • Видение общей картины: какие факторы важны для самих сотрудников, а какие для компании или клиентов.
  • Коучинг: эксперты, менторы.

Интеграция с веб-порталами

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

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