Как сейчас устроено согласование решений и откуда берётся ручная нагрузка
Согласование решения человеком — это процесс, в котором сотрудник или руководитель проверяет подготовленный вариант, оценивает его по известным критериям и разрешает дальнейшее действие либо возвращает вопрос на доработку. Например, менеджер согласует скидку, бухгалтер — платёж, руководитель отдела — коммерческое предложение, а юрист — нестандартное условие договора.
Обычно такой процесс распределён между почтой, мессенджерами, таблицами и корпоративными системами. Один сотрудник собирает информацию, второй уточняет недостающие детали, третий проверяет правила, четвёртый принимает решение. Даже если само согласование занимает несколько минут, подготовка к нему может требовать заметно больше внимания.
Ручная нагрузка возникает не только в момент нажатия кнопки «Согласовать». Нужно найти исходные документы, проверить заполнение полей, сопоставить запрос с внутренними правилами, вспомнить похожие случаи и кратко объяснить руководителю суть вопроса. После решения остаётся обновить статус, уведомить участников и сохранить комментарий.
Особенно много времени теряется, когда запрос приходит в свободной форме. Один менеджер пишет: «Нужно срочно дать клиенту скидку», другой присылает таблицу, третий пересылает длинную переписку. Согласующему приходится каждый раз восстанавливать контекст: кто клиент, какова сумма, почему требуется исключение и что произойдёт после одобрения.
ИИ-агент в таком процессе — это программа, которая получает задачу, собирает нужный контекст, выполняет заданную последовательность действий и передаёт человеку подготовленный результат. Он не просто отвечает на сообщение, а ведёт рабочий запрос от поступления до следующего разрешённого шага. Более общее объяснение есть в статье «Что такое ИИ-агент для бизнеса».
Какие шаги согласования можно поручить ИИ-агенту
Полезно сравнить три подхода: полностью ручную работу, обычную автоматизацию по жёстким правилам и работу с ИИ-агентом.
При ручном подходе сотрудник сам читает запрос, ищет сведения и готовит пояснение. Это гибко, но один и тот же путь приходится проходить заново для каждой заявки. Качество подготовки также зависит от внимательности конкретного исполнителя.
Обычная автоматизация действует по заранее описанной схеме: если сумма меньше установленного порога, отправить запрос одному руководителю, если больше — другому. Такой механизм хорошо работает со структурированными данными и однозначными условиями. Но ему трудно разобрать письмо, выделить причину исключения или собрать смысл из нескольких документов.
ИИ-агент занимает промежуточное место. Ему можно поручить принять запрос из разрешённого канала, определить его тип, проверить комплектность и запросить недостающие сведения. Затем агент способен собрать данные из подключённых источников, сопоставить их с правилами и подготовить краткую карточку для согласующего.
В карточке могут быть предмет решения, важные параметры, найденные несоответствия и ссылки на исходные материалы. Это сокращает путь от необработанного запроса до понятного варианта, который человек способен быстро проверить. После ответа агент может записать статус и отправить участникам уведомления.
Отличие здесь не в красивом тексте. Чат-бот обычно ведёт диалог и отвечает на отдельный запрос. Обычный сценарий выполняет фиксированную цепочку команд. Агент работает с контекстом конкретной заявки и может выбирать следующий разрешённый шаг: запросить данные, провести проверку или передать вопрос нужному сотруднику.
Разработка ИИ-агентов имеет смысл там, где такой выбор действительно нужен. Если весь процесс сводится к проверке одного поля и отправке стандартного уведомления, достаточно простой автоматизации. Использовать более сложную систему только ради слова «ИИ» нет практического смысла.
Какие задачи подходят агенту, а какие должны оставаться под контролем человека
Лучше всего агенту подходят повторяющиеся подготовительные задачи с понятным результатом. Например, проверить наличие обязательных документов, извлечь из них нужные сведения, найти расхождения, классифицировать обращение и составить короткое резюме. Сюда же относится маршрутизация: определить, кому передать заявку согласно установленным условиям.
Подходящей может быть и предварительная оценка по формализованным критериям. Агент способен показать, что запрошенная скидка выходит за обычный диапазон или что в договоре обнаружено нестандартное условие. Важно, чтобы он не скрывал основание такой отметки, а указывал правило и исходные данные.
Плохо подходят задачи, где решение зависит от неописанного контекста, личной ответственности или последствий, которые нельзя надёжно оценить по доступной информации. Переговорная позиция в важном контракте, исключение для стратегического клиента или спорная выплата могут выглядеть похожими на обычные заявки, но требовать управленческого суждения.
За человеком стоит сохранять решения, которые создают существенные финансовые, юридические, кадровые или репутационные последствия. Также ручная проверка нужна при конфликте данных, отсутствии обязательного документа, низкой уверенности агента и выходе за утверждённые границы.
Контроль человека не должен быть формальной кнопкой в конце цепочки. Согласующему нужны понятное резюме, первоисточники и объяснение, почему запрос попал именно к нему. У него должна оставаться возможность отклонить предложение, запросить уточнение и исправить ошибочно распознанные сведения.
Граница ответственности задаётся до запуска: что агент вправе делать самостоятельно, где он только рекомендует действие и при каких условиях обязан остановиться. Это помогает не выдавать вероятностный вывод модели за подтверждённый факт. Агент может уменьшить объём подготовительной работы, но сам по себе не гарантирует правильность каждого решения.
Какие данные, правила и интеграции нужны для работы агента
Система начинается не с модели, а с источников информации. Нужно определить, где находятся заявки, документы, история согласований, сведения о клиентах и действующие внутренние правила. Если сотрудники пользуются разными версиями таблиц и пересылают документы без понятных названий, агент унаследует эту путаницу.
Следующая часть — правила процесса. В них фиксируют обязательные поля, допустимые значения, пороги, роли согласующих и основания для передачи вопроса выше. Отдельно описывают исключения. Правило «нестандартные условия отправлять юристу» бесполезно, пока не определено, какие именно условия считаются нестандартными.
Затем нужны интеграции — безопасные соединения с рабочими системами. Агенту может потребоваться читать заявки из CRM, получать документ из хранилища, создавать задачу или записывать статус. Доступ лучше ограничивать конкретными операциями. Если агенту достаточно читать карточку клиента, ему не нужны права на изменение всей базы.
Для каждого решения полезен журнал действий. В нём сохраняются полученные данные, выполненные проверки, предложенный вариант, ответ человека и итоговый статус. Такой журнал помогает разбирать ошибки и понимать, на каком этапе возникло расхождение.
Наконец, нужен интерфейс согласования: карточка в привычной системе, письмо или сообщение с нужными кнопками. Техническая сложность может быть скрыта, но содержание должно оставаться прозрачным. Руководителю важнее увидеть сумму, причину отклонения от правила и исходный документ, чем читать длинное рассуждение модели.
Как проверить результат на небольшом пилоте
Для первого пилота я бы выбирал один узкий тип согласования с регулярным потоком и понятным началом и концом. Хороший кандидат — процесс, где сотрудники тратят время на сбор одних и тех же сведений, а решение принимается по сравнительно устойчивым правилам. Дополнительные ориентиры собраны в материале «Как выбрать процесс для первого AI-пилота».
Не стоит начинать с самого редкого, конфликтного или ответственного сценария. На нём трудно получить достаточно наблюдений, а цена ошибки может оказаться слишком высокой. Также слабым кандидатом будет процесс, правила которого разные участники понимают по-разному. Сначала полезнее договориться о самом порядке работы.
До пилота нужно зафиксировать текущую точку: сколько ручных действий требуется, где запросы чаще возвращаются и какие сведения приходится уточнять. Для оценки не обязательно сразу переводить всё в деньги. Можно сравнить время подготовки заявки, долю неполных запросов, число возвратов и количество исправлений после решения.
На пилоте агенту лучше поручить ограниченную часть процесса, например проверку комплектности и подготовку карточки. Его предложения можно некоторое время сопоставлять с обычной работой сотрудников, не включая автоматическое исполнение. Так становятся заметны пропущенные правила, неоднозначные формулировки и источники с неактуальными данными.
Применимость идеи к своему процессу можно проверить совсем спокойно: взять несколько типичных заявок, вручную выписать сведения, которые ищет согласующий, и отметить повторяющиеся проверки. Если большую часть подготовки удаётся описать одинаковыми шагами, а точки обязательного решения человека понятны заранее, процесс подходит для небольшого пилота.