ИИ-агенты берут онбординг клиентов на себя: что уже работает

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

Речь не о чат-боте с деревом сценариев из 2019 года. Современный агент^* держит контекст диалога, вызывает внешние инструменты (CRM, базу знаний, платёжный сервис) и планирует последовательность действий сам, а не по жёстко прописанной ветке. Именно это отличает нынешнее поколение от классических ботов и делает автоматизацию онбординга реалистичной.

Что изменилось за последний год

Три вещи сошлись вместе. Модели научились устойчиво вызывать функции (function calling) — то есть по запросу пользователя дёргать нужный API и подставлять результат в ответ. Появились фреймворки для агентов, где логику «спроси — проверь — запиши» можно собрать без месяцев разработки. И крупные платформы автоматизации добавили ИИ-узлы, так что агент встраивается в уже существующий поток заявок.

На практике онбординг-агент закрывает четыре типовых задачи:

• Сбор данных. Вместо формы из 20 полей — диалог, где агент задаёт вопросы по одному и пропускает то, что уже знает из CRM.
• Проверка документов. Распознаёт скан паспорта или ИНН, сверяет с введёнными данными, отмечает расхождения.
• Настройка продукта. Проводит по первым шагам, подключает нужные модули, отвечает на вопросы из базы знаний через RAG^**.
• Передача человеку. Когда случай нестандартный, собирает всё в карточку и отдаёт менеджеру, а не бросает клиента.

Агент хорош не там, где заменяет менеджера целиком, а там, где снимает с него 80% однотипных заявок и оставляет 20% сложных — уже с готовым контекстом.

Чем подходы отличаются друг от друга

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

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

Кому это пригодится, а кому нет

Автоматизация онбординга через агента окупается не всегда. Ориентиры такие.

Пригодится

• Онлайн-сервисам с потоком регистраций. Если в день приходят десятки новых клиентов с одинаковыми вопросами — агент снимает нагрузку с поддержки и ускоряет первый успех пользователя.
• Финтеху и сервисам с проверкой документов. Распознавание и сверка данных экономят часы ручной работы, а спорные случаи всё равно уходят человеку.
• B2B с длинной анкетой. Диалоговый сбор данных вместо формы из 30 полей заметно повышает долю дошедших до конца.

Не пригодится или преждевременно

• Если клиентов мало. Пять регистраций в неделю менеджер обработает вручную быстрее и теплее, чем окупится настройка агента.
• Если процесс не описан. Агент автоматизирует то, что уже есть. Хаотичный онбординг он превратит в автоматизированный хаос.
• Где цена ошибки высока и нет проверки. В юридических или медицинских сценариях выпускать агента без обязательной проверки человеком опасно: модель может уверенно ошибиться.

Где агенты ломаются

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

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

Третье — обрыв контекста. На длинном диалоге агент забывает начало разговора, если не настроено сохранение состояния. Проверяйте сценарий на длинных заявках, а не только на демо из трёх реплик.

^* Агент — программа на базе языковой модели, которая не просто отвечает текстом, а планирует шаги и вызывает внешние инструменты (API, базы, сервисы) для выполнения задачи.

^** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом достаёт нужные фрагменты из вашей базы знаний и отвечает на их основе, а не только по памяти обучения.

^*** Контекстное окно — объём текста (в токенах), который модель удерживает за один запрос: и вопрос, и историю диалога, и подставленные данные. Когда окно переполняется, начало разговора «выпадает».