Zvonobot AI — платформа voice AI-агентов для B2B

Zvonobot AI: платформа voice AI-агентов, которую я отгружаю каждую неделю

Zvonobot AI — это новый продукт группы Prof-IT, который я запустил в 2026-м и веду end-to-end: продукт, UX и инженерию. Multi-tenant SaaS-кабинет поверх telephony-инфраструктуры: клиенты собирают голосовых AI-агентов, дают им промпт и базу контактов, и запускают исходящие кампании: продажи, онбординг, реактивацию, опросы.

За 2026 год через продукт уже прошло 500 000+ минут разговоров от новых клиентов.

Какую боль решает продукт

У mid-market и enterprise B2B-команд есть повторяющаяся проблема исходящего обзвона, которую не решить просто CRM-кой и колл-центром:

• Штат не масштабируется линейно. Нанять, обучить и удержать команду исходящего обзвона на 30–60 операторов под прогрев тёплых лидов или life-cycle звонки — это ад. Особенно на русскоязычных рынках, где хороших телесейлов мало и они выгорают быстро.
• Скорость до первого касания убивает воронку. Лид, до которого дозвонились за минуты, конвертируется в разы лучше того, до которого дозвонились на следующий день. Люди не могут быть на каждой смене, в каждые выходные, в каждом канале, а входящие лиды ждать не будут.
• Качество разговора плавает. Два оператора по одному и тому же скрипту проведут два разных разговора. Понять «что реально происходило на звонке» сложно, и руководители тратят больше времени на прослушку записей, чем на управление командой.
• Lifecycle-звонки экономически невыгодны людям. Напоминалки об онбординге, реактивация, NPS-опросы, напоминания об оплате: каждый звонок по отдельности приносит мало, но вместе это огромный объём, который команда людей не оправдает.

Голосовой AI-агент, который берёт скрипт, ведёт диалог, отрабатывает типичные возражения и передаёт квалифицированного лида человеку, схлопывает все четыре проблемы в настраиваемый workflow.

Что я собрал и держу в проде

Кабинет Zvonobot AI — это поверхность, в которой живут клиенты. В нём собран сборщик агентов, дозвон, биллинг и аналитика — всё под одной role-aware консолью.

• Регистрация без трения. Почта, пароль, телефон, и клиент сразу внутри. Телефон подтверждается уже в кабинете, перед первым звонком, а не блокирует вход. Есть и быстрый вход через Яндекс ID.
• Сборщик агентов. Клиент выбирает голос, модель, язык, кладёт структурированный промпт, прикрепляет базу контактов и номер, и через минуты у него рабочий исходящий агент.
• Кампании и дозвон. Кампания — это «этот агент звонит этой базе с этого номера». Оператор может ставить на паузу, продолжать, делать повторные попытки и переключать carrier, не выходя со страницы.
• История звонков с маской номеров. Каждый звонок попадает сюда: статус, исход, длительность, стоимость, запись. Номера телефонов в UI замаскированы, кабинет безопасен для демо и аудита.
• Real-time дашборд клиента. KPI: лиды / конверсия / стоимость лида / звонки / дозвоны / потрачено, плюс воронка, график по дням и разбивка по агентам, всё в рублях по тарифу организации.
• Тарифы и биллинг с резервом баланса. Кампания резервирует ориентировочную стоимость на старте, поэтому клиент не уходит в минус посреди обзвона. Реальный расчёт идёт после каждого звонка, тарифы и пополнение живут в самом кабинете.
• Multi-tenant роли. Супер-админ, менеджер, владелец кабинета, бухгалтер: четыре роли с разными скоупами и view, всё на одной кодовой базе.

Аналитика, на которую смотрят руководители

Голос — это только половина продукта. Вторая половина в том, чтобы превратить тысячи разговоров в цифры, по которым принимают решения. После каждого звонка LLM раскладывает разговор на исход, настроение и кастомные пост-call параметры, и всё это собирается в аналитику кабинета.

• Исходы звонков. Топ-меток исхода: что реально говорили люди, отсортированное по частоте.
• Настроение. Распределение позитив / негатив / нейтрально / смешанное по всему пулу разговоров.
• Активность по часам. Когда дозвоны проходят лучше, чтобы клиент звонил в правильное окно.

Сборщик агентов: от промпта до живого звонка

