Контроль поручений через ИИ: как собрать систему за 2 недели

Поручения теряются не потому, что люди ленивые. Они теряются потому, что задача рождается в одном месте, живёт в другом, а проверяют её в третьем. Директор наговорил голосовое в машине. Руководитель направления пересказал это на планёрке своими словами. Исполнитель записал в блокнот. Через неделю все трое помнят разное, и спор идёт не о результате, а о том, что именно просили.

За полтора года корпоративных внедрений я собирал эту схему в рознице, в отделке помещений, в проектных отделах и в службе обработки обращений. Формулировки боли у всех почти дословно совпадают: «от чатов и голосовых — к чётким задачам», «контроль постановки задач и их исполнения, насколько просрочка», «ассистент, на которого можно сгружать задачи, а он фиксирует и напоминает». Ниже — порядок действий, который я повторял в каждой из этих компаний, с промптами, которые можно скопировать, и с честным списком того, чего ИИ здесь не делает.

Почему контроль разваливается на трёх стыках, а не по всей длине

Если разложить путь поручения, ломается оно всегда в одних и тех же точках. Первый стык — между произнесённым и записанным: сказано голосом, записано по памяти и уже другими словами. Второй — между записанным и понятым: формулировка допускает несколько прочтений, и исполнят её самым дешёвым. Третий — между сроком и проверкой: в реестр никто не смотрит, пока дедлайн не наступил.

Первый стык — вход. Задача поставлена в устной форме или в потоке переписки. Допустим, в чате отдела за день проходит 200 сообщений, из них поручений — восемь, и ни одно не оформлено как поручение. Никто не ленился: просто между «Петь, глянь по смете к пятнице» и карточкой в трекере есть ручная работа на две минуты, а таких фраз за день восемь. Шестнадцать минут в день руководитель не тратит никогда.

Второй стык — формулировка. «Проработать вопрос с поставщиком» — это не задача, это тема. У неё нет измеримого результата, поэтому через неделю исполнитель отчитается «прорабатываю», и формально он прав. Дальше начинается управление настроением вместо управления сроками.

Третий стык — проверка. Чтобы понять, где просрочка, надо открыть трекер, отфильтровать, сопоставить с тем, что обсуждали на планёрке, и вспомнить, кому что переносили. По моим наблюдениям на внедрениях это 30–40 минут в день, и делает это руководитель, чей час стоит дороже всего в компании. В итоге проверка выполняется рывками: перед советом директоров и после скандала.

ИИ не чинит дисциплину. Он убирает ручную работу на первом и третьем стыке и проверяет формулировку на втором. Всё остальное — трекер, регламент и воля руководителя.

Что автоматизируем, а что оставляем людям

Граница простая, и нарушают её почти все, кто начинает с «а давайте ассистента, который всё ведёт». Машине отдаём механику: разбор голосового и переписки в карточки, проверку формулировки на двусмысленность, ежедневную сводку по просрочкам. За людьми остаются решения — кому поручить, какой срок реален и что делать со сорванным сроком.

Модель не ведёт реестр. Память между чатами есть у всех трёх продуктов — ChatGPT Memory со ссылками на прошлые чаты, память Claude на платных тарифах, personal context у Gemini, — но это память о пользователе и его контексте, а не учёт задач. На неё нельзя опереться в управленческом учёте: в ней нет статусов, переносов и истории, по которой видно, что задача №47 вчера была в работе, а сегодня просрочена.

Срабатывать по времени модели тоже научились: ChatGPT Tasks (с января 2025, на платных тарифах) и Scheduled Actions у Gemini запускаются по расписанию и присылают сообщение сами, без вызова пользователем. Но это именно напоминалка по расписанию, а не планировщик с реестром, сроками и статусами, — трекер она не заменяет.

Значит, реестр задач остаётся за трекером: Bitrix24, Notion, Google Sheets — подойдёт любой, где есть поля «исполнитель», «срок», «статус» и выгрузка. Расписание остаётся за тем, кто знает сроки задач: встроенные напоминания трекера или обычный календарь. А ИИ берёт на себя три вещи: разбор входящего потока в карточки, приёмку формулировки и сборку сводок и разборов из выгрузки.

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

Шаг 1. Один список, в который сходится всё

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

Первая неделя внедрения уходит не на ИИ, а на решение «поручение существует, только если оно в реестре». Реестр — таблица или трекер с восемью полями, больше не надо: номер, дата постановки, формулировка, измеримый результат, исполнитель, срок, статус, источник (планёрка, чат, голосовое, письмо).

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

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

Шаг 2. Промпт, который превращает голосовое и чат в карточки

