← На главную

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

Multi-tenant SaaS-кабинет для голосовых AI-агентов на исходящих звонках. Запустил в 2026 в группе Prof-IT и веду end-to-end: продукт, UX, инженерия.

Роль Продуктовый лид · product engineer
Сроки Запуск 2026, активный shipping
Результат 500 000+ минут разговоров от новых клиентов за 2026

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

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

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

Клиентский дашборд Zvonobot AI с KPI и графиком по дням (демо-данные)
Клиентский дашборд · демо-данные · реальные интерфейсы клиентов под NDA

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

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

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

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

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

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

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

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

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

  • Frontend: React 19 + TypeScript + Vite. Vanilla CSS со строгими design-токенами (без Tailwind), переключение через data-theme="dark", role-aware sidebar.
  • 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: имена клиентов, конкретные промпты у платных агентов, voice-провайдер, поверх которого работаем, и абсолютные цифры выручки / минут. Всё описанное выше — реально, но конкретика обобщена. Готов проговорить по любому пункту на созвоне.