Голосовой AI-продавец для входящих звонков: как связать Telegram, SIP и финансовый контроль

Голосовой AI-продавец для входящих звонков становится полезным только тогда, когда за ним есть 2 контура: стабильная телефония и понятный контроль после разговора. 7 июля 2026 года в Solar тестовый звонок прошёл по цепочке Telegram, SIP.TG, Asterisk и Vapi с 0 потерянных пакетов, но этого оказалось мало: голос сначала молчал по 10 секунд, звучал тяжело и пытался продавать монологом. В тот же день финансовый контур показал похожую механику: строка на 69 187 500 IDR выглядела как крупная пропажа, пока сверка Danamon и переводов Кетут не показала дубль и неправильный знак.

Владелец бизнеса обычно видит эти задачи отдельно. Тут звонки, там бухгалтерия, отдельно менеджеры, отдельно Telegram, отдельно банк. На практике это один вопрос: как сделать так, чтобы повторяемый хаос не висел на голове владельца. Входящий звонок должен попадать в систему, система должна задать нормальные вопросы, после разговора владелец должен получить запись и сжатый отчёт. Деньги должны идти через такой же принцип: выписка, период, источник, статус, сверка, понятная ошибка вместо паники. Ниже разбор, как устроить такой контур без обещаний про чудо-продавца и без игры в робота, который притворяется отделом продаж.

Голосовой AI-продавец начинается не с модели

Первая ошибка при запуске голосового AI-продавца — начать с выбора голоса или текста приветствия. Это заметная часть, но не фундамент. Фундаментом остаётся маршрут звонка. Человек звонит в привычный канал, например в Telegram. Дальше звонок нужно вынести из мессенджера в телефонию, принять в своём узле и передать в голосовую платформу. Если на этом уровне есть разрывы, задержка, односторонний звук или нестабильный мост, весь сценарий продаж сверху становится декоративным.

В рабочем прототипе Solar маршрут выглядел так: звонок с Telegram-аккаунта @salessolar попадал в SIP.TG, дальше шёл в Asterisk, затем передавался в Vapi, где уже отвечал голосовой помощник. Такой путь нужен не из любви к сложным схемам. Он даёт контроль над медиа, логами, маршрутизацией и последующим расширением. Можно заменить голосовую платформу, поменять правила обработки, включить запись, добавить fallback на человека и не переписывать весь входящий контур с нуля.

Первый живой тест закрывает простой вопрос: ходит ли звук в обе стороны. В Solar он ходил, а потери пакетов были 0. Это не значит, что система готова продавать. Это значит, что транспортный слой перестал мешать дальнейшей работе. На этом этапе разумно фиксировать не красивые фразы помощника, а технические факты: какой аккаунт принимает звонок, какой SIP-провайдер используется, какой узел принимает трафик, где пишется лог, где хранится запись и кто получает post-call отчёт.

Для малого бизнеса такая архитектура выглядит избыточной только снаружи. Если входящие звонки важны, владелец всё равно платит за хаос: пропущенные обращения, забытые обещания, менеджер без контекста, спор о том, кто кому звонил, и ручной пересказ разговора в чате. Голосовой AI-продавец полезен не потому, что говорит человеческим голосом. Он полезен, когда каждый входящий контакт становится событием в системе: с записью, текстом, статусом и следующим действием.

Техническая карта звонка должна храниться рядом со сценарием, а не в голове у одного разработчика. Минимальный документ: входящий канал, SIP-аккаунт, Asterisk endpoint, Vapi assistant, место записи, формат транскрипта, получатель отчёта, fallback при ошибке. Когда один из узлов меняется, команда видит, какую часть контура трогать. Без этой карты любой сбой снова превращается в ручной детектив.

Почему технически рабочий бот всё ещё плохой продавец

После первого теста обычно начинается неприятная часть. Система работает, но слушать её тяжело. В Solar так и произошло: голос звучал слишком низко, паузы растягивались до 10 секунд, после приветствия помощник мог уйти в длинный pitch или молчать не там, где человек ждёт реакции. Снаружи это выглядит как мелкие настройки. Для входящего клиента это разница между «мне ответили» и «я попал в странную машину».

Голосовой продавец не должен начинать с монолога. Человек звонит не за презентацией всей компании. Он хочет быстро понять, туда ли попал, можно ли решить его задачу и что делать дальше. Поэтому первый экран разговора, если так можно назвать первые 20-30 секунд, должен быть коротким: приветствие, роль помощника, один вопрос. Не анкета на 12 пунктов, не лекция, не обещание цены, которой помощник не имеет права называть. Один вопрос, потом реакция на ответ.