Это тот кусок, ради которого всё и затевается: «от чатов и голосовых к чётким задачам».

Голос на вход принимают ChatGPT и Gemini — можно надиктовать или приложить аудиофайл; у OpenAI распознавание речи описано в разделе Speech to text, у Google — в документации по работе с аудио. В мобильных приложениях Claude и DeepSeek голосовой ввод тоже есть, но работает он иначе: сами модели Claude аудиофайл как вложение не принимают — в таблице модальностей в обзоре моделей Anthropic у них только текст и изображения, а речь в текст переводит клиент. Практический вывод один: в чат с Claude попадает уже расшифровка, и качество разбора зависит от того, чем эту расшифровку сделали. Отдельно отмечу: распознать речь и разделить её по говорящим — разные функции. Диаризация есть не везде, и если в записи планёрки говорят пятеро, модель по звуку не всегда поймёт, кто именно дал поручение. Поэтому в промпте ниже есть пункт про неизвестного постановщика.

Ты — ассистент руководителя. Разбери текст ниже на поручения.

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

Для каждого поручения верни строку таблицы с полями:
1. Формулировка — глагол в начале, одно действие
2. Измеримый результат — по какому артефакту поймём, что сделано
   (файл, письмо отправлено, договор подписан, цифра в отчёте)
3. Исполнитель — имя из текста
4. Срок — конкретная дата в формате ДД.ММ
5. Цитата-основание — дословный фрагмент, из которого ты это взял

Жёсткие правила:
- Не придумывай сроки и исполнителей. Если в тексте их нет — пиши «не указан».
- Если непонятно, кто ставит задачу, пиши «постановщик не определён».
- Относительные сроки («к пятнице», «на следующей неделе») переводи в дату,
  считая от даты, которую я укажу, и помечай звёздочкой.
- Обсуждения без действия в таблицу не попадают. Их вынеси отдельным
  списком «Обсуждали, но поручения не прозвучало».

После таблицы отдельным блоком: «Вопросы постановщику» — перечисли,
что нужно уточнить, чтобы каждая задача стала исполнимой.

Сегодня: [дата].
Текст:
"""
[вставить расшифровку или переписку]
"""

Два пункта в этом промпте делают всю работу. «Цитата-основание» убивает выдумку: если модель не может показать фрагмент, откуда взяла задачу, задача выдумана, и это видно за секунду. «Вопросы постановщику» переворачивают процесс — вместо того чтобы раздать сырые задачи и получить их обратно через неделю, руководитель получает список из трёх уточнений и закрывает их сразу, пока контекст в голове.

По моему опыту, разбор получасовой планёрки этим промптом занимает около трёх минут вместе с вычиткой, а руками на то же уходило 25–30. Если нужен не список задач, а полноценный протокол со структурой и решениями — об этом отдельно в статье про протокол совещания, там разобран режим, когда встреча длинная и решений много.

Шаг 3. Приёмка формулировки: поручение, которое нельзя понять двояко

Второй стык. Задача сформулирована, но её можно исполнить пятью способами — и исполнят самым дешёвым.

Я держу отдельный короткий промпт-приёмщик. Руководитель вставляет туда формулировку до отправки, а не после.

Проверь поручение на исполнимость. Верни три блока.

1. Двусмысленности. Перечисли все места, которые исполнитель может
   понять иначе, чем задумал постановщик. К каждому — два варианта
   прочтения: минимальный (как сделает тот, кто хочет закрыть быстро)
   и максимальный.
2. Чего не хватает. Проверь по списку: субъект, действие, измеримый
   результат, срок, кому сдаём, что считается несделанным.
3. Переписанная формулировка — не длиннее трёх предложений,
   без слов «проработать», «оптимизировать», «взять на контроль»,
   «подумать», «уделить внимание».

Не задавай мне вопросов, не проси уточнений — работай с тем, что есть,
и помечай пропуски как [уточнить: ...].

Поручение: «[текст]»

Пример из реального внедрения. Исходник: «Проработать вопрос с задержками поставок по объекту». Минимальное прочтение — написать поставщику письмо. Максимальное — сменить поставщика. Разница в цене вопроса — в сто раз. После приёмки формулировка стала такой: «Собрать по объекту таблицу срывов сроков за 3 месяца: дата плана, дата факта, причина по версии поставщика. Прислать файлом до 24.09. Несделанным считается таблица без графы причин».

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

Шаг 4. Ежедневная сводка: кто просрочил и на сколько

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

Схема работы: утром из трекера выгружается CSV с полями «номер, задача, исполнитель, срок, статус, дата последнего изменения», файл прикладывается в чат с моделью, запускается сохранённый промпт.

