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