Как превратить переписки и звонки клиентов в сценарий ИИ-агента

Содержание статьи

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

Клиенты при этом ведут себя по-своему. С первого сообщения спрашивают цену, не объяснив, что им нужно, и задают три вопроса сразу. Редко говорят прямо «дорого»: пишут «надо посоветоваться с мужем», «а у вас рассрочка есть?» или просто перестают отвечать. Начинают переписку в MAX, через день звонят, а потом дописывают в Telegram и ждут, что их помнят. В скрипте таких поворотов нет, и бот, спроектированный по идеальному процессу, на реальных диалогах ошибается.

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

Как устроен метод

Метод состоит из семи шагов: от разбора диалогов до запуска агента. Каждый шаг можно пройти вручную, но быстрее - с ИИ-помощником.

Для этого мы сделали скиллы. Скилл - это инструкция для ИИ-помощника в Claude Code или Codex: какие материалы прочитать, что в них найти, какие вопросы задать и в каком виде записать результат. Помощник выполняет шаг по инструкции, а решения, которые касаются бизнеса, выносит вам. Результаты всех шагов он записывает в один документ проекта, поэтому работу можно прервать и продолжить позже.

Скиллы выросли из того, как мы проектируем ботов для клиентов. Мы сверили их с открытыми руководствами Anthropic (Building effective agents, Demystifying evals for AI agents, Customer support agent) и практическим руководством OpenAI.

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

Вам остаётся отвечать на вопросы, подтверждать решения и вносить правки. Промпты, цепочки, выбор сервисов и настройку интеграций берут на себя агенты.

Что нужно на входе

• Переписки и расшифровки звонков с разными исходами: сделки, которые закончились покупкой или записью, отказы и обращения, оставшиеся без ответа.
• Прайс и справочные данные: услуги, цены, адреса, график работы, условия оплаты.
• Действующие регламенты и скрипты, если они есть.
• Список систем, с которыми агент будет работать: CRM, мессенджеры, телефония, календарь, платёжный сервис и учётная система. У каждой компании она своя: МИС в клинике, LMS в онлайн-школе, ERP или 1С на производстве и в торговле.

Если CRM подключена к Bewise, ничего выгружать не нужно: звонки и переписки уже собраны по каждой сделке. Через MCP-доступ Claude Code или Codex читает эти данные напрямую: достаточно попросить разобрать выигранные и проигранные сделки за последний месяц.

Скрипты и представления руководителя о процессе тоже пригодятся: их сверяют с диалогами и видят, где реальная работа с ними расходится.

Шаг 1. Разобрать диалоги

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

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

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

Шаг 2. Написать сценарии и решить, когда бот зовёт сотрудника

По итогам разбора описываются сценарии. Для каждого записывается:

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

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

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

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

Шаг 3. Заложить базу знаний и возражения

Агент отвечает на вопросы и возражения. Если оставить и то и другое на усмотрение модели, она начнёт придумывать цены, условия и скидки. Поэтому ответы на них закладываются в архитектуру заранее.

База знаний

Факты, от которых зависит решение клиента, хранятся в утверждённом источнике: цены, услуги, специалисты, адреса, график, условия оплаты. Модель не пишет их по памяти.

• Частые вопросы - в инструкции модели. Цены, график, адреса и другие сведения, о которых спрашивают постоянно, агент знает сразу и не ищет их.
• Редкие и сложные вопросы - в поиске по базе знаний. Подробные условия договора, описание сотни курсов, технические характеристики агент находит в документах, когда о них спрашивают.
• Готовый ответ сверяется с источником. В клинике код находит в тексте ответа все суммы и сравнивает их с прайсом. Если суммы нет в прайсе, сообщение не уходит.
• Вопрос, на который в базе нет ответа, передаётся сотруднику. Бот не пытается ответить общими словами.
• Цены меняются без программиста. Прайс хранится с версиями: новая цена публикуется новой версией, старая остаётся для отката.

Возражения

Список возражений берётся из тех же диалогов. Для каждого возражения разбор показывает, как на него отвечали в сделках, которые закончились покупкой, и что происходило в проигранных.

В архитектуре возражение - отдельная ветка сценария:

1. Модель определяет, что клиент возражает, и относит возражение к одному из известных типов.
2. Код выбирает для этого типа утверждённый ответ.
3. После ответа агент возвращает разговор к шагу, на котором клиент возразил.
4. Если клиент продолжает сомневаться, агент действует по правилу для этого возражения.

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

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

Шаг 4. Подключить действия во внешних системах

Агент может не только отвечать, но и выполнять действия: записывать клиента в календарь или учётную систему, выставлять счёт, проверять оплату, создавать заказ, узнавать статус доставки. Каждое такое действие подключается как инструмент - операция с понятным входом и результатом, которую агент вызывает по ходу разговора.

Правила, которые мы закладываем в каждый проект:

