Мы попросили AI отличить успешный звонок от неуспешного. Но сами не смогли показать ему разницу

Это первая часть серии “От анализа звонков к управляемому действию”.

Позже, уже после нескольких изменений в базе, критериях и работе команды, за период около трёх недель в проекте были зафиксированы более 120 звонков, 49 предложений аудита, 9 встреч и 5 договоров на ежемесячное обслуживание общей стоимостью 200 000 рублей.

Но первый запуск не дал рабочего отчёта.

Мы начали с логичной идеи: взять успешные и неуспешные звонки, найти различия и на этой основе настроить AI-анализ.

Проблема обнаружилась раньше, чем мы успели всерьёз заняться промтом.

Мы сами не могли однозначно показать системе, какой конкретно звонок считаем успешным.

В одной CRM-карточке было несколько разных разговоров

Компания хотела активнее возвращать клиентов, с которыми раньше уже работала.

Руководству было важно понять:

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

Для первого теста мы запросили несколько примеров успехов и отказов.

На бумаге последовательность выглядела простой:

1. Взять несколько хороших разговоров.
2. Взять несколько плохих.
3. Найти различия.
4. Собрать критерии.
5. Проверить остальные звонки.

Вместо отдельных звонков мы получили ссылки на CRM-карточки.

Но карточка клиента или сделки - это не один разговор.

Внутри могли находиться:

• короткие попытки дозвона;
• промежуточные обсуждения;
• технические вопросы;
• работа с коммерческим предложением;
• повторный контакт;
• звонок, после которого результат появился значительно позже.

В одной карточке было несколько попыток связи и один более длинный разговор.

Он казался очевидным кандидатом на роль успешного звонка.

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

Такой звонок мог быть полезным этапом сделки. Но сам по себе он ещё не доказывал успех.

В другом примере клиент говорил, что решил продолжить работу с другой компанией. Менеджер пытался выяснить причины.

Этот разговор мог быть качественным с точки зрения исследования отказа.

Но почему он был передан как пример успеха, оставалось неясно.

Слово “успех” скрывало несколько разных результатов

Успехом можно считать:

• состоявшийся содержательный контакт;
• правильно выясненную причину отказа;
• назначенную встречу;
• перевод сделки на следующий этап;
• новую задачу;
• подписанный договор;
• поступившую оплату.

Это разные события.

Их нельзя объединить одной меткой без потери смысла.

Если компания хочет оценить действие менеджера, нужно смотреть на то, что он сделал в конкретном разговоре.

Если нужно оценить результат коммуникации, нужно проверить реакцию клиента.

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

Поэтому полезно сразу разделить три уровня.

Действие менеджера

Например:

• выяснил задачу;
• проверил полномочия;
• предложил следующий шаг;
• согласовал дату.

Реакция клиента

Например:

• согласился;
• отказался;
• попросил прислать информацию;
• предложил вернуться позже.

Коммерческий результат

Например:

• встреча состоялась;
• появилась задача;
• заключён договор;
• поступила оплата.

На первом этапе эти уровни были смешаны.

Статус CRM не равен результату отдельного звонка

CRM обычно показывает итог по всей сущности:

• сделка в работе;
• клиент отказался;
• встреча назначена;
• договор заключён.

Но между звонком и итоговым статусом могли произойти:

• переписка;
• отправка коммерческого предложения;
• внутреннее согласование клиента;
• встреча с техническим специалистом;
• изменение бюджета;
• повторные контакты.

Даже успешная сделка не делает автоматически успешным каждый звонок внутри неё.

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

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

Нужна конкретная связка:

Один звонок - одно наблюдаемое действие - одна зафиксированная реакция.

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

Почему AI не мог решить эту неопределённость за нас

Можно передать модели разговор и спросить:

Успешный он или нет?

Ответ, скорее всего, будет.

Но на каком определении он основан?

Без точного правила модель может посчитать успешным разговор, в котором:

• клиент активно участвовал;
• общение было продолжительным;
• стороны договорились продолжить;
• тон был позитивным;
• менеджер хорошо отвечал на вопросы.

Для бизнеса успехом при этом могла считаться только назначенная встреча.

Или только проведённая диагностика.

Или договор.

Или поступившая оплата.

AI может применить определённый критерий к большому количеству коммуникаций.

Но он не должен самостоятельно решать, какой результат важен компании.

Это управленческое решение.

Мы начали работать над промтом раньше, чем определили объект анализа

К этому моменту уже существовала первая инструкция.

Она должна была:

1. Определить, относится ли звонок к повторной продаже.
2. Найти причину отказа.
3. Оценить действия менеджера.
4. Предложить следующий шаг.

Но выполнить эту задачу устойчиво было невозможно, пока не был решён предыдущий вопрос:

Что именно мы размечаем?

Отдельный звонок?

Всю историю клиента?

Этап сделки?

Финальный коммерческий результат?

Мы анализировали отдельные разговоры, но примеры получили на уровне CRM-карточек и итогов всей работы с клиентом.

Это была методическая несовместимость.

Промт не мог устранить её дополнительными инструкциями.

Почему проект правильно остановили

Технически можно было выбрать звонки самостоятельно и запустить отчёт.

Но тогда критерий отражал бы нашу интерпретацию, а не согласованное определение владельца процесса.

Ошибка быстро масштабировалась бы:

• система анализирует сотни разговоров;
• руководитель получает цифры;
• менеджеры получают оценки;
• при первом споре выясняется, что участники по-разному понимают сам результат.

Поэтому первый цикл остановили до появления однозначных примеров и определения успеха.

На тот момент это могло выглядеть как отсутствие результата.

Сейчас я считаю остановку правильным решением.

Мы не получили готовую систему, но и не превратили спорную гипотезу в автоматическую оценку сотрудников.

Что мы сделали бы иначе сейчас

1. Выбрали бы один тип звонка

Например:

Исходящий звонок бывшему клиенту, с которым компания действительно выполняла работы.

Не все звонки отдела и не вся CRM-база.

2. Определили бы одно действие

Например:

Менеджер предложил бесплатный аудит ранее выполненных работ.

Не “хорошо провёл разговор” и не “заинтересовал клиента”.

3. Отделили бы действие от результата

Действие:

• предложил;
• не предложил;
• предложение было неуместно.

Реакция:

• согласился;
• отказался;
• перенёс решение.

Продолжение:

• встреча назначена;
• встреча проведена;
• договор заключён.

4. Подготовили бы конкретные эталоны

Каждый пример должен содержать:

• один звонок;
• полную транскрибацию;
• правильную разметку;
• пояснение владельца процесса;
• связь с последующим этапом, если она нужна.

5. Сначала проверили бы согласованность людей

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

Если люди расходятся, промт писать рано.

Сначала нужно уточнить правило.

Первый вывод серии

Нельзя начинать с просьбы показать успешные и неуспешные звонки, пока успех не переведён в наблюдаемое событие.

Первый вопрос должен звучать иначе:

Какое конкретное действие должно произойти в подходящем разговоре и какое следующее событие мы ожидаем после него?

После первой остановки мы решили зайти с другой стороны.

Если пока нельзя надёжно отделить успех от отказа, можно исследовать сами разговоры и понять, что останавливает клиентов.

Так начался следующий этап - анализ явных и скрытых возражений.

Следующая часть: Мы нашли десятки возражений клиентов. Управленческого ответа от этого больше не стало.

Проверить собственный проект можно с одного вопроса: какое одно событие в коммуникации вы хотите увидеть, прежде чем подключать массовый AI-анализ?

Все материалы серии
Следующая часть →