В Solar для первого звонка отказались от персонажа Альтрона. Для внутренней операционной системы такой образ работает: сухой, тяжёлый, с характером. Для входящего клиента он даёт лишний вес там, где нужна ясность. Так появилась Алиса: голосовой консультант, который сначала понимает бизнес, источник заявок и боль, затем предлагает одну гипотезу автоматизации и мягко передаёт диалог Юрию. Это не смена имени ради косметики. Это смена роли под конкретный сценарий.

У хорошего голосового помощника есть границы. Алисе отдельно запрещено собирать номер голосом, обещать цены и сроки, изображать офисного сотрудника и давить на человека. Она может уточнить контекст, задать следующий вопрос, назвать общий принцип и передать разговор владельцу. Такой помощник не заменяет доверие в сложной продаже. Он снимает первый слой рутины: принять звонок, не потерять заявку, понять тип запроса, сохранить разговор, подготовить владельцу сжатый контекст.

Отдельная настройка — перебивания. В живом разговоре люди редко говорят идеальными блоками по 40 секунд. Они поправляются, перебивают, уточняют, смеются, жалуются на качество звука. Если помощник продолжает pitch после фразы «голос странный», доверие падает. Поэтому в сценарий нужно встроить реакцию на сам разговор: «поняла», «сейчас короче», «да, слышу», «давайте одним вопросом». Это не театральность. Это минимальная гигиена голосового интерфейса.

Проверять такие вещи нужно ушами. Транскрипт покажет слова, но не покажет, как долго человек ждал ответа, где помощник звучал тяжело, где пауза убила доверие, где клиент уже хотел закончить разговор. Поэтому первые тесты лучше слушать целиком: приветствие, первая реакция, перебивание, финальная передача. Только после этого текст сценария начинает соответствовать живому звонку, а не красивой схеме на бумаге.

Сценарий Алисы: квалификация без фальшивой человечности

Фальшивая человечность в голосовых ботах раздражает сильнее, чем честный автоматический помощник. Человек быстро слышит, что с ним говорит система. Проблема начинается там, где система пытается скрыть свою природу, обещает невозможное или делает вид, что сидит в офисе с календарём и прайсом. В Solar сценарий Алисы строится иначе: она не маскируется под менеджера, а выполняет конкретную работу на первом входящем звонке.

Базовый сценарий состоит из 5 шагов. Первый — короткое приветствие и обозначение роли. Второй — вопрос про бизнес или задачу человека. Третий — уточнение источника заявок: Telegram, сайт, Instagram, WhatsApp, звонки, рекомендации. Четвёртый — вопрос про боль: где теряются обращения, кто отвечает, как фиксируются договорённости. Пятый — одна гипотеза автоматизации и передача Юрию, если разговор похож на живой интерес. Такая структура удерживает разговор в полезном коридоре и не превращает звонок в допрос.

Пример нормального первого хода: «Здравствуйте, я Алиса, голосовой помощник Solar. Помогу понять, есть ли смысл автоматизировать ваш входящий поток. Скажите, у вас сейчас заявки чаще приходят в звонки, Telegram или форму на сайте?» В этой фразе нет продажи, цены, обещания результата и длинной самопрезентации. Есть роль и один вопрос. Дальше помощник должен идти от ответа, а не от заранее заученного полотна.

Если человек говорит, что заявки приходят в Telegram и менеджер отвечает вручную, Алиса может уточнить: «А где чаще теряется контекст: человек не отвечает вовремя, забывает записать договорённость или не передаёт заявку дальше?» Если человек говорит про звонки, вопрос другой: «Звонки сейчас кто-то слушает после разговора или всё остаётся в памяти менеджера?» Такие вопросы хороши тем, что они одновременно квалифицируют лида и показывают, как думает система.

Нельзя давать помощнику право назначать цену. В Solar есть жёсткое правило: цены клиентам даёт только Юрий. Для голосового AI-продавца это особенно важно. Человек на звонке легко воспринимает фразу помощника как обещание компании. Поэтому Алиса не говорит «это стоит столько-то» и не обещает сроки внедрения. Она может сказать: «По цене и срокам Юрий ответит сам после контекста. Я сейчас соберу главное, чтобы он не начинал разговор с нуля». Это честно и снижает риск мусорных обещаний.

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