• Модель собирает данные, код проверяет условия. Модель понимает, что клиент хочет записаться на четверг вечером. Код запрашивает свободное время в календаре или учётной системе и проверяет, что услуга есть в прайсе. Сумму счёта код тоже берёт из прайса, а не из разговора.
• Клиент узнаёт о результате только после ответа системы. «Вы записаны» или «оплата получена» агент пишет, когда календарь или платёжный сервис это подтвердили. Если клиент пишет «я оплатил», агент проверяет статус платежа, а не верит на слово.
• Перед записью или счётом агент повторяет данные. Клиент видит услугу, время или сумму и подтверждает их. Исправить ошибку до записи проще, чем отменять неверную запись.
• Одна операция выполняется один раз. Если событие пришло повторно, клиент не должен получить второй счёт, а в календаре не должна появиться вторая запись. Для этого у каждой операции есть свой ключ.
• Для каждой ошибки есть заранее описанный ответ. Время занято - агент предлагает другое. Оплата не найдена - уточняет данные и зовёт сотрудника. Система не ответила - агент не повторяет операцию вслепую, а сначала проверяет, выполнилась ли она.
• Доступ - только к нужным операциям. Агенту, который проверяет оплату, не нужны права на возврат денег. Ограничения задаются в интеграции: запрет в тексте инструкции не защищает от ошибки. Ключи доступа хранятся на сервере и не попадают в инструкцию модели.
• Сначала тестовая среда. Прототип работает с тестовым календарём и тестовым режимом платёжного сервиса.

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

Шаг 5. Подготовить проверки

Каждое правило превращается в проверочный случай ещё до того, как написан бот. Для каждого случая записывается, что должно произойти и что недопустимо:

Результат проверяется по состоянию CRM, а не только по тексту ответа. Если бот написал «заявка передана», а задачи в CRM нет, случай провален.

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

Шаг 6. Выбрать архитектуру

На этом шаге работа распределяется между кодом, моделью, CRM, внешними системами и сотрудником. Главный принцип взят из руководства Anthropic: начинать с простого решения и усложнять, когда простое не справляется.

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

Путь сообщения в боте клиники:

1. Сервис сохраняет входящее сообщение в базу.
2. Ждёт 12 секунд, чтобы склеить сообщения, отправленные подряд.
3. Проверяет, должен ли бот отвечать: этап сделки, нет ли в диалоге сотрудника.
4. Модель возвращает смысл сообщения.
5. Если модель нашла услугу или время, второй короткий запрос проверяет, что это действительно есть в тексте пациента.
6. Код выбирает шаг и собирает ответ из утверждённых текстов и каталога.
7. Проверка сверяет суммы с прайсом и не пропускает обещания записи и медицинские советы.
8. Сначала в CRM создаётся задача, потом пациент получает сообщение, что с ним свяжется администратор.

На одно сообщение приходится один-два вызова модели.

Несколько агентов и главный агент

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

Пример такой системы для застройщика:

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

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

Шаг 7. Собрать прототип и запустить

Большая часть проблем после запуска связана с интеграцией, а не с моделью. Проверьте заранее:

• Повторы событий. CRM и мессенджеры иногда присылают одно событие дважды. Каждый шаг защищён уникальным ключом, чтобы клиент не получил два ответа и сотрудник - две задачи.
• Сообщения во время ответа. Пока модель думает, клиент может написать ещё. Часть интеграций такие сообщения не передаёт, поэтому нужна сверка: клиент написал, ответа нет - агент обрабатывает сообщение повторно или ставит задачу сотруднику.
• Сбой модели. Если модель недоступна или у сервиса закончились деньги, пустой или выдуманный ответ не должен уйти клиенту. Агент молчит и зовёт сотрудника.
• Лимиты CRM. CRM ограничивает число запросов в секунду. Если агент превышает лимит, CRM может заблокировать весь аккаунт, включая работу менеджеров.
• Доставка. Успешный ответ сервиса отправки не означает, что клиент получил сообщение. Статус доставки сверяется отдельно.

Запускаем в три этапа. Сначала агент работает «в тени»: принимает решения по живым обращениям, но ничего не отправляет. Затем - на небольшом числе сделок. Затем - на всех новых обращениях, с выключателем, который останавливает агента без участия разработчика.

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

Сколько это занимает

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

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

Чек-лист перед запуском

• Сценарий собран по реальным диалогам, включая отказы.
• Для каждой ветки понятно, что делает агент и когда передаёт диалог сотруднику.
• Сотрудник получает от бота все данные и не перечитывает переписку.
• Агент замолкает, когда в диалог вступает сотрудник.
• Цены и условия берутся из утверждённого источника, ответ сверяется с ним.
• У каждого возражения есть утверждённый ответ и понятно, когда подключается сотрудник.
• Для каждого действия во внешней системе описаны условия, результат и ответ на ошибку.
• О записи или оплате клиент узнаёт только после подтверждения системы.
• У агента есть доступ только к нужным операциям, интеграции проверены в тестовой среде.
• Есть проверочные случаи, и модель выбрана по их прогону.
• Повтор события не создаёт второй ответ, вторую задачу, второй счёт или вторую запись.
• Сбой модели или CRM не приводит к пустому или выдуманному ответу.
• Назначен человек, который читает живые диалоги.

Как начать

Подключите Claude Code или Codex к Bewise через MCP-доступ или положите выгрузку диалогов в папку проекта. Добавьте прайс и вызовите главный скилл «Ведение проекта» командой /agent-project. Помощник разберёт материалы, задаст до трёх вопросов, от которых зависит решение, и начнёт документ проекта. Команды остальных скиллов - в памятке к архиву.