Протокол встречи не равен выполненной работе
После встречи у компании обычно остаётся несколько источников правды: запись звонка, заметки менеджера, письмо с итогами и задачи в CRM. Между ними появляются расхождения. Владелец задачи указан только в чате, срок потерялся в расшифровке, а договорённость, которую клиент понял как обещание, никто не включил в контроль.
AI-агент может сократить этот разрыв, если его цель — не «написать красивый протокол», а довести проверенное решение до наблюдаемого состояния. Агент извлекает факты, предлагает структуру результата, показывает неопределённости человеку, создаёт задачи только после проверки и затем перечитывает CRM. Так автоматизируется процесс, а не отдельный текст.
Для владельца бизнеса полезный вопрос звучит так: можно ли через неделю доказать, кто что должен сделать, к какому сроку, на основании какой договорённости и что произошло после записи? Если нельзя, генерация протокола не решила проблему.
Сначала опишите границы процесса
У рабочего сценария должны быть начало и стоп-условие. Начало — завершённая встреча с устойчивым идентификатором: meeting_id, участники, время, источник записи и связанная сделка. Стоп-условие — отсутствие подтверждённого владельца, срока или существенного решения. В таком случае агент формирует вопрос на уточнение, но не записывает догадку в CRM.
Минимальный результат встречи можно представить так:
| Поле | Что проверяет агент | Если проверки нет |
|---|---|---|
| Решение | Что именно согласовано | В протоколе остаётся мнение участника |
| Владелец | Кто отвечает за следующий шаг | Задача «для команды» без исполнителя |
| Срок | Дата и часовой пояс | Просрочка обнаруживается слишком поздно |
| Доказательство | Фрагмент заметки или записи | Нельзя быстро разобрать спор |
| Разрешение | Можно ли писать и уведомлять | Черновик превращается в обещание |
Ключевой принцип — отделять извлечение от действия. Модель может предложить owner, due_at и next_step, но эти поля ещё не являются разрешением на запись. Их нужно сопоставить с участниками встречи, правилами компании и существующими объектами CRM.
Архитектура из пяти переходов
В 4BOS такой сценарий удобно строить как короткий автомат состояний:
flowchart LR
A[Запись встречи] --> B[Извлечение фактов]
B --> C[Проверка и вопросы]
C --> D[Согласованный план]
D --> E[CRM и уведомление]
E --> F[Read-back и контроль]
C --> X[Стоп: ручное уточнение]
F --> X1. Приём и нормализация
Агент принимает только завершённое событие. Он проверяет подпись источника, версию схемы и наличие связанной сделки. Повторная доставка с тем же meeting_id должна привести к чтению уже созданного результата, а не к новой пачке задач. Исходную расшифровку полезно сохранять отдельно: она является доказательством, но не должна бесконтрольно попадать в промпт целиком.
2. Извлечение с указанием уверенности
Для каждого пункта агент возвращает не только текст, но и тип: решение, вопрос, обязательство или контекст. Рядом хранится ссылка на источник и причина, по которой выбран владелец. Фраза «вернёмся к этому позже» не должна автоматически стать задачей со сроком. Если дата относительная — «к пятнице» — система нормализует её только при известном часовом поясе и дате встречи.
3. Независимая проверка
Проверяющий слой сравнивает предложенный план с политикой. Владелец должен быть участником или разрешённым исполнителем, срок — не раньше текущего состояния сделки без объяснения, а чувствительное обещание — пройти ручное согласование. Несовпадение не исправляется новой генерацией до бесконечности: результат переводится в REVIEW с конкретным вопросом.
4. Безопасная запись
Перед изменением создаётся diff: какие задачи добавить, какие поля сделки обновить, какие уведомления подготовить. У каждой операции есть correlation_id и идемпотентный ключ. Сначала сохраняется снимок прежнего состояния, затем выполняется узкий вызов CRM. Агент не должен одновременно менять этап сделки, бюджет и владельца, если в согласованном плане есть только следующий шаг.
5. Read-back и наблюдение
Успешный ответ API не доказывает, что запись сохранилась. Агент перечитывает задачу и сравнивает фактические поля с ожидаемым diff. Если сеть оборвалась после запроса, состояние становится AMBIGUOUS: система сначала ищет объект по идемпотентному ключу и только после однозначного отрицательного результата рассматривает повтор.
Где оставить человека
Автономность должна зависеть от риска действия. Создать внутренний черновик с низким лимитом можно без отдельного подтверждения, но отправить клиенту новое обязательство или изменить коммерческие условия — только после просмотра ответственным. Человеку нужно показывать короткую карточку: факт, предложенное действие, источник, конфликт и последствия согласования.
Плохое подтверждение выглядит как кнопка «ОК» под длинной расшифровкой. Хорошее содержит конкретный diff: «создать задачу Анне до 12 сентября, не менять этап сделки, подготовить письмо без отправки». Тогда решение занимает секунды и оставляет ясное доказательство.
Как измерить эффект без выдуманных результатов
До запуска зафиксируйте базовую линию хотя бы на двух неделях: время от встречи до появления задачи, долю задач без владельца, число дублей и время разбора спорных договорённостей. После пилота сравнивайте те же показатели на одном типе встреч. Не приписывайте системе рост продаж, если измеряли только скорость записи.
Практичный критерий расширения — стабильный read-back и отсутствие необъяснимых дублей в ограниченном потоке. Если агент экономит минуты на протоколе, но создаёт часы на исправления, его нужно остановить и разобрать контрольную точку, на которой возникла ошибка.
Что можно сделать за неделю
В первый день выберите один тип встречи и опишите обязательные поля. Затем подключите источник событий и извлечение в режиме черновика. На третий день добавьте проверку владельца, срока и доказательства. После этого включите одну CRM-запись с идемпотентным ключом и read-back. В конце недели проиграйте повторную доставку, неоднозначную дату, конфликт владельцев и тайм-аут после записи.
Итоговая ценность такого AI-агента не в том, что он быстрее печатает резюме. Он связывает разговор, решение, полномочие и фактическое состояние системы. Если вашей команде нужно выбрать один процесс для такого пилота, обсудите его с 4BOS через контакты студии: вместе можно определить границу автоматизации, доказательства результата и безопасное стоп-условие.
Частые вопросы
Можно ли автоматически создавать задачи из любой встречи?
Нет. Нужны устойчивый идентификатор встречи, проверенный владелец и однозначный срок. Иначе результат должен остаться черновиком или перейти на уточнение.
Что делать, если CRM вернула тайм-аут?
Не повторять запись вслепую. Сначала проверить результат по идемпотентному ключу и пометить операцию как AMBIGUOUS, пока состояние не станет однозначным.
Зачем хранить фрагмент источника?
Он позволяет быстро проверить, не превратил ли агент вопрос в обязательство и не перепутал ли участника. Источник не заменяет человеческое решение, но делает разбор воспроизводимым.