Моделирование процесса внедрения интеллектуального чат-бота в работу службы технической поддержки

Введение

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

Практика показывает, что до 60–70% обращений в поддержку – это однотипные вопросы («как сбросить пароль», «где мой заказ», «почему не работает вход»). Если на такие вопросы отвечает живой человек, компания тратит квалифицированный ресурс впустую [1, с. 15-20].

Решением проблемы является внедрение чат-бота. Однако, главная ошибка многих предприятий – попытка внедрить технологию без понимания процесса. Если просто «прикрутить» бота к сайту, не продумав сценарии его взаимодействия с операторами и базой данных, это приведет лишь к раздражению клиентов.

Цель данного исследования –спроектировать модель используя нотацию BPMN (Business Process Model and Notation), включив чат бот.

Анализ текущего состояния процесса («As-Is»)

Внося изменения в любой процесс, необходимо зафиксировать его рабочее состояние в данный промежуток времени. В качестве объекта исследования была выбрана типовая служба поддержки IT-сервиса. Рассмотрен и проанализирован один из процессов «Обработка обращения клиента» на рисунке 1.

В ходе построения и анализа модели As-Is был выявлен ряд недостатков:

• входящий поток: клиент пишет вопрос в чат или на почту, при этом заявка попадает в общую очередь Service Desk;
• первичная реакция: оператор (диспетчер) открывает заявку, читает её, что требует больших временных затрат (Reaction Time);
• классификация: оператор вручную определяет категорию проблемы.

Если вопрос простой (FAQ), оператор ищет шаблон ответа, копирует его и отправляет. Эта рутинная работа ведет к выгоранию сотрудников [3, с. 44-48].

Рис. 1. Диаграмма «Обработка обращения клиента» (модель As-Is)

• эффект «бутылочного горлышка»: в часы пик операторы физически не успевают решить все задачи, из-за этого время первого ответа может достигать нескольких часов;
• человеческий фактор: уставший сотрудник может нагрубить, ошибиться в классификации или забыть отправить шаблон;
• отсутствие режима 24/7: ночная смена требует больших затрат, поэтому ночью поддержка либо не работает, либо отвечает очень медленно.

В процессе моделирования «As-Is» становится понятно, что автоматизировать нужно не весь процесс, а конкретно этапы № 2 и 3 (первичная реакция и классификация), а также частично № 4 (решение по шаблону).

Разработанная модель «To-Be», с использованием чат-бота, предлагает изменения в процессе «Обработка обращения клиента», учитывая ряд выявленных выше недостатков и частично ликвидировав или нивелировав их.

Рис. 2. Диаграмма процесса «Обработка обращения клиента» с использованием чат-бота (модель To-Be)

Алгоритм работы новой модели:

1. Инициация диалога. Клиент пишет сообщение. Перехват сообщения осуществляет Бот, а не оператор. Время реакции – мгновенно (менее 1 секунды).

2. Анализ тональности. На этом этапе (которого нет в стандартных решениях) система оценивает психоэмоциональное состояние клиента:

• Если выявлен высокий уровень агрессии (шлюз «Агрессия?» – «Да»), бот не пытается отвечать самостоятельно, чтобы не раздражать пользователя, и сразу переводит диалог на оператора с пометкой приоритета.
• Если тон сообщения нейтральный (шлюз «Агрессия?» – «Нет»), процесс идет по стандартному сценарию.

3. Распознавание интента (намерения). Бот анализирует ключевые слова:

• Ветка «Знаю ответ» (Да): Бот находит решение в Базе Знаний и выдает автоматический ответ. Процесс завершается.
• Ветка «Не знаю ответ» (Нет): Если уверенность алгоритма низкая или вопрос сложный, происходит переключение на человека.

4. Работа специалиста. Оператор получает задачу. В случае агрессивного клиента он сразу видит предупреждение и использует скрипты погашения конфликта. В случае сложного технического вопроса – приступает к его решению.

Важный нюанс моделирования: в схеме обязательно нужно предусмотреть «аварийный выход». В любой ветке диалога у клиента должна быть кнопка «Позвать человека». Если «загнать» пользователя в бесконечный цикл общения с роботом, это убьет клиентский сервис. В BPMN-схеме это реализуется через событийный подпроцесс (Event Sub-process).

Ожидаемые результаты и метрики исследования

Предложенная модель To-Be при внедрении в рабочий процесс, должна показать следующие результаты:

1. Разгрузка первой линии (L1 Support). Согласно расчетам, бот способен закрывать до 40–50% обращений самостоятельно. Это заявки категории «Как восстановить доступ» и «Тарифы».
2. SLA (Service Level Agreement). Время первого ответа сократиться с часов до секунд.
3. Снижение стоимости контакта. Обработка запроса ботом стоит в разы меньше (электричество + амортизация сервера) работы оператора.
4. Качество работы персонала. Операторы не будут работать «автоответчиками» и начнут заниматься реальным инжинирингом, что повысит их мотивацию и профессиональный рост [4, с. 11-14].
5. Удержание клиентов. Благодаря модулю анализа тональности исключаются ситуации, когда «робот» отвечает шаблонами уже рассерженному клиенту. Это снижает риск ухода пользователей к конкурентам из-за плохого сервиса.

Однако, в ходе создания модели были выявлены риски.

Главный риск – неправильная настройка сценариев. Если бот будет отвечать некорректно, количество повторных обращений (Reopen Rate) вырастет. Поэтому процесс внедрения должен быть итеративным: сначала бот только подсказывает варианты, и только потом начинает отвечать.

Заключение

В ходе работы была спроектирована модель внедрения интеллектуального помощника в бизнес-процесс технической поддержки. Использование графической нотации BPMN позволило выявить скрытые связи и избежать классической ошибки – полной изоляции клиента от человека.

Чат-бот не должен быть просто «автоответчиком». Эффективная модель – это адаптивная система: бот берет на себя повседневную работу сотрудника, но при этом «уступает дорогу» человеку, если фиксирует напряжение в диалоге. Предложенная схема позволяет масштабировать службу поддержки, сохраняя человеческий подход к клиентам.