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