директор и машина · операционное управление · запись № 025 · 27 июля 2026 · Давид Герштейн

Протокол планёрки, который пишется сам

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

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

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

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

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

Зачем вам протокол планёрки

Не для отчётности. Для того, чтобы через неделю вы могли проверить, сделал ли ваш человек то, о чём договорились, — не по памяти, а по записи.

Без протокола планёрка живёт ровно до момента, пока участники не разошлись по делам. Дальше начинается пересказ по памяти, и каждый помнит немного своё. Я видел, к чему это приводит на уровне данных: при попытке выгрузить список клиентов одного региона из воронки CRM получили несколько разных чисел, заметно расходящихся между собой. Причина — децентрализованное хранение информации, никто не сверялся с единым источником. С задачами из планёрок работает тот же механизм: если протокол не зафиксирован автоматически сразу после встречи, каждый участник уносит свою версию договорённостей, и через неделю выяснить, кто прав, уже нельзя.

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

Шаблон протокола планёрки: что должно быть в каждом

Протокол работает, если в нём всегда одни и те же поля — тогда его можно и собирать машиной, и читать по диагонали. Наш набор такой:

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

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

Механика по шагам

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

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

1. Запись. Планёрка идёт в Zoom, Google Meet или просто на диктофон в переговорке. Источник аудио не принципиален — важно, чтобы запись велась постоянно, а не «когда вспомнили».
2. Расшифровка. Аудио уходит в сервис распознавания речи. Для старта не нужно ничего разрабатывать: Яндекс SpeechKit и Salute Speech от Sber дают разметку по спикерам из коробки через обычный API-запрос, платите за минуты записи — удобно, если планёрок немного. Если записей много и хочется считать не в минутах, а в разовой настройке, — Whisper (открытая модель, можно развернуть на своём сервере) обходится дешевле в пересчёте на час при большом потоке, но требует один раз настроить инфраструктуру. На выходе в любом случае — транскрипт с таймкодами и, желательно, разметкой по спикерам.
3. Структурирование. Транскрипт подаётся в языковую модель с промптом, который вытаскивает поручения: что сделать, кто отвечает, к какому сроку, на какой минуте это прозвучало.
4. Передача в систему. Результат — не текст в чате, а структурированные записи, которые скрипт кладёт в CRM или таск-трекер через вебхук: задача, ответственный, дедлайн, ссылка на исходный фрагмент записи.
5. Просмотр человеком. Руководитель или проект-менеджер один раз в день получает сводку: что добавилось, что просрочено, что требует подтверждения — и подтверждает или правит вручную.

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

ИИ-связка: промпт, модель, обвязка

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

Расшифровка сама по себе — самая дешёвая часть цепочки, около 2 000 ₽ в месяц при ежедневной получасовой планёрке. Дороже интеграция: связать запись с CRM, таск-трекером, распределить задачи по людям. И вот здесь легко переплатить, даже не заметив этого. В одной команде разработчик гонял тяжёлую модель (Opus) на задачах, которые дешёвая версия (Sonnet) решала одинаково хорошо. Проверили на одном и том же промпте — результат оказался идентичным. Для выделения задач из транскрипта планёрки это прямое указание: не нужна самая дорогая модель, чтобы превратить текст в список поручений. Дорогая модель имеет смысл там, где есть более глубокая смысловая нагрузка — например, оценка качества переговоров с клиентом, а не структурирование внутренней планёрки.

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

Ты — ассистент, который структурирует протокол планёрки.
На входе — транскрипт с таймкодами и именами спикеров.

Транскрипт:
{{transcript}}

Задача: выделить из текста все поручения и договорённости,
которые прозвучали явно (не общие обсуждения, а конкретные "сделать X").

Верни ответ строго в формате JSON-массива. Для каждой задачи укажи:
- task: краткая формулировка в повелительном наклонении
- owner: имя ответственного, только если оно названо явно в тексте,
  иначе значение "уточнить"
