В этом тексте — живой кейс внедрения речевой аналитики в крупнейшей онлайн-школе EasyCode.
Как мы пытались поднять конверсию, контролируя скрипты.
Почему бинарная проверка «сказал ⁄ не сказал» не спасла продажи.
Откуда взялся феномен «вежливого тумана» — сделка ещё вежлива, но уже мертва.
Как идея тайм-лайна коммуникаций вывела нас к собственным паттернам риска и успеха.
И зачем теперь выгоднее собрать аналитику своими руками (один dev, три дня), чем покупать очередную коробку.
Первый серьёзный вызов
Когда мы начали работать над проектом для EasyCode, наша компания была ещё молодой.
Я основал bipiai.com, чтобы закрывать реальный разрыв между возможностями ИИ и реальными бизнес-процессами.
Мы начинали с небольших клиентов: в основном это были компании, которые продавали через телефон и искали способы улучшить качество коммуникаций.
На этом рынке уже работали компании, которые строили решения по контролю звонков, чек-листам, речевой аналитике.
Мы делали свои проекты, искали подходы, учились на практике.
Тогда казалось, что всё сводится к настройке проверки скриптов и улучшению контроля.
Подписать контракт с EasyCode стало для нас переходом на совсем другой уровень.
EasyCode — крупнейшая онлайн-школа дополнительного образования для детей: программирование, игры, цифровые навыки.
Их продукт был зрелым, процессы были масштабными, и работа над их воронкой продаж обещала быть настоящим блокбастером.
Главной задачей было повысить конверсию на вводных уроках с помощью речевой аналитики.
На старте всё выглядело логично: нужно было разбить скрипты на этапы, проверить выполнение на звонках, выявить отклонения и повысить качество коммуникаций.
Это казалось стандартным проектом.
Но очень быстро стало понятно, что никакие чек-листы не дадут реального роста.
Провал пилота
Когда только появился шанс поработать с одной из крупнейших онлайн-школ, это стало для нас важной точкой. Компания была молодой, за плечами — работа с небольшими клиентами, но именно этот проект мог изменить всё.
Я принял решение: сделать бесплатный пилот. Мы предложили проверить нашу систему на реальных данных. Клиент передал нам 10–15 звонков и чек-листы с этапами стандартного скрипта.
Изначальная гипотеза была очевидной: если продавец строго следует скрипту, сделка должна закрываться. Мы построили простую модель проверки: сказал или не сказал нужный блок. В теории всё должно было работать.
Когда мы прогнали первые звонки через систему, цифры выглядели правильно. Скрипты соблюдены. Ошибок почти нет. Но что-то было не так.
Я начал смотреть глубже. И понял: сделки срывались даже тогда, когда формально соблюдены все этапы. Чек-листы были заполнены. Но реального контакта с клиентом не было.
1. Пример из звонков: проблема структуры
В неуспешных звонках менеджеры слишком долго рассказывали про школу, лицензии, партнёрство со Сколково — вместо того, чтобы быстрее перейти к практике для ребёнка. Это снижало вовлечённость и разрушало динамику разговора.
Почему важно:
Это конкретно показывает: не просто “что-то пошло не так”, а что именно — затягивали начало и теряли внимание клиента.
2. Пример из звонков: вовлечение ребёнка
В успешных звонках менеджеры вовлекали ребёнка в активные действия: задавали вопросы, запускали практическое задание, интересовались его впечатлением.
Почему важно:
Это живой критерий — сразу видно разницу между мёртвыми и живыми звонками.
3. Пример из звонков: роль родителя
В неуспешных звонках родители часто переключались на обсуждение налоговых вычетов, лицензий и рассрочек — вместо обсуждения обучения ребёнка. Продавцы не всегда вовремя возвращали фокус на ценность урока.
Почему важно:
Даёт понятную картину: почему даже правильный скрипт может не работать, если продавец теряет эмоциональную нить разговора.
Стало ясно: не то, что говорят, определяет успех, а как это говорят. Настроение, интонация, живое вовлечение ребёнка и родителя. Простая бинарная система “сказал — молодец, не сказал — ошибка” не работает.
Это был сложный момент. Мы пришли к клиенту с одним продуктом, а понимание реальности требовало предложить совершенно другое решение. При этом не было гарантии, что клиент воспримет это как шаг вперёд, а не как признание провала.
Я принял решение идти честно. Мы переделали методику. Вместо чек-листа появился адаптивный анализ: не только структура разговора, но и эмоциональная динамика, вовлечённость, реакция клиента.
Чтобы подтвердить гипотезу, мы повторно прогнали те же звонки через новую адаптивную модель. И сразу увидели разницу. Вместо механической проверки чек-листов система начала выделять реальные провалы: потерю интереса ребёнка, уход родителей в обсуждение формальностей, снижение темпа разговора. Там, где раньше формально всё выглядело правильно, теперь становилось видно, почему сделка не состоялась. Это был первый реальный результат, который дал уверенность: мы движемся в правильном направлении.
На встрече мы впервые рассказали об этом. Было видно, что команда клиента не ожидала поворота. Но их CEO оказался человеком с сильной интуицией. Он быстро увидел, что за этим стоит возможность: не просто контролировать скрипты, а управлять реальными эмоциями клиентов.
Мы показали, что даже из нескольких звонков можно вытащить глубокие инсайты, которые помогут изменить структуру продаж. И объяснили главное: чем больше звонков будет обрабатываться системой, тем точнее она будет выявлять закономерности успеха и провала.
Именно тогда на их проекте родилась новая идея: строить продажи не на формальном контроле слов, а на понимании реального контакта с клиентом.
Как я нащупал «вежливый туман»
Контракт был подписан сразу после демо-пилота. Следующий шаг — откалибровать систему на сотне звонков EasyCode, уже поступавших к нам из CRM в реальном времени.
Адаптивная модель отрабатывала без сбоев, оценки выглядели обнадеживающе: структура соблюдается, ошибки редкость. Я собирался радоваться — пока не сверил данные с фактическими оплатами.
Странность, которую нельзя было игнорировать
40 % звонков, отмеченных системой как «почти идеальные», заканчивались… ничем. Менеджер любезен, родитель вежлив, ребёнок отвечает, — а оплата так и не появляется.
Я начал слушать руками: пять звонков, десять, двадцать.
Картина повторялась: беседа идёт ровно, но в какой-то момент энергия падает.
Все остаются корректными — решения «беру» не рождается
Чек-лист ничего не «видел»: слова произнесены правильно — сделка мертва. Я назвал это "вежливым туманом": внешне всё прилично, внутри — нулевая конверсия.
Таймлайны и паттерны: следующий рубеж
Когда мы закончили сотню звонков, «вежливый туман» уже не удивлял, но раздражал: одна-две идеальные беседы из трёх всё-равно тонули где-то после звонка. Я распечатал несколько таких сделок и рассадил их, будто кадры плёнки, прямо на стене переговорки: пробный урок → пятнадцать минут паузы → письмо со счётом → сутки тишины … и именно в этой паузе, казалось, исчезала вся энергия разговора.
Что я вынес из сотни «идеальных» звонков
• Формальный контроль даже с адаптивной моделью — это только дашборд.
• Решение клиента окончательно формируется между касаниями: в паузах, в чате, в письмах, в реакции на первый счёт. И вообще может находиться за пределами коммуникаций.
• Чтобы по-настоящему управлять продажей, нужно смотреть сквозь весь путь клиента, а не на один звонок.
Именно здесь у меня родилась следующая гипотеза: раз «туман» прячется между событиями, значит, нужно вытащить всю цепочку коммуникаций на один таймлайн и искать повторяющиеся паттерны — как успеха, так и провала.
Чек-листу и даже адаптивной модели внутри одного звонка там делать нечего — нужно видеть всю линию, «как на ЭКГ».
Дальше продукт уже не мог быть простой «речевой аналитикой». Теперь он должен был описывать и предсказывать поведение клиента от первого касания до оплаты — и возвращать менеджеру подсказки в тот самый момент, когда сделку ещё можно спасти.
Первый «ручной» таймлайн
День 0, 19:45 — урок, оценка 8/10.
+15 минут — менеджер отправил счёт по почте.
+24 часа — счёт даже не открыт, клиент молчит.
+30 часов — SMS «Как вам урок?» — реакции нет.
+48 часов — вероятность сделки падает ниже 20 %.
Через трое суток родитель вежливо благодарит и… откладывает решение «на потом».
Я изобразил это правило в коде двумя «if-ами» и отправили себе алерт в Telegram — просто чтобы проверить чувство. Результат был жёсткий: каждое такое молчание действительно превращалось в отказ, а если менеджер перехватывал родителя до 24-го часа, конверсия возвращалась почти к исходной.
Почему нельзя отдавать тайм-лайн наружу
Отдаёте данные внешней платформе — отдаёте сердце отдела продаж.
SaaS покажет вам «красивую дэшборду», а настоящие сокровища оставит себе: какие формулировки выключают тревогу, в какой минуте родитель начинает скучать, какой интервал между уроком и счётом смертелен именно для ваших клиентов.
Каждый чужой «ИИ-продавец» учится на миллионах звонков, но учится не для вас.
В тот момент, когда вы ждёте чуда, тот же движок уже подсказывает конкуренту, как резать вашу маржу.
Ваш тайм-лайн — это ДНК компании: страхи вашей аудитории, сроки ваших платежей, неписаные правила принятия решения.
Вынесите его за периметр — и через месяц не сможете отличить собственный бизнес-ритм от усреднённой статистики рынка.
Через год-два аренда «готовых ИИ-продавцов» станет такой же обузой, как сегодня бесконечная закупка лидов.
А те, кто сегодня выращивает аналитику внутри, завтра будут продавать быстрее и дешевле.
Вы будете не конкурировать с ними, а догонять их собственными же данными, но уже по чужим правилам.
Что дальше — и почему это легче, чем кажется
Если после всего прочитанного у вас внутри звучит: «Да-да, круто, но это же космос, нам такого не потянуть…» — расслабьтесь.
Чтобы построить свою внутреннюю речевую аналитику (а завтра на её базе — собственный ИИ-отдел продаж) вам понадобится ровно шесть кирпичей:
Всё. Это не ракетостроение — это базовый зеркальный набор для любого data-проекта 2025 года.Программист уровня «сильный middle» собирает прототип за пару дней, а через неделю у вас уже крутится первая версия таймлайна.
Всё, что описано выше, можно развернуть из шести простых кирпичей. Это не архитектура единорога — это стек, с которым любой сильный мидл соберёт MVP за пару дней. Вот он, по-человечески
LLM-движок : Любая модель, которой вы доверяете: GPT-4o, Claude, YandexGPT — не так важно. Главное, чтобы она понимала речь, эмоции, контекст. Это мозг, который будет слушать звонки и подсказывать, что пошло не так.
Связывающее ПО : LangChain или LlamaIndex — инструменты, которые связывают вашу LLM с базами, CRM, почтой, Telegram. Без этого мозг просто не узнает, что у клиента уже было три касания и он ждал счёт.
Python-стек : FastAPI + Pandas + PostgreSQL. Тут вы описываете правила, считаете метрики, рисуете графы. Никакой магии — просто код, который превращает поток данных в управляемую аналитику.
Интегратор событий : Zapier, Make или n8n — помогают без строчки кода забирать звонки, письма, статусы оплаты. Все «касания» клиента вытягиваются и собираются в цепочку.
Cursor IDE : Код пишется текстовыми промптами — прямо в редакторе. Можно работать быстро и понятно, даже если вы не писали с нуля ничего полгода. Средний разработчик за день собирает MVP-логику.
Ваш сервер : Docker на локальной машине или в облаке (Yandex Cloud, VK Cloud, AWS). Данные остаются у вас, масштабируется по клику, а не через саппорт «SaaS-платформы недели».
Почему это важно сделать именно внутри
Правила меняются ежедневно. Новый банк-партнёр? Свайпнули YAML-файл — и LLM уже знает, какие страхи снимать.
Данные остаются у вас. Ни один внешний вендор завтра не продаст их конкуренту «в обезличенном виде».
Это фундамент для ИИ-агентов. Сегодня вы ловите «24 h тишины», завтра бот сам пишет письмо, а послезавтра — торгуется за цену без участия менеджера.
Зачем я это пишу.
Не хочу играть в эту гонку за подписками, токенами и “умными SaaS”, которые продают обёртку вместо результата.
Рынок изменился.
Если раньше на арбитраже и прокладках можно было жить годами, сегодня срок жизни такого бизнеса — месяцы.
Фичи, за которые вы платите сегодня, уже завтра будут встроены в любую нейросеть по умолчанию.
Экспертиза — вот что остаётся.
Поэтому всё, что описано выше — это не тизер, не прогрев и не продажа.
В этом тексте я постарался помочь разобраться, куда движется технология продаж в 2025 — и что нужно начинать делать уже сейчас, чтобы завтра не остаться без бизнеса.
Собственнику — чтобы увидеть: ключевые инсайты нельзя аутсорсить, их нужно взращивать как корпоративную ДНК.
Директору по продажам — чтобы перестать мерить чек-листами и начать ловить провалы между касаниями.
ИТ-/ИИ-стартапу — чтобы не пилить очередную «коробку», а сосредоточиться на кастомной логике и скорости итераций.
Тем, кто обжёгся на SaaS — чтобы понять, почему «универсальный» сервис не может знать страхов именно ваших клиентов.
Для инвесторов — потому что именно внутренняя экспертиза станет завтра тем, что будет стоить дороже всего.
Мой план
Если этот материал окажется полезным — нажмите «лайк», поделитесь, напишите в комментах, какие точки боли мешают именно вам:
много реакций — записываю подробное видео на Youtube «От нуля до MVP таймлайн-аналитики» с пошаговым кодом.
материал становится хитом — открываю GitHub-репозиторий с готовыми шаблонами пайплайнов, чтобы каждый мог развернуть свой ИИ-таймлайн.
Хочется, чтобы через год рынок говорил не «где купить ИИ-продавца», а «как качать собственную ИИ-компетенцию быстрее конкурентов».
Начнём сегодня — берите и делайте.