Post-call контур: запись, текст и управленческий смысл

Голосовой AI-продавец без post-call контура создаёт новую слепую зону. Разговоры вроде бы проходят, клиент вроде бы услышан, помощник вроде бы что-то сказал, но владелец не видит, что произошло. Потом начинается старый сценарий: «а что он спрашивал?», «а почему ему не ответили?», «а кто обещал перезвонить?». Поэтому запись и текст разговора нужны не для коллекции логов, а для управления.

Минимальный post-call пакет в Solar включает запись звонка голосовым сообщением в Telegram, полный текст разговора и краткий отчёт с якорями. В отчёте должны быть не красивые выводы, а рабочие поля: кто звонил, какой бизнес, откуда заявки, какая боль, какой следующий шаг, нужно ли Юрию подключиться, есть ли риск неверного обещания. Если помощник сказал что-то спорное, это тоже должно попасть в отчёт. Система не должна прятать собственные ошибки.

Такой контур меняет роль владельца. Ему не нужно сидеть у телефона, чтобы не потерять входящий поток. Он может прослушать запись, увидеть текст и решить, стоит ли писать человеку самому. Для небольшого бизнеса это особенно ценно: входящих может быть немного, но каждый требует внимания. Автоматизация не должна превращать владельца в наблюдателя за дашбордами. Она должна сжимать хаос до нескольких понятных решений в день.

Post-call отчёт также помогает улучшать самого помощника. Если в 10 разговорах подряд Алиса задаёт вопрос слишком рано, это видно. Если люди часто перебивают на одной фразе, её нужно сократить. Если клиенты спрашивают про цену, а помощник отвечает слишком уклончиво, можно добавить честную фразу про то, что цену даёт Юрий после контекста. Настройка голосового продавца — это не один prompt, а цикл прослушивания, правок и повторных звонков.

Хороший post-call контур должен быть привязан к каналу, где владелец уже живёт. В Solar это Telegram. Не отдельная админка, куда никто не зайдёт. Не папка с файлами без контекста. Запись приходит туда, где Юрий может быстро открыть голосовое, увидеть резюме и написать следующий ответ. Чем меньше трения между звонком и решением владельца, тем выше шанс, что система останется в работе после первого дня эксперимента.

Отчёт после звонка стоит хранить как отдельный объект, а не только как сообщение в чате. В сообщении удобно принять решение сейчас, но через месяц понадобится поиск: кто спрашивал про Telegram, кто жаловался на пропущенные звонки, кто просил финансовый контроль, кто уже получил ответ владельца. Поэтому у post-call слоя должны быть идентификатор звонка, дата, канал, статус и ссылка на запись. Тогда голосовой контур становится базой знаний по входящим обращениям.

Финансовый контроль строится по той же логике

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

В Solar проверили июньскую выписку Danamon и отдельно зафиксировали период: с 1 по 30 июня. Это важная деталь, потому что июльская выплата Booking не должна подтверждаться июньской банковской выпиской. Если смешать банковское движение с управленческим учётом, можно получить фантомную недостачу. Деньги не исчезли, но система показывает тревогу, потому что периоды и источники перепутаны.

Дальше сверяли переводы Кетут. Там всплыла строка на 69 187 500 IDR. Сначала она выглядела как крупная пропажа. После разбора оказалось, что одна запись была дублем, а у другой был неправильный знак. Выплату зарплаты за июнь вынесли отдельной датой на 3 июля. После сверки старый взаиморасчёт с Кетут после передачи денег закрыли в ноль, а новый поток начали считать после 5 июня. Это скучные детали. Именно они отделяют управленческий контроль от гадания по таблице.

Здесь работает тот же принцип, что и с post-call отчётом. В системе должны быть период, источник, тип события, запись и следующий статус. Для звонка это канал, запись, текст, боль клиента и следующий шаг. Для финансов это банк, дата, контрагент, знак, период, связанный документ и статус сверки. Когда этих полей нет, владелец получает не управление, а тревожный шум.

Автоматизация финансового контроля не обязана начинаться с большой ERP. Иногда первый рабочий слой — это жёсткая дисциплина вокруг дат и источников. Выписка Danamon за июнь не отвечает за июльскую выплату Booking. Перевод Кетут после 5 июня не должен смешиваться со старым взаиморасчётом. Зарплата за июнь, выплаченная 3 июля, должна жить как отдельное событие. Эти правила можно и нужно превращать в код, но сначала они должны быть явно названы.

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

Как собрать такой контур в малом бизнесе

