ElevenLabs Workflows: как собрать разговорный сценарий в виде блок-схемы и превратить голосового агента в настоящего специалиста

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

Кстати, если вам тоже приходится собирать рабочие сценарии для нейросетей, я часто советую заглянуть в Бот SozdavAI, где собраны нейросети для генерации текста, фото и видео. Мне он реально облегчает жизнь в разных задачах: не нужно держать десятки подписок и прыгать между сервисами, потому что всё собрано в одном удобном боте. Для меня это не абстрактный совет, а рабочая привычка, которая экономит и время, и деньги. При переходе по ссылке есть приветственный бонус — 10 000 токенов, а для подписчиков моего канала доступны бесплатные запросы к ChatGPT 5 nano даже после того, как закончится баланс. Возвращаясь к теме, в голосовых сценариях особенно видно, насколько полезно заранее разложить диалог по этапам.

ElevenLabs Workflows я воспринимаю как визуальный редактор логики разговора внутри ElevenAgents. В нем сценарий можно собрать не в виде одного перегруженного промпта, а как граф: есть старт, отдельные этапы, условия, вызовы инструментов, передача разговора другому агенту и завершение. Для меня это выглядит как рабочая карта, где у каждой реплики есть смысл, а у каждого поворота — причина.

Что такое ElevenLabs Workflows

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

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

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

Чем workflow отличается от обычного промпта

Один длинный промпт объясняет агенту правила. Workflow показывает, когда и в какой точке разговора эти правила должны сработать. Это совсем разный уровень контроля. Когда я впервые сравнила оба подхода на одном и том же сценарии, разница стала очевидной: текстовая инструкция быстро расползается, а блок-схема держит поведение в рамках.

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

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

Из чего состоит сценарий

Основные элементы здесь довольно понятны: узлы и переходы. Узел делает что-то одно, переход ведет к следующему шагу. Но в этой простоте и сила. Когда я строю схему для голосового агента, я всегда мысленно задаю один вопрос: что именно должен решить этот этап?

Subagent

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

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

Dispatch tool

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

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

Agent transfer

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

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

Transfer to number

Transfer to number переводит разговор на телефонный номер, то есть к живому оператору. На мой взгляд, это один из самых полезных узлов в практическом проекте. Потому что хороший разговорный агент не должен держать человека в цифровой ловушке. Если вопрос сложный, чувствительный или пользователь прямо просит сотрудника, передача звонка — нормальный, правильный и даже уважительный шаг.

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

End call

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

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

Как работают переходы и условия

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

Прямой переход

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

Условие на естественном языке

Особенно интересна LLM Condition — условие, сформулированное обычными словами. Модель сама оценивает, что происходит в разговоре, и выбирает нужную ветку. Например, если человек хочет отменить заказ, если речь о технической неисправности, если клиент подтвердил данные или если он просит оператора.

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

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

Что делать с ошибками инструментов

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

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

Как собрать сценарий в ElevenLabs

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

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

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

Практический пример: возврат товара

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

Схема может выглядеть так: приветствие, определение намерения, ветка возврата, запрос номера заказа, проверка данных через dispatch tool, уточнение причины возврата, создание заявки, сообщение номера обращения, завершение. Если заказ не найден или система дает сбой, срабатывает отдельная ветка. Если клиент просит сотрудника, разговор уходит через Transfer to number.

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

Где помогают другие инструменты

Когда я готовлю сценарий для ElevenLabs, мне почти всегда нужны и другие нейросети. Для текстов и диалогов удобно брать ChatGPT, Google Gemini или Claude. Они помогают быстро собрать приветствия, варианты реплик и тестовые диалоги, чтобы проверить, как агент поведет себя в живой беседе.

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

Когда сценарий уже готов и хочется оформить его как понятную схему для команды, в ход идут визуальные инструменты. Для изображений мне иногда удобны GPT Image 2, Seedream 5 или Nano Banana, если нужна быстрая правка. А если нужно показать сам принцип работы агента в видеоформате, уже смотрю в сторону Veo 3.1, Kling AI или Hailuo AI MiniMax. Но это уже не про логику разговора, а про подачу и визуальное объяснение процесса.

На что я смотрю в рабочем сценарии

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

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

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

Если вам интересен такой практический взгляд на создание контента в нейросетях, загляните в мой Telegram-канал «AI VISIONS», там я делюсь тем, как собирать рабочие сценарии и делать контент в нейросетях более собранным и живым.

Когда я настраиваю такие сценарии для рабочих задач, мне еще приходится думать о мелочах, которые снаружи не видны, но внутри проекта решают многое. Например, для оплаты нейросетей я пользуюсь Wanttopay — это пополняемые виртуальные карты Visa и Mastercard с 3D-Secure, а управлять ими удобно через мини-приложение в Телеграме. Для меня это не отдельная тема, а просто часть рабочей рутины: если сервис нужен регулярно, доступ к нему должен быть таким же собранным, как и сам сценарий.

Как я проверяю сценарий до запуска

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

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

Что я слушаю в первую очередь

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

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

Где сценарий ломается чаще всего

Опыт у меня здесь уже накопился приличный, и некоторые слабые места повторяются почти в каждом проекте. Первое — слишком общие условия. Второе — один узел пытается решить сразу несколько задач. Третье — нет понятной точки, где разговор передается дальше. Четвертое — ошибки внешнего инструмента предусмотрены формально, но не прописаны по-человечески.

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

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

Как сделать сценарий удобным для команды

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

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

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

Что помогает не запутаться

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

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

Что дает такой подход на практике

Мне нравится, что workflow делает разговор измеримым. Не в абстрактном смысле, а очень конкретно. Можно увидеть, на каком этапе люди чаще уходят, где возникает задержка, в какой ветке нужен человек, а где система справляется сама. Для рабочего проекта это гораздо полезнее, чем ощущение, что «вроде бы всё звучит нормально».

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

Мне это особенно близко в проектах, где важны и вежливость, и точность. Голосовой агент не должен звучать сухо, но и расплывчатость ему не подходит. Когда у него есть четкая логика, он отвечает спокойнее, увереннее и не теряет нить беседы.

Коротко о главном

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

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

А ещё приглашаю вас в мою AI Лабораторию на Boosty — там я регулярно выкладываю уроки по инструментам для работы с видео и изображениями, делюсь промптами, которыми пользуюсь сама, и делаю разборы видео: рассказываю, как создавать с нуля. Подписывайтесь!