Как мы проектируем ИИ-агента для возврата клиентов через SIP-телефонию

Зачем звонить клиентам, которые перестали покупать

У компании со временем накапливается база прежних покупателей. Одни сменили поставщика, другие приостановили закупки, третьи просто давно не получали подходящего предложения. В таблице все они могут выглядеть одинаково, хотя причины ухода и вероятность возвращения у них разные. Менеджерам приходится заново выяснять, кто ещё работает в прежнем направлении, кому интересны новые цены и с кем имеет смысл продолжить разговор.

В этом проекте задача начинается с актуального прайс-листа и коммерческого предложения. Сотрудники выбирают группу клиентов и отправляют им материалы, после чего агент связывается с получателями. Он уточняет, удалось ли посмотреть предложение, собирает обратную связь и фиксирует интерес к закупке. Так мы хотим проверить, помогает ли дополнительный разговор вернуть покупателей, которым одной рассылки недостаточно.

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

Почему рассматриваем собственную систему

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

Приложение должно управлять очередью контактов, звонками и учётом результатов. Речевую часть планируем подключить через Yandex AI Studio Realtime, а телефонную — через SIP. SIP здесь означает способ соединить наше приложение с телефонией компании, чтобы агент мог звонить на обычные номера. Код и настройки передаём заказчику, поэтому новые сценарии и интеграции можно будет развивать в собственной системе.

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

Как должен проходить разговор

Предположим, клиент раньше покупал определённую группу товаров и получил обновлённый прайс-лист. Через согласованный промежуток времени агент звонит от имени компании и спрашивает, удалось ли ознакомиться с предложением. Говорить об отправленном письме он может только тогда, когда отправка подтверждена в данных контакта.

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

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

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

Из каких частей складывается приложение

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

Вторая часть — голосовой диалог. Realtime API позволяет обмениваться речью и ответами в реальном времени. Наше приложение задаёт контекст и правила разговора, а затем сохраняет его результат. До подключения к реальным клиентам отдельно проверяем шум, тишину, перебивание и вопросы за пределами согласованного сценария. Для выбора голосовой конфигурации используем одинаковые тестовые диалоги, чтобы сравнивать поведение в сопоставимых условиях. Документация Yandex.

Третья часть — связь с телефонией. В качестве возможной схемы рассматриваем собственный телефонный мост на Asterisk, который соединяет SIP-линию с речевой моделью. В документации Yandex описан такой способ подключения. Для проекта, однако, ещё нужно подтвердить совместимость конкретной услуги оператора, доступ к звуку в обе стороны и ограничения линии. Начинать планируем с одного или двух одновременных звонков на тестовые номера. Документация Yandex.

Четвёртая часть — журнал и выдача результатов. Для каждой попытки сохраняем технический статус, длительность и краткий итог разговора. Отдельно отмечаем интерес, причину отказа, просьбу о повторной отправке и удобное время контакта. Менеджер получает таблицу с результатами и задачами, связанными с конкретным клиентом. Неясный ответ остаётся помеченным для проверки, а не превращается автоматически в подтверждённую заявку.

Почему запускаем пилот поэтапно

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

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

В плане пилота предусмотрено до 4 000 минут состоявшихся разговоров. Это верхняя граница объёма проверки, а не обещанное количество клиентов или заказов. Размер базы, допустимое число попыток и период наблюдения согласуем до запуска. По ходу работы сотрудник проверяет выборку разговоров и точность итогов, а при существенных дефектах обзвон приостанавливаем и исправляем причину.

Как понять, помогает ли агент возвращать покупателей

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

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

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

Даже когда прирост заказов окажется небольшим, у проекта может быть отдельная польза для работы с базой. Разговоры помогут собрать причины отказов, найти неактуальные контакты и понять, кому предложение действительно интересно. Эту пользу учитываем отдельно от продаж, чтобы решение о развитии системы опиралось на понятные результаты.

Что можно добавить после проверки гипотезы

В первой версии подготовку базы, прайс-листа и рассылку выполняют сотрудники. Прямую интеграцию с 1С и автоматическую отправку предложений сознательно оставляем за рамками пилота. Для проверки влияния звонка достаточно обмена таблицами; сложная интеграция на этом этапе увеличила бы объём разработки до того, как станет понятен эффект.

Если пилот покажет полезный результат, следующим шагом можно связать приложение с 1С или CRM, автоматизировать подготовку задач и добавить новые товарные направления. Для каждого направления понадобятся собственные ограничения, актуальные материалы и контрольные диалоги. Возможность дорабатывать систему под процессы компании и есть одна из причин выбирать собственное приложение.

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

Больше материалов и разборов реальных кейсов об AI, автоматизации и разработке продуктов — в моём Telegram-канале.