Ты — контролёр исполнения поручений. На входе выгрузка задач (CSV).
Сегодня [дата].

Собери сводку для руководителя, строго в таком порядке:

БЛОК 1. Просрочено. Задачи со сроком раньше сегодня и статусом
не «выполнено». Сортируй по глубине просрочки, от большей.
Формат строки: [дней просрочки] — задача — исполнитель — срок.

БЛОК 2. Горит сегодня и завтра. То же поле, срок = сегодня или завтра.

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

БЛОК 4. Картина по исполнителям. Таблица: исполнитель, всего
в работе, просрочено, максимальная глубина просрочки.

БЛОК 5. Три наблюдения. Только то, что видно из данных:
повторяющиеся переносы, перегруз одного исполнителя, задачи
без срока. Не давай советов по мотивации и по управлению людьми.

Правила: ничего не додумывай, считай только по выгрузке.
Если поле пустое — так и пиши «срок не заполнен», это отдельная
строка в блоке 5. Общий объём — не больше одного экрана.

Блок 3 — тот самый «свыше трёх дней» из запроса службы качества. Он ловит задачи, которые формально не просрочены, но мертвы: их взяли, отметили «в работе» и не трогали неделю. Без него сводка показывает только пожары, а не тлеющее.

Блок 4 обычно вызывает самое сильное удивление на первом же запуске: просрочки почти никогда не размазаны по команде ровно — они собираются у одного-двух человек, и у них же идут волнами. Никакой ИИ этого не «находит»: задачи лежат в трекере месяцами, просто их никто не складывал в одну кучу и не смотрел на срез по исполнителям.

Сама сборка у меня занимает около 4 минут: выгрузка, вставка, чтение. Раньше на это же уходило до получаса, и делалось оно раз в неделю, а не ежедневно. Если нужна не оперативная сводка, а отчёт для собственника или совета — это соседняя задача, и она разобрана в статье «Отчёт руководителя с помощью ИИ».

Шаг 5. Напоминания до срока, а не после

Напоминание после дедлайна — это не контроль, а протокол о нарушении. Работает напоминание за день.

Здесь важно не перепутать роли. Тикать должно то, что знает срок и статус: в Bitrix24 это штатное напоминание по задаче, в таблице — простое правило, в Telegram — бот или отложенное сообщение. Встроенные расписания у моделей тоже есть — ChatGPT Tasks и Scheduled Actions у Gemini действительно пришлют сообщение в заданное время сами, — но о переносах и закрытых задачах они не знают и будут напоминать про то, что уже сдано. Поэтому если кто-то обещает «ассистента, который напомнит», спрашивайте не умеет ли он срабатывать по времени, а откуда он берёт срок и статус.

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

Сделай из строки задачи короткое сообщение исполнителю в мессенджер.

Требования:
- максимум 4 строки
- первая строка: что и к какому сроку
- вторая: какой результат считается сданным
- третья: один прямой вопрос — успеваешь или нужен перенос
- без обращений «уважаемый», без извинений, без «пожалуйста, обратите внимание»
- нейтральный тон, без давления и без угроз

Строка задачи: [вставить]

Ключ — третья строка. Вопрос «успеваешь или нужен перенос» переводит молчание в ответ. Исполнитель, который не успевает, обычно не пишет об этом сам, потому что признаваться неприятно; на прямой закрытый вопрос отвечают. В отделочной компании это одно изменение сократило количество сюрпризов в день сдачи примерно вдвое за месяц — переносы стали приходить заранее, а не постфактум.

Шаг 6. Подрядчики и контрагенты: контроль без общего трекера

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

Раз в неделю переписка с подрядчиком выгружается или копируется и прогоняется через промпт-экстрактор.

Перед тобой переписка с подрядчиком за период.
Сегодня [дата].

Вытащи все обещания и договорённости с датами. Для каждого:
- что обещано (одним предложением)
- кто обещал: мы или они
- дата, к которой обещано
- дословная цитата
- статус по переписке: подтверждено выполнение / не подтверждено /
  срок перенесён (укажи, сколько раз переносился)

Отдельно: обещания, срок которых прошёл, а подтверждения
выполнения в переписке нет.
Отдельно: обещания без даты — их надо превратить в датированные.

Не делай выводов о добросовестности подрядчика. Только факты
из переписки с цитатами.

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

На стройке эта схема за квартал дала неожиданный побочный результат: стало видно, что один из поставщиков переносил сроки в среднем по три раза на каждое обещание, а второй — ни разу. До этого оба считались «нормальными, как все».

