Вернуться к блогу

Как не слушать сотни звонков, но знать всё об отделе продаж: Кейс с ИИ

15 мин
Как не слушать сотни звонков, но знать всё об отделе продаж: Кейс с ИИ

Разговор, с которого всё началось, был коротким. Руководитель отдела продаж одного из моих клиентов показал мне папку на рабочем столе. В ней лежало 847 аудиофайлов — звонки за один месяц. Прослушано вручную — 41.

«Я физически не могу больше», — сказал он. — «Но именно в этих записях спрятан ответ, почему мы не выполняем план».

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


Проблема в отделе продаж: Почему 95% звонков уходят в никуда

Отдел продаж из пяти человек совершает 150–200 звонков в неделю. РОП физически способен прослушать 5–10% из них — и то если специально выделит на это время. Остальные 90–95% уходят в никуда.

Что происходит в этой «серой зоне»:

  • менеджер не отрабатывает возражение «дорого» и кладёт трубку
  • скрипт нарушается на каждом втором звонке, но никто об этом не знает
  • лид квалифицирован неправильно, и в CRM попадает мусор
  • новый сотрудник совершает одни и те же ошибки три месяца подряд, потому что их никто не замечает

Инструменты на рынке либо стоят как самолёт (Gong, Chorus), либо требуют сложной интеграции с телефонией. Для малого и среднего бизнеса в России это тупик.

Мне нужно было сделать что-то простое: загрузил файлы → получил таблицу с оценками → понял, кто работает по скрипту, а кто нет.


Архитектурное проектирование системы анализа

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

Выяснилось несколько неочевидных вещей.

Первое: людей не интересует транскрипт. Никто не будет читать текст разговора на 40 минут. Им нужна оценка — зелёный/красный флаг по каждому пункту чек-листа.

Второе: у каждой компании свой скрипт. Универсальный чек-лист «поздоровался, выявил потребность, закрыл» — слишком грубо. Один продаёт ипотеку, другой — корпоративное ПО. Система должна настраиваться.

Третье: самое дорогое в цепочке — транскрибация. Прогнать аудио через Speech-to-text стоит денег. Прогнать готовый текст через GPT — копейки. Это определило всю архитектуру.

Я разделил пайплайн на два независимых этапа:

  1. Транскрибация — один раз, результат сохраняется навсегда
  2. Анализ — можно запускать сколько угодно раз на одном тексте

Если клиент меняет скрипт продаж — он не платит за транскрибацию повторно. Это сэкономило им до 70% затрат на API по сравнению с наивной реализацией «прогони аудио → получи ответ».


Технический пайплайн: BullMQ, Redis и YandexGPT

Очереди как основа всего

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

BullMQ + Redis стали сердцем системы. Файл попадает в очередь, воркер берёт его в работу, обновляет статус в базе, фронтенд опрашивает состояние. Никаких блокировок, никаких таймаутов на уровне HTTP.

Статусы звонка в базе: pending → processing → transcribing → analyzing → completedfailed с автоматическим retry).

Это решило и другую проблему — отказоустойчивость. YandexGPT иногда возвращает ошибку 429 (rate limit). BullMQ автоматически делает повторную попытку через экспоненциальный backoff. Пользователь ничего не замечает.

Почему Node.js, а не Python

Вопрос, который задают чаще всего: «это же AI-проект, почему не Python?»

Потому что бэкенд здесь — дирижёр, а не исполнитель. Он принимает файлы, кладёт их в S3, ставит задачи в очередь, обновляет базу, отдаёт результат фронтенду. Вся тяжёлая математика — на стороне Yandex API.

Node.js с его event loop идеально подходит для таких задач. Пока один файл грузится в хранилище, второй транскрибируется, третий анализируется GPT — всё параллельно в одном процессе.

AI-стек: почему Яндекс

Я рассматривал OpenAI Whisper + GPT-4 и в итоге выбрал YandexCloud. Несколько причин:

SpeechKit лучше работает с телефонным качеством звука. Звонки пишутся в 8kHz с компрессией, много шума, перебивания. Whisper на таких данных даёт заметно больше ошибок — особенно на профессиональной лексике конкретных отраслей.

Юридический контур. Когда компания передаёт тебе записи разговоров с клиентами — это персональные данные. Для многих российских B2B-клиентов принципиально, чтобы данные не уходили за рубеж. YandexCloud — российский дата-центр, ФЗ-152 из коробки.