- deadline: срок в формате ГГГГ-ММ-ДД, если он назван, иначе "не назван"
- timecode: таймкод начала фрагмента, где это обсуждалось
- confidence: high / medium / low — насколько явно это
  прозвучало как поручение, а не как рассуждение

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

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

[
  {"task": "Свести три выгрузки клиентов по региону в один отчёт",
   "owner": "уточнить", "deadline": "не назван",
   "timecode": "00:04:12", "confidence": "medium"},
  {"task": "Проверить настройки фильтра воронки в CRM",
   "owner": "Ирина", "deadline": "2026-07-29",
   "timecode": "00:11:47", "confidence": "high"}
]

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

Вот как эти две задачи выглядят уже после того, как скрипт разложил их по CRM — так руководитель видит их в системе, а не в чате:

Формат вебхука и структура очереди — для тех, кто будет собирать это руками

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

• Скрипт получает JSON-массив от модели и построчно пишет его в промежуточную таблицу (можно на первое время в Google Sheets, дальше — в БД): столбцы id, task_text, owner_raw, deadline_raw, timecode, confidence, status. Статус по умолчанию — pending.
• Отдельный воркер раз в 5–10 минут разбирает записи со статусом pending. Если confidence = low или owner_raw = «уточнить» — запись уходит в manual_review, задача не создаётся автоматически, а в Telegram руководителю приходит карточка с кнопками «создать» / «отклонить».
• Если confidence = high и имя из owner_raw находится в справочнике сотрудников (простой маппинг «имя → ID ответственного в CRM»), воркер отправляет задачу через API и меняет статус на sent, сохраняя ID созданной задачи для сверки при аудите.

Пример запроса на создание задачи через REST-вебхук Bitrix24 (метод tasks.task.add) для второй строки из примера выше:

POST https://ваш-портал.bitrix24.ru/rest/1/вебхук_код/tasks.task.add.json

{
  "fields": {
    "TITLE": "Проверить настройки фильтра воронки в CRM",
    "RESPONSIBLE_ID": 34,
    "DEADLINE": "2026-07-29T18:00:00+03:00",
    "DESCRIPTION": "Источник: планёрка 27.07, таймкод 00:11:47. Автоматически из транскрипта, confidence: high.",
    "UF_CRM_TASK": ["CO_1482"]
  }
}

Для amoCRM логика та же, меняется только эндпоинт и поля: задача создаётся через API amoCRM в сущность «задачи» с привязкой к сделке по ID, а не через отдельный сервис задач, как в Bitrix24. Выбор платформы не принципиален — принципиально то, что между JSON от модели и записью в системе стоит очередь с проверкой уверенности, а не прямой пайп «расшифровал → создал».

Если JSON невалиден или больше половины пунктов получили confidence «low» — система не создаёт задачи молча, а шлёт алерт в Telegram ответственному за автоматизацию: транскрипт кривой, нужно посмотреть руками. Перезапуск — по той же записи повторным вызовом, без пересборки всей цепочки.

Как задачи из совещания перестают теряться

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

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

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

Что именно должно попадать в протокол

• Формулировка задачи — не «обсудили», а «сделать X»;
• Ответственный — конкретное имя, не отдел целиком;
• Срок — дата, а не «в ближайшее время»;
• Ссылка на источник — таймкод записи, чтобы можно было проверить контекст.

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

Вот как обычно распределяются трудозатраты на внедрение такого конвейера с нуля — по опыту, не точные часы:

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

Больше про экономию на моделях и реальные счета за токены я разбирал в статье о реальных расходах на ИИ — там же пример, когда правильная настройка лимитов сэкономила около 50 000 ₽ за одну ночь просто на выборе модели.

Экономика: что это стоит и что даёт

Настройка конвейера «запись → расшифровка → задачи в CRM» — это около 40 часов интеграции при ставке подрядчика ~2 000 ₽/час (≈80 000 ₽ разово), эксплуатация — около 2 000 ₽/мес на транскрибацию, эффект — примерно 70 000 ₽/мес высвобожденного времени менеджеров (оценка).

Формула для прикидки своего случая словами: (число участников планёрки) × (минуты, которые в среднем уходят у каждого на переспрашивание задач в день) × (рабочих дней в месяц) / 60 = часы потерь в месяц; умножьте результат на свою почасовую ставку — получите сумму, которую сейчас незаметно съедает отсутствие протокола.

Возьмём условный отдел из 15 менеджеров сервисной компании с оборотом около 12 млн ₽/мес и ежедневной 30-минутной планёркой. Без протокола каждый в среднем тратит около 15 минут в день на то, чтобы переспросить у коллеги или руководителя, что именно решили и кто за что отвечает — это ровно та ситуация, которую описывал финансовый сотрудник в начале статьи. Подставляем в формулу: 15 менеджеров × 15 минут × 22 рабочих дня / 60 ≈ 82 часа в месяц, потерянных на одном отделе. При ставке рабочего часа ~1 000 ₽/час это около 82 000 ₽ в месяц — только на переспрашивание, без учёта цены забытых договорённостей, если из-за них зависла сделка или не выставлен вовремя счёт.

Прикидка по времени на уточнение задач после планёрки, не абсолютные внутренние данные компании.

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

Стоимость эксплуатации не в расшифровке — она обходится примерно в 2 000 ₽ в месяц при разумном выборе модели, о чём и говорит история с Opus и Sonnet, давшими идентичный результат на одном промпте. Основные деньги уходят один раз: на интеграцию с CRM или таск-трекером и на настройку промпта под структуру конкретных планёрок компании.

Откуда берётся раскладка трудозатрат на весь конвейер — не с потолка, а прямая раскладка по этапам с диаграммы выше, для интеграции среднего уровня сложности (одна CRM, один таск-трекер, без кастомных полей и без переписывания структуры данных): настройка и тест расшифровки — меньшая часть общего объёма (10%), доводка промпта на 10–15 реальных записях планёрок — заметно больше (20%), интеграция с CRM через вебхук — аутентификация, маппинг сотрудников на ID ответственных, обработка ошибок, буферная очередь, тестирование на боевых данных — основная часть работы (50%), обучение команды пользоваться и первые недели поддержки — ещё одна пятая часть (20%). Если CRM кастомная, полей для задач нет вообще или нужна интеграция сразу с двумя системами — время на интеграцию вырастет в полтора-два раза, и окупаемость ниже сдвинется соответственно.

Дальше это около 70 часов высвобожденного времени в месяц на отдел из 15 менеджеров (82 часа минус 11 часов, которые остаются на уточнение и после автопротокола), которые больше никому не нужно объяснять заново — задача уже лежит в системе со сроком и ответственным. Что не считаем эффектом: если высвобожденные часы менеджеров просто перераспределяются на другую работу без роста числа закрытых сделок — это не доход, а перераспределение времени. В деньги эффект превращается только там, где время реально высвобождается, а не тратится на замену той же самой работы.

Окупаемость по грубой прикидке: при ставке подрядчика на интеграцию около 2 000 ₽/час и объёме работ порядка 40 часов разовые вложения в проект составляют около 80 000 ₽. Экономия по времени в пересчёте на стоимость рабочего часа — около 70 000 ₽/мес — отбивает эти вложения примерно за один-два месяца. Дальше это уже чистое высвобождение времени, а не разовая экономия.

Цифры в таблице — грубая прикидка по формуле «часы × ставка», не факт из системы учёта.

Надзор всё равно нужен

Соблазн включить систему и забыть о ней — самый частый способ сломать автоматизацию протоколов; проверять выборочно нужно каждые две-три недели, а не полагаться на то, что скрипт работает вечно без присмотра. Я видел похожую историю с коммуникационными каналами в этой же компании: в одном месяце было оплачено на порядок меньше линий, чем в следующем, — переплата шла за WhatsApp и Telegram на сотрудников, которых физически не было в таком количестве. Никто не следил, что система разрастается сама. Признаю: следить там должен был я, и не следил — это моя недоработка, а не сбой системы. Включённая автоматизация выглядит работающей ровно до первой выборочной проверки, и здесь ошибаются все, я в том числе. Так что если вы сейчас подумали «ну я-то проверю» — я тоже так думал. С автопротоколами планёрок риск тот же: если не проверять выборочно, что задачи реально долетают до исполнителя и срок в CRM совпадает со сроком на записи, система тихо начнёт врать — так же, как врёт CRM при рассинхроне дат, о чём я писал в статье про сдвиг дат в Битрикс24.

Про то, что любая автоматизация без периодической проверки превращается во вторую работу, а не в экономию времени, я подробно писал в статье про надзор за автоматизацией. Протокол планёрки — не исключение: раз в две-три недели стоит выборочно сверить три-четыре записи с тем, что реально попало в задачи. Это 15-20 минут проверки против часов ручного набора текста, которые экономятся каждую неделю.

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

Чек-лист: с чего начать в понедельник

• Выберите одну регулярную планёрку — не самую важную, а самую частую — и начните записывать её постоянно, без исключений.
• Подключите сервис расшифровки речи с таймкодами и разметкой по спикерам: для старта проще всего облачный API (Яндекс SpeechKit или Salute Speech), при большом потоке записей выгоднее Whisper на своём сервере.
• Возьмите промпт из этой статьи, прогоните на одной реальной записи и сверьте результат вручную — сколько задач модель нашла верно, сколько пропустила, где ошиблась с ответственным.
• Настройте передачу результата в CRM или таск-трекер через вебхук с промежуточной очередью и статусами pending/manual_review/sent — не в чат, чат не считается системой хранения задач.
• Назначьте человека, который раз в две-три недели выборочно сверяет 3-4 протокола с записью — это тот самый надзор, без которого автоматизация врёт молча.
• Через месяц посчитайте разницу: сколько времени раньше уходило на переспрашивание задач и сколько уходит сейчас на проверку протокола.

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

Как поставить это на поток, чтобы протокол собирался сам, — в бесплатном курсе для руководителей.

Как это меняет ваши планёрки

У вас изменится не только документооборот. Когда участники знают, что решения записываются с именами и сроками, они формулируют их точнее — и половина расплывчатых договорённостей исчезает сама.

Ваш побочный выигрыш: вы перестаёте быть единственным человеком, который помнит, о чём договорились. Это освобождает вам голову лучше любого тайм-менеджмента.

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

Попробуйте на ближайшей встрече — вам понадобится только запись и десять минут на проверку результата.

Ваш первый протокол машина соберёт уже завтра — попробуйте.

Частые вопросы

Протокол планёрки — это то же самое, что протокол собрания по форме?

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

Чем расшифровка планёрки ИИ отличается от обычной диктофонной записи?

Диктофонная запись — это файл, который никто не переслушает. Расшифровка ИИ превращает голос в текст с таймкодами и делит его на темы, из текста легко вытащить задачи автоматически.

Нужно ли проверять протокол планёрки после ИИ?

Да, минимум выборочно, раз в две-три недели. ИИ иногда путает похожие фамилии и цифры на слух — это тот же принцип надзора, что и в любой другой автоматизации.

Сколько стоит автоматизация протоколов совещаний?

Дороже всего не транскрибация, а интеграция с CRM и таск-трекером. Сама расшифровка на своих серверах обходится примерно в 2 000 ₽ в месяц при ежедневной получасовой планёрке — на порядок дешевле часа менеджера, который иначе тратит время на ручной набор текста.

Какой сервис расшифровки речи выбрать для старта?

Для быстрого старта — облачный API с разметкой по спикерам из коробки, например Яндекс SpeechKit или Salute Speech от Sber, оплата за минуты. Если записей много и важна приватность — Whisper на своём сервере: дороже настроить один раз, дальше расшифровка почти бесплатна.

#автоматизация #ии и нейросети #контроль и надёжность