Voiceflow — конструктор, в котором диалог клиентского бота собирают из агента, сценариев, базы знаний и инструментов, а затем проверяют тестами до публикации. Для работающего бота мало красиво нарисовать ветки: нужны данные, которые бот вправе называть, запасной путь на случай непонимания и ясная передача человеку. Пока обращения редкие и каждое уникально, конструктор лишний; когда они повторяются, а оператор остаётся за сложными случаями, схема оправдана.
Карта диалога
Документация описывает Voiceflow как платформу для сборки, тестирования, запуска и мониторинга чат- и голосовых агентов; основа проекта — агент с общими инструкциями и инструментами плюс сценарии для разных задач.
Условный интернет-магазин получает четыре типа обращений: где заказ, как оформить возврат, какая доставка в мой город, жалоба на качество. Перед конструктором нарисуйте по каждому типу короткую карту: что клиент хочет, какие данные нужны боту, какой ответ считается завершением, когда подключается человек. Карта на бумаге избавляет от споров на холсте.
Определите также границы бота. Он отвечает на вопросы по утверждённым текстам, собирает данные для заявки и передаёт сложное. Скидки, сроки сверх написанного и оценка качества товара остаются за сотрудником. Эти границы записываются в инструкции агента и проверяются тестовыми диалогами, потому что клиент рано или поздно попросит именно то, что остаётся за человеком. Контрольные диалоги с такими просьбами показывают, держит ли бот границу и как вежливо он возвращает разговор к своей задаче.
По описанию платформы в Voiceflow есть агент с глобальным промптом и инструментами, сценарии на основе цели с вызовом инструментов, рабочие процессы для многошаговых задач, база знаний и инструменты для вызовов API, интеграций, функций и серверов MCP. Выбор между свободным сценарием и жёстким процессом зависит от того, насколько допустима вариативность: справка о доставке терпит свободу, возврат с проверкой условий требует последовательных шагов. Общие правила формулировок для таких ботов собраны в статье про промпты для ботов.
Данные и переменные
Бот помнит разговор через переменные: номер заказа, выбранный город, причина возврата. Данные, которые меняют деньги и статусы, живут во внешней системе, а бот запрашивает их через инструмент и пересказывает ответ. Таблица помогает разнести информацию по источникам.
| Тип данных | Откуда берётся | Что делает бот |
|---|---|---|
| Условия доставки и возврата | База знаний с утверждёнными текстами | Отвечает по тексту и называет источник |
| Статус заказа | Запрос к учётной системе через инструмент | Пересказывает ответ сервера близко к тексту |
| Номер заказа и контакты | Переменные, собранные в ходе диалога | Передаёт в запрос собранное и уточняет недостающее |
| Решение по возврату | Сотрудник или правило на сервере | Принимает заявку и сообщает, что решение за человеком |
Базу знаний включают как системный инструмент, и агент обращается к ней по мере надобности, как сказано в разделе про запросы к базе знаний. Содержимое базы формирует владелец контента: устаревший текст про доставку бот повторит так же уверенно, как актуальный. Назначьте человека, который отвечает за обновление, и дату проверки каждого документа.
Тон ответов тоже входит в проект. Разговор с клиентом интернет-магазина допускает дружелюбный стиль, но короткие фразы и конкретное следующее действие важнее остроумия. В инструкции агента перечислите, как бот обращается к клиенту, какие слова допустимы, как он называет себя и что говорит, если ответа нет. Проверьте результат на нескольких десятках реплик реальных клиентов, обезличенных заранее.
Запасной путь
Любой диалог рано или поздно выходит за карту: клиент пишет невнятно, меняет тему, вставляет длинный текст жалобы. Запасной путь решает, что делает бот в этот момент. Худший вариант — бесконечные переспросы, лучший — короткая цепочка с выходом к человеку.
- Первое непонимание: бот коротко перефразирует вопрос и предлагает два-три варианта темы кнопками.
- Второе непонимание подряд: бот извиняется одной фразой и предлагает оставить контакт или позвать оператора.
- Сбой инструмента или недоступная учётная система: бот сообщает, что данные временно недоступны, фиксирует обращение и обещает ответ человека.
- Грубость, угроза, юридические формулировки, просьба о компенсации: диалог сразу передаётся оператору без попыток переубедить клиента.
Эти правила записывают в сценарий как явные ветки, оставляя модели лишь формулировку. Тексты ветки готовит редактор службы поддержки: вежливый, короткий, с понятным следующим действием. Хорошо составленный запасной путь снимает основной страх владельцев процесса, что бот зациклится и разозлит клиента. Проверьте каждую ветку вручную: пройдите её от первой реплики до выхода и засеките, сколько действий понадобилось клиенту.
Передача оператору
Шаг передачи в Voiceflow, по описанию, соединяет клиента с живым сотрудником через интеграцию с контакт-центром. Названы Genesys, Ujet, Kustomer, Dixa и Zendesk. Шаг переносит сообщения и файлы в обе стороны, пишет разговор в журнал, умеет передавать расшифровку или выбранные переменные и при желании возвращает клиента боту. Предусмотрен и путь на случай сбоя с повторными попытками до эскалации.
Для российской компании первый вопрос практический: используется ли у вас одна из названных систем. Если нет, передачу придётся строить через собственный механизм, например уведомление в рабочий чат с карточкой обращения, и проверять, как это согласуется с возможностями платформы. Доступность самого сервиса и способы оплаты для вашей страны уточняйте у вендора до начала проекта.
Что передавать оператору, решите заранее: тему, номер заказа, суть жалобы своими словами клиента, список уже сделанных действий и признак срочности. Короткая справка лучше полной расшифровки: оператор видит смысл за несколько секунд, а полный журнал открывает при необходимости.
Нерабочие часы требуют отдельной ветки: бот сообщает, когда ответит человек, принимает контакты и ставит обращение в очередь на утро. Если оператор занят дольше обещанного, клиент получает сообщение с честной оценкой ожидания, а менеджер смены видит просроченные обращения.
Через какой инструмент ваши операторы сегодня принимают обращения?
Тест сценария
В документации Voiceflow платформа заявлена как место, где агентов собирают, тестируют, запускают и мониторят; для мониторинга названы история сообщений, записи звонков, журналы и оценки по метрикам. Проверку стройте в таком порядке: сначала прогон по контрольным репликам, затем разбор расшифровок, затем пилот на небольшой доле реальных обращений.
- Типовые вопросы по каждой ветке и ожидаемый ответ с указанием источника.
- Вопросы, ответа на которые в базе знаний нет: бот обязан признать это и предложить помощь человека.
- Попытки вывести бота за рамки: просьбы пообещать скидку, ответить на постороннюю тему.
- Сбой инструмента: проверка, что запасной путь срабатывает и обращение сохраняется.
- Передача оператору с контрольной справкой и возвратом клиента к боту.
Каждый запуск тестового набора фиксируйте с датой и версией сценария. Так видно, какая правка улучшила одну ветку и испортила другую. Проверка людьми остаётся обязательной: сотрудник поддержки читает выборку расшифровок и отмечает слабые ответы.
После запуска наблюдение продолжается. Раз в неделю смотрите, на каких вопросах бот чаще всего уходит в запасной путь, какие темы приходят вне карты и сколько диалогов заканчивается передачей. Частые вопросы без ответа становятся материалом для базы знаний, частые передачи подсказывают новую ветку. Так сценарий растёт по фактам реальных обращений.
Выпишите двадцать реальных вопросов клиентов и отметьте те, на которые есть утверждённый текст ответа. Ветки стройте под них, остальное уводите к оператору, до тех пор, пока контрольный набор даёт ошибки. Если нужен проект под ключ, посмотрите страницу про чат-ботов для бизнеса.