Design the right team for your AI Agent projects.

Каждая статья о построении команды AI-поддержки клиентов начинается с одного и того же приёма: список новых должностей. AI Manager, Knowledge Manager, Conversational AI Designer, AI Trainer, AI Agent Owner, Director of ACX. Подразумевается обещание: наймёте этих пятерых — получите AI-программу.

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

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

Почему списки должностей бьют мимо цели

Если вы хоть немного гуглили эту тему, топ-10 выдачи покажется знакомым. Ada перечисляет три операционные модели и горстку новых ролей. IBM называет AI Owners и AI Champions. Writer говорит, что ваш следующий найм — AI Agent Owner. Zendesk рассуждает об AI-тиммейтах. Статья HBR советует онбордить их как новых сотрудников.

Они не ошибаются насчёт работы. Они ошибаются насчёт единицы анализа.

Правильная единица — это не должность. Это функция — объём работы, у которого должен быть владелец, неважно, как он называется. Мы наблюдали десятки команд, строящих программы AI-агентов на Voiceflow, и форма, которая стабильно работает, — небольшая. Turo ведёт свою программу в ограниченном уголке продукта. StubHub International запустили MVP только внутри раздела «My Account». Один из наших клиентов обрабатывает десятки тысяч разговоров в неделю силами PM и инженера. И всё. Два человека.

Численность редко является ограничением. Ясность владения — да. Программы убивает именно функция без владельца. Вакантная должность — почти никогда.

Есть четыре функции. Вот как выглядит каждая, кто в вашей текущей структуре скорее всего ею владеет и что разваливается, когда никто не владеет.

Функция 1: дизайн диалогов (автор плейбука)

Работа — писать инструкции агента. Его идентичность, его цели, процедуры, которым он следует для конкретных задач, тон, который он берёт, когда клиент раздражён.

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

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

В вашей текущей структуре этот человек — почти всегда ваш senior CX-стратег, ваш conversation designer, если он есть, или ваш самый опытный support manager. Совпадение навыков высокое. Они уже знают, как клиенты задают вопросы, какие пограничные случаи кусаются, где важны пути эскалации. Чему им нужно научиться — это писать для LLM: BLUF вместо преамбулы, конкретика вместо абстракции, предвосхищение того, как реальные клиенты беспорядочно формулируют вопросы.

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

Функция 2: владение знаниями (хранитель источника истины)

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

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

В вашей текущей структуре это владелец help center, ваш технический писатель или ваш лид по управлению знаниями. Иногда это человек из CX ops, который уже разбирает тикеты типа «статья про X неверна». Навык, который им нужно добавить, — писать для извлечения, а не для человеческого чтения. Длинные дружелюбные для людей простыни текста плохо извлекаются. Размер чанка имеет значение. Заголовки несут вес. Агент ищет релевантные фрагменты, а не весь документ — и это меняет то, как вы структурируете контент.

Скажем честно: это функция, которой чаще всего «владеют все, а значит — никто». Закрепите её за человеком до запуска. Иначе вы получите самый болезненный тип сбоя в обслуживании клиентов: агент уверенно сообщает клиентам то, что когда-то было правдой. «Политика возврата — 30 дней» — за исключением того, что в прошлом квартале её изменили на 60, и теперь вы из принципа возмещаете разницу. Доверие рушится быстро, когда ИИ красноречиво ошибается.

Функция 3: операции и наблюдаемость (менеджер агента)

Это функция, которую большинство команд пропускают. Это также единственная самая частая причина деградации программ AI-агентов после запуска.

Работа — еженедельно читать транскрипты. Запускать структурированные оценки против критериев, которые вы определили как «хорошо». Отслеживать метрики, которые имеют значение — resolution rate, escalation rate, latency, CSAT — и превращать увиденное в обновления промптов, дополнения к базе знаний и периодическое «нам нужен новый плейбук для этого».

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

В вашей текущей структуре это ваш лид support ops, ваш QA manager или senior support manager, который уже неравнодушен к обзору транскриптов. Они уже настроены смотреть на разговоры и спрашивать «почему всё пошло не так?». Новый навык — читать трейсы агента, а не только транскрипты — понимать, почему агент сделал то, что сделал. На какой источник знаний он сослался, какой инструмент вызвал, где он проявил суждение, а где следовал фиксированной процедуре. Для этого и нужны observability и evaluations: каждый разговор зафиксирован, каждое решение прослеживается, структурные evals автоматически запускаются против установленной вами планки.

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

Когда у этой функции нет владельца, агент тихо деградирует. Знания устаревают. Пограничные случаи накапливаются. Эскалации ползут вверх на 2% в месяц, и никто не замечает, пока кто-то из другого подразделения не пожалуется. К моменту, когда клиенты начнут шуметь, вы отстанете на месяцы.

Функция 4: инженерия и интеграции (сантехник)

Работа — подключать агента к системам, которые ему нужны: Salesforce, Zendesk, ваша order management, ваш провайдер аутентификации, какой бы тикетинг-инструмент вы ни стандартизировали. Затем поддерживать эти подключения. Затем безопасно выкатывать изменения через dev, staging и production, не ломая production в 16:00 в пятницу.

