Создание ИИ-агента без кода: база знаний, многоходовые диалоги, действия

Почему большинство «ИИ-агентов» останавливаются на ответах на вопросы

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

Для руководителей CX, поддержки и RevOps, оценивающих эту категорию, это различие имеет коммерческое значение. Бот, который просто ищет по базе знаний, отклоняет тикеты, которые и так были простыми. Агент, способный вести многоходовой диалог и выполнять действие — оформить возврат средств, оформить RMA, эскалировать претензию — отклоняет тикеты, обработка которых вручную реально стоит вам денег. В этой статье разбирается, что нужно, чтобы построить такого агента без привлечения инженерных ресурсов, используя строительные блоки, которые у большинства команд уже есть или которые можно быстро развернуть.

Три уровня, необходимые настоящему агенту

Уровень 1: Опора на базу знаний

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

Именно это даёт шаблон Support Portal из коробки: раздел базы знаний, доступный публично, находится рядом со страницами, требующими входа, такими как отслеживание тикетов, на одном домене. Структура страниц поддерживает динамические страницы — слаг с префиксом-двоеточием вроде articles/:articleId отображает нужную запись базы знаний из Data List, а значит, содержимое вашей базы знаний хранится в структурированной сущности данных, а не разбросано по PDF-файлам. Именно такая структура нужна агенту для надёжного извлечения информации.

Уровень 2: Многоходовой контекст, который не сбрасывается

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

Возможность Threads в SurveyAnalytica создана именно для этого. Тред типа «Разговор» изначально ориентирован на клиента — та же конструкция используется для диалогов RMA или последующих контактов с респондентами — и остаётся привязанным к сущностям, которых он касается: ответу, контакту, заказу, обрабатывающему его рабочему процессу. Один тред может одновременно ссылаться на ответ, кампанию, которая его сгенерировала, связанный контакт и обрабатывающий запрос рабочий процесс, с двунаправленной навигацией между ними. Это означает, что когда клиент возвращается к разговору два дня спустя, агент не начинает с нуля — он подхватывает тред (буквально), который уже знает, кто это и что обсуждалось.

Уровень 3: Выполнение действий, а не просто рекомендации

Именно здесь большинство продуктов «ИИ-агент» незаметно останавливаются. Они составят ответ, предложат следующий шаг или пометят тикет — но человеку всё равно придётся идти и выполнять это в другой системе. No-code агенту, который стоит внедрять коммерчески, нужно запускать реальные действия: создавать запись, отправлять отгрузку, публиковать в Slack, записывать в бухгалтерскую систему.

События жизненного цикла треда — тред создан, сообщение опубликовано, тред решён, заархивирован или закрыт — являются нативными триггерами для рабочих процессов. Решённый тред поддержки может автоматически запустить отправку транспортной этикетки. Действия, созданные внутри треда, наследуют связанные сущности треда и отображаются в Action Center со сроками выполнения и отслеживанием ответственных, поэтому ничто, созданное агентом, не пропадает в журнале чата — оно превращается в отслеживаемую задачу с владельцем. Для финансовых и операционных команд, уже использующих Tally Prime, коннектор поддерживает триггеры в реальном времени или пакетные — для каждого типа ваучера, так что инициированный агентом возврат может напрямую превратиться в кредит-ноту без ручного повторного ввода.

Четвёртый уровень: передача человеку

Агент, который никогда не эскалирует, — это не уверенность, а безрассудство. Честная цель дизайна — не полная автоматизация, а автоматизация тех частей, которые не требуют суждения, и направление остального человеку с полным контекстом, а не в виде холодного тикета. Клиентский тред, оставшийся без ответа 24 часа, может автоматически запустить уведомление в Slack, а внешние участники (клиент, сторонний установщик) могут быть приглашены в один конкретный тред без доступа к данным других рабочих пространств — доступ ограничен этим тредом и истекает в обязательную дату, которую вы устанавливаете. Именно этот механизм позволяет человеку подключиться к разговору с агентом в процессе, не переспрашивая всё заново и не открывая более широкий доступ к системе ради этого.

