Разговорный ИИ для бизнеса: сравнение 7 платформ в 2026 году
Сравнение Google, Copilot Studio, Cognigy, Rasa, Voiceflow, Botpress и Kore.ai: цены, чат и голос, передача оператору и контроль действий агентов.
Опубликовано

Чтобы внедрить разговорный ИИ в клиентский сервис, выбирайте платформу с учётом того, кто будет отвечать за агента после запуска: Cognigy — для действующего контакт-центра, Rasa — для команды, которая сама поддерживает код, а Google Conversational Agents — для инженеров, работающих с облачной инфраструктурой. При выборе любой из этих 7 платформ нужно ответить на один и тот же вопрос: что произойдёт, когда агент должен прекратить работу и передать её человеку?
Цены, правила тарификации и возможности продуктов сверены с актуальными страницами поставщиков 27 октября 2026 года. В статье сопоставляются заявленные функции и требования к внедрению; практического тестирования надёжности мы не проводили. Рекомендации касаются платформ для создания клиентских агентов и учитывают работу, которую придётся взять на себя вашей организации.
Небольшой службе поддержки с ограниченными инженерными ресурсами стоит начать с Voiceflow, если важна совместная разработка диалогов, или с Botpress, если нужен прежде всего чат-бот с публично указанной начальной ценой. В организации, где основа ИТ-среды — Microsoft, первым стоит оценить Microsoft Copilot Studio. Kore.ai — корпоративная альтернатива для проектов, которые объединяют автоматизацию обслуживания, помощь операторам и управление качеством сервиса.
Разговорный ИИ: краткое сравнение платформ
Указанные ниже начальные цены относятся к разным единицам работы. Запрос, Copilot Credit и диалог нельзя считать взаимозаменяемыми, а бесплатная лицензия не покрывает все сервисы, необходимые для работы агента.
Строка Google в таблице относится к тарифам Conversational Agents Flows/Playbooks. Прежний адрес страницы продукта теперь ведёт на Customer Experience Agent Studio, у которого есть отдельные страницы с описанием и ценами. Нельзя оценивать внедрение одного продукта по заявленной цене другого.
Что такое платформа разговорного ИИ?
Платформа разговорного ИИ — это программное обеспечение для проектирования, запуска и сопровождения клиентских диалогов: система отвечает на вопросы, выполняет бизнес-процессы и обращается к подключённым сервисам. Платформа даёт агенту рабочую среду, а компания предоставляет знания, права доступа, правила и маршрут передачи обращения человеку.
Полезная платформа сочетает большую языковую модель, или LLM, которая понимает и генерирует текст, со сценариями, где шаги выполняются в заданном порядке. Такие сценарии нужны, когда клиент меняет адрес, оспаривает списание или запрашивает данные учётной записи. Свободный диалог помогает человеку объяснить, что ему нужно. Явно заданная логика определяет, разрешено ли запрошенное действие.
Возьмём вопрос о заказе. Агенту нужны утверждённые сведения о доставке, способ установить личность клиента, подключение к системе заказов, правила допустимых изменений и возможность привлечь сотрудника, если требуется исключение. Одного складного ответа для выполнения всей задачи недостаточно.
Поэтому при выборе нужно смотреть шире, чем на окно чата:
- Проектирование диалогов: инструкции для LLM, предсказуемые сценарии, условия и резервные ответы.
- Каналы: чат на сайте, мессенджеры и голос; нужные функции проверяются в каждом канале отдельно.
- Действия и знания: доступ к утверждённым документам и бизнес-системам с соответствующими правами.
- Передача оператору: рабочий маршрут в систему поддержки, где есть сотрудники, с сохранением нужного контекста.
- Аналитика и оценка: данные о сбоях в диалогах, выполненных действиях и изменениях после выпуска новой версии.
- Ограничения: контроль доступа к информации, использования инструментов, контента и публикации, а также бизнес-правила за пределами промпта.
Если нужен готовый помощник для непосредственного использования, посмотрите сравнение лучших чат-ботов с ИИ. Готовые агенты, работающие внутри существующей службы поддержки, разобраны в сравнении ИИ-инструментов для клиентского сервиса. Здесь же речь о том, как создать и поддерживать собственную систему общения с клиентами.
Чем разговорный ИИ отличается от генеративного?
Разговорный ИИ описывает формат взаимодействия: система понимает сообщения и отвечает в рамках диалога. Генеративный ИИ — это способность создавать текст или другой контент, которую используют многие такие системы. Диалоговый агент может сочетать сгенерированные ответы с заранее подготовленными репликами и детерминированной бизнес-логикой.
Руководителю поддержки это различие полезно на практике. Пусть модель понимает фразу «посылка уехала на мою старую квартиру». А возможность изменить адрес пусть определяет процесс с проверкой личности клиента. Способность модели понять смысл не должна превращаться в право менять любую учётную запись, которую она может упомянуть.
Три типа платформ: кто отвечает за работу?
Корпоративные платформы для контакт-центров связывают создание агентов с процессами обслуживания. К этой группе относятся Cognigy и Kore.ai. Их стоит оценивать, когда ключевыми требованиями становятся маршрутизация обращений, телефония, работа операторов и контроль эксплуатации. Контакт-центр — это подразделение и программная среда для обработки звонков и сообщений клиентов; ИИ-платформа может подключаться к нему, а не заменять его.
Фреймворки для разработчиков и облачные конструкторы оставляют больше проектных решений вашей команде. Rasa — вариант для разработки через код. Voiceflow и Botpress в этой группе представляют облачные визуальные конструкторы. У каждого свой баланс между самостоятельным управлением инфраструктурой, визуальным редактированием и разработкой интеграций.
Конструкторы облачных провайдеров подходят организациям, которые уже умеют эксплуатировать облачные сервисы. В этой группе мы выбрали Google Conversational Agents и Microsoft Copilot Studio. Существующие решения для идентификации пользователей, интеграций и администрирования могут оказаться важнее небольших различий в редакторе диалогов.
Что делает платформу подходящей для крупного бизнеса?
Главный критерий — можете ли вы распределить ответственность за весь клиентский путь. Кто-то должен согласовывать изменения, поддерживать интеграции, обеспечивать работу очередей операторов и разбирать сбои. Покупка продукта с корпоративной маркировкой сама по себе никого на эти задачи не назначает.
Для международной службы поддержки нужно выяснить, кто вправе опубликовать изменённые правила возврата, как выбирается региональная очередь и что происходит, если принимающая платформа недоступна. Для небольшой компании вопросы те же, но ей может хватить более простого конструктора. Сложность организации процессов говорит о подходящей платформе больше, чем сама численность сотрудников.
По каким критериям отбирались платформы
В основе рекомендаций — опубликованные сведения о создании агентов, сочетающих LLM и заданные сценарии, передаче диалогов людям, ограничении действий, работе в нужных каналах и единицах тарификации. Для сравнения проверены страницы продуктов, тарифов и документации самих платформ.
Показатель containment — доля диалогов, оставшихся в автоматизированном обслуживании, — ни у одного поставщика не используется как прогноз для вашего бизнеса. Он не доказывает, что проблема клиента решена. Для деликатного обращения правильным результатом может быть успешная передача человеку.
Главное различие, которое выявляет это сравнение, — ответственность за передачу оператору. У Cognigy описаны коннекторы и узлы передачи. У Google — сигнал, который должна обработать ваша интеграция. У Rasa — шаблон поведения, который вам предстоит реализовать. Voiceflow различает подключение для ответов оператора в реальном времени и создание заявки. Botpress описывает изменение системы, куда передаются обращения из новых рабочих пространств. Именно эти детали определяют объём работ, скрытый за общей галочкой «передача человеку поддерживается».
Какие разработчики платформ вошли в сравнение
Эти семь поставщиков представляют корпоративные сервисные платформы, решения для самостоятельной разработки и облачные конструкторы. Мы не расширяем список за счёт персональных помощников, видеоаватаров или готовых агентов для help desk. Сначала идут наиболее подходящие варианты в каждой из трёх групп, затем — альтернативы для конкретных моделей работы.
Оценки применимости ниже — редакционные рекомендации. Документированная поддержка интеграций даёт платформе место в списке кандидатов. Но только пилот в вашем реальном канале покажет, работает ли для ваших клиентов весь сценарий целиком.
Сравнение семи платформ
1. Cognigy: для действующего контакт-центра
Cognigy, представленная под брендом NiCE Cognigy, — корпоративная платформа для создания клиентских агентов на базе существующего контакт-центра. В этом сравнении это первый кандидат для службы поддержки, основная сложность которой — согласованная работа голоса, чата, подключённых систем и передачи обращений операторам. По описанию поставщика, платформа объединяет рассуждения LLM с детерминированными шагами, оценкой качества, эксплуатационным контролем и аналитикой диалогов. Условие выбора вполне конкретное: масштаб ваших сервисных процессов должен оправдывать такую широту возможностей.
Кому подходит: Службам поддержки с налаженными процессами, ответственным за контакт-центр и командой внедрения.
Главное преимущество: Создание агентов связано с передачей обращений людям и повседневной работой службы поддержки.
Цена: По запросу; на актуальной странице платформы не удалось подтвердить числовой публичный тариф.
Пробный доступ: Есть демонстрация; наличие и условия пробного доступа уточняйте у поставщика.
Как устроена передача оператору
В документации Cognigy описаны Handover Providers — подключения агента к совместимому контакт-центру. Узел Handover to Human Agent запускает передачу внутри сценария. Для этого нужны подходящий коннектор и поддерживающая передачу конечная точка, то есть конкретное подключение канала. В списке поддерживаемых конечных точек есть Voice Gateway и Webchat. Документация также описывает узлы для проверки доступности операторов, отслеживания статуса передачи и её завершения. Документация Cognigy по передаче оператору
Для службы поддержки авиакомпании полезная демонстрация — проблемное бронирование, которое попадает в нужную очередь с работающими операторами и уже собранным контекстом о пассажире. Попросите внедренца показать, что видит принимающий сотрудник. Затем сделайте очередь недоступной. Успешная передача в идеальных условиях говорит меньше, чем понятный сценарий восстановления после сбоя.
Собственный продукт Cognigy Live Agent предоставляет рабочее место оператора для цифровых диалогов, включая контекст о клиенте и рабочие метрики. Его нужно оценивать отдельно от подключения ИИ к вашему существующему контакт-центру. Наличие рабочего места оператора в линейке продуктов не означает, что оно входит в ваше коммерческое предложение. Cognigy Live Agent
Как ограничить действия агента
Cognigy описывает инструменты с заданными параметрами и условиями выполнения, а также переключение между взаимодействиями под управлением LLM и структурированными сценариями. Среди возможностей агентной платформы также указаны модерация контента и фильтры против обхода ограничений модели. Используйте их как отдельные уровни защиты: фильтрация контента регулирует то, что модель говорит, а условия выполнения — то, разрешено ли запустить действие. Средства контроля агентов Cognigy
В случае проблемного бронирования модель может понять пожелания клиента, а правило — проверить условия тарифа до изменения билета. При приёмке попробуйте убедить агента внести запрещённое изменение. Ожидаемый результат — отказ в действии или передача оператору с понятной записью причины.
Вердикт: Выбирайте Cognigy, если сохранить работу существующего контакт-центра важнее, чем получить максимально простой конструктор. Для узкого FAQ на сайте, когда никто не отвечает за внедрение и сервисные процессы, платформа не подойдёт.
- Документированы подключения для передачи оператору и требования к каналам.
- Контроль доступности и статуса передачи помогает проектировать обработку сбоев.
- Структурированные шаги процесса сочетаются с взаимодействием через языковую модель.
- Платформа охватывает оценку качества и эксплуатационный контроль.
- Индивидуальные коммерческие предложения затрудняют раннее сравнение бюджетов.
- Совместимость коннекторов и конечных точек всё равно нужно проверять.
- Полноценное внедрение в контакт-центре требует более серьёзной организации работ, чем простой виджет чата.
Начните оценку с передачи обращения человеку
Ниже — предлагаемый пилот на основе документированных механизмов Cognigy, а не тест, проведённый для этой статьи.
Настройте принимающую службу
В разделе Deploy > Handover Providers настройте подключение к контакт-центру. Прежде чем проектировать остальной клиентский путь, убедитесь, что выбранная конечная точка поддерживает передачу оператору.
Явно задайте условие передачи
Добавьте в тестовый сценарий узел Handover to Human Agent. Первым условием сделайте прямую просьбу клиента связать его с человеком: так передачу будет легко воспроизвести.
Проверьте доступность и статус
С помощью документированных механизмов доступности и статуса различайте диалог, который ждёт в очереди, и диалог, уже принятый оператором. Определите, что увидит клиент, если никто не сможет принять обращение.
Проверьте диалог с оператором
Попросите коллегу принять обращение и ответить из системы поддержки. Проверьте доставку контекста, ответы клиента и завершение диалога. Прежде чем расширять пилот, повторите проверку при недоступной принимающей службе.
2. Rasa: для команды, которая сама поддерживает код
Rasa ориентирована на разработчиков: это выбор для тех, у кого поведение диалогового агента — часть продукта и кому нужен прямой контроль над его реализацией. Подход CALM, сокращённо от Conversational AI with Language Models, отделяет понимание языка от структурированных бизнес-сценариев. Он особенно интересен продуктовой команде с бэкенд-разработчиками и правилами сложнее, чем «отвечай по этим документам». Но та же необходимость всё сопровождать своими силами делает Rasa неудачным коротким путём для руководителя поддержки без инженерной команды.
Кому подходит: Техническим продуктовым командам, способным поддерживать интеграции, развёртывание и логику диалогов.
Главное преимущество: CALM отделяет интерпретацию запроса моделью от сценария, который выполняет задачу.
Цена: Бесплатная Developer Edition разрешает одного бота на компанию и до 1,000 диалогов с внешними пользователями в месяц; Enterprise — по запросу.
Пробный доступ: Бесплатная лицензия допускает локальное использование и работу в продакшене в пределах установленных лимитов.
Что даёт фреймворк
В CALM языковая модель интерпретирует сообщение и формирует команды. Менеджер диалога использует их, чтобы продвигаться по сценариям, вызывать бэкенд-интеграцию или обрабатывать изменения в разговоре. По умолчанию ответы строятся по шаблонам; дополнительно можно подключить компонент переформулирования. Такое разделение позволяет разработчикам явно описывать бизнес-шаги. Документация Rasa CALM
Представим сервис подписки, в котором клиент меняет условия доставки. Он может прервать смену адреса вопросом о дате доставки, а затем вернуться к исходной задаче. Нужно сохранить эту гибкость диалога, но само обновление учётной записи проводить через те же проверки, что и в остальных частях продукта. Свободно сформулированный ответ не должен незаметно обходить эти проверки.
В текущей документации Rasa продукты Rasa Pro и Studio отделены от более нового оркестратора Mantle и интерфейса создания агентов в раннем доступе. Здесь рекомендация относится именно к документированному подходу Pro/CALM. Уточняйте, какую среду выполнения и интерфейс предполагает конкретное внедрение: не все возможности под брендом Rasa относятся к одному выпуску или входят в одну лицензию. Область охвата документации Rasa
Как устроены передача оператору и ограничения действий
По умолчанию механизм передачи человеку в Rasa лишь сообщает пользователю, что помощник не может помочь. Чтобы передача действительно работала, нужно переопределить pattern_human_handoff и реализовать собственное действие. Это существенное различие: фреймворк предоставляет шаблон поведения в диалоге, а ваше приложение должно связать его с принимающей службой. Шаблон передачи оператору в Rasa
Реализация должна передавать сведения о личности клиента и нужную историю диалога, приостанавливать автоматические ответы и обрабатывать отказ системы поддержки принять обращение. Назначьте конкретного инженера ответственным за эту интеграцию. Формулировки «передача есть в сценарии» для приёмки недостаточно.
Rasa также поддерживает flow guards — условия, определяющие, может ли сценарий запуститься. Однако в документации указаны исключения для связанных и вызываемых сценариев, а также триггеров понимания естественного языка, или NLU. Рассматривайте guards как механизм управления диалогом, а проверку прав доступа выполняйте повторно в бэкенд-действии. При запросе данных учётной записи сервер должен проверять доступ независимо от того, по какому диалоговому пути пришёл запрос. Исключения для flow guards в Rasa
Какая работа остаётся за вашей командой
На странице тарифов Rasa указаны самостоятельное развёртывание и развёртывание в виде управляемого сервиса. Голосовой коннектор AudioCodes приобретается отдельно. Поэтому развёртывание, использование модели и телефонию нужно оценивать отдельно от лицензии. Бесплатная редакция полезна для проверки архитектуры, но не означает, что все необходимые для эксплуатации компоненты тоже бесплатны.
Вердикт: Выбирайте Rasa, если разработчики готовы сопровождать клиентский процесс как полноценное программное обеспечение. Если важнее быстро запустить и настраивать небольшого агента силами службы поддержки с меньшим объёмом инфраструктурных работ, лучше подойдёт облачный конструктор.
- Структурированные сценарии явно задают бизнес-шаги.
- Бесплатная лицензия позволяет провести ограниченную проверку в продакшене.
- Собственные действия создают понятную границу интеграции.
- Варианты развёртывания позволяют по-разному распределить ответственность за инфраструктуру.
- Для передачи оператору нужно реализовать интеграцию.
- У flow guards есть исключения; они не заменяют проверку прав на бэкенде.
- Расходы на голос, хостинг и модели нужно оценивать отдельно.
- При закупке нужно разобраться в терминологии перехода между продуктами.
3. Google Conversational Agents: для облачной инженерной команды
Google Conversational Agents — облачный конструктор, сочетающий детерминированные Flows, также известные как Dialogflow CX, с генеративными Playbooks. Он подходит разработчикам, которые готовы отвечать за клиентское приложение и хотят совместить заданные процессы с диалогами на базе языковой модели. Платформа особенно полезна, когда нужно выбирать, какие части клиентского пути генерировать, а какие проводить по явным шагам. Главное ограничение: движок агента сам по себе не становится полноценной системой поддержки с операторами.
Кому подходит: Облачным инженерным командам, создающим собственные клиентские сценарии для чата и голоса.
Главное преимущество: Flows и Playbooks дают разные способы управления диалогом.
Цена: Чат Flows — $0.007 за запрос; чат Playbooks — $0.012 за запрос; голос во Flows — от $0.001 за секунду аудио; для Playbooks и гибридных решений действуют другие правила тарификации.
Пробный доступ: Новым пользователям предлагаются кредиты на Flows и Playbooks.
Уточняйте, о каком продукте идёт речь
Текущий адрес страницы продукта ведёт на CX Agent Studio, входящий в Gemini Enterprise for Customer Experience. Тарифы Flows/Playbooks по-прежнему опубликованы отдельно. Этот раздел посвящён документированной системе Conversational Agents; её цену за запрос нельзя использовать для оценки CX Agent Studio. Актуальная страница CX Agent Studio
При обсуждении закупки это различие принципиально. Попросите поставщика или внедренца указать в предложении конкретные консоль, среду выполнения и единицу тарификации. Формулировка «разговорный ИИ Google» слишком широка, чтобы сверить счёт или воспроизвести показанную функцию.
Playbook может предоставлять информацию, обращаться к внешним сервисам или передавать работу сценарию Flow либо другому Playbook. Например, магазин может использовать генерацию текста, чтобы понять неоднозначную проблему с доставкой, а затем перейти к заданному процессу проверки личности и заказа. Проводите границу вокруг бизнес-действия, вместо того чтобы делать каждую реплику либо полностью скриптовой, либо полностью генеративной. Google Playbooks
Как устроены передача оператору и ограничения действий
Ответ Google live agent handoff сигнализирует вызывающей системе, что диалог нужно передать человеку. В документации прямо сказано: этот сигнал не меняет состояние сессии, а саму передачу должна выполнить ваша система или интеграция. Перевод телефонного звонка через fulfillment — отдельный механизм с поддержкой Phone Gateway и ограничениями, зависящими от интеграции. Документация Google по fulfillment
Для веб-агента это означает, что разработчик должен связать передачу с реальной очередью операторов и управлять дальнейшими сообщениями. Иначе в аналитике появится событие «передача оператору», а клиенту по-прежнему будет не с кем поговорить. На пилоте требуйте одновременно показать экраны клиента и оператора.
В настройках агента Google есть запрещённые фразы, фильтры безопасности контента и дополнительная проверка безопасности промпта. Это полезные механизмы, но описанная проверка лишь пытается обнаружить вредоносный ввод: она не гарантирует, что поведение агента невозможно перенаправить. Выполняйте чувствительные операции через бэкенд-функции с проверкой прав и осознанно определяйте, какие инструменты доступны каждому Playbook. Настройки агента Google
Какое голосовое ограничение проверить заранее
В документации Playbooks сказано, что они не поддерживают DTMF — тональные сигналы, возникающие при нажатии клавиш телефона. Если звонящим нужно вводить номер учётной записи или использовать клавиатуру как резервный способ взаимодействия, проверьте сценарий и устройство телефонии до выбора диалогового подхода. Обработка естественной речи и ввод с клавиатуры — разные требования.
Вердикт: Выбирайте Google, если облачная команда возьмёт на себя окружающее приложение, интеграции и анализ тарификации. Это не короткий путь к готовой службе поддержки с операторами. Платформа привлекательна именно тогда, когда вы хотите сами принимать эти проектные решения и можете их сопровождать.
- Явный выбор между заданными Flows и генеративными Playbooks.
- Опубликованы единицы тарификации: запрос и секунда аудио.
- Документированы настройки контента и безопасности промпта.
- Playbooks могут передавать задачи структурированным сценариям.
- Сигнал передачи оператору нужно обработать в собственной интеграции.
- Playbooks не поддерживают ввод с телефонной клавиатуры.
- Для гибридных решений нужно правильно применять правила тарификации.
- Conversational Agents и CX Agent Studio нельзя считать одним продуктом.
4. Microsoft Copilot Studio: для организаций в экосистеме Microsoft
Microsoft Copilot Studio — конструктор агентов с минимальным объёмом кода для организаций, которые уже администрируют бизнес-системы Microsoft и Power Platform. Его стоит оценить первым, если специалисты по доступу к данным и интеграциям уже работают в этой среде. Для клиентского сервиса рассматривайте самостоятельный продукт и интеграции с системами обслуживания клиентов. Доступ к внутренним агентам Microsoft 365 и публикация агента для внешних клиентов — разные задачи закупки.
Кому подходит: Организациям на базе Microsoft, у которых есть администратор и определена система, принимающая обращения клиентов.
Главное преимущество: Создание агентов управляется через существующую модель администрирования Power Platform.
Цена: Оплата по потреблению — от $0.01 за Copilot Credit; требуется подписка Azure, оплачивается фактическое потребление кредитов.
Пробный доступ: Есть, но пробные лицензии не разрешают публикацию.
Для внешних клиентов нужны другие условия
На странице тарифов Microsoft возможности, включённые в Microsoft 365 Copilot, отделены от самостоятельного Copilot Studio для внешних каналов. Поэтому агент для клиентов может лицензироваться иначе, чем внутренний помощник, которым пользуются коллеги. Прежде чем закладывать существующую подписку в бюджет, опишите реальную аудиторию, каналы и подключённые сервисы. Продуктовые и лицензионные границы Copilot Studio
Copilot Credits — единица потребления. Разные действия и ответы расходуют разное количество кредитов, поэтому кредит не равен клиенту, диалогу или решённому вопросу. Запросите оценку потребления для предлагаемого клиентского пути, включая действия интеграций, вместо того чтобы умножать трафик на предполагаемый тариф в один кредит.
Как устроены передача оператору и ограничения действий
Для обслуживания клиентов Microsoft описывает генеративных агентов, использующих сайты компании, файлы и базы знаний, с передачей обращений в системы клиентского сервиса. Среди названных систем — Dynamics 365 Customer Service, ServiceNow, Salesforce, LivePerson и Genesys. Документированные возможности передачи относятся к standard harness — среде выполнения этих агентов. Обслуживание клиентов и передача оператору
Если команда уже принимает клиентские обращения в Dynamics, естественный пилот — типовой вопрос, который передаётся в существующий процесс обслуживания. Проверьте, какие сведения о личности клиента и контекст диалога получает сотрудник. Не считайте, что все каналы и альтернативные среды выполнения автоматически поддерживают такую же передачу.
Политики данных Copilot Studio позволяют блокировать коннекторы, используемые как инструменты, ограничивать HTTP-подключения к веб-сервисам, требовать аутентификацию и сужать набор каналов публикации. Администраторы также могут ограничивать событийные триггеры. Это полезные точки принудительного контроля: они регулируют доступ к системам, а не только тон ответов агента. Политики данных Microsoft
Первую проверку стоит начать с перечня подключённых систем, способных менять данные клиентов. Предоставьте агенту только те операции, которые нужны для его задачи. Затем убедитесь, что администраторское ограничение блокирует нежелательное действие в развёрнутой среде, даже если пользователь прямо просит его выполнить.
Голосовой канал нужно принимать отдельно
Microsoft описывает базовых голосовых агентов и агентов реального времени, речевой и клавишный ввод, контекстные переменные и перевод звонков. Для голосового сценария нужен телефонный номер; Azure Communication Services позволяет получить или подключить его. Это отдельное внедрение канала, которое нужно проверить: работающий веб-агент сам по себе его не обеспечивает. Обзор голосовых возможностей Copilot Studio
Вердикт: Выбирайте Copilot Studio, если существующее администрирование Microsoft снижает нагрузку на эксплуатацию. Аргумента «мы уже платим за Microsoft» недостаточно: нужно проверить публикацию для внешней аудитории, принимающие системы поддержки и расход кредитов.
- Документированы интеграции передачи в системы клиентского сервиса.
- Административные политики ограничивают коннекторы и публикацию.
- Публичная цена за потребление даёт исходную единицу для расчётов.
- Голосовая документация охватывает ввод с клавиатуры и перевод звонка.
- Внешним агентам требуется соответствующая самостоятельная лицензия.
- Чтобы превратить кредиты в бюджет, нужен расчёт по клиентскому сценарию.
- Пробная лицензия не позволяет опубликовать рабочего агента.
- Совместимость каналов и сред выполнения нужно проверять явно.
5. Voiceflow: для небольшой продуктовой команды или команды клиентского опыта
Voiceflow — облачный конструктор для совместного проектирования клиентских диалогов с помощью сценарных инструкций (playbooks), визуальных процессов и инструментов интеграции. В этом сравнении это лучший стартовый вариант для небольшой продуктовой команды или команды клиентского опыта (CX), в которой есть специалист для настройки технических подключений. Он подходит, когда операторам поддержки и дизайнерам нужно часто пересматривать сами диалоги. Важная граница ответственности: очередью обращений к операторам по-прежнему управляет принимающая платформа поддержки.
Кому подходит: Небольшим командам из специалистов разных профилей, которые создают собственные сценарии для чата и голоса.
Главное преимущество: Сценарные инструкции на естественном языке сочетаются с визуальными детерминированными процессами.
Цена: Для бизнеса — по запросу; счёт складывается из платы за тариф, дополнительных опций и потребления в кредитах.
Пробный доступ: В публичном предложении для агентств и партнёров заявлен пробный доступ без банковской карты; уточните, какой вариант доступен вашей компании.
Что команда может проектировать вместе
Voiceflow описывает playbooks в виде инструкций на естественном языке, визуальные процессы и расширения для разработчиков через функции, API — подключения к другому ПО — и инструменты Model Context Protocol (MCP). MCP — стандарт предоставления инструментов агенту. Платформа также поддерживает телефон, веб-чат и SMS, но возможности каждого канала нужно проверять отдельно. Сведения о продукте Voiceflow
В магазине с подписной моделью команда поддержки может определить, как агент объясняет нестандартные ситуации с доставкой, а инженер — реализовать поиск заказа с проверкой прав. Момент передачи оператору должен быть виден обоим специалистам в рабочем процессе. Такой подход полезен, когда изменение правил требует изменить диалог, но он не оправдывает выдачу каждому редактору прав на изменение доступа к бэкенду.
Публичная страница тарифов Voiceflow теперь предлагает компаниям запрашивать коммерческое предложение. Прежние цены подписок не стоит брать за основу закупки. Попросите указать в одном предложении плату за тариф, включённый объём, условия превышения лимитов и права на необходимые интеграции. Облачный конструктор легче оценить, когда предложение описывает конкретный канал и подключение к поддержке, которые вы собираетесь использовать.
Как устроены передача оператору и ограничения действий
В документации Voiceflow описаны встроенные подключения для передачи диалога оператору в Genesys, UJET, Kustomer, Dixa и Zendesk. Для других систем поддержки доступен Custom Handoff через сервис, который размещаете вы. Этот вариант требует разработчика и доступа к соответствующей функции. Система поддержки отвечает за доступность и назначение операторов; сценарий Voiceflow — за момент передачи и действия при сбое. Обзор передачи оператору в Voiceflow
Для небольшой команды особенно важно различие: создать заявку — не то же самое, что передавать клиенту ответы оператора в реальном времени. Если вы обещаете «сейчас к чату подключится человек», до покупки продемонстрируйте обратную доставку ответа. Если обещаете «мы свяжемся с вами позже», прямо скажите это в диалоге.
В качестве контекста при передаче можно отправить полную историю диалога, собственную переменную или ничего. Пользовательское значение контекста само по себе не создаёт краткое содержание: данные для передачи нужно подготовить. Настройте как возврат к автоматическому сценарию, так и обработку ошибки, затем проверьте опубликованный канал, а не только редактор. Настройка передачи в Voiceflow
Для телефонных звонков Voiceflow выделяет отдельный шаг Call forward, который переводит звонок на телефонный номер или SIP-адрес — адрес интернет-телефонии. Не считайте подключение для передачи цифрового диалога и перевод телефонного звонка одной и той же реализацией.
Voiceflow сочетает глобальные инструкции и защитные ограничения с детерминированными процессами, оценкой качества и облачными средами от разработки до продакшена. Обязательные бизнес-шаги задавайте в процессе, а бэкенд-действие ограничивайте независимо. Хорошо написанный playbook может описывать, когда положен возврат, но сервис возвратов всё равно должен проверять, соответствует ли конкретный клиент и заказ условиям.
Вердикт: Выбирайте Voiceflow, если основная сложность — совместное проектирование диалогов. Если решающим требованием является полностью самостоятельное размещение среды выполнения или публичная цена для бизнеса без общения с продажами, лучше рассмотреть другой вариант.
- Операторы и разработчики могут работать над общей схемой диалога.
- Для встроенных подключений передачи документировано распределение ответственности.
- Custom Handoff позволяет подключать другие системы поддержки.
- Отдельные среды помогают контролировать процесс публикации.
- Публичная цена для бизнеса доступна только по запросу.
- Custom Handoff требует размещённого сервиса интеграции и разработчика.
- Доступностью и назначением операторов по-прежнему управляет платформа поддержки.
- Краткое содержание контекста и обработку сбоев в каналах нужно настраивать.
6. Botpress: для небольшой команды, которая начинает с чата
Botpress — облачная платформа создания агентов с визуальным редактором Studio, инструментами интеграции и продуктом для работы операторов Botpress Desk. Это практичный старт для небольшой команды, которой нужен собственный чат-агент и возможность разбирать, как он выбирает действия. Текущие тарифы позволяют понять начальные условия покупки проще, чем у решений с ценой только по запросу. Для проекта, где главный канал — телефон, платформа менее очевидна: в публичном сравнении тарифов голос указан в Enterprise.
Кому подходит: Небольшим командам, создающим агентов для сайта или мессенджеров и имеющим доступ к технической помощи.
Главное преимущество: Визуальные процессы с настраиваемыми автономными узлами и возможностью изучать использование инструментов.
Цена: Free включает 100 диалогов; Plus — от $150 в месяц при годовой оплате с 250 диалогами в месяц; действуют лимиты использования и правила платного пополнения.
Пробный доступ: Есть тариф Free; дополнительные пакеты и превышение лимитов в нём не предусмотрены.
Почему важно понимать текущую единицу тарификации
Botpress теперь публикует тарифы с оплатой по диалогам. Согласно странице тарифов, учитываются и полностью автоматизированные диалоги, и диалоги с участием человека, если клиент отправил не менее двух сообщений за расчётный месяц. Диалог, продолжающийся в разных месяцах, может учитываться в каждом из них. Поэтому передача оператору сама по себе не исключает общение из тарифицируемого объёма.
На странице также описаны автоматические платные пакеты диалогов и сказано, что автопополнение диалогов отключить нельзя. Для использования ИИ действуют собственные лимиты и механизмы пополнения. Прежде чем подключать публичный сайт, попросите ответственного за бюджет изучить эти правила. Низкая начальная цена полезна лишь тогда, когда команда понимает, что произойдёт при росте трафика.
Подходящий пилот для небольшой команды — агент с узкой задачей: проверять статус заказа или помогать по продукту, с явно заданным маршрутом передачи оператору. Он должен работать в настоящем канале сайта и с реальными источниками знаний. Эффектный диалог в предпросмотре не показывает, смогут ли коллеги из поддержки принять живое обращение и подходит ли модель оплаты вашему трафику.
Как устроены передача оператору и ограничения действий
Для новых рабочих пространств документация Botpress направляет Human Handoff в Botpress Desk. Существующие пространства могут продолжать использовать прежнюю интеграцию Human-in-the-Loop, у которой свои настройки и требования к тарифу. Прежде чем следовать старому руководству, уточните, какой вариант относится к вашей учётной записи. Документация Botpress по передаче оператору
До покупки нужно продемонстрировать весь цикл: клиент просит помощи, обращение появляется в нужном рабочем месте оператора, сотрудник отвечает, затем автоматизация возобновляется или заканчивается в соответствии с выбранным поведением. Не следует считать, что действие «Resume Chatbot» из прежней документации описывает любой новый процесс в Desk.
Autonomous Node позволяет модели выбирать ответы и инструменты; стандартный узел выполняет свои карточки последовательно. Для автономного узла можно задать инструменты, базы знаний, процессы и условия выхода. Доступ к переменным разрешается явно, причём запись настраивается отдельно. Окно Inspect помогает увидеть доступные инструменты и итерации выполнения. Botpress Autonomous Node
Эти настройки дают полезные точки контроля. Для поиска заказа откройте только операцию поиска и необходимые переменные. Не предоставляйте универсальный инструмент изменения клиентской записи лишь потому, что он может пригодиться агенту. Обязательные проверки вынесите в структурированный сценарий и бэкенд-сервис, который выполняет изменение.
Где заканчивается рекомендация для небольшой команды
Место голосового канала в публичной таблице тарифов — существенная граница. Небольшой команде, выбирающей Botpress для сайта, не стоит рассчитывать, что тот же начальный тариф покроет будущего телефонного агента. Если основной канал — телефон, начните с платформы и предложения, где он явно включён, а затем обратитесь к сравнению платформ голосовых агентов, чтобы сузить выбор.
Вердикт: Выбирайте Botpress для конкретной задачи в чате, если нужны публичные начальные условия и наглядное управление процессами. Не принимайте его за заведомо дешёвое решение для телефона, а до подключения непредсказуемого трафика изучите автоматические пополнения.
- Публичная начальная цена и тариф Free с чёткими ограничениями.
- Автономные и последовательные узлы подходят для разных задач диалога.
- Права на чтение и запись переменных можно задавать явно.
- Просмотр работы инструментов помогает разработчикам разбирать поведение агента.
- На текущей странице тарифов голос указан в Enterprise.
- Платное автопополнение диалогов влияет на контроль бюджета.
- Инструкции для нового Desk и прежней HITL-интеграции не взаимозаменяемы.
- Диалоги с участием человека тоже могут учитываться в потреблении.
7. Kore.ai: для комплексного преобразования клиентского сервиса
Kore.ai — корпоративная альтернатива для проектов, включающих клиентских агентов, помощь сотрудникам и управление качеством обслуживания. Текущее предложение AI for Service охватывает голосовых и цифровых агентов, Agent Assistance, Quality Management и контакт-центр, построенный на ИИ. Включайте платформу в список кандидатов, когда эти функции нужно обсуждать как единое внедрение. Покупать такую широкую программу лишь ради ответов на небольшой набор вопросов на сайте не стоит.
Кому подходит: Крупным организациям, которые координируют клиентскую автоматизацию, помощь операторам и контроль качества.
Главное преимущество: Автоматизацию сервиса и работу сотрудников можно оценивать вместе.
Цена: По запросу; на актуальной странице AI for Service не удалось подтвердить числовую публичную цену.
Пробный доступ: Есть демонстрация; публичные условия самостоятельного пробного доступа не подтверждены.
Когда широкий охват оправдан
Представьте службу, где есть типовые вопросы, сложные исключения и отдельная команда качества, которая проверяет обработку тех и других. Конструктор агентов закрывает лишь часть этого процесса. Более крупный вопрос — смогут ли автоматизированная часть и сотрудники работать по согласованным правилам, с понятной ответственностью при сбоях.
На странице сервиса Kore.ai описаны передача с подробным контекстом, подключения к бэкенду, сценарии помощи операторам и собственные критерии оценки. Также заявлены принудительное применение политик на уровне движка вне LLM и трассировка действий агента. Это опубликованные поставщиком возможности, которые нужно проверять на демонстрации, а не независимо измеренные гарантии правильного поведения.
Поэтому практический смысл включения Kore.ai в список кандидатов связан с организацией работы: руководитель поддержки, ответственный за интеграции и руководитель качества могут оценить общую модель обслуживания. Привлекательная демонстрация одного чат-бота не покажет, решает ли вся платформа отдельные задачи каждого из них.
Как устроены передача оператору и ограничения действий
Kore.ai описывает передачу человеку с контекстом, но внедрение нужно спроектировать под вашу реальную принимающую систему и каналы. Попросите поставщика показать, как на рабочее место оператора поступает пакет контекста: запрос клиента, статус проверки личности, попытки выполнить действия и причина передачи. Затем проверьте, может ли сотрудник ответить, не открывая обращение заново и не восстанавливая его по частям.
Проверяйте передачу голосовых и цифровых обращений отдельно. Успешная эскалация чата не доказывает, что перевод звонка сохранит нужный контекст, а установившееся соединение не доказывает, что сотрудник получил историю клиента. Если закупка охватывает оба канала, включите обе проверки в требования к демонстрации.
Для проверки ограничений попросите показать политику, которая применяется вне языковой модели. Подходящий пример — изменение услуги, для которого нужны аутентифицированная учётная запись и успешная проверка права на изменение. Пусть демонстратор попробует выполнить то же запрещённое действие другим путём в диалоге. Нужное подтверждение — последовательный отказ в действии с записью, понятной команде эксплуатации.
Как сделать коммерческое предложение предметным
В предложении должны быть перечислены приобретаемые компоненты, единица потребления, включённые среды, работы по внедрению и ответственность за поддержку. Также нужно указать, как учитываются объёмы голосовых и цифровых обращений. Без этого «цена Kore.ai» не является одной сопоставимой суммой, а использование старой цены другого модуля вводило бы в заблуждение.
Уточните, кто поддерживает правила после запуска. Если каждое исключение требует нового обращения к поставщику, для строго управляемой сервисной программы это может быть приемлемо, но такой порядок нужно выбрать осознанно. Если правила будут менять внутренние сотрудники, покажите процесс проверки и публикации с теми ролями, которые они получат.
Вердикт: Выбирайте Kore.ai, когда организация приобретает и конструктор агентов, и программу организации обслуживания. Если главная задача — добавить агентов в действующий контакт-центр, первым кандидатом лучше сделать Cognigy; окончательный выбор между ними должен опираться на демонстрацию реальных подключений, ограничений и рабочих процессов.
- Охватывает автоматизацию обслуживания и помощь операторам.
- Опубликован подход к применению политик вне LLM.
- Управление качеством можно включить в общую оценку сервиса.
- Передача с подробным контекстом явно заявлена как возможность продукта.
- Для рассматриваемого предложения не подтверждена конкретная публичная начальная цена.
- До сравнения коммерческих предложений нужно определить модули и объём внедрения.
- Поведение передачи в каждом канале требует конкретной демонстрации.
- Широкая программа может быть избыточной для небольшой службы поддержки.
Примеры, на которых видны различия платформ
Сравнивайте платформы на клиентском сценарии с исключением. Простые ответы на частые вопросы редко показывают, способна ли система сохранять сведения о личности клиента, соблюдать правила и подключать человека.
Заказ пришёл повреждённым. Агент может объяснить правила и найти заказ. Если запрошенное исключение требует одобрения сотрудника, агент должен передать обращение с нужным контекстом и не утверждать, что замена уже согласована. Оценивайте не только автоматический ответ, но и возможность принимающего оператора продолжить работу.
Клиент просит данные другой учётной записи. Правильный результат зависит от проверки прав в подключённой системе. Промпт «защищай конфиденциальность» полезен как инструкция, но сама операция поиска учётной записи должна отклонять доступ, которого у клиента нет. Попробуйте изменить идентификатор учётной записи во время диалога и проверьте ответ бэкенда.
Звонящий просит оператора, когда очередь не работает. Нужен честный резервный сценарий: реально действующий процесс обратного звонка, заявка с понятными ожиданиями или другой канал с доступными сотрудниками. Система не должна обещать соединение с человеком, которое невозможно завершить. Для голоса также нужны отдельные проверки перебиваний, требований к вводу с клавиатуры и поведения при переводе звонка.

