«Как аналитика отказов и ИИ помогли точнее понимать трафик и увеличить конверсию»: кейс Русской школы управления

Компания работает на высококонкурентном рынке бизнес-образования, где отдел продаж должен справляться как с B2B-, так и с B2C-воронками. При этом рост и обучение менеджеров осложнялись сразу несколькими факторами: высокая текучка, слабая мотивация новичков и нехватка специалистов с нужным опытом. Зачастую новички приходили без навыков продаж и ожидали быстрых результатов — без готовности к системной работе. А сильные менеджеры, наоборот, работали по собственным паттернам, которые не всегда совпадали с целевой моделью.

Управление таким отделом требовало «тотального» контроля диалогов, но это было невозможно: текущие ресурсы компании не позволяли вручную отслеживать весь объём звонков. Последняя попытка наладить ручной контроль результатов заняла слишком много времени и показала свою неэффективность.

Автоматизация на базе Битрикс24 была частичной и нестабильной — даже с индивидуальными разработками бизнес-процессов. Внутренний ИТ-ресурс не справлялся с поддержкой и развитием решений, а маркетинг не получал достоверной аналитики по качеству трафика. В таких условиях РОП, не имеющий классических полномочий и инструментов анализа, не мог строить выводы на данных — только на фрагментарных наблюдениях.

Руководству требовалась аналитическая база для принятия решений, стабильный процесс контроля качества и возможность улучшать работу менеджеров без расширения штата. И всё это — без задержек, в условиях большой воронки и активной динамики продаж.

Специфика бизнеса Uprav — работа и в сегменте b2b, и в b2c. Поэтому в компании используется матрица сценариев продаж: сценарий в каждом случае зависит, с одной стороны, от сегмента клиента, с другой — от его воронки (которых всего пять).
Первоначально в проекте была предпринята попытка настроить нейросеть на единый и универсальный для всех воронок сценарий диалога. Но системные промпты (спецификации, которы регулируют работу искуственного интеллекта) получились достаточно перегруженными, что уже сигнализировало о рисках. Тем не менее, внедрение bewise всегда происходит итеративно, поэтому мы решили попробовать.

При тестировании клиентом опасения подтвердились — качество оценки диалогов было низким, процент качествы был в районе 70%, при целевом значении 90%+. Тогда мы применили другой подход: написали для каждой из пяти воронок отдельные промпты, которые в каждой воронке оценивают разные критерии диалога. Также, в зависимости от воронки, мы настроили фильтры: системный промт, который отсекал спам звонки, сохранение контекста из предыдущих диалогов для оценки, разные сценарии оценки в зависимости от этапа, на котором находится сделка. Результаты оказались гораздо лучше, мы достигли уровня качества в 94%, и именно эта конфигурация пошла в промышленную эксплуатацию.

Как и во многих других проектах, внедрение нейросети в uprav стало толчком к оптимизации процессов продаж. РОП пересмотрел взгляды на многие из них, в результате в компании появилась новая воронка «Реанимация», а при оценке качества стали использоваться новые критерии — «дожим» и «частые вопросы» (кстати, оба клиенту предложила команда bewise).

Много внимания было уделено блоку аналитики звонков.

Главной её составляющей стала аналитика отказов. Здесь стояла задача оценивать именно уже произошедшие отказы. Поэтому нейросеть берет только сделки из этапа «нереализованные».

Самым сложным для аналитики стал критерий «перечень вопросов», определяющий, обо всех ли важных моментах менеджер спросил клиента. Загвоздка была в том, что многие темы вопросов носили пограничный характер, соответственно, «объяснить» нейросети, какие фразы должны были считаться выполнением критерия, а какие — нет, было проблематично. Например, менеджеры школы должны обговаривать с клиентом тайминг: график и время обучения (кому-то удобно учиться днём, а кому-то — по вечерам). А нейросеть считала выполнением этого критерия любое упоминание сроков или времени.
Такие препятствия преодолеваются только итеративным дообучением ИИ. Мы правили системный промпт, давали нейросети 15−20 реальных звонков на оценку и вместе с заказчиком смотрели, как много брака будет в её аналитике. Упор мы делаем на звонки, получившие от искусственного интеллекта низкую или нулевую оценку (на этом проекте, например, на одной из итераций из 27 звонков такие баллы получили 12 диалогов. Оказалось, что все они — нецелевые).
Далее — опять же совместно с заказчиком — мы определяли, какие фразы и термины нейросеть должна «отсекать», снова редактировали системный промпт, и цикл повторялся.

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

Широкая выборка данных позволила полноценно обучить bewise и научить ИИ максимально корректно определять темы и ставить оценки. В случае Uprav без этого реализовать качественную отработку критерия «перечень вопросов» вряд ли бы получилось, т.к. он подразумевает очень жесткое следование своим трактовкам.

И, наконец, мы реализовали ряд дэшбордов.

Качественному обучению нейросети могут помешать много факторов: низкое качество записи, неразборчивая дикция клиента, заикания.
Но даже если предоставлен хороший набор данных, то получить все 100% качественных оценок фактически невозможно: системный промпт, который пытается учесть разом все противоречия и исключения, получается перегруженным, и его части начинают конфликтовать друг с другом. В результате одни критерии могут отрабатывать на 100%, но другие — упасть, условно, до 80%. Поэтому проще согласовать с заказчиком, что останутся незначительные и редкие шероховатости, но в среднем получить 90% качества — это наша минимальная планка.

Как мы замеряем уровень качества?
Очень просто: берём выборку звонков, которую «послушал» и оценил ИИ, и отдаём эти жe звонки на разбор нашему аналитику. Аналитик слушает их, ставит оценки, и его табличка сравнивается с табличкой оценок от нейросети. Процент качества — это разница этих двух оценок.

В большинстве случаев отклонения ИИ выражаются в занижении оценок.
В этом проекте в процессе тестирования мы заметили устойчивые паттерны, которые повторялись в оценках — и предложили заказчику добавить несколько дополнительных критериев. В данном случае это было некритично, но часто такие наблюдения становятся основой для изменений в проекте. Более того, bewise помогает командам по-новому взглянуть на сами скрипты: когда начинается работа с конкретными метриками, у заказчика появляется важный вопрос — «а мы вообще то измеряем?» Это позволяет не просто контролировать продажи, а выстраивать их более осознанно и эффективно.