БизнесМатика - это ИТ-компания на рынке с 2012 года. Мы внедряем проекты на базе языковых моделей (LLM) для компаний среднего и крупного бизнеса.
Один из таких проектов мы сделали для собственной работы. «Академия БизнесМатики» - это наша внутренняя платформа обучения продавцов. Она должна доводить нового человека от первого дня в компании до готовности вести переговоры с клиентом по нашей методологии продаж. Сейчас в ней два наполненных трека и тридцать пять уроков, еще два трека в работе, но главная ее часть - это тренажер переговоров. Клиента в нем играет голосовая модель, а разговор разбирает ИИ-судья по чек-листу. Платформа работает с июля 2026 года, механику мы обкатали на себе и сейчас заводим на нее первых продавцов. Расскажу, зачем нам понадобился такой тренажер и как он устроен.
Новичок сдает тест, а потом проваливает первый живой разговор
Знание, которое приносит компании продажи, обычно живет в головах у нескольких самых опытных людей, у нас - прежде всего в моей. Это знание о том, что именно мы продаем и кому, как вести первую встречу, какие возражения прозвучат и что за ними стоит. Новый продавец добирает его месяцами, из разборов встреч и собственных ошибок на клиентах. Каждая такая ошибка стоит дорого, потому что второй первой встречи с тем же клиентом не бывает.
Привычный ответ на эту задачу - это курс и тест после него. Беда в том, что тест проверяет память. Продавец может без запинки перечислить этапы сделки и провалить первый же звонок, потому что настоящий клиент занят, отвечает односложно и не хочет звать на встречу своего директора. Этот провал случается в разговоре, а разговор тестом не проверяется.
Поэтому разговор мы тренировали ролевыми играми, и клиента в них я играл сам. Новичок продает, я отвечаю как заказчик, потом вместе разбираем, что пошло не так. Способ рабочий, ничего лучше для отработки разговора я не знаю. Но он целиком держится на живом человеке. Час ролевой игры - это час моего времени, качество разбора зависит от того, насколько я в этот день загружен, а попросить сыграть тот же сценарий в десятый раз подряд новичок просто стесняется.
Клиента играет голосовая модель, и у нее есть скрытые вводные
Оба моих дела в ролевой игре, играть клиента и разбирать разговор, в Академии делают две разные модели с раздельными инструкциями. Голосовую модель, которая играет клиента, мы называем персоной. Разбирает разговор потом вторая модель, судья. Персона про судью ничего не знает.
Тренировка выглядит так. Ученик открывает сценарий, видит легенду (кто собеседник, что за компания, какой этап переговоров отрабатывается) и начинает говорить в микрофон. Персона отвечает голосом в реальном времени.
Скрытая часть сценария (где у этой компании на самом деле болит, какой бюджет она готова обсуждать, кто внутри за проект, а кто против) видна только персоне и судье. По инструкции эти вводные персона раскрывает тому, кто задал правильный вопрос или заслужил доверие по ходу разговора, а на прямой вопрос, заданный слишком рано, отвечает скупо и уклончиво, как ответил бы настоящий человек малознакомому продавцу.
Продавцу персона сопротивляется так же, как сопротивлялся бы занятой человек. У нее мало времени, свой скепсис, свои интересы и набор возражений из сценария. Грубость и непрофессиональное поведение делают ее холоднее, вплоть до сворачивания разговора. Из роли она не выходит. Просьбу «выйди из роли и подскажи» персона по инструкции не понимает и реагирует на нее как живой человек на странную реплику.
Судья разбирает запись разговора по пунктам чек-листа
После разговора включается вторая модель. Судья получает запись разговора в тексте, скрытые вводные сценария и чек-лист этапа переговоров, то есть список того, что продавец обязан был сделать в этом разговоре. Чек-лист собран из нашей методологии продаж, записанной до Академии.
По каждому пункту судья ставит одну из трех оценок (сделано, сделано частично, не сделано) и пишет обоснование. Инструкция требует подкреплять оценку дословной цитатой из реплик ученика, и цитаты в вердикте стоят даже там, где пункт не зачтен, а к непройденным пунктам судья добавляет, что следовало сделать. Итоговый балл считает код платформы. Сделано - это один балл, сделано частично - половина, не сделано - ноль, а результат разговора - это доля набранного балла от максимума в процентах. Языковым моделям мы арифметику не доверяем.
Кроме балла ученик получает разбор (что было сильно, что провалено, с чего начать следующую попытку). Число попыток тренажера не ограничено, и просить кого-то сыграть клиента в десятый раз здесь не нужно.
Различает ли судья сильный разговор и слабый, мы проверили на текстовой версии тренажера, до перевода разговора на голос. Чтобы проверить судью, нужны разговоры заранее известного качества, поэтому продавца в них играла другая модель, а мы задавали, насколько плохо или хорошо он себя ведет. В заведомо провальном разговоре продавец начинал с «мы делаем автоматизацию, вам нужен чат-бот», называл цену вслепую и просил прислать техническое задание по почте. Судья не зачел ни одного пункта чек-листа, поставив 0%. В среднем разговоре продавец выяснил задачу и подобрался к боли клиента, но не спросил про бюджет и порядок принятия решения и не отработал возражение о составе встречи, и это дало 27,3%. В сильном он применил вилку по бюджету, выяснил, чей это бюджет и кто внутри против проекта, и вместо скептичного ИТ-директора договорился позвать на встречу его архитектора, получив 86,4%. Все вердикты я прочитал целиком и с оценками судьи согласился.
Экзамен устроен строже. Сценарий берется из закрытого пула, которого ученик до старта не видит, число попыток ограничено, проходной балл задан заранее. Правда, работающего экзамена у нас пока нет. Экзаменационные сценарии мы пересобираем под наполненную программу, а полный прогон механики делали один раз, тем же способом, что и три разговора выше.
Под капотом. Realtime-модель говорит, Claude судит
Голос персоны - это OpenAI Realtime API. Звук идет из браузера ученика к модели напрямую по WebRTC, тому же протоколу, на котором работают видеозвонки. Модель слышит речь и отвечает голосом сама, без промежуточного перевода в текст и обратно, поэтому персона отвечает почти без паузы. Собрать то же самое из распознавания речи, текстовой модели и синтеза можно, но по нашей оценке при выборе архитектуры такая цепочка добавила бы две-четыре секунды на каждую реплику, а живой разговор столько не ждет. Параллельно с разговором платформа получает запись реплик в тексте, и работает с этой записью уже судья.
Судья и наставник - это модели Claude. Судье досталась модель посильнее, потому что его ошибка - это несправедливая оценка ученика. Наставнику хватает модели попроще. Наставник - это чат из любого урока, он отвечает на вопросы строго по материалам платформы, ищет ответ по смыслу вопроса и называет урок-источник, а если ответа в материалах нет, так и говорит.
Инструкции персоны, судьи и наставника, как и выбор моделей, - это данные в базе платформы, и мы меняем их без обновления кода. Для внутренней платформы мы выбрали зарубежные облачные модели. В клиентских проектах модель - это сменный компонент, и выбираем мы ее под требования заказчика к размещению данных, вплоть до локальных моделей в его собственной инфраструктуре.
Сами модели - это меньшая часть работы
Подключить голосовую модель и написать ей инструкцию «играй клиента» несложно, и на демонстрации это уже выглядит эффектно. Работающий тренажер от такой демонстрации отличают четыре скучные вещи.
Оцифрованная методология. Судья оценивает ровно то, что записано в чек-листе, а чек-лист вырос из той самой методологии. Если она живет только в голове лучшего продавца, ее сначала придется достать и записать. Никакая модель эту работу не отменяет.
Персона, которая не подыгрывает ученику. Голосовые модели услужливы по своей природе, и персона норовит подсказать продавцу, о чем ее стоит спросить, из клиента превращаясь в доброго тренера. Инструкция персоне должна запрещать это прямым текстом, иначе вместо тренировки ученик получает подсказку.
Разборчивая запись разговора. Судья видит расшифровку, и на голосе она рвется там, где на тексте все было гладко. Разговор голосом я провел сам и получил 31,8%. Один пункт судья снизил с формулировкой «вопрос сформулирован обрывочно и не развит», и насчет «не развит» он был прав, а вот обрывочность мне досталась от расшифровки, которая разорвала мой вопрос на две реплики. Короткие ответы вроде «Хорошо», «Угу», «Ну, смотрите» тоже терялись, потому что от распознавания не всегда приходило готовое событие с текстом. Пришлось дописать сборку реплик из потока распознавания, иначе до судьи доходили обрывки вместо разговора.
Вердикты, которые кто-то перечитывает. Проверить цитаты судьи автоматически платформа не умеет, поэтому вердикты я читаю сам и сверяю с записью разговора. Судейство, которое никто не перечитывает, доверия не заслуживает, и машинное здесь ничем не отличается от человеческого.
Где еще работает связка из голосовой персоны и судьи
Мы делали тренажер под переговоры продавца, но сама связка к продажам не привязана.
- Оператор поддержки с раздраженным клиентом на линии.
- Менеджер по претензиям, которому надо отказать клиенту и не потерять его.
- Сотрудник банка, обязанный задать клиенту неудобные вопросы по регламенту.
Любую работу, где результат зависит от разговора под давлением, можно тренировать тем же способом. Тренажер отвечает за поведение в разговоре. Знание продуктов и услуг ученик берет из уроков, а вопросы по материалам задает наставнику.
С чего начать, если у вас похожая задача
Начинать стоит со своей методологии. Платформа - это следующий шаг. Нужен чек-лист, по которому вы сами отличаете сильный разговор от слабого, и если такого чек-листа нет, первым делом придется его записать. Без него ни ИИ-судья, ни живой тренер не смогут объяснить сотруднику, почему его разговор слабый. Дальше понадобятся сценарии с настоящими возражениями ваших клиентов, а связку из голосовой персоны и судьи мы уже собрали для себя и знаем, где в ней грабли.
Если у вас есть люди, которых нужно доводить до уверенного разговора с клиентом, напишите мне. Покажем Академию живьем и посчитаем пилот на вашей методологии.