Агент — это центральный объект продукта. Клиент задаёт голос, модель и язык, пишет структурированный промпт со сценарием разговора, настраивает первую фразу (чтобы LLM не «думал» в тишину и звонок не обрывался), кастомные параметры для пост-call анализа и success-метки. После публикации и модерации агент готов звонить, и прямо отсюда можно запустить тестовый звонок на свой номер.

Архитектура: что внутри

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

• Frontend: React 19 + TypeScript + Vite. Vanilla CSS со строгими design-токенами (без Tailwind), переключение через data-theme="dark", role-aware sidebar, двуязычный интерфейс (ru/en).
• Backend: Flask modular monolith, SQLAlchemy + Alembic, PostgreSQL под state, Redis под джобы и broker.
• Voice + LLM: оркестрация диалога поверх execution-слоя voice-провайдера. Голос агента, ASR, TTS и LLM настраиваются для каждого агента отдельно.
• Телефония: интеграция с нашим SIP-trunk для российских номеров, плюс определение оператора через P1SMS HLR, чтобы заранее знать, дойдёт ли вообще звонок до номера.

Три инженерных решения, которые стоит описать

1. Поллер статусов, а не только вебхуки. Voice-провайдеры присылают вебхуки по lifecycle-событиям звонка, но вебхуки теряются: оборванный TLS, backpressure в очереди, инциденты на стороне провайдера. Я сделал фоновый поллер, который просыпается каждые 60 секунд и сверяет каждый незавершённый звонок с источником истины у провайдера. Если вебхук не пришёл, поллер обновляет звонок, закрывает расчёт по кошельку, выкатывает данные в аналитику. Итог: в проде нет звонков, «застрявших в queued», каждая минута корректно списана.

2. Резерв баланса на старте кампании, реальный расчёт по концу звонка. Наивный биллинг ждёт вебхук и списывает после звонка. Это ломается по двум причинам: списания гоняются с апдейтом кошелька на параллельных кампаниях, и клиент может выжечь баланс, а стоимость остаётся на нас. Поэтому я делаю hold на ориентировочную стоимость при старте кампании, settle на реальную при завершении звонка, и release hold при остановке. Всё это идёт через row-lock (SELECT ... FOR UPDATE) в Postgres, чтобы два параллельных звонка не могли списать одни и те же последние 10 рублей.

3. Импорт контактов, который не давится на реальных CSV. Реальные клиентские базы грязные: +7 (982)…, 8982…, 9822…, номера с шумом в добавочных, мобильные в колонке городских. Pipeline импорта нормализует каждую строку к каноническому +7XXXXXXXXXX, дедуплицирует и определяет оператора через P1SMS. По умолчанию я фильтрую неустойчивые маршруты carrier’а (в нашем SIP-trunk это МТС) и даю оператору переключить пикер для конкретной базы. Это та же логика, с которой когда-то начался bazabot: когда стало очевидно, что каждая кампания делает этот preprocessing руками, я поднял её в продукт.

Как я веду продукт

Я один на продукте каждый день: от продуктовой логики и UX до бэкенд-кода и инфры. Пишу код в паре с AI-агентами (Claude Code, Codex), но продуктовые решения, edge-кейсы биллинга и решения на уровне SIP остаются за мной. Вокруг есть широкая команда Prof-IT (телефония, операционка, поддержка), но кабинет, API, поток дозвона, математика биллинга и UI лежат на мне end-to-end.

На практике:

• Я веду цикл продукт → UX → код → релиз → метрика сам, за дни, а не за спринты.
• Я отношусь к скучной инфраструктуре как к фиче: поллеры, hold’ы, идемпотентность, маска PII — это то, что делает SaaS стабильным, а не хрупким.
• Я беру минимально устойчивую поверхность и наращиваю её. Кабинет стартовал с одной роли и одного отчёта, а сегодня в нём четыре роли, биллинг, сборщик агентов, аналитика и реальный call pipeline.

Что можно потрогать, а что под NDA

Кабинет открыт: можно пройти регистрацию и собрать своего агента. Скриншоты выше сделаны из живого продукта, но на демо-аккаунте: организация, агент и ~2 500 звонков сгенерированы и обезличены, поэтому их безопасно показывать.

Под NDA остаётся конкретика: имена реальных клиентов, их промпты и базы, voice-провайдер, поверх которого работаем, и абсолютные цифры выручки / минут. Всё описанное выше реально, просто эти детали обобщены. Готов проговорить по любому пункту на созвоне.