Если переложить опыт Solar в нейтральный чек-лист, получится не «внедрить AI», а собрать 2 управляемых потока: входящие обращения и деньги. Начинать лучше с одного канала, а не со всех сразу. Например, только Telegram-звонки или только звонки с сайта. Дальше нужен технический маршрут: канал, SIP или телефония, узел обработки, голосовая платформа, запись, транскрибация, отчёт владельцу. Пока нет стабильной записи и отчёта, запускать рекламу на такой контур рано.

Второй шаг — сценарий. Его лучше писать не как продажную презентацию, а как короткий протокол квалификации. Роль помощника, 3-5 главных вопросов, список запретов, условия передачи владельцу, fallback при плохом звуке, правила реакции на перебивания. Отдельно стоит выписать фразы, которые помощник не имеет права говорить: цены, точные сроки, гарантии, обещания от имени владельца. Это снижает риск уже на первом дне.

Третий шаг — post-call пакет. Запись должна приходить туда, где владелец её увидит. Текст разговора нужен для поиска и разбора. Краткий отчёт должен быть одинаковым по структуре, иначе каждый звонок придётся читать заново. В отчёте полезны поля: «тип бизнеса», «канал заявок», «боль», «интерес», «следующий шаг», «риск», «нужен ответ Юрия или менеджера». Названия можно поменять под компанию, но структура должна быть стабильной.

Четвёртый шаг — финансовая связка. Каждый входящий контур рано или поздно приводит к оплатам, счетам, переводам и сверкам. Если звонок автоматизирован, а деньги потом разбираются вручную из 4 источников, бизнес всё равно зависит от памяти владельца. Минимальный слой контроля: банковская выписка по периоду, таблица управленческих событий, правила для дублей, правила для знаков, отдельные даты для выплат за прошлый период и отчёт по расхождениям.

Пятый шаг — ручной мониторинг первых 20-30 событий. Для звонков это прослушивание разговоров и правка сценария. Для финансов это проверка каждой строки, которая выглядит как пропажа, дубль или перенос между периодами. Автоматизация без первого ручного контроля быстро закрепляет ошибки. Сначала система должна показать, что она понимает реальные события бизнеса, и только потом ей можно отдавать больше рутины.

Шестой шаг — критерии остановки. Если качество звука плохое, помощник долго молчит, post-call отчёт не приходит или финансовая сверка путает периоды, контур нельзя считать рабочим. Лучше остановить расширение, исправить один слой и снова прогнать тестовые события. В малом бизнесе автоматизация должна уменьшать число ручных проверок, а не добавлять владельцу ещё один канал тревоги.

Связанный разбор про операционный слой агентов можно прочитать в статье AGENTS.md как операционная инструкция для AI-команды. Там тот же принцип: агенту нужен не красивый промпт, а границы, контекст, источники правды и понятный протокол передачи.

Что забрать в свою систему

Главный вывод из этого дня простой: голосовой AI-продавец не должен быть отдельной игрушкой. Он должен стать частью операционного контура. Человек звонит, система принимает звонок, задаёт короткие вопросы, сохраняет запись, отдаёт владельцу отчёт и не обещает лишнего. Финансы работают по тому же правилу: выписка имеет период, перевод имеет знак, контрагент имеет статус, ошибка должна объясняться строкой, а не ощущением, что где-то пропали деньги.

Для внедрения в малом бизнесе достаточно начать с 3 артефактов. Первый — карта входящего звонка: откуда пришёл, через что прошёл, где записался, кому ушёл отчёт. Второй — сценарий первого разговора: роль помощника, вопросы, запреты, условия передачи человеку. Третий — таблица финансовой сверки: период, источник, дата, контрагент, сумма, знак, статус, комментарий. Эти документы выглядят скучно, зато именно они превращают AI из демонстрации в рабочую систему.

Не надо начинать с обещания, что голосовой помощник заменит отдел продаж. В Solar первый день дал более трезвый результат: звонок прошёл, звук не развалился, Алиса стала говорить короче и человечнее, после звонка появился отчёт, а вечерняя сверка сняла фантомную дыру в финансах. Этого достаточно, чтобы двигаться дальше: слушать реальные звонки, улучшать сценарий, закрывать ошибки учёта и постепенно убирать повторяемую ручную работу из головы владельца.

Полный набор артефактов — AGENTS.md, промпты, схемы контуров, примеры post-call отчётов и рабочие разборы из моей системы — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Solar OS.