Агенты в корпоративных процессах: где помогают, а где нет

Почему команды путаются в этой теме

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

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

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

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

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

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

Чем цепочка отличается от агента

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

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

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

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

Агент требует большего контроля. Ему нужны лимиты на шаги, явные права доступа, хорошие логи и понятные стоп-условия. Иначе он начинает ходить по кругу, делает лишние запросы или принимает решение там, где должен был остановиться и позвать человека.

Где в поддержке хватает простой цепочки

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

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

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

Такая схема удобна и там, где надо заполнить поля в CRM из письма или чата. Система вытаскивает номер заказа, тему обращения, канал связи, признак срочности и имя клиента, если оно есть в тексте, а потом раскладывает все по нужным полям.

Еще один частый сценарий - проверка текста на персональные данные перед тем, как он попадет в карточку обращения или во внутренний комментарий. Один вызов модели может найти паспортные данные, телефон, почту, адрес и убрать то, что не нужно хранить в открытом виде. Для компаний с требованиями по 152-ФЗ это обычная рабочая задача.

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

Когда в поддержке нужен многошаговый агент

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

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

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

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

Последний пункт часто недооценивают. Агент не должен упрямо закрывать каждый тикет сам. Для части диалогов нормальный результат - эскалация, но не пустая фраза "передаю оператору", а уже собранные факты и понятный журнал шагов.

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

Что происходит в бэк-офисе на практике

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

Много времени уходит на простую, но утомительную работу. Сотрудник открывает письмо или ЭДО, находит номер договора, копирует ИНН, проверяет сумму, потом переносит те же данные в 1С, ERP или CRM. Если систем несколько, одни и те же поля вводят дважды, а иногда и трижды.

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

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

Например, поставщик прислал счет в PDF, а заявка на оплату уже есть в ERP. Сотрудник сверяет реквизиты, ищет договор, проверяет лимит и только потом отправляет документ на согласование. Если в PDF указан старый КПП, весь путь останавливается.

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

Так выглядит обычный бэк-офис: много повторов, мало свободы и высокая цена даже у мелкой ошибки.

Где агент в бэк-офисе помогает, а где мешает

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

Где лучше цепочка

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

Подход скучный, но надежный. Он дает один и тот же результат на одинаковом входе, проще тестируется и не раздувает число вызовов. Свободный агент в такой задаче часто мешает: он может пойти в лишний источник, по-своему трактовать исключение или написать длинное объяснение там, где нужен простой флаг "совпало / не совпало".

Где агент уместен

Сбор пакета по контрагенту уже ближе к агенту. Данные могут лежать в ERP, CRM, архиве договоров, почте, внутренней базе рисков и в учетной системе. Иногда документов не хватает, иногда названия расходятся, иногда нужно повторно запросить выписку или найти последнюю версию доверенности.

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

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

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

Как выбрать подход

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

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

Отдельно отметьте все места, где нужен доступ к внешним данным. CRM, 1С, база договоров, сервис проверки документов, внутренний чат - каждый такой вызов добавляет риск. Если источник часто тормозит, отдает неполные данные или требует сложных прав, агент начнет ошибаться не из-за модели, а из-за окружения.

Потом оцените цену ошибки на каждом шаге. Неверно определить тему обращения неприятно, но обычно поправимо. Перепутать реквизиты поставщика - уже прямой финансовый риск. Пропустить просроченный документ - риск для комплаенса. Закрыть задачу без подтверждения клиента - удар по поддержке.

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

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

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

Пример с возвратом и проверкой документов

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

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

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

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

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

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

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

Ошибки, которые ломают проект

Чаще всего проект ломается не на модели, а на правах и границах. Команда видит удачное демо и сразу дает агенту доступ на запись в CRM, ERP или тикетную систему. После этого одна неверная интерпретация письма меняет статус заказа, закрывает обращение или запускает выплату. Для пилота это почти всегда слишком рано.

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

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

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

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

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

Если у системы нет такого тормоза, она ломает доверие быстрее, чем приносит пользу.

Быстрая проверка перед запуском

Запускать агента в поддержку или бэк-офис без короткой проверки дорого. Ошибка редко выглядит как сбой на весь отдел. Чаще это тихая потеря денег: лишние шаги, ручные разборы, спорные решения и недовольные сотрудники.

Перед пилотом стоит ответить на пять вопросов.

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

Если команда использует RU LLM как OpenAI-совместимый шлюз, на каждый запрос полезно сохранять маршрут, версию промпта, выбранную модель, факт маскирования PII и причину, по которой агент пошел дальше или остановился. Такой след помогает разбирать спорные кейсы. Для компаний с требованиями по 152-ФЗ важны и хранение логов в РФ, и понятный аудит-трейл, но даже при такой инфраструктуре границы процесса все равно нужно задавать заранее.

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

Что делать дальше

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

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

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

Удобный порядок такой:

1. Выберите один процесс с понятными правилами.
2. Запустите базовую цепочку и снимите метрики за 1-2 недели.
3. Добавьте один агентный шаг в самое узкое место.
4. Заранее определите порог, после которого задачу берет человек.

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

Для первого пилота этого достаточно: один процесс, базовая цепочка и одна понятная точка ручной эскалации.