Шаг 7. Еженедельный разбор: почему сроки срывались

Ежедневная сводка отвечает на вопрос «где горит». Она не отвечает на вопрос «почему горит каждую неделю в одном и том же месте». Для этого раз в неделю прогоняется разбор — по выгрузке закрытых и просроченных задач за 7 дней.

На входе — задачи за неделю: закрытые, просроченные, перенесённые.
Сгруппируй причины срыва сроков по типам, опираясь на данные:

- задача поставлена без измеримого результата
- срок поставлен без согласования с исполнителем (перенесён в первые сутки)
- исполнитель перегружен (больше N задач в работе одновременно)
- задача зависит от другой невыполненной задачи
- задача зависит от внешней стороны
- причина из данных не выводится

Для каждого типа: сколько задач, примеры номеров.
Затем — один вывод: какой тип даёт больше всего срывов на этой неделе.
Гипотез о людях не строй.

Этот разбор занимает у меня минут десять в неделю и меняет не задачи, а регламент. В проектном отделе три недели подряд первым типом выходило «срок поставлен без согласования с исполнителем» — задачи переносились в первые же сутки после постановки. Вывод был не про ИИ: перестали ставить сроки в одностороннем порядке на планёрке, начали спрашивать «когда реально». Количество переносов упало, потому что они переехали на пять минут раньше — в момент постановки.

Что эта система не делает

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

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

Она не подключается к вашему трекеру сама. В чат-интерфейсе всё ходит через выгрузку и копирование: 3–4 минуты в день. Прямая интеграция по API возможна, но это уже проект с разработкой, и начинать с него не надо — сначала надо две недели пожить на ручной выгрузке и понять, какие поля реально нужны. Половина хотелок отваливается на этом этапе.

Она не разбирает запись встречи по ролям автоматически, если в записи один общий звуковой канал. Раздельные дорожки участников есть не во всех сервисах связи, а распознавание речи и разделение по говорящим — разные вещи. Когда постановщик не определён, промпт из шага 2 обязан честно писать «постановщик не определён», а не угадывать.

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

Приватность: что не кладём в чат с моделью

Выгрузка задач — это внутренние данные: фамилии сотрудников, названия объектов, иногда суммы. Перед внедрением стоит потратить полчаса на три решения.

Первое — режим обучения. У ChatGPT на личных тарифах (Free, Plus, Pro) переключатель «Improve the model for everyone» включён по умолчанию и выключается вручную в разделе Settings → Data controls. У Anthropic устроено иначе: после обновления политики от 28 августа 2025 года пользователю показывают явный выбор — диалог, в котором переключатель предустановлен во «включено», так что согласиться, не читая, легко, но молчаливого включения нет. Корпоративные и командные планы работают по другим правилам. Если компания сидит на личных аккаунтах сотрудников — это первое, что надо проверить, и делать это надо по актуальной справке вендора, а не по совету из чата.

Второе — обезличивание. В выгрузку, которая уходит в модель, обычно достаточно отдать фамилии как «Исполнитель 1, 2, 3» и заменить названия клиентов на коды. Сводка от этого не теряет смысла: руководитель сопоставляет обратно по своему файлу за десять секунд. Персональные данные клиентов, реквизиты договоров, паспортные данные в чат не уходят вообще.

Третье — кто именно работает с выгрузкой. В большинстве внедрений это не руководитель, а ассистент, и у него должен быть рабочий аккаунт компании, а не личный.

План на две недели

Сроки ниже — по моему опыту внедрений, при двух-трёх часах работы в неделю со стороны руководителя.

Первая неделя. День 1–2: собрать реестр из восьми полей и объявить правило «поручение существует только в реестре». День 3–4: перенести туда всё, что помнят руками, — по моему опыту выясняется, что задач в полтора-два с половиной раза больше, чем казалось (в кейсе выше было 74 против примерно 30). День 5: запустить промпт разбора входящего потока на одном отделе и назначить человека, который делает разбор утром и вечером по 15 минут.

Вторая неделя. День 6–7: подключить промпт-приёмщик формулировок — обязателен для всех задач дороже определённого порога, остальные по желанию. День 8–9: запустить ежедневную сводку и вынести её на планёрку. День 10: включить напоминания за день до срока. В конце второй недели — первый еженедельный разбор причин срывов.

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

Начинать лучше не с выбора сервиса, а с одной планёрки: возьмите расшифровку ближайшей, прогоните через промпт из шага 2 и посмотрите на блок «Вопросы постановщику». Обычно там три-четыре пункта, которые в обычном режиме всплыли бы через неделю — вместе со сдвинутым сроком.