Я руковожу проектом по внедрению цифровых сотрудников в компании, которая занимается разработкой, внедрением и поддержкой ПО для автоматизации дистрибуции. В этой статье расскажу, почему первым большим сценарием мы выбрали поддержку, как начинали с помощника инженера и что получили после выхода в реальный поток.
Продуктами компании пользуются сотрудники в полях: мерчендайзеры, торговые представители, супервайзеры. Человек работает на маршруте, посещает торговые точки, имеет дело с товарами, остатками, договорами, фотографиями — и в этот момент что‑то не отображается, не синхронизируется или не распознаётся.
Недавно наша команда сделала для себя внутреннюю платформу цифровых агентов. На ней начали собирать разных цифровых сотрудников: помощников инженеров поддержки, агентов для общения с пользователями, помощника по наполнению базы знаний, ревизора качества обращений. Внутри команды мы называем таких цифровых сотрудников тиммейтами; в технических описаниях — агентами.
Поддержка стала первым крупным стримом, где всё это начали использовать в боевом режиме.
Это не история о том, как мы «внедрили ИИ». Скорее, о том, как команда, много лет поддерживающая сложный продукт с индивидуальными клиентскими настройками, пыталась перестроить собственную поддержку — и что из этого получилось.
Почему поддержка перестала масштабироваться наймом
В поддержку сейчас приходит около 3 000 обращений в месяц. В команде — примерно 30 человек.
Полевые сотрудники обращаются в поддержку через мобильный портал внутри рабочего приложения или звонят. Офисные пользователи — аналитики, супервайзеры, руководители проектов со стороны клиента — используют веб‑портал. Всё попадает в Microsoft Dynamics CRM: там инженер ведёт обращение, а клиент получает ответ в своём интерфейсе.
На первый взгляд всё привычно. Но у нас накопилось несколько проблем.
Во‑первых, обращения приходят неравномерно. В обычный день команда справляется. Но после инфраструктурного сбоя, неудачного импорта данных или массовой ошибки очередь быстро растёт.
Во‑вторых, продукт сложный, а поддержка персонализирована. У каждого клиента могут быть собственные доработки, регламенты, версии продуктов, конфигурации и исключения. Инженеру недостаточно знать общий функционал: нужно учитывать именно этого клиента.
В‑третьих, часть знаний держалась на опытных людях. К ним выстраивались очереди: «А у этого клиента как устроено?», «Где посмотреть логи?», «Почему эта точка не попала в маршрут?» Формально коллеги помогали друг другу. Фактически самые ценные специалисты постоянно отвлекались от сложных задач.
И, наконец, время ответа критично. Если пользователь в торговой точке получает первый вопрос через три часа, он уже мог уехать, переключиться на другую проблему или стать недоступным.
Почему не ограничиться личными помощниками инженеров
У нас был показательный случай.
Один сотрудник собрал для себя личного тиммейта: подключил внутренний контур кода, Confluence, добавил свои навыки. Для его задач это работало неплохо.
Но когда он попытался передать эту конструкцию коллегам, выяснилось, что скопировать настройки недостаточно. Нужно объяснить, какие доступы нужны, как собирать контекст, какие инструкции использовать. Затем всё это надо обновлять после каждой доработки продукта, исправлять ошибки и синхронизировать между несколькими людьми.
А ещё у руководителя поддержки нет единой точки контроля. Непонятно, одинаково ли настроены личные помощники, не устарели ли их знания и не работает ли кто‑то с неверной логикой.
Личный помощник может ускорить одного инженера. Но его удачная находка обычно остаётся в личном чате.
Мы хотели другое: чтобы улучшение, которое сделали один раз, сразу начинало работать для всей линии поддержки.
Первым появился тиммейт инженера
Первым цифровым сотрудником на платформе стал тиммейт инженера — помощник прямо в CRM.
Он ищет знания по конкретному клиенту, разбирает логи, сопоставляет документацию и похожие обращения, предлагает следующий шаг и помогает подготовить эскалацию.
Позже вокруг него появились другие роли: агент для части клиентских обращений, помощник по наполнению базы знаний и ревизор качества для руководителей поддержки.
Но до прямого общения с клиентами мы дошли не сразу. Сначала помощник работал только внутри команды. Инженеры лучше всех могли проверить, где он ошибается, каких данных ему не хватает и в какой момент он должен остановиться. Пока его ответы не стали полезными для них, выпускать помощника к клиентам было просто рано.
Поначалу мы думали, что главная ценность тиммейта — доступ к базе знаний. Оказалось, что для опытных инженеров этого недостаточно.
Реакция была ожидаемой: «Я давно здесь работаю, я и так всё знаю. Зачем мне спрашивать у бота?»
Перелом наступил, когда тиммейт начал разбирать большие логи и отвечать на вопросы «по картинке». Он быстро находил значимые фрагменты, связывал их с симптомом и предлагал направление для диагностики. Это помогало не только новичкам, но и опытным инженерам: никто не хочет вручную перечитывать огромный файл в поисках одной ошибки.
Следующим шагом мы стали автоматически передавать новые обращения этому же помощнику. Он формировал гипотезу, перечислял, что удалось проверить, и предлагал, что инженеру сделать дальше. Но клиенту ответ пока не уходил: он сохранялся в отдельном поле CRM.
И здесь мы столкнулись с другой проблемой. Инженеры не всегда открывали эти подсказки и ещё реже давали обратную связь. Кто‑то не видел пользы, кто‑то боялся за свою роль, у кого‑то просто не было времени.
Кто внедрял тиммейтов
Платформу цифровых агентов разработала техническая команда. Но самих цифровых сотрудников настраивала не она.
Я как руководитель проекта собирала роли агентов, инструкции, знания, сценарии и правила работы. Руководители поддержки помогали встроить тиммейтов в реальные бизнес‑процессы и работу в CRM. Кураторы оценивали качество ответов, дописывали памятки, контролировали работу тиммейтов — и продолжают это делать.
Отдельный разработчик сделал интеграцию с CRM. Команда, которая разрабатывала ядро нашей внутренней платформы цифровых агентов, подключалась, когда не хватало базовой возможности: например, требовалась обработка нового типа документов или общий механизм работы с данными.
Получилась не история «поддержка написала требования, а разработчики потом сделали бота». Внедрение шло короткими циклами: поддержка и кураторы приносили реальные случаи, мы меняли агентов и знания, а разработчики помогали там, где требовалось расширить саму платформу.
Универсальный помощник для тех, кто настраивает агентов
Очень помог в работе встроенный в платформу универсальный AI‑помощник — эксперт по платформе. Он консультирует по её возможностям, помогает собрать технологическую структуру цифрового сотрудника, оформить инструкции, сценарии и подготовить инструменты для работы с внешними системами.
Под инструментом здесь я понимаю конкретную операцию, которую может вызвать агент: найти события в логах, получить данные из CRM, проверить версию приложения или состояние записи. Более сложные инструменты внутри платформы реализованы как skills, или навыки. Такой skill может выполнить несколько последовательных запросов, проверить ошибки и вернуть агенту нормализованный результат.
Благодаря этому я как руководитель проекта могла не только описывать задачу разработчикам, но и сама собирать и менять агентов: настраивать инструкции, знания, маршруты и базовые инструменты.
Универсальный помощник не выдаёт готовую production‑архитектуру по кнопке и не отменяет проверку человеком. Но он заметно снижает порог входа: помогает превратить идею в первый работающий вариант, который затем можно проверить, протестировать и улучшить вместе с командой.
Для меня это один из главных результатов внедрения: технически такой проект на платформе можно запускать и развивать без глубоких навыков разработки. Но одних только удобных инструментов недостаточно. Нужны люди, которые знают поддержку, владеют знаниями о продукте и готовы постоянно улучшать процесс. А главное — необходимы воля, поддержка и искреннее желание самого руководства компании видеть этот проект успешным.
Две недели, без которых ничего бы не заработало
Мы собрали рабочую группу из кураторов и руководителя поддержки.
Около двух недель каждый день примерно по часу разбирали ответы тиммейта. Сначала почти все. Потом — только спорные и неудачные.
Смотрели:
правильно ли агент понял вопрос;
какие данные он не нашёл;
где выбрал не тот источник;
какую памятку нужно переписать;
нужен ли новый skill;
где не хватает логирования, доступа или вообще описанного процесса.
После разбора обновляли знания, инструкции, маршрутизацию или skills. Цикл был коротким: сегодня нашли проблему — завтра проверяем, изменилось ли поведение.
Это был не процесс «дообучения модели» в классическом смысле. Скорее, настройка рабочего процесса: какие данные собирать, в какой последовательности их проверять и в каком месте агент обязан остановиться.
Когда ответы стали достаточно предсказуемыми, мы волевым усилием выбрали первую тему, по которой агент мог общаться с клиентом напрямую. При этом инженеры поддержки по‑прежнему в большинстве случаев игнорировали результаты работы агента.
Как мы выбирали первую тему
Мы не стали брать самый сложный или самый эффектный сценарий.
Первой выбрали тему, которая одновременно:
часто встречается;
хорошо наблюдаема;
имеет понятный путь диагностики;
обеспечена нужными данными;
с высокой вероятностью решается без инженера.
Так эффект можно увидеть быстро, а сам сценарий — быстро проверить на реальном потоке.
Сложные, редкие и плохо наблюдаемые вопросы оставили людям. Их нельзя безопасно автоматизировать только потому, что очень хочется поднять процент автоматизации.
Что происходит с обращением
Допустим, пользователь пишет: «Не вижу торговую точку в маршруте».
Это не вопрос, на который можно ответить по общей документации. Нужно понять:
о каком клиенте речь;
какие у него настройки и доработки;
какая версия приложения назначена сотруднику;
есть ли точка в маршруте;
не было ли ошибки синхронизации;
как такие случаи решались у этого клиента раньше.
Обращение приходит из Dynamics CRM в нашу платформу через API. Дальше оно очищается, нормализуется и передаётся оркестратору.
Оркестратор определяет, какому агенту отдать задачу: для клиентов с большим количеством индивидуальных особенностей существуют отдельные агенты, для серийного функционала — общий.
Агент идёт по иерархии источников:
Памятки и ограничения конкретного клиента.
Общие инструкции поддержки.
Документация продукта.
Похожие закрытые обращения.
Разрешённые диагностические skills.
При необходимости он смотрит логи в Graylog, информацию о лицензии и версии приложения, а в ограниченных сценариях может выполнить диагностический запрос к базе клиента.
Если информации недостаточно, он не придумывает ответ по скриншоту. Он запрашивает конкретные данные: код торговой точки, номер маршрута, время синхронизации и так далее.
Если данные противоречат друг другу или критичный источник недоступен, агент эскалирует обращение на реального инженера поддержки, описывая для сотрудника все пройденные проверки и рекомендации по дальнейшим шагам со ссылками на использованную документацию. Для нас это не ошибка. Это нормальный, предусмотренный исход.
Как устроены инструкции тиммейтов
Сначала мы пытались описать поведение каждого тиммейта одной большой инструкцией. Но чем больше появлялось клиентов, исключений и инструментов, тем труднее было понять, какое правило сработало и что именно нужно менять. Поэтому со временем разнесли инструкции по нескольким уровням.
Общая инструкция. В ней задаются формат ответа, допустимые исходы resolved (решено), need_more_info (нужно больше информации от пользователя) и escalate (эскалация), правила безопасности и условия, при которых агент должен остановиться. Это одинаково для всех тиммейтов.
Общие правила поддержки. Они описывают работу с источниками, требования к доказательствам, массовые инциденты и эскалацию. Например, неполный результат или техническая ошибка ещё не означают, что данных нет.
Инструкции конкретного клиента. Здесь находятся его терминология, конфигурации, индивидуальные доработки, порядок источников и разрешённые способы диагностики.
Памятка по сценарию. Она задаёт последовательность проверок для конкретного симптома: какие идентификаторы собрать, куда посмотреть сначала и когда нужно вернуться к пользователю за уточнением.
Описание навыка (skill). В нём фиксируются входные параметры, признаки успешного и полного результата, границы проверки и допустимый следующий шаг.
Текст обращения и результаты инструментов собираются заново для каждого запуска. В постоянные инструкции они не входят.
Если правила противоречат друг другу, на первом месте остаются безопасность и обязательный формат ответа. Клиентская инструкция может изменить порядок источников, но не отменить эти ограничения. Проектная памятка важнее общей продуктовой статьи, если у клиента функциональность устроена иначе. Карточка массового инцидента используется только при точном совпадении симптома и условий. Если источники всё равно противоречат друг другу, агент не выбирает более удобную версию, а передаёт конфликт инженеру.
Например, общая памятка при отсутствии торговой точки может рекомендовать проверить назначение маршрута, синхронизацию и логи. Инструкция конкретного клиента уточняет, где лежит актуальная памятка, какой тип идентификатора используется в проекте, какой skill нужно вызвать первым и можно ли после него идти в логи. То есть одна и та же модель не «помнит особенности клиента». Она каждый раз работает с явно собранным набором правил.
Агент — не один большой промпт
Инструкции задают путь, но саму диагностику мы не оставили на усмотрение модели. Агент работает внутри довольно строгого процесса, а на стороне ИИ остаётся узкий семантический слой. Проще говоря, модель выступает лишь точным «переводчиком»: она понимает смысл запроса и формулирует ответы, но не выходит за рамки правил и не принимает бизнес‑решений самостоятельно.
Для примера: мы проанализировали 16 навыков (skills), которые используются в этом сценарии. На долю языковой модели приходится всего один этап. При этом в контуре есть 58 детерминированных вычислительных шагов, 26 вызовов инструментов и 19 явных условий перехода между ними.
Модель нужна там, где требуется понять смысл обращения, сформулировать ответ или оценить семантику. Но она не должна сама решать, существует ли объект в базе, успешен ли вызов внешней системы или можно ли выполнять действие.
Например, сам по себе вызов инструмента ещё не считается успехом. Если это skill, внутри него отдельно проверяются статус, ошибки, таймауты, пустой и неоднозначный результат. Только после этого агент продолжает диагностику, просит уточнение или завершает сценарий.
Даже похожие идентификаторы из разных систем не ищутся одним широким запросом. Они проверяются в отдельных ветках, а затем объединяются только после подтверждения, что речь об одной сущности.
У каждого skill есть явное завершение. Процесс не должен зависнуть в состоянии «что‑то проверили, но непонятно, что дальше».
Как мы ограничили роль модели
Мы сознательно не сделали модель прямым пользователем корпоративных систем.
Доступ к знаниям, логам, CRM и другим источникам задаётся отдельно для каждого агента. Модель не может сама «пойти посмотреть всё, что есть». Нужные данные извлекают разрешённые skills (навыки), причём точные идентификаторы — например, коды маршрутов или торговых точек — передаются им как типизированные параметры.
Дальше модель работает только с контекстом, который явно собрал сценарий: текстом обращения или нормализованной карточкой, разрешёнными фрагментами знаний и структурированными результатами проверок. Формальные проверки, обращение к источникам, работа с доступами и расчёт итогов выполняются вне LLM. На стороне модели остаются смысловая оценка, выбор одного из заранее разрешённых исходов и формулировка ответа.
Отдельно защищаются логи и сохраняемые вложения: из них исключаются учётные данные, сырые данные файлов и часть технического контекста.
Здесь важна честная граница. Это не универсальное обезличивание всего до отправки в модель. Безопасность строится на правах доступа, явном составе workflow‑контекста, ограниченных skills и отказе от прямого доступа модели к корпоративным системам.
Почему мы смогли перейти на более дешёвую модель
Сначала мы использовали самую дорогую модель. Нам нужно было убедиться, что агент вообще способен решать наши обращения.
Потом всё больше диагностики выносили в skills, правила и проверяемый контекст. В итоге перешли на более доступную модель. При ежедневной проверке ответов кураторы не увидели заметного ухудшения качества. Отдельный A/B‑тест мы при этом не проводили, поэтому говорить о полном равенстве моделей было бы неправильно.
Медианные расходы на токены для обработки одного обращения в агентном контуре сейчас составляют около $0,06. В эту сумму входят модельные вызовы по всей цепочке, включая вложенных агентов. Инфраструктура, хранение данных, интеграции и труд команды в расчёт не входят.
Это не экономия «за счёт ухудшения качества». Просто модель перестаёт быть одновременно базой знаний, инженером по логам, контролёром доступа и интерпретатором всех бизнес‑правил. Она делает то, что у неё получается лучше всего: помогает понять вопрос и сформулировать понятный ответ на основании уже проверенных данных.
Отдельную RAG‑инфраструктуру перед пилотом мы тоже не строили. Материалы, которые попадают на платформу, индексируются и становятся доступны агентам для поиска. Поэтому мы сосредоточились не на инфраструктуре поиска, а на более неприятной работе: привести знания в порядок.
Где оказалось больнее всего
Сложнее всего были не модель и не интеграция с CRM — сложнее всего оказались данные.
Один и тот же клиент мог по‑разному называться в CRM, Confluence, логах и других системах. Единого сквозного идентификатора не было. Часть проблемы пришлось временно компенсировать инструкциями и дополнительными проверками, хотя правильнее решать её на уровне модели данных.
Пришлось перестраивать и базу знаний. Раньше информация о клиентах могла лежать в общем пространстве Confluence, разложенная по папкам. Для работы отдельных клиентских агентов этого оказалось недостаточно.
Мы переносили знания в более понятную структуру, дополняли сведения о версиях продуктов, конфигурациях и индивидуальных правилах. И постоянно находили вещи, которые раньше никто не фиксировал, потому что их «и так помнили».
Что получилось по итогам
Оценка клиентов и до внедрения была высокой — около 4,8–4,9 из 5. Оценок немного, поэтому приписывать изменение качества агентам было бы нечестно.
Но операционные эффекты видны.
Медианное время ответа клиента на вопросы в обращении, которое решает тиммейт, сократилось примерно с трёх часов до полутора. Пользователь чаще успевает ответить на уточняющий вопрос, пока ещё находится в контексте своей проблемы.
Сейчас цифровым сотрудникам передаётся около 70% всех обращений, которые попадают в поддержку. Из контура мы вывели вопросы, для решения которых агентам пока не хватает доступов или skills. Ближайшая цель — передавать 90%.
В обычном потоке, без массовых инцидентов, на текущий момент примерно 45% переданных обращений решается без участия инженера.
Во время массового инцидента доля автоматически закрытых обращений может быть выше. Команда фиксирует симптомы и согласованный ответ, агент сообщает пользователям, что проблема известна, а после исправления повторно проходит по обращениям и сообщает, что она устранена. Поэтому результат за период с массовым инцидентом нельзя напрямую сравнивать с долей автоматического решения в обычном потоке (в этом случае цифра 45% превращается в 75% решённых обращений только агентом без участия человека от общего количества всех обращений).
Мы посмотрели ещё на один показатель: сколько времени обращения проводят в статусах ожидания, когда ими не занимается инженер. У одного клиента до подключения агента это было в среднем 2,4 часа, а в период работы агента — 0,8 часа. У другого — 5,7 и 1,3 часа соответственно. Это не A/B‑тест, но разница заметная: обращения после первичной обработки агентом в среднем в три‑четыре раза меньше «висят» между этапами и быстрее продвигаются к решению — даже если в итоге подключается инженер.
Как мы считали результат
Мы проанализировали обезличенную сводку за пять полных недель — с 20 июля по 23 августа 2026 года. Единицей подсчёта был уникальный CRM‑диалог (диалог по решению обращения пользователя), а его результат определялся по последнему корректному действию агента. Повторные запуски внутри одного диалога не считались новыми обращениями.
За этот период агентный контур обработал 3 071 уникальный CRM‑диалог. Из них 1 370 завершились со статусом resolved (решено) — 44,6%. Остальные потребовали дополнительных данных, были эскалированы или не получили корректного финального действия.
Получившиеся 44,6% не стоит воспринимать как постоянную долю автоматического решения. Результат сильно зависит от состава потока, массовых инцидентов, повторных обработок и действующих правил эскалации.
Это хорошо показывает реальность работы: цифровой сотрудник не обязан закрыть всё с первого сообщения. Иногда он решает проблему, иногда корректно собирает недостающие данные, иногда передаёт человеку контекст вместо того, чтобы уверенно выдать неправильный ответ.
Что изменилось для команды
Мы не увольняли сотрудников после запуска.
Но когда люди уходят естественным образом, мы не всегда открываем заменяющую вакансию: часть нагрузки уже стабильно закрывает тиммейт. И одновременно появляется запас мощности, чтобы подключать новых клиентов к первой линии поддержки без пропорционального роста штата.
Для нас это не история про сокращение людей. Это возможность меньше зависеть от бесконечного цикла: выросло число клиентов — нанимаем, кто‑то ушёл — снова нанимаем, долго обучаем, потом всё повторяется.
Что изменилось после запуска
Поддержка стала первым большим боевым применением нашей внутренней платформы цифровых агентов. На ней мы проверили не только технологию, но и собственные процессы.
Главный вывод пока такой: агент не заменяет инженера одним махом. Он делает видимой ту работу, которая раньше была спрятана в личных чатах, памяти опытных людей, старых тикетах и неочевидных папках в Confluence.
Сама по себе сборка этого массива актуальных данных из разрозненных систем — огромный труд. Но его ценность окупается. Во‑первых, это фундамент для дальнейшей, более качественной работы с клиентами. Во‑вторых, мы фактически создали «застрахованную» базу знаний. Это снижает риски при уходе ключевых сотрудников и упрощает онбординг новичков, если команде потребуется масштабироваться.
Тиммейты начали влиять и на документацию. Когда агент не может найти подтверждённый ответ или разные источники противоречат друг другу, пробел становится виден сразу. Это уже не знание, которое можно оставить в личном чате: его приходится оформить, назначить владельца и поддерживать в актуальном состоянии.
Изменилась и роль опытных экспертов. Они по‑прежнему подключаются к сложным случаям, но всё реже выступают «внутренним поисковиком» для типовых вопросов. Найденное ими решение можно зафиксировать один раз и сделать доступным всей линии поддержки.
Для руководителей поддержки появился отдельный ревизор качества. Он не решает обращения вместо основного агента, а помогает находить неудачные ответы, пропущенные проверки и повторяющиеся пробелы в знаниях. Это даёт материал не только для исправления конкретного тиммейта, но и для улучшения самого процесса поддержки.
Со временем полезный агент перестаёт быть экспериментом и становится частью рабочей инфраструктуры. Ему нужны владельцы, мониторинг, контроль изменений и регулярное обновление знаний и сценариев — иначе вчерашнее удачное решение быстро устаревает.
Если строить такого помощника как часть процесса — с проверяемыми skills, ограничениями, эскалацией, владельцами знаний и коротким циклом улучшений — он действительно начинает разгружать поддержку.