Современные платформы агентов абстрагируют значительную часть AI-специфичной инженерии. Вашему инженеру не нужно файнтюнить модель или поднимать векторную БД. Ему нужно интегрироваться с системами, которые ваша CX-команда уже использует, иногда писать function tool, когда интеграции нужна кастомная логика, и владеть пайплайном деплоя, чтобы изменения не уходили в production без тестирования.

В вашей текущей структуре это platform engineer, ваш лид по IT-интеграциям или бэкенд-разработчик, который уже владеет интеграциями CX-систем. Они, вероятно, уже знают API Zendesk и Salesforce лучше всех. Навык, который им нужно добавить, — примитивы платформы агентов (tools, function steps, environments), что ближе к изучению нового SaaS-продукта, чем к изучению machine learning.

Environments в Voiceflow (отдельные dev, staging, production) существуют именно для того, чтобы этот человек мог безопасно выкатывать изменения, не превращаясь в бутылочное горлышко в день релиза. Вам не нужно, чтобы каждое изменение промпта требовало инженера; вам нужно, чтобы инженеры владели механизмом деплоя, а люди из дизайна и ops могли через него выпускать свою работу.

Когда у этой функции нет владельца, интеграции ломаются в тишине. Деплои идут прямо в production без проверки на staging. Никто не может отладить сбой инструмента, когда он случается. Агент выглядит сломанным для клиентов; команда не может понять, дело в рассуждении агента или в том, что CRM лежит.

Разделение build/maintain — и почему ваша команда во второй год больше, чем в первый

Вот часть, которая больше всего удивляет CXO: построение занимает недели; поддержка — вечность.

Разумное разделение в первый год — 30% построение, 70% поддержка. Доля построения дальше только уменьшается.

Большинство презентаций платформ выстроены вокруг фазы построения — «смотрите, как быстро вы можете запустить своего первого агента!» — что правда и одновременно вводит в заблуждение. Работа, определяющая успех программы, идёт после запуска. Больше знаний нужно курировать по мере эволюции бизнеса. Больше транскриптов проверять по мере роста объёма. Больше интеграций поддерживать, когда меняются upstream-системы. Больше evals держать актуальными по мере расширения области действия агента.

Что не растёт так же быстро: усилия на дизайн. Как только структура плейбука выстроена, расширение на новый use case куда дешевле, чем построение первого. Sanlam Studios построили и выбросили четыре или пять агентов, прежде чем выйти на что-то рабочее. Это не провал — это то, как выглядит обучение. Когда структура была найдена, дополнения пошли быстро.

К 18-му месяцу ваша функция ops и observability, вероятно, занимает 60–70% времени команды, хотя на запуске это было 30%. Планируйте это. CXO, относящиеся к запуску как к финишной черте, заканчивают с деградировавшим агентом и командой, которая тихо перестала им владеть. Те, кто относятся к нему как к стартовой линии, получают возможность, которая работает на сложных процентах.

Самая маленькая команда, которая реально работает

Минимально жизнеспособная форма — три человека:

Владелец PM-типа, который покрывает дизайн диалогов и решает, что приоритизировать дальше Человек ops-типа, который ведёт observability и владеет функцией знаний Человек инженерного типа, который владеет интеграциями и пайплайном деплоя

Это настоящая команда. С ней можно вести осмысленную программу. Упомянутый ранее клиент — десятки тысяч разговоров в неделю силами PM и инженера — доказательство того, что даже трое иногда больше, чем нужно, если область действия ограничена, а два человека опытны.

Средний размер, когда область действия растёт или вы переходите через несколько use case: пять человек. Отделите дизайн диалогов от приоритизации (отдельный CxD). Отделите знания от ops (отдельный владелец базы знаний).

Enterprise-форма, когда вы запускаете несколько агентов по продуктовым линиям: 8–12 человек. Несколько владельцев ops по доменам. Выделенная команда базы знаний. Два инженера — один по интеграциям, один по платформе и безопасности.

Заметьте, чего нет ни в одной из трёх форм: «AI Manager» с таким названием должности, «AI Agent Owner» с таким названием должности, «Conversational AI Designer» с таким названием должности. Эти должности могут существовать, если вы находите их полезными, но не они делают команду работающей. Работающей её делает покрытие четырёх функций.

Выводы

Перестаньте читать статьи, перечисляющие новые AI-должности. Начните с того, что наложите четыре функции на людей, которых уже нанимаете: дизайн, знания, ops, инженерия. Закрепите функцию 3 — ops и observability — за конкретным человеком до запуска. Это самая часто пропускаемая и самая нагруженная из четырёх. Заложите 30% времени программы на построение и 70% на поддержку в первый год. Ожидайте, что доля поддержки будет только расти. Правильный размер для старта — три человека с ясным владением всеми четырьмя функциями, а не восемь человек с пересекающимися должностями.

Куда двигаться дальше

Команда, которая вам нужна, — это в основном та команда, которая у вас уже есть. Но только если вы серьёзно относитесь к владению и только если вы относитесь к поддержке так же серьёзно, как к запуску.

Если ваш пилот в полёте и вы пытаетесь довести его до финиша, наш гайд moving an AI CX pilot into production покрывает 90-дневную версию этого разговора. Если хотите увидеть, как плейбуки, workflow, observability и environments складываются вместе на практике — реальную поверхность продукта, против которой работают четыре функции, — забронируйте обзор Voiceflow.