Полезная аналитика следует за этими сценариями. Измеряйте, выполнено ли запрошенное действие, принял ли человек обращение и обратился ли клиент снова с той же проблемой. Разбирайте неудачные и прерванные диалоги наряду с успешными.
Метки поставщика «решено» или «обработано без оператора» требуют проверки их определения. Вашим бизнес-результатом может быть изменение доставки при соблюдении условий, безопасная передача деликатного запроса или корректное объяснение клиенту, что нужное действие недоступно. Согласуйте этот результат до сравнения дашбордов.
Какую платформу выбрать вашей команде
Разработчику, работающему самостоятельно, или небольшой группе поддержки, которая начинает с чата, стоит первым выбрать Botpress. У него есть публичные начальные условия и понятный способ изучить связь между автономными узлами, инструментами и структурированными процессами. Рекомендация меняется, если основной канал — телефон или автоматическое пополнение объёма не вписывается в ваш бюджетный процесс.
Небольшой продуктовой или CX-команде с дизайнером, оператором и доступом к инженеру стоит первой выбрать Voiceflow. Причина — совместная работа над диалогами. В сторону Rasa стоит переходить, когда контроль над средой выполнения и кодом становится важнее удобства облачного визуального конструктора.
Продуктовой команде с бюджетом и бэкенд-разработчиками среди фреймворков стоит выбрать Rasa. Она подходит бизнесу, который рассматривает агента как программный продукт, требующий постоянного сопровождения. Решающий фактор — ответственность за эксплуатацию: если некому поддерживать развёртывание и интеграции передачи оператору, выбирайте облачный вариант или закладывайте управляемое внедрение.
Облачной инженерной команде компании среднего сегмента среди облачных конструкторов стоит выбрать Google Conversational Agents. Предполагается, что команда хочет отвечать за окружающее приложение и может реализовать передачу человеку. В организации на базе Microsoft с существующим администрированием Power Platform и подходящей принимающей службой вместо него выбирайте Copilot Studio.
Действующему контакт-центру среди корпоративных платформ стоит первой выбрать Cognigy. Приоритеты здесь — передача обращений, интеграция каналов и повседневная эксплуатация сервиса. Включайте Kore.ai в финальное сравнение, если проект также охватывает помощь операторам и управление качеством. Победить должен поставщик, который продемонстрирует весь ваш сценарий с наиболее ясным распределением ответственности за внедрение.
Это рекомендации по устройству команды, а не минимальной численности штата. Небольшая техническая команда может эксплуатировать сложный фреймворк, а крупной компании может не хватать назначенного ответственного даже за простую интеграцию.
В каких случаях платформа не подойдёт
Не выбирайте Cognigy или Kore.ai для узкого FAQ-проекта, если никто не отвечает за внедрение. Широта этих платформ полезна, когда нужно координировать сервисные процессы. Небольшое внедрение не должно без причины получать закупочную и эксплуатационную нагрузку большой программы.
Не выбирайте Rasa, если единственный аргумент — «бесплатно». Бесплатная лицензия не назначает сотрудника, который подключит операторскую поддержку, будет сопровождать действия агента и эксплуатировать среду выполнения.
Не выбирайте Google Conversational Agents в расчёте на то, что ответ handoff сам подключит сотрудника. Документация возлагает эту задачу на интеграцию.
Не считайте Botpress заведомо недорогим пакетом для телефона, а Copilot Studio — частью любой подписки Microsoft. Нужный канал и работа с внешними клиентами должны соответствовать приобретаемому продукту.
Не принимайте предложение Voiceflow, в котором создание заявки выдают за подключение живого оператора. Полезным может быть и то и другое, но обещание клиенту должно соответствовать возможностям интеграции.
Как проверить платформу для бизнеса до покупки
Начните с одного ограниченного клиентского сценария и команды, которая будет принимать переданные обращения. Цель пилота — выяснить, кто отвечает за каждый сбой, а не получить красивую запись демонстрационного диалога.
До подключения модели к бизнес-системам письменно определите разрешённые действия. В случае запроса о заказе первая версия может читать статус и объяснять правила, оставляя одобрение исключений человеку. Чем меньше полномочий у агента на старте, тем проще проверить критерии приёмки.
Промпт-инъекция — это попытка перенаправить поведение модели через данные, с которыми она сталкивается. Сообщения клиентов, документы и результаты инструментов могут размывать границу между информацией и инструкциями. В руководстве по промпт-инъекциям объясняется, почему подключённое приложение должно ограничивать доступные модели действия, даже если она последует неверной инструкции.