Разобранный пример: агент по возвратам для бренда электронной коммерции

Вот как четыре уровня складываются вместе для ритейлера среднего сегмента, обрабатывающего RMA через портал самообслуживания:

• Точка входа: Клиент заходит на брендированный Support Portal на returns.yourbrand.com и открывает публичную страницу базы знаний с политикой возврата. Если его вопрос там решён, взаимодействие завершается — тред не нужен, накладных расходов агента нет.
• Эскалация к диалогу: Если клиенту нужно реально оформить возврат, агент открывает тред-«Разговор» и запрашивает номер заказа, товар и причину — многоходовой обмен, а не выгрузка формы. Поскольку клиент вошёл в систему, тред уже связан с его записью контакта.
• Структурированный сбор деталей: Для заказа с несколькими товарами агент передаёт диалог в повторяющийся раздел формы RMA — по одному экземпляру на каждый возвращаемый товар, каждый последовательно помечен («Возвраты · Товар 1», «Возвраты · Товар 2») — так что клиенту, возвращающему три товара в одном заказе, не приходится проходить разговор три раза отдельно.
• Выполнение действия: Когда тред достигает статуса «решён» (возврат одобрен, право на возврат подтверждено), автоматически срабатывает триггер рабочего процесса: генерируется и отправляется по почте транспортная этикетка, а запись RMA обновляет систему заказов через вебхук.
• Передача человеку: Если тред остаётся без ответа 24 часа — скажем, агент не смог подтвердить право на возврат из-за пограничного случая политики, — уведомление в Slack подключает сотрудника поддержки, который присоединяется к тому же треду с уже видимым полным контекстом вместо начала с пустого тикета.

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

Что на самом деле требует от вас «no-code»

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

• Структурированный контент базы знаний. Агент извлекает информацию из того, что вы ему предоставили. База знаний, состоящая из разрозненных PDF-файлов и разбросанных вики-страниц, будет давать непоследовательные ответы, независимо от того, насколько хороша базовая модель. Перенос содержимого базы знаний в структурированную сущность Data List — это реальная работа, которую стоит выполнить один раз, но качественно.
• Чёткие пороги эскалации. Определите заранее, что означает «не решено» — 24 часа, три хода без ответа, определённый показатель тональности клиента — до того, как включите автоматизацию, а не после того, как клиент пожалуется на зацикливание бота.
• Непрерывность идентификации. Если вашему агенту для качественного ответа нужна история заказов или контекст покупок, потребуется связывать анонимные сессии просмотра с известными контактами при входе в систему — тот вид разрешения идентичности, который обрабатывает вызов identify в отслеживании кликстрима, связывая поведенческий сигнал с тем же ID контакта, который агент уже использует в своём треде разговора.
• Управление внешним доступом. Если клиенты или поставщики участвуют в тредах, обязательные сроки истечения внешних приглашений — это не необязательное дополнение, а именно то, что не даёт области действия агента поддержки незаметно превратиться в утечку данных.

Чем помогает SurveyAnalytica

SurveyAnalytica не продаёт единый виджет «ИИ-агент», приклеенный к окну чата, — платформа даёт компоненты, необходимые настоящему агенту, уже соединённые между собой: структурированную брендированную базу знаний через шаблон Support Portal, постоянные многоходовые треды-«Разговоры», остающиеся связанными с записью клиента и всеми связанными сущностями, и движок рабочих процессов, превращающий события треда в реальные действия — транспортные этикетки, уведомления в Slack, обновления ERP — вместо того, чтобы оставлять их рекомендациями в журнале чата.

Поскольку эти компоненты используют ту же модель данных, что и ваши опросы, порталы и коннекторы, разговор с агентом не становится изолированным силосом. Тональность, извлечённая из жалобы клиента на возврат, поступает в тот же слой аналитики, что и ваши опросы NPS; действие, которое она запускает, отображается в том же Action Center, что и ваши процессы согласования. В этом и заключается разница между развёртыванием чат-бота и созданием операционной возможности, которой можно реально управлять, аудировать и улучшать со временем.

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

Заключение

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