«Клиент отказался из-за высокой цены», сообщает ИИ после звонка. Вы открываете запись и слышите: «По цене понятно, но во вторник не успеваю. А в четверг есть время?»
Если принять короткий вывод без проверки, команда начнёт обсуждать скидку, хотя человеку нужен другой день. Речевая аналитика полезна, когда помогает найти такие разговоры и увидеть их содержание. Для этого у вывода должна быть ссылка на фрагмент, из которого он получен.
Задайте вопрос, на который есть ответ в разговоре
Просьба «оцени работу менеджера» оставляет слишком много места для догадок. Начните с конкретной работы: найти вопросы без ответа, договорённости о следующем звонке или разговоры, где время визита так и не выбрали.
Для небольшой сервисной компании первый набор может быть таким:
- По какой услуге обратился человек.
- Какой вопрос остался неразрешённым.
- Что предложил сотрудник.
- О чём договорились в конце.
- Кто и когда должен сделать следующий шаг, если это прозвучало.
Каждый пункт нужно уметь проверить по словам участников. Если срок не называли, полезный ответ будет «срок не указан». Придуманное «завтра до обеда» создаст ложную договорённость.
Вопрос «почему клиент в итоге не купил» часто выходит за пределы звонка. Человек мог принять решение позже, поговорить с другой компанией или вовсе отложить задачу. Результат разговора и причина окончательного решения требуют разных свидетельств.
Посмотрите, как выглядит проверяемый вывод
Ниже синтетический диалог, придуманный для статьи. Это не запись клиента и не результат работы внедрённой системы.
Клиент: «На сайте вижу стоимость вводного занятия. Она актуальна?»
Администратор: «Да. Во вторник есть вечернее время».
Клиент: «По цене понятно, но во вторник не успеваю. А в четверг есть время?»
Администратор: «Уточню расписание и перезвоню».
На этом фрагменте можно проверить несколько выводов. Клиент спросил о занятии и времени в четверг. Администратор обещал уточнить расписание и позвонить. Запись на конкретный час не подтверждена. Срок обратного звонка не назван.
А вот утверждение «человеку дорого» фрагмент не поддерживает. Даже если такая причина кажется вероятной по другим разговорам, в карточке этого звонка она должна остаться неподтверждённой гипотезой.
Удобный результат анализа содержит короткий вывод, цитату или временную отметку, а также то, что осталось неизвестным. Тогда руководителю не обязательно слушать всё подряд, но есть возможность быстро проверить спорное место.
Разделите распознавание и понимание
Сначала система переводит речь в текст, затем анализирует полученную расшифровку. Ошибка на первом шаге может изменить смысл второго: «не подходит» превратится в «подходит», а слова одного участника окажутся приписаны другому.
Для пробной проверки возьмите записи с разными условиями: ясная речь, фоновый шум, перебивания, короткий разговор. Используйте только материалы, которые разрешено обрабатывать в выбранном контуре. Доступы к аудио, передача провайдеру и срок хранения должны быть определены до загрузки реальных звонков.
Сравните расшифровку с оригиналом в местах, на которых основан вывод. Особенно внимательно смотрите на отрицания, цены, даты и обещания. Если важный фрагмент не разобран, итог должен показывать неопределённость. Уверенно звучащее резюме не исправляет плохую исходную запись.
Готовый сервис тоже нужно проверять на своей задаче
Не обязательно разрабатывать речевую аналитику с нуля. Например, Yandex SpeechSense описывает поиск по словам, смысловые теги и краткие содержания разговоров. В том же материале предусмотрена проверка тегов на выборке диалогов.
Наличие функции ещё не отвечает на ваш рабочий вопрос. Попросите показать, как сервис выделяет именно ваши ситуации: обещали перезвонить, не назвали срок, предложили неподходящее время. Заранее подготовьте примеры, где нужного события нет.
Если система находит «жалобу» в разговоре, где администратор говорит «жалоб не было», это полезный контрпример. По нему можно проверить, учитывает ли настройка смысл или реагирует на отдельное слово. Больше обнаруженных совпадений не всегда означает более качественный анализ.
Сверьте выводы с независимой разметкой
Для первого прохода выберите небольшой набор разрешённых записей и дайте человеку отметить нужные события без подсказки ИИ. Затем сравните два результата по каждому вопросу.
Смотрите отдельно на пропуски и ложные находки. Пропущенный обещанный звонок может оставить клиента без ответа. Ложная метка «отказ из-за цены» может увести руководителя к неверному решению. Важность этих ошибок определяется вашей задачей.
Часть примеров оставьте для проверки после настройки. Если менять правила на каждом разговоре и затем проверять только на нём же, трудно понять, перенесётся ли результат на новые звонки.
Небольшая выборка помогает обнаружить ошибки и уточнить критерии. Она не доказывает качество на всех будущих разговорах или влияние аналитики на продажи. Для этого нужны дальнейшие наблюдения и сопоставимые данные.
Договоритесь, что происходит после обнаружения
Полезная аналитика заканчивается понятным действием человека. Если система нашла обещание перезвонить, сотрудник сначала проверяет фрагмент и действующее состояние обращения: возможно, звонок уже состоялся через другой канал.
После этого можно назначить следующий шаг в рабочем инструменте. Автоматическое создание задач или изменение CRM требует отдельной проверки прав, повторов и уже выполненных действий. Анализ разговора сам по себе не даёт разрешения менять записи.
Не используйте непроверенную метку как готовую оценку сотрудника. Руководитель должен видеть контекст и иметь возможность оспорить вывод. Обнаруженный неудобный разговор помогает найти вопрос для разбора, а не установить вину по одному резюме.
С чего начать в небольшой компании
Выберите один вопрос, например: «В каких разговорах обещали перезвонить, но не назвали срок?» Определите допустимые источники, ожидаемый вид результата и того, кто проверит находки. Затем пройдите один полный цикл на небольшом наборе.
Если после проверки всё равно приходится слушать разговор целиком и переписывать вывод, это тоже результат эксперимента. Уточните задачу или настройку, прежде чем подключать большой поток.
На разбор ИИ-решения можно сначала принести синтетический диалог и пример нужного результата. По ним проще определить границы первой проверки. А различие между полезным ответом ИИ и выполненным действием в системе разобрано в статье о проверке ИИ-агента.
