ИИ-агенту тесно в чате. Подключаем его к бизнесу через API Андаты

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

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

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

Зачем бизнесу API, если есть личный кабинет

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

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

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

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

Как соединяются агент, события и аналитика

У этой схемы четыре части.

Например: заявка → разбор агентом → запись в CRM → звонок менеджера → оплата → отчёт.

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

В Тег Менеджере Андаты задают смысл событий и правила их передачи. Факты из CRM, приложения и серверных систем должны поступать через настроенные подключения. Затем из этих данных можно строить отчёты и воронки.

Пять процессов, в которые можно встроить агента

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

1. Продажи: от заявки до подготовленного разговора

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

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

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

2. Интернет-магазин: консультация рядом с товаром

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

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

Цепочка измерения: вопрос задан → ответ показан → товар добавлен в корзину → заказ оформлен → оплата подтверждена. Отдельно стоит считать передачу вопроса человеку и повторные обращения. По API аналитики можно забирать события и денежные показатели, а по API воронок — видеть, на каком переходе прерывается путь.

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

3. Поддержка: ответ, после которого клиент продолжил работу

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

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

Рабочая цепочка: обращение создано → инструкция показана → пользователь повторил действие → действие успешно выполнено. Если продукт умеет фиксировать успешное подключение источника, это событие полезнее одного статуса «ответ отправлен». Дополнительные показатели — повторное обращение по той же проблеме, передача человеку и время до решения. API помогает собрать эти факты в панель поддержки вместе с обычными обращениями.

4. Активация клиента: довести регистрацию до первого результата

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

Чтобы выбрать следующий шаг, агенту нужны данные о настройке. Сервер может сообщить: код установлен, но событий ещё нет. Тогда агент поможет проверить отправку события. Эти сведения передаёт ваша интеграция или подключённый инструмент; одного сообщения пользователя «вставил код» для проверки установки недостаточно.

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

5. Маркетинг: от цифр к вопросу, который стоит проверить

По расписанию ваша система получает отчёт аналитики и показатели воронки, затем передаёт агенту агрегированные данные. Задача агента — подготовить разбор: где изменились показатели, на каком переходе выросли потери, какие объяснения согласуются с данными и чего не хватает для вывода.

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

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

Как создать агента внутри Андаты для такого процесса

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

Для агента, который разбирает заявки, это может выглядеть так:

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

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

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

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

Как вызвать агента по API

Для первого запроса нужны адрес личного кабинета, токен клиента и идентификатор доступного агента. Список агентов возвращает GET /api/v1/agents. Токен передаётся в заголовке X-Andata-Token; он определяет клиента и доступные ему данные.

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

curl 'https://lk.andata.ru/api/v1/agents/messages' \
  --header 'X-Andata-Token: YOUR_ACCESS_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "agent_id": "AGENT_ID_FROM_LIST",
    "message": "Разбери учебную заявку: нужна аналитика для интернет-магазина. Подготовь вопросы о текущих источниках данных, учёте заказов и целях внедрения.",
    "async": true
  }'

При асинхронном вызове API возвращает HTTP 202 и состояние processing, а также chat_id, request_id и адрес проверки status_url. Сохраните их. Затем запрашивайте состояние по status_url на том же адресе личного кабинета с тем же заголовком авторизации. При completed готовый ответ находится в message; при error нужно обработать ошибку.

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

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

Если ответ задержался, проверяйте status_url. Повторный POST может запустить работу заново. Это правило пригодится и при синхронном вызове: после 25 секунд ожидания он тоже может вернуть 202. Статус completed относится к обработке сообщения. Продажу в отчёте учитываем по событию оплаты из платёжной или учётной системы.

Полные параметры, история диалогов и обработка ошибок — в руководстве API агентов.

Какие события нужны, чтобы считать результат

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

Это примеры названий — в своём проекте используйте принятый справочник. Событие agent_result_saved отправляйте после сохранения разбора, а order_paid — после получения оплаты.

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

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

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

Как собрать свой отчёт через API аналитики и воронок

В опубликованном внешнем API есть четыре метода чтения:

Воронку сначала настраивают в личном кабинете Андаты. Через API получают её готовые показатели и собирают свою панель или регулярную выгрузку. Методов создания и изменения воронки в этой версии API нет.

Для отчёта сначала получите справочник /api/v1/analytics/events. Выберите реальные event_name, которые уже поступают в проект. Затем задайте события в нужных колонках отчёта. В примере ниже lead_received и order_paid должны существовать в вашем справочнике; даты тоже нужно заменить на период с данными.

curl --get 'https://lk.andata.ru/api/v1/analytics' \
  --header 'X-Andata-Token: YOUR_ACCESS_TOKEN' \
  --data-urlencode 'range[]=2026-09-01' \
  --data-urlencode 'range[]=2026-09-20' \
  --data-urlencode 'report=utm_source' \
  --data-urlencode 'events[0][]=lead_received' \
  --data-urlencode 'events[1][]=order_paid' \
  --data-urlencode 'attribution=all' \
  --data-urlencode 'limit=30'

В таком запросе колонка events_1 относится к выбранному событию заявки, а events_2 — к оплате. Денежные показатели имеют смысл, когда денежные данные действительно переданы и связаны с событиями. Без параметра events первая колонка считает все события, поэтому её нельзя автоматически назвать покупками.

Ответ содержит строки текущей страницы в data, общие итоги в total_sum и пагинацию в pager. Если страниц несколько, получите остальные. Общий итог не нужно суммировать повторно по каждой странице.

Для анализа переходов возьмите id воронки из /api/v1/funnels и запросите её levels за тот же период. В режиме chain_each учитывается прохождение предыдущих этапов по порядку; в chain_first промежуточные этапы можно пропускать. Выбирайте правило под смысл своей воронки: для строго последовательного процесса эти варианты дают разный ответ.

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

В итоге эти данные можно показать в собственной панели, добавить к отчёту руководителя или передать агенту для разбора. Ограничение частоты для воронок и аналитики — 120 запросов в минуту отдельно на каждый продукт. При 429 нужно снизить частоту и повторить запрос позже. Все параметры и скачиваемая спецификация OpenAPI есть в справке воронок и аналитики.

Как понять, что агент полезен бизнесу

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

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

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

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

С чего начать свой первый процесс

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

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

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

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