Практичный список критериев приёмки пилота короткий:
- Проверьте полезный сценарий. Агент отвечает по нужному источнику или выполняет разрешённое действие, а бизнес-система фиксирует результат.
- Проверьте запрещённый сценарий. Запрос без необходимых прав не может изменить данные или раскрыть информацию другого клиента.
- Проверьте работу человека. Сотрудник получает диалог, контекст и ответы клиента в нужной системе поддержки.
- Проверьте обработку сбоя. Недоступная очередь, сломанный инструмент или отсутствующий источник приводят к понятному сообщению и следующему шагу, который служба действительно способна выполнить.
- Проверьте ответственность. Назначенный сотрудник может изучить журналы, изменить нужное правило, опубликовать согласованное обновление и восстановить работу после неудачного изменения с помощью выбранного процесса развёртывания.
Попросите каждого поставщика из короткого списка оценить один и тот же сценарий и назвать единицу тарификации. Отдельно показывайте стоимость внедрения, телефонии, использования моделей и платформы поддержки там, где эти расходы возникают. Внешне дешёвая платформа может потребовать больше работы ваших сотрудников; более крупное предложение может включать ненужные вам работы. По одной заявленной ставке нельзя сделать ни тот ни другой вывод.
Что сделать в понедельник: пусть ответственные за поддержку и интеграции вместе опишут один сценарий передачи, проверят его на сильнейшем кандидате из подходящей вам группы платформ и увидят, как реальный коллега принимает обращение. Сделайте это до расширения полномочий агента.
Частые вопросы
Как создать чат-бота с ИИ с нуля?
Начните с конкретной клиентской задачи, утверждённых источников знаний и явного списка разрешённых агенту действий. Выберите среду выполнения диалогов, подключите один реальный канал, реализуйте бэкенд-операции с проверкой прав и резервную передачу человеку, затем проверьте успешные и неудачные сценарии. Языковая модель обеспечивает часть диалога; платформа и ваше приложение создают вокруг неё рабочую систему.
Как бесплатно сделать собственного чат-бота с ИИ?
Rasa предлагает бесплатную лицензию для разработчиков с лимитами, а Botpress — ограниченный тариф Free. Они подходят для первоначальной оценки, но ограничения и необходимые внешние компоненты различаются. Прежде чем называть всё внедрение бесплатным, проверьте расходы на модели, хостинг, телефонию и принимающую систему поддержки. Пробный доступ Microsoft Copilot Studio предназначен для оценки и не позволяет публиковать агента.
Чем полезны чат-боты с ИИ?
Они могут упрощать доступ к типовой информации, собирать данные до подключения человека и последовательно выполнять разрешённые задачи. Польза зависит от знаний, интеграций и сервисных процессов, которые стоят за ботом. В собственном пилоте измеряйте выполнение задач, усилия клиента и повторные обращения, а не рассчитывайте, что заявленный поставщиком уровень автоматизации автоматически повторится в вашем бизнесе.
Если вам нужна помощь, чтобы превратить такой ограниченный пилот в работающую систему клиентской поддержки, посмотрите услугу внедрения ИИ в клиентский сервис.
- Опубликовано
- Категория
- AI
- Язык














