ИИ-агент для Telegram и WhatsApp: как он обрабатывает заявки и передает их в CRM

Клиент пишет в Telegram или WhatsApp в 22:47: спрашивает цену, уточняет сроки и хочет понять, подойдет ли ему услуга. В обычной схеме сообщение остается непрочитанным до утра или попадает в общий чат, где менеджер сначала выясняет контекст, затем вручную создает контакт и сделку в CRM. ИИ-агент меняет не только скорость ответа. Он превращает переписку в управляемый процесс: распознает намерение, задает уточняющие вопросы, обращается к базе знаний, проверяет правила компании, записывает структурированные данные и передает человеку уже подготовленный лид.

Но мессенджер сам по себе не становится агентом. Telegram предоставляет Bot API, WhatsApp работает через Business Platform и связанные бизнес-инструменты Meta. Логика квалификации, доступ к знаниям, интеграция с CRM, контроль действий и журналирование строятся отдельно. Если связать компоненты без четкой архитектуры, получится дорогой автоответчик, который красиво разговаривает, но засоряет CRM и теряет важные детали.

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

Короткий ответ: что делает ИИ-агент в мессенджере

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

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

Рабочая схема включает пять слоев:

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

Telegram и WhatsApp: одинаковая задача, разная инфраструктура

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

В июне 2026 года Meta представила Meta Business Agent: он может отвечать на вопросы, рекомендовать товары из каталога, квалифицировать лиды, бронировать встречи и передавать разговор сотруднику. Для крупного внедрения Meta отдельно описывает платформу с подключением внешних систем, правилами и измерением результата. Это важный рыночный сигнал, но не отмена проектной работы: бизнесу все равно нужны корректные данные, интеграция с CRM и ограничения на действия агента.

В Telegram аналогичный сценарий обычно собирается на базе официального Bot API и собственной логики. Telegram дает транспорт и интерфейс, а не готового продавца. Поэтому качество зависит от архитектуры, базы знаний и того, как агент связан с бизнес-процессом.

Как заявка проходит путь от сообщения до CRM

1. Прием события и восстановление контекста

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

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

2. Определение намерения

Фраза «Сколько будет стоить подключить это к нашей CRM?» содержит как минимум три сигнала: интерес к интеграции, наличие CRM и запрос цены. Агент классифицирует обращение, извлекает сущности и решает, какой следующий шаг нужен. Он не должен сразу выдавать случайную цену, если расчет зависит от числа каналов, объема обращений и набора интеграций.

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

3. Сбор обязательных данных

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

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

4. Ответ по базе знаний

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

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

5. Создание или обновление сущности в CRM

Перед созданием нового контакта система ищет совпадения по номеру телефона, Telegram ID, email или другому устойчивому идентификатору. Затем выбирает действие: обновить существующую карточку, создать новый лид или открыть сделку по действующему клиенту. Это критический этап: если каждый диалог порождает новый лид, менеджеры быстро перестают доверять автоматизации.

В Bitrix24, например, внешняя интеграция может создавать и изменять CRM-сущности через REST API и webhooks. Официальная документация отдельно предупреждает, что секретный ключ webhook дает доступ к данным и не должен попадать в публичный код. Аналогичные требования действуют для любой CRM: токены хранятся на сервере, права ограничиваются необходимыми методами, действия журналируются.

6. Передача менеджеру

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

Что именно записывать в CRM

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

Практический пример: заявка на внедрение ИИ-агента

Клиент пишет в WhatsApp: «Нужно отвечать на заявки ночью и складывать все в Битрикс. У нас около 300 обращений в месяц». Агент не начинает с презентации компании. Он фиксирует канал, объем и CRM, затем уточняет, откуда приходят обращения и что должно происходить после квалификации.

После двух коротких вопросов система получает достаточно данных: заявки идут с сайта и рекламы, основная задача — записывать на консультацию, менеджеры работают с 9:00 до 19:00. Агент отвечает на базовые вопросы, предлагает доступные окна, получает имя и телефон, после согласия создает контакт и сделку, записывает источник, объем и CRM, ставит задачу ответственному на начало рабочего дня.

Менеджер утром видит не стену сообщений, а карточку: «Компания рассматривает ночную обработку 300 обращений в месяц; каналы — сайт и реклама; CRM — Битрикс24; требуется квалификация и запись на консультацию; встреча предложена на 11:30; клиент ожидает подтверждения». Он проверяет данные и продолжает разговор с конкретного шага.

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

Где заканчивается автоматизация и начинается работа человека

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

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

Что агенту нельзя разрешать без дополнительного контроля

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

Почему такие проекты часто проваливаются

Агент отвечает красиво, но не двигает процесс

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

CRM заполняется мусором

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

База знаний не соответствует реальной работе отдела

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

Нет владельца процесса

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

Как оценивать результат

Количество диалогов и скорость первого ответа полезны, но не показывают, помогает ли агент продажам. Метрики должны связывать мессенджер, CRM и итог сделки.

Безопасный порядок запуска

1. Выбрать один канал и один сценарий: например, ночная обработка новых заявок с записью на консультацию.
2. Зафиксировать обязательные данные, правила квалификации, основания для отказа и триггеры передачи менеджеру.
3. Подготовить узкую базу знаний и назначить владельца каждого критичного ответа.
4. Подключить CRM сначала в режиме черновика: агент предлагает поля и действия, сотрудник подтверждает.
5. Проверить тестовые диалоги, включая опечатки, голосовые сообщения, агрессию, смену темы и повторного клиента.
6. Открыть ограниченный реальный поток и сравнить карточки агента с ручной обработкой.
7. Только после стабильной статистики разрешать автономное создание задач, сделок или встреч.

Технически проект должен предусматривать повторную доставку событий, защиту от дублей, тайм-ауты внешних сервисов, журнал запросов к CRM и возможность быстро отключить отдельное действие. Иначе временная ошибка API превращается в потерянную заявку или повторное создание сделки.

Когда ИИ-агент в Telegram или WhatsApp действительно оправдан

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

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

Что в итоге получает бизнес

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

Telegram и WhatsApp дают удобные каналы общения, языковая модель помогает понимать свободную речь, но надежность решения определяют правила, данные и интеграции. Чем точнее описан процесс и уже первый контур автономности, тем быстрее можно получить результат без риска для продаж.

Вам нужен ИИ для бизнеса? Обращайтесь к нам в Полигант. Вы не платите за гипотезы и эксперименты. Мы берем на себя анализ, разработку и внедрение AI-решения, которое должно приносить бизнесу реальную пользу.

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

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

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