Рассказываем о кейсе, где все начиналось со стандартной задачи по автоматизации контроля качества, а развилось в комплексный проект по изучению и улучшению CJM и клиентского опыта
Формулирование ТЗ и целей пилотного проекта: ожидание vs реальность
Ожидание
В центре любого пилотного проекта по внедрению речевой аналитики — документ с техническим заданием (ТЗ) для вендора, составленный заказчиком.
ТЗ отражает ключевые запросы и потребности, которые вы планируете закрыть с помощью технологии. Они и формируют итоговые цели и определяют эффективность пилота.
Ключевая задача заказчика здесь — заложить в поставленные цели потенциальный
В нашей практике мы часто сталкиваемся с такими запросами от клиентов:
01
Автоматизировать контроль качества
С самим по себе запросом все хорошо. Но подкреплен ли он пониманием задачи, которую решит его выполнение? Какую часть оценки действительно стоит автоматизировать, а какую все равно стоит усилить ручным QM? И главное — как настроить эту комбинацию под конкретные выгоды для КЦ?
02
Внедрить весь возможный функционал /сделать, как у конкурентов
Большое количество функций не означает высокое качество решения. Например, часто клиенты ожидают от системы функционала вроде GPT — способности считывать субъективные параметры речи и эмоции. Но понимания, какой эффект это действительно оказывает на бизнес, часто отсутствует.
В этой статье подробно разобрали топ самых частых ошибок при внедрении речевой аналитики и варианты их решения — в том числе риски полной автоматизации и «перегрузки» решения нецелевыми функциями.
03
Самим потестировать продукт на
Логичный и понятный запрос. Самостоятельный тест на
04
Импортозаместить решение, ушедшее с российского рынка
Крупные корпоративные клиенты часто просто ищут замену своим текущим решениям без намерения оптимизировать процессы и анализировать ограничения предыдущего решения.
Реальность
Что не так с запросами выше?
Ни один из них не отвечает на вопрос: на что мы хотим повлиять внедрением решения?
И тут возможны два варианта развития ситуации:
01
Задачу поиска реальных болевых точек в
Риск: увеличение длительности и ресурсоемкости пилота. Заказчику придется проходить путь проработки проблематики вместе с вендором по ходу проекта: искать ответы на неудобные вопросы, вовлекаться в проработку гипотез и кастдевы.
02
В худшем сценарии — вы получаете то, что запрашивали (полную автоматизацию, максимум функционала, понимание, как работает система или российское решение вместо зарубежного). Кстати, часто так и выглядят классические пилоты.
Риск: отсутствие понятного оцифрованного эффекта внедрения технологии на бизнес и, как следствие, слив бюджета на проект.
Чек-лист вопросов для составления эффективного ТЗ
Итак, чтобы приземлить свои ожидания на практику и очертить понятную рамку пилотного проекта для вендора, важно понять, на что вы хотите повлиять внедрением технологии.
Ниже — несколько ключевых вопросов, ответы на которые помогут:
- проанализировать реальные боли КЦ
- отшлифовать ТЗ и сформировать реалистичные ожидания от пилота
Как устроен мой КЦ?
- численность операторов/сотрудников отдела контроля качества
- количество входящих звонков в промежуток времени
- стоимость минуты работы оператора
- каналы коммуникации (входящая/исходящая линии/чаты/почта)
В какой момент и с какими целями клиент взаимодействует с КЦ?
- обращение за услугой
- консультация
- поддержка
и т. д.
Какие инструменты используют сотрудники при взаимодействии с клиентом?
- Excel
- CRM
- платформа КЦ
- скрипты
чек-листы - технологические карты
и т. д.
Как выглядят KPI сотрудников КЦ?
- количество звонков, оцененных контроллером
- конвертация в продажи
- средняя оценка качества звонка
и т. д.
Как сейчас выглядят основные метрики эффективности КЦ?
- AHT (среднее время обработки вызовов)
- CR (количество звонков в промежуток времени)
- CSI (оценка удовлетворенности клиента коммуникацией)
- FCR (доля клиентских вопросов, решенных во время первого обращения)
- конверсия в целевое действие
- Service Level (доля обращений клиентов, обработанных операторами за определенный период времени)
Как мы считаем эти показатели? Можем ли оценить их репрезентативность?
Как между собой соотносятся KPI сотрудников КЦ и основные метрики эффективности КЦ?
Способствует ли улучшению метрик КЦ достижение сотрудниками своих личных KPI?
Есть ли гипотезы о факторах, негативно влияющих на метрики эффективности КЦ?
Например, «у нас высокий AHT, но мы не понимаем, какие тематики на него влияют»
Какие процессы и метрики мы еще не анализируем, но считаем важным анализировать и почему?
Например, «знаем ли мы, какие фразы гарантированно ведут к отказу клиента от предложения?»
В каких процессах мы видим возможности для автоматизации c помощью речевой аналитики?
Например, «мы хотим анализировать коммуникацию
Какие зоны мы хотим усилить/улучшить с помощью автоматизации?
- конверсия в продажи
- ФОТ
- качество сервиса
- текучка кадров в КЦ
- лояльность клиентов
и т. д.
Как решение встроится в общую стратегию автоматизации бизнеса?
Можно ли с помощью речевой аналитики усилить общую CX стратегию компании? Есть ли польза от РА для других направлений бизнеса?
Подход вендора к пилотному проекту: лучшие практики
Качественно сформулированное заказчиком ТЗ поможет улучшить взаимодействие сторон на всех этапах внедрения и задать верное направление проекту.
А что считается лучшими практиками пилотирования со стороны поставщика решения?
01
Вендор проводит аудит до старта проекта
ТЗ отражает понимание текущей ситуации заказчиком. Но даже если оно сформулировано подробно и качественно, хорошая практика со стороны вендора — провести собственную диагностику КЦ. Часть этого исследования происходит до старта проекта в рамках коммуникации с клиентом. Ниже — пример того, как можно внести больше конкретики на начальном этапе и попробовать вывести образ результата из типичных запросов клиентов:
В NCI мы формализовали этот аудит и разделили его на три стадии:
Сбор/анализ информации о клиенте
Формирование у вендора представления об устройстве конкретного КЦ: количестве входящих вызовов/стоимости минуты разговора/числе сотрудников контроля качества/операторов (вопрос 1 в
чек-листе заказчика).Зачем? Чтобы спрогнозировать эффект от внедрения системы
Формирование идеальной модели речевой аналитики для клиента
Здорово, если у клиента есть примерное понимание ожидаемого результата. Если на этом этапе возникают сложности — вендор может предложить клиенту заполнить анкету по целям использования продукта.
Зачем? Чтобы выяснить ожидания клиента относительно идеальной системы
Выявление проблемных зон
Главная задача здесь — определить ключевые KPI клиента и факторы, которые на них влияют
Зачем? Чтобы выявить области бизнеса, которые требуют внимания или улучшения
По сути, главная цель этого предпроектного исследования — сформировать/скорректировать ТЗ вместе с заказчиком и договориться об ожиданиях от пилотного проекта.
Что происходит на практике дальше?
02
Вендор готов выходить за рамки очерченного ТЗ
Успешный пилот — это не только достижение целей, закрепленных в ТЗ. Часто в ходе пилота обнаруживаются новые точки влияния системы на бизнес клиента, о которых последний может не знать.
Задача вендора тут — правильно настроить фокус проекта, то есть:
- сформировать и проверить дополнительные гипотезы или наоборот сузить область воздействия системы, если в этом есть смысл в рамках конкретного кейса.
- выстроить полноценную картинку клиентского пути и подсветить в нем слабые места -> предложить варианты их усиления с помощью продукта.
Кейс 1: Банк
Клиент: консультационный центр одного из
Было: по данным заказчика, операторы вели себя тактично с клиентами, особых проблем на входящей линии при первом приближении не было.
Что выяснили в ходе пилота?
- выявили 32% нецелевого трафика, который на самом деле предназначался для другого подразделения холдинга и другой горячей линии;
- нашли 15% трафика, который можно автоматизировать: это звонки по типовым вопросам, которые можно передать голосовому помощнику, запустив новые сценарии;
- нашли 8 зон роста, проработав которые, можно качественно улучшить CSI и оптимизировать CX стратегию в целом. Например, выяснилось, что операторы не озвучивали одно из ключевых преимуществ услуги, предлагая ее клиентам, что мешало отработать часть возражений и вело к снижению конверсии.
Кейс 2: Организация из госсектора
Клиент: есть собственный КЦ и запрос на контроль качества диалогов операторов (гипотеза клиента заключалась в повышении основных метрик через повышение качества самих диалогов)
Было: несколько пилотов с разными вендорами подтвердили, что операторы общаются корректно. NCI проанализировали 500 записей, проверили их по своему алгоритму и первоначально тоже не нашли существенных проблем.
Что выяснили в ходе пилота?
На этом этапе пилот мог бы быть закончен. Но мы решили выйти за рамки ТЗ и сфокусироваться не на работе операторов, а на устройстве
03
Вендор проводит презентацию для заказчика по результатам пилота
Что происходит на этапе оценки результатов?
- Оценка результатов в привязке к сформулированным в ТЗ ожиданиям
- Оценка инсайтов и собственного исследования вендора (extra mile)
- Общий анализ возможностей оптимизации/влияния продукта на конкретный КЦ с потенциальным оцифрованным эффектом
Мы в Naumen Conversation Intelligence сформировали стандарт презентации клиентам результатов пилота. Она всегда состоит из двух частей:
- Образ результата внедрения РА по заданному ТЗ (
чек-листу ) с описанием эффектов - Дополнительный анализ: что еще важного мы смогли найти/изучить/исследовать за пределами ТЗ
Красные флаги со стороны вендора
А вот маленькая памятка о том, что точно «не ок» со стороны вендора:
- Нет опции пилота в принципе, только демонстрация решения
- Демонстрация функционала решения по презентации, без доступа к
демо-стенду /отдельного демо под клиента - Нет опции обучения и поддержки клиентов
- Вендор не делает собственное исследование, работает исключительно по ТЗ
- Вендор не погружается в
бизнес-процессы КЦ, стремится продать коробочное решение
Главные идеи
- Цель любого пилота — понять, как именно технология может оптимизировать процессы заказчика, и определить конкретный эффект на бизнес и КЦ
- Отсутствие стадии пилотирования как опции существенно повышает риски «слива» бюджета заказчиком на продукт, который не решает понятную
бизнес-задачу - ТЗ на пилот решает две главных задачи: анализ реальных болей КЦ и формулирование реалистичных ожиданий от пилота обеими сторонами
- При этом, успешный пилот — это не только выполнение требований по ТЗ, но и дополнительное исследование вендором проблемных зон и точек роста в рамках КЦ
- Лучшие практики со стороны вендора в ходе пилотирования включают в себя аудит процессов в КЦ перед стартом проекта, выход за рамки ТЗ и анализ всего клиентского пути/CX стратегии компании и проведение презентации по результатам с потенциальным оцифрованным эффектом по требованиям из ТЗ и дополнительным инсайтам.