YandexGPT для анализа. Промпт выглядит примерно так:

Ты — эксперт по продажам. Проанализируй транскрипт звонка 
и оцени каждый пункт чек-листа: [список пунктов].

Для каждого пункта верни:
- выполнен: true/false
- цитата из разговора (если выполнен)
- комментарий

Отвечай строго в JSON.

Ответ парсится, сохраняется в базу, и на дашборде каждый пункт становится зелёным или красным флагом.

База данных и схема

PostgreSQL + Prisma. Реляционная структура здесь необходима: звонок → менеджер → клиент → скрипт → результаты анализа по каждому пункту. Аналитические запросы типа «покажи все звонки менеджера Иванова за март, где не отработано возражение по цене» — это JOIN’ы, которые Postgres делает элегантно.


Что пошло не так

Честный раздел, который обычно вырезают из технических статей.

Проблема «длинных хвостов». Я не ожидал, насколько разными бывают звонки. 2 минуты против 47 минут — это принципиально разные задачи для транскрибатора. Первая версия системы иногда падала на длинных файлах из-за таймаута на стороне SpeechKit. Решение: разбивка длинных файлов на чанки по 5 минут перед отправкой.

JSON из GPT — это не JSON. Модель иногда возвращала текст с комментариями до или после JSON-блока, иногда — с лишними запятыми. Пришлось написать парсер-обёртку с несколькими стратегиями извлечения и fallback на структурированный промпт с более жёсткими инструкциями.

Промпт-дрейф. При обновлении модели на стороне Яндекса формат ответов слегка менялся. Теперь у меня есть набор тестовых транскриптов с эталонными результатами — что-то вроде unit-тестов для промптов. Любое изменение промпта прогоняется через них.


Безопасность как продуктовая фича

В B2B продукте, который работает с чувствительными данными, безопасность — это не галочка. Это аргумент в переговорах.

Когда я говорю клиенту «ваши записи хранятся в изолированном S3-бакете, доступ только через подписанные временные ссылки, сервер закрыт по портам, аутентификация через Better Auth с защитой от брутфорса» — это снимает возражение «а вдруг утечка» быстрее любого договора NDA.

Что сделано на уровне инфраструктуры:

  • Docker-контейнеризация — каждый сервис изолирован
  • UFW: открыты только 80/443, всё остальное закрыто
  • Fail2ban: автоматическая блокировка при подозрительной активности
  • Presigned URLs для S3: файл доступен по ссылке ровно 15 минут
  • Better Auth: из коробки закрывает большинство уязвимостей сессионной аутентификации

Итоги запуска: Что я понял про B2B-продукты на базе ИИ

Sales Call Insight — мой первый продукт, который я делал с мышлением «кто будет за это платить» с самого начала, а не в конце.

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

Скорость важнее красоты. Первая версия с одной очередью и простым промптом заработала за три недели. Потом я её переписывал, оптимизировал, добавлял функции — но первые реальные отзывы получил уже с MVP.

Интерфейс — это и есть продукт. Сколько бы умной ни была система под капотом, РОП смотрит на таблицу. Я потратил на UX дашборда столько же времени, сколько на весь бэкенд. Цветовые флаги, сортировка по оценке, фильтр по менеджеру — это и есть ценность для пользователя.

Монорепозиторий с самого начала. Я сделал это в середине проекта и сэкономил дни на синхронизации типов между фронтендом и бэкендом. Если бы начал сразу с pnpm workspaces — не потерял бы эти дни.


Где это живёт сейчас

Sales Call Insight запущен и принимает клиентов. Если вы РОП или владелец бизнеса с отделом продаж — можно попробовать на своих звонках: salesinsight.ru.

Первые результаты пользователей: компания из 8 менеджеров за первую неделю обнаружила, что двое из них системно не отрабатывают конкретное возражение. Это не было видно в CRM. Это не звучало на планёрках. Это было спрятано в 300 аудиофайлах, которые никто не слушал.


Если интересно обсудить архитектуру очередей, промпт-инжиниринг под структурированные ответы или опыт интеграции YandexGPT — пишите в Telegram. Отвечаю всем.

Хотите обсудить проект?

Если у вас есть интересный проект или вопросы, буду рад пообщаться

Связаться со мной