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

Рабочий цикл не заканчивается на созвоне: результат нужно проверить, разослать и перенести в рабочую систему.
Где начинается работа: сначала расшифровка, затем анализ
Запись, транскрибация и анализ — три разные операции. Некоторые сервисы видеовстреч умеют первые две. Например, Google Meet может создать текстовый транскрипт и сохранить его на Google Drive, а Microsoft Teams строит AI recap на основе уже полученной транскрипции. Но текущий сценарий библиотеки Agent Roi начинается с готового текста: пользователь загружает расшифровку или вставляет её в чат.
Перед анализом быстро проверьте:
- имена и роли участников;
- названия компаний, продуктов и профессиональные термины;
- числа, даты, суммы и проценты;
- отрицания — потерянное «не» полностью меняет смысл;
- метки спикеров и таймкоды, если они доступны;
- места, где запись неразборчива.
Не нужно исправлять каждую запятую. Важнее не позволить ошибке распознавания превратить «не согласовали запуск» в «согласовали запуск». Если сомнительный фрагмент влияет на решение, срок или обязательство, вернитесь к записи.
Запись разговора может регулироваться законом, договором и внутренней политикой компании. Проверьте основание для записи, правила хранения и допустимость загрузки во внешний сервис. В Google Workspace администратор, например, может включить явное согласие участников на запись и транскрибацию. Это не универсальное юридическое правило, а хороший сигнал: доступ к расшифровке нужно продумать до встречи, а не после утечки.
Что передать ИИ до подготовки встречи
Чем яснее контекст, тем меньше модель будет достраивать ситуацию по стереотипам. Минимальный бриф состоит из семи полей:
| Поле | Что написать | Пример |
|---|---|---|
| Тип встречи | Внутренняя, клиентская, продающая, конфликтная, проектная | Разбор задержки релиза с клиентом |
| Ваша роль | За что вы отвечаете и что можете решать | Продакт, могу менять приоритеты, но не бюджет |
| Участники | Роли, интересы и известный контекст | CTO клиента, руководитель проекта, аккаунт |
| Цель | Какой результат нужен к концу | Согласовать новый объём первой версии |
| Предыстория | Что уже произошло и что обещали | Срок сдвинулся на две недели |
| Риски | Где возможны возражения или конфликт | Клиент считает, что его не предупредили |
| Ограничения | Что нельзя обещать или раскрывать | Нельзя называть неподтверждённую дату |
Если какого-то поля нет, попросите модель сначала задать вопросы. Полезная подготовка начинается не с повестки, а с обнаружения неизвестного.
Помоги подготовиться к рабочей встрече. Сначала проведи короткое интервью: задавай по одному вопросу о типе встречи, моей роли, участниках, цели, предыстории, рисках, ограничениях и желаемом решении.
Не приписывай участникам мотивы как факты. Отделяй известное от гипотез. Когда информации достаточно, верни:
1. цель встречи одной фразой;
2. интересы и вероятные вопросы каждой стороны;
3. что мне нужно подготовить;
4. пять ключевых вопросов;
5. возможные возражения и спокойные ответы;
6. желаемый итог и допустимый запасной вариант;
7. проект повестки с таймингом.
Перед финальной версией покажи пробелы и дождись моих уточнений.
Один смысл для разных участников
Одна и та же инициатива звучит по-разному для разных ролей. Руководителю важны решение, риск и ресурс. Разработчику — поведение функции, границы, зависимости и критерий готовности. Маркетологу — аудитория, сообщение, канал и измеримый результат. Клиенту — изменение в его процессе и следующий шаг.
Продакт, который приходит к разработчикам только с фразой «это даст бизнес-ценность», не отвечает на их практические вопросы. ИИ может помочь перевести цель в язык участников, но технические детали всё равно подтверждает команда.
Ниже моя позиция для встречи: [текст].
Участники: [роли].
Для каждой роли перепиши позицию в её рабочей логике:
- что человеку важно понять;
- какие факты и примеры ему нужны;
- какие вопросы он, вероятно, задаст;
- чего в моём объяснении пока не хватает.
Не выдумывай мотивы и не подменяй неизвестные факты. Для разработчиков отдельно укажи функциональное поведение, границы, зависимости и критерии приёмки, которые нужно уточнить у команды.
Как подготовиться к конфликтной или продающей встрече
В сложном разговоре полезно не репетировать «идеальную победу», а разделить факты, интерпретации и варианты решения. Если клиент приходит разбираться с задержкой, задача ИИ — помочь восстановить хронологию, увидеть слабые места вашей позиции и подготовить честные варианты, а не придумать психологический портрет клиента.
Подготовь меня к сложной встрече.
Факты: [проверенная хронология].
Моя ответственность: [что признаём].
Позиция второй стороны: [что она сообщила своими словами].
Ограничения: [что нельзя обещать].
Желаемый результат: [что хотим согласовать].
Составь:
1. нейтральное открытие разговора;
2. факты, которые нужно подтвердить в начале;
3. вопросы, помогающие понять ущерб и ожидания;
4. три варианта решения с условиями и рисками;
5. формулировки, которых лучше избегать;
6. признаки, что решение не принято и нужен следующий шаг.
Не приписывай человеку эмоции или намерения. Не предлагай манипуляции и ложные обещания.
Перед продающей встречей можно добавить внешний ресёрч: отрасль клиента, последние публичные новости, выступления, продукты и изменения на рынке. Perplexity Pro Search, например, выполняет несколько поисков и показывает прямые ссылки на источники. Но его собственная справка рекомендует проверять информацию по этим ссылкам.
Исследуй компанию [название и сайт] перед встречей [цель]. Используй только материалы за период [даты].
Найди:
- официальные новости и изменения продукта;
- публичные выступления руководителей по теме встречи;
- отраслевые события, выставки и регуляторные изменения;
- вероятные приоритеты, обозначенные самой компанией;
- вопросы, которые стоит задать.
Для каждого факта дай прямую ссылку и дату. Отдельно пометь выводы, которые являются гипотезами. Не используй непроверенный факт в рекомендации.
Такой поиск даёт фон, но не заменяет внутреннюю информацию клиента. Фраза из пресс-релиза не доказывает бюджет, срочность или готовность купить.
Промпт для повестки совещания
Повестка должна отвечать не только на вопрос «о чём поговорим», но и на вопрос «какое решение или результат нужен по каждому пункту». Если встреча нужна лишь для одностороннего статуса, сначала проверьте, нельзя ли заменить её письменным обновлением.
Подготовь повестку встречи на [N] минут.
Тип встречи: [тип].
Цель: [результат к концу].
Участники и роли: [список].
Контекст и материалы: [кратко].
Вопросы, которые уже известны: [список].
Ограничения: [что нельзя решить на этой встрече].
Для каждого пункта укажи:
- цель обсуждения;
- ведущего;
- входной материал;
- вопрос или решение;
- тайминг;
- ожидаемый выход.
Добавь пять минут на фиксацию решений, задач и открытых вопросов. Если цель можно достичь асинхронно, предложи формат сообщения вместо встречи и объясни почему.
Atlassian описывает похожую логику в page-led meetings: письменный документ заранее содержит контекст, цель и предлагаемое решение, а после встречи остаётся обновляемым источником договорённостей. ИИ может подготовить такой документ, но участники должны прочитать и подтвердить его сами.
Промпт для протокола короткой встречи
Один запрос подходит, когда расшифровка помещается в чат, тема одна, участники подписаны, а решения сформулированы явно. Просите не пересказ разговора, а рабочие объекты и опору на исходник.
Используй только приложенную расшифровку. Подготовь проект протокола встречи.
Верни:
1. цель и контекст — до трёх предложений;
2. обсуждённые темы;
3. принятые решения с цитатой или таймкодом;
4. задачи в таблице: действие, результат, ответственный, срок, зависимость, источник;
5. открытые вопросы;
6. разногласия и позиции сторон;
7. темы, перенесённые на потом.
Правила:
- не превращай предложение или гипотезу в решение;
- не назначай ответственного и срок, если их не назвали;
- пиши «не назначен», «срок не указан» или «нужно подтвердить»;
- не угадывай имя по голосу или контексту;
- перечисли противоречивые фрагменты отдельно.
Это черновик. Даже Microsoft предупреждает, что AI-резюме встречи может быть неточным или неполным, а автоматически подготовленное письмо нужно отредактировать перед отправкой.
Почему длинную расшифровку лучше разбирать по этапам
Проблема длинного текста не сводится к тому, помещается ли он в контекст модели. Чем больше тем, участников и зависимостей, тем труднее одновременно найти все упоминания, не перепутать статусы и объяснить, откуда взялся вывод. Поэтому промпт для расшифровки встречи должен задавать не только формат ответа, но и порядок проверки промежуточных результатов. OpenAI Docs отмечает, что работа с длинным контекстом может ухудшаться, когда нужно извлечь много элементов и удерживать состояние всего материала.
Поэтому для важной встречи полезнее не один огромный ответ, а последовательность с остановками:

Промежуточные подтверждения не дают красивому итоговому тексту скрыть ошибку в теме, решении или владельце задачи.
- принять весь текст или его части и составить реестр фрагментов;
- выделить темы, не делая выводов;
- получить подтверждение пользователя;
- собрать позиции, решения и разногласия по подтверждённым темам;
- снова получить подтверждение;
- извлечь задачи, сроки и владельцев;
- подготовить итоговые документы только после проверки.
Так пользователь корректирует не готовый красивый протокол, а промежуточные факты.
Системный промпт секретаря совещаний
Системный промпт нужен, если команда регулярно обрабатывает длинные расшифровки и хочет одинаковый порядок работы. Он задаёт поведение помощника во всех следующих сообщениях.
Ты — секретарь рабочих совещаний. Ты работаешь только с текстом, который передал пользователь: расшифровкой, заметками, повесткой и справочником участников. Ты не записываешь встречу, не расшифровываешь аудио, не подключаешься к календарю и не отправляешь сообщения.
Цель — подготовить проверяемый протокол, задачи и follow-up без выдуманных договорённостей.
Постоянные правила:
1. Отделяй дословный факт, интерпретацию и гипотезу.
2. Не превращай обсуждение, пожелание или вариант в принятое решение.
3. Не назначай ответственного, срок, сумму или обязательство, если они не названы явно.
4. Для спорного пункта приводи короткую цитату или таймкод. Если их нет, указывай номер смыслового блока.
5. Сохраняй пометки «не назначен», «срок не указан», «неразборчиво», «нужно подтвердить».
6. Не оценивай людей и не приписывай им мотивы.
7. Не переходи к следующему этапу без явного подтверждения пользователя.
Рабочий процесс:
Этап 0. Запроси цель обработки, тип встречи, список участников, желаемые документы и правила конфиденциальности.
Этап 1. Прими расшифровку целиком или частями. Для каждой части верни только подтверждение приёма, диапазон таймкодов и 3–7 нейтральных меток содержания. Не составляй итог.
Этап 2. После команды «текст передан полностью» создай карту тем: тема, участники, диапазон фрагментов, статус обсуждения. Остановись и запроси подтверждение.
Этап 3. По подтверждённой карте выдели позиции сторон, принятые решения, отклонённые варианты, разногласия и открытые вопросы. Покажи источники. Остановись и запроси подтверждение.
Этап 4. Извлеки задачи в таблицу: действие, ожидаемый результат, ответственный, срок, зависимости, источник, статус подтверждения. Остановись и запроси подтверждение.
Этап 5. После подтверждения подготовь по запросу: официальный протокол, короткое сообщение команде, follow-up клиенту, список задач для переноса в трекер и черновик следующей повестки.
Если пользователь исправляет факт, сохрани исправление как подтверждённую правку и укажи, какие итоговые блоки оно меняет.
Пример первого сообщения
Встреча: еженедельный проектный статус с клиентом.
Цель обработки: официальный протокол, сообщение в командный чат и задачи.
Участники: Анна — клиентский руководитель проекта; Илья — наш продакт; Мария — разработка.
Особые правила: не публиковать финансовые детали в сообщении для общего чата.
Расшифровку передам четырьмя частями. Пока не напишу «текст передан полностью», только регистрируй части по правилам этапа 1.
Если части приходится готовить вручную, режьте их по таймкодам или смысловым паузам, а не посередине реплики. Нумеруйте их как Часть 1 из 4 и сохраняйте перекрытие в одну-две реплики на границе. После последней части попросите модель перечислить все диапазоны, которые она получила. Это помогает заметить пропуск, но не гарантирует, что каждая деталь удержалась: ключевые решения всё равно сверяют с исходником.
Что сделать после встречи
Протокол нужен не всем в одинаковом виде. Руководителю важны решения и риски, исполнителю — конкретная задача, клиенту — подтверждённый следующий шаг. Из одного проверенного реестра можно подготовить несколько сообщений.
На основе только подтверждённого протокола подготовь четыре результата:
1. Follow-up клиенту: до 180 слов, цель встречи, согласованные решения, действия обеих сторон, сроки и следующий контакт.
2. Сообщение команде: до 900 знаков, что решили, что изменилось, кто что делает и какие есть блокеры.
3. Реестр задач: действие, ожидаемый результат, один владелец, срок, зависимость, ссылка на пункт протокола.
4. Черновик следующей повестки: незакрытые вопросы и задачи, которые нужно проверить.
Не добавляй новые обещания. Если пункт не подтверждён, вынеси его в раздел «Требует согласования», а не в основной текст.
Atlassian рекомендует делать задачу достаточно конкретной для начала работы: указать одного владельца, действие, объём, ожидаемый результат, срок и источник. Чат подготовит такую строку, но в Agent Roi не создаст карточку в Jira, Битрикс24 или другом трекере и не отправит письмо. Сотрудник переносит утверждённый текст вручную.
Что проверить вручную
Перед рассылкой пройдите короткий аудит:
- все ли участники и роли указаны правильно;
- есть ли источник у каждого решения и обязательства;
- не перепутаны ли «предложили», «обсудили», «согласовали» и «отложили»;
- назван ли ответственный явно;
- относится ли срок к этой задаче, а не к соседней теме;
- отражены ли разногласия и условия согласия;
- не попали ли конфиденциальные детали в общий follow-up;
- подходит ли тон адресату;
- перенесены ли утверждённые задачи в рабочую систему;
- определён ли человек, который отвечает за финальную версию протокола.
Системный промпт проверяйте не на одном удобном примере. Дайте ему четыре теста: короткую встречу с ясными решениями, длинную расшифровку, разговор без принятых решений и конфликтный текст с противоречивыми сроками. Хороший помощник не только красиво пишет, но и останавливается там, где данных недостаточно.
Связанные промпты и первый пилот
Общие правила постоянной инструкции разобраны в статье «Системные промпты: как создать и проверить», а подготовку деловых документов можно связать с гайдом «ИИ для работы с документами и таблицами».
Для первого пилота возьмите одну регулярную внутреннюю встречу без чувствительных данных. Подготовьте повестку через интервью-промпт, затем загрузите проверенную расшифровку и пройдите системный сценарий до реестра задач. Сравните результат с ручным протоколом по пяти критериям: пропущенные решения, ложные решения, владельцы, сроки и время на проверку. Только после этого переносите шаблон на клиентские и конфликтные встречи.
Источники проверены 16 сентября 2026 года: OpenAI Docs — работа с длинным контекстом и структурой промпта, Microsoft Support — Recap в Teams, Google Meet Help — транскрипты, Perplexity Help Center — Pro Search, Atlassian — требования к action items и page-led meetings.
Больше материалов по теме — в разделе «Промпты».