Как сделать ИИ-агента для встреч и follow-up

Что получится в результате

Соберем рабочего ИИ-агента, который помогает до и после встречи: берет событие из календаря, собирает контекст из CRM, готовит короткую повестку, принимает transcript или заметки, выделяет решения, задачи, владельцев, дедлайны, готовит follow-up, создает draft-обновления для CRM и отправляет спорные пункты на ручную проверку.

Первая версия будет делать так:

1. встреча попадает в `meeting_queue`;
2. данные календаря сохраняются в `meeting_metadata`;
3. участники связываются с CRM через `participant_map`;
4. контекст клиента или проекта пишется в `crm_context`;
5. шаблон повестки берется из `agenda_templates`;
6. transcript или ручные заметки сохраняются в `transcript_log`;
7. агент делает структурированный разбор в `summary_results`;
8. решения сохраняются в `decisions_log`;
9. задачи попадают в `action_items`;
10. письмо после встречи создается в `followup_drafts`;
11. CRM-обновления сохраняются в `crm_updates`;
12. задачи для команды пишутся в `task_queue`;
13. чувствительные действия попадают в `approval_queue`;
14. отправленные сообщения пишутся в `sent_messages_log`;
15. все действия фиксируются в `audit_log`;
16. ошибки попадают в `error_log`.

В первой версии агент не отправляет клиенту письма без проверки, не обещает сроки, не меняет сумму сделки, не создает юридически значимые договоренности и не редактирует CRM без approval. Он готовит черновики и помогает ничего не забыть.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для управляющих таблиц.
• Google Calendar API или Microsoft Graph Calendar API.
• Zoom API, Google Meet transcript, Teams transcript или ручные заметки.
• CRM: HubSpot, amoCRM, Bitrix24, Pipedrive или другая система.
• Канал для approval: Telegram, Slack, email или задача в CRM.
• API-ключ LLM-провайдера.
• 10-20 прошлых встреч для теста.
• Список правил: что можно отправлять автоматически, а что только после согласования.

Шаг 1. Выберите один тип встречи

Не начинайте со всех созвонов компании. У sales demo, onboarding, QBR и внутренней планерки разные итоги.

Для первой версии выберите один сценарий:

1. sales discovery;
2. демо продукта;
3. onboarding клиента;
4. customer success check-in;
5. проектная встреча;
6. встреча после инцидента;
7. внутренний weekly sync;
8. интервью с пользователем.

Самый удобный старт - встречи, после которых регулярно теряются задачи, follow-up и обновления CRM.

Проверка: вы можете описать одну встречу одной фразой, например: `sales discovery для B2B-заявок после демо`.

Шаг 2. Определите финальный результат

Запишите, что агент должен выдать после встречи.

Для sales discovery результат такой:

summary
client_goal
pain_points
current_process
budget_signal
timeline
decision_makers
risks
decisions
action_items
client_followup_draft
crm_update_draft
next_meeting_suggestion

Для проектной встречи результат другой:

summary
decisions
open_questions
blockers
action_items
owners
deadlines
risks
status_update
internal_followup_draft

Проверка: у вас есть список полей, а не абстрактное “сделать summary”.

Шаг 3. Создайте таблицу проекта

Создайте Google Sheet:

Meeting follow-up agent

Добавьте листы:

settings
meeting_queue
meeting_metadata
participant_map
crm_context
agenda_templates
pre_meeting_briefs
transcript_log
summary_results
decisions_log
action_items
followup_drafts
crm_updates
task_queue
approval_queue
sent_messages_log
audit_log
weekly_report
error_log

Проверка: n8n может читать и писать в каждый лист.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните базовые настройки:

timezone | Europe/Moscow | основная таймзона встреч
default_language | ru | язык summary и follow-up
auto_send_external_followup | false | внешние письма только после approval
auto_create_internal_tasks | true | внутренние задачи можно создавать после проверки правил
crm_update_mode | draft | CRM обновляется через черновик
max_summary_length | 1200 | максимум символов в summary
default_followup_tone | calm_business | стиль письма
approval_channel | telegram | куда отправлять согласование
recording_retention_days | 30 | срок хранения ссылки на запись

Проверка: все опасные действия по умолчанию выключены.

Шаг 5. Настройте meeting_queue

В `meeting_queue` агент получает встречи на обработку.

Колонки:

meeting_id
source
calendar_event_id
crm_deal_id
crm_contact_id
meeting_type
title
start_at
end_at
owner_email
status
priority
created_at
updated_at

Статусы:

new
preparing
waiting_transcript
processing
waiting_approval
done
error
skip

Пример строки:

MTG-1001 | google_calendar | evt_91 | deal_482 | contact_77 | sales_discovery | Демо с ООО Альфа | 2026-05-25 14:00 | 2026-05-25 15:00 | sales@company.ru | new | high

Проверка: одна встреча равна одной строке в очереди.

Шаг 6. Подключите календарь

В n8n создайте workflow:

Meeting intake

Минимальная цепочка:

1. Cron Trigger каждые 30 минут;
2. Google Calendar или Microsoft Outlook node;
3. фильтр встреч за последние 24 часа и следующие 48 часов;
4. Function node для нормализации полей;
5. Google Sheets node для записи в `meeting_queue`;
6. Google Sheets node для записи деталей в `meeting_metadata`.

В `meeting_metadata` добавьте колонки:

meeting_id
calendar_event_id
title
description
location
meeting_url
organizer_email
attendees_json
start_at
end_at
timezone
is_external
recording_expected
created_at

Проверка: тестовая встреча из календаря появляется в `meeting_queue` и `meeting_metadata`.

Шаг 7. Сделайте дедупликацию встреч

Перед записью в `meeting_queue` проверьте:

1. есть ли уже `calendar_event_id`;
2. совпадает ли `start_at`;
3. совпадает ли `owner_email`;
4. не стоит ли статус `skip`;
5. не была ли встреча уже обработана.

Правило:

если calendar_event_id уже есть, обновить meeting_metadata, но не создавать новую строку meeting_queue

Проверка: повторный запуск workflow не создает дубль встречи.

Шаг 8. Свяжите участников с CRM

В `participant_map` добавьте колонки:

meeting_id
email
name
company
role
is_internal
crm_contact_id
crm_company_id
crm_deal_id
confidence
match_reason
created_at

Логика поиска:

1. внутренние домены помечаются как `is_internal = true`;
2. внешние email ищутся в CRM contacts;
3. если контакт найден, подтягивается company и active deal;
4. если найдено несколько сделок, ставится `confidence = low`;
5. низкая уверенность отправляется в review.

Проверка: агент понимает, с каким клиентом, сделкой или проектом связана встреча.

Шаг 9. Соберите CRM-контекст

В `crm_context` добавьте колонки:

meeting_id
crm_system
crm_deal_id
crm_contact_id
company_name
deal_stage
deal_amount
last_activity_at
last_notes
open_tasks
open_tickets
known_risks
context_text
created_at

Контекст должен быть коротким. Не тяните всю CRM-карточку.

Хороший `context_text`:

Клиент: ООО Альфа. Стадия: демо проведено. Интерес: автоматизация поддержки. Риск: нужен запуск до конца месяца. Открытая задача: отправить пример интеграции с Bitrix24.

Проверка: перед встречей агент видит только нужные факты.

Шаг 10. Создайте шаблоны повестки

В `agenda_templates` добавьте колонки:

template_id
meeting_type
goal
questions_json
required_outputs_json
forbidden_topics_json
is_active
updated_at

Пример для sales discovery:

{
  "questions": [
    "Как сейчас устроен процесс?",
    "Где теряется больше всего времени?",
    "Какие системы уже используются?",
    "Какие ограничения по безопасности есть?",
    "Какой следующий шаг будет полезен после встречи?"
  ],
  "required_outputs": [
    "pain_points",
    "decision_makers",
    "timeline",
    "next_step"
  ],
  "forbidden_topics": [
    "обещать цену без менеджера",
    "подтверждать сроки внедрения без команды"
  ]
}

Проверка: для каждого `meeting_type` есть один активный шаблон.

Шаг 11. Сгенерируйте pre-meeting brief

Создайте workflow:

Pre-meeting brief

Цепочка:

1. взять встречи со статусом `new`;
2. загрузить `meeting_metadata`;
3. загрузить `participant_map`;
4. загрузить `crm_context`;
5. загрузить `agenda_templates`;
6. вызвать LLM;
7. записать результат в `pre_meeting_briefs`;
8. перевести встречу в `waiting_transcript`.

В `pre_meeting_briefs` добавьте колонки:

meeting_id
brief
agenda
questions
risks
do_not_say
owner_email
created_at

Prompt для brief:

Ты готовишь менеджера к встрече.
Используй только переданный контекст.
Не выдумывай факты.
Верни JSON:
{
  "brief": "коротко до 700 символов",
  "agenda": ["пункт 1", "пункт 2", "пункт 3"],
  "questions": ["вопрос 1", "вопрос 2"],
  "risks": ["риск 1"],
  "do_not_say": ["что нельзя обещать"]
}

Проверка: за 15-30 минут до встречи менеджер получает короткую подготовку.

Шаг 12. Получите transcript или заметки

Для первой версии можно использовать один из вариантов:

1. Zoom cloud recording transcript;
2. Google Meet transcript из Drive;
3. Microsoft Teams transcript;
4. ручные заметки организатора;
5. текст из call recorder;
6. summary от секретаря встречи.

В `transcript_log` добавьте колонки:

meeting_id
source
recording_url
transcript_text
notes_text
language
quality_status
consent_status
created_at

Статусы качества:

good
partial
bad
missing

Проверка: если transcript плохой или отсутствует, агент не делает жестких выводов и отправляет встречу в review.

Шаг 13. Добавьте consent check

Не обрабатывайте записи без понятного основания.

В n8n перед анализом добавьте IF node:

если consent_status != approved, перевести meeting_queue.status в waiting_approval

Для внутренних тестов можно использовать ручное поле:

approved
not_required
unknown
rejected

Правило:

unknown и rejected не идут в автоматический анализ

Проверка: встреча без разрешения не попадает в LLM.

Шаг 14. Нормализуйте transcript

Перед LLM уберите технический шум:

1. timestamps оставьте только при необходимости;
2. повторяющиеся системные сообщения удалите;
3. имена говорящих приведите к одному формату;
4. длинные паузы замените на `[pause]`;
5. фразы “неразборчиво” оставьте как маркер;
6. пустой transcript не отправляйте в модель.

Пример нормального блока:

Manager: Давайте зафиксируем следующий шаг.
Client: Нам нужен пример интеграции с Bitrix24 до пятницы.
Manager: Я отправлю пример и предложу дату технического созвона.

Проверка: LLM получает читаемый текст, а не сырую мешанину из записи.

Шаг 15. Сделайте основной prompt разбора встречи

Prompt:

Ты анализируешь встречу.
Используй только transcript, notes и CRM context.
Не выдумывай факты.
Если факта нет, пиши null.
Разделяй:
- подтвержденные решения;
- предположения;
- задачи;
- спорные пункты;
- внутренние заметки;
- текст, который можно отправить клиенту.

Верни только JSON:
{
  "summary": "до 1200 символов",
  "decisions": [
    {
      "decision": "что решили",
      "evidence": "короткая цитата или фрагмент",
      "confidence": "high|medium|low"
    }
  ],
  "action_items": [
    {
      "task": "что сделать",
      "owner": "email или null",
      "deadline": "YYYY-MM-DD или null",
      "source": "цитата",
      "confidence": "high|medium|low"
    }
  ],
  "open_questions": ["вопрос"],
  "risks": ["риск"],
  "client_followup": "черновик письма клиенту",
  "internal_notes": "заметки только для команды",
  "crm_update": {
    "deal_stage_change": null,
    "next_step": "следующий шаг",
    "note": "заметка в CRM"
  },
  "needs_review": true
}

Проверка: модель возвращает валидный JSON без Markdown.

Шаг 16. Запишите summary_results

В `summary_results` добавьте колонки:

meeting_id
summary
open_questions
risks
internal_notes
client_safe_summary
needs_review
model
prompt_version
created_at

Правило:

client_safe_summary не должен содержать internal_notes, риски сделки, оценки клиента, маржу, внутренние сомнения и технические токены

Проверка: внутренние заметки и внешний follow-up разделены.

Шаг 17. Запишите decisions_log

В `decisions_log` добавьте колонки:

decision_id
meeting_id
decision_text
evidence
confidence
owner_email
status
created_at

Статусы:

confirmed
needs_review
rejected

Правило:

если confidence != high, решение не считается подтвержденным

Проверка: спорные договоренности не превращаются в факт.

Шаг 18. Запишите action_items

В `action_items` добавьте колонки:

task_id
meeting_id
task_text
owner_email
deadline
source_quote
confidence
task_system
external_task_id
status
created_at

Статусы:

draft
ready
created
needs_review
cancelled

Правила:

1. задача без владельца идет в `needs_review`;
2. задача без дедлайна получает мягкий срок по умолчанию;
3. задача с `confidence = low` не создается автоматически;
4. клиентская задача не назначается внутреннему сотруднику без проверки;
5. дубли задач объединяются.

Проверка: после встречи есть список задач, а не общий текст “надо сделать”.

Шаг 19. Создайте task_queue

`task_queue` нужна, чтобы не создавать задачи напрямую из LLM-ответа.

Колонки:

queue_id
task_id
task_system
task_payload_json
approval_required
status
created_at
processed_at
error_message

Пример `task_payload_json`:

{
  "title": "Отправить пример интеграции с Bitrix24",
  "assignee": "sales@company.ru",
  "due_date": "2026-05-29",
  "description": "По итогам встречи MTG-1001 клиент попросил пример интеграции.",
  "source": "meeting_followup_agent"
}

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

Шаг 20. Подготовьте follow-up draft

В `followup_drafts` добавьте колонки:

draft_id
meeting_id
recipient_emails
subject
body
tone
contains_commitment
contains_price
contains_deadline
approval_required
status
created_at

Prompt для письма:

Составь follow-up после встречи.
Пиши коротко и по делу.
Не добавляй новых обещаний.
Не называй цены, сроки и обязательства, если они не подтверждены.
Структура:
1. благодарность;
2. что обсудили;
3. что договорились;
4. следующие шаги;
5. кто что делает.

Проверка: письмо можно отправить после быстрой человеческой правки.

Шаг 21. Добавьте проверку опасных обещаний

Перед approval проверьте `followup_drafts.body`.

Флаги:

contains_commitment
contains_price
contains_deadline
contains_legal_terms
contains_discount
contains_security_claim

Простые правила:

1. есть цена или скидка - approval обязателен;
2. есть дата запуска - approval обязателен;
3. есть “гарантируем”, “обязуемся”, “точно успеем” - approval обязателен;
4. есть безопасность, сертификаты или персональные данные - approval обязателен;
5. внешний follow-up всегда approval в первой версии.

Проверка: агент не отправляет опасные обещания клиенту.

Шаг 22. Сформируйте CRM update draft

В `crm_updates` добавьте колонки:

crm_update_id
meeting_id
crm_system
crm_deal_id
crm_contact_id
update_type
payload_json
approval_required
status
created_at
processed_at

Типы обновлений:

note
next_step
task
stage_change_request
risk_flag
contact_field_request

Пример:

{
  "note": "Встреча: клиент хочет пример интеграции с Bitrix24. Следующий шаг: отправить пример до пятницы и предложить технический созвон.",
  "next_step": "Отправить пример интеграции",
  "risk": "клиенту нужен запуск до конца месяца"
}

Проверка: CRM не обновляется напрямую, пока менеджер не подтвердил черновик.

Шаг 23. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
meeting_id
object_type
object_id
reason
preview
approver_email
status
decision_comment
created_at
decided_at

`object_type`:

followup_draft
crm_update
task
decision
low_confidence_summary

Статусы:

pending
approved
rejected
needs_edit
expired

Проверка: человек видит, что именно нужно подтвердить и почему.

Шаг 24. Сделайте Telegram approval

В n8n добавьте ветку:

1. взять новые строки `approval_queue` со статусом `pending`;
2. отправить в Telegram краткий preview;
3. добавить кнопки `Approve`, `Reject`, `Needs edit`;
4. по нажатию обновить `approval_queue.status`;
5. записать решение в `audit_log`.

Сообщение:

Нужно согласовать follow-up по встрече MTG-1001
Причина: внешний клиент + дедлайн

Тема: Итоги встречи и следующий шаг
Preview: Спасибо за встречу. Отправим пример интеграции...

[Approve] [Needs edit] [Reject]

Проверка: approve меняет статус объекта, но не теряет историю решения.

Шаг 25. Отправляйте follow-up только после approval

Для первой версии настройте правило:

если followup_drafts.approval_required = true и approval_queue.status != approved, письмо не отправлять

После approval:

1. отправить письмо через Gmail API, Outlook API или CRM email;
2. записать факт отправки в `sent_messages_log`;
3. обновить `followup_drafts.status = sent`;
4. записать действие в `audit_log`.

В `sent_messages_log` добавьте колонки:

message_id
meeting_id
draft_id
channel
recipient_emails
subject
sent_by
sent_at
external_message_id

Проверка: каждое отправленное письмо можно найти по meeting_id.

Шаг 26. Создайте задачи во внешней системе

Подключите одну систему задач:

1. HubSpot tasks;
2. Bitrix24 tasks;
3. amoCRM tasks;
4. Asana;
5. Jira;
6. ClickUp;
7. Todoist.

Для MVP достаточно одной.

Правило:

создавать автоматически только internal tasks с confidence = high и без опасных флагов

Проверка: после approve или безопасного правила задача появляется во внешней системе, а `external_task_id` записывается в `action_items`.

Шаг 27. Настройте audit_log

В `audit_log` добавьте колонки:

audit_id
meeting_id
actor
action
object_type
object_id
before_json
after_json
created_at

Логируйте:

1. создание brief;
2. анализ transcript;
3. создание summary;
4. создание action item;
5. создание follow-up draft;
6. отправку approval;
7. решение approval;
8. отправку письма;
9. обновление CRM;
10. ошибку внешнего API.

Проверка: можно восстановить, кто и когда подтвердил follow-up.

Шаг 28. Настройте error_log

В `error_log` добавьте колонки:

error_id
meeting_id
workflow_name
node_name
error_type
error_message
payload_snapshot
status
owner_email
created_at

Типы ошибок:

calendar_api_failed
crm_lookup_failed
transcript_missing
consent_missing
llm_invalid_json
approval_timeout
email_send_failed
task_create_failed
crm_update_failed

Проверка: сбой не исчезает молча, а получает владельца.

Шаг 29. Соберите weekly_report

В `weekly_report` добавьте колонки:

week_start
meetings_processed
followups_created
followups_sent
tasks_created
crm_updates_created
approval_pending
errors_count
avg_processing_time_minutes
top_error_types
created_at

Минимальные метрики:

1. сколько встреч обработано;
2. сколько follow-up создано;
3. сколько задач создано;
4. сколько пунктов ушло на approval;
5. сколько ошибок возникло;
6. где чаще всего ломается процесс.

Проверка: раз в неделю видно, экономит ли агент время.

Шаг 30. Протестируйте на 10 встречах

Возьмите 10 прошлых встреч одного типа.

Проверьте вручную:

1. summary не выдумывает факты;
2. action items имеют владельца;
3. дедлайны не придуманы без основания;
4. client follow-up не содержит внутренних заметок;
5. CRM update не меняет стадию без approval;
6. спорные решения попадают в review;
7. письма не отправляются без подтверждения;
8. дубли задач не создаются;
9. плохой transcript не проходит как точный;
10. ошибки попадают в `error_log`.

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

Минимальная проверка результата

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

• встреча из календаря попадает в `meeting_queue`;
• участники связаны с CRM через `participant_map`;
• краткий контекст есть в `crm_context`;
• agenda создается до встречи;
• transcript или notes пишутся в `transcript_log`;
• summary пишется в `summary_results`;
• решения пишутся в `decisions_log`;
• задачи пишутся в `action_items`;
• follow-up draft пишется в `followup_drafts`;
• CRM draft пишется в `crm_updates`;
• опасные действия уходят в `approval_queue`;
• отправленные письма пишутся в `sent_messages_log`;
• все действия есть в `audit_log`;
• ошибки есть в `error_log`;
• weekly report показывает пользу.

Перед запуском на живых встречах пройдите чек-лист:

1. Создайте тестовую встречу в календаре.
2. Добавьте тестового участника с CRM-карточкой.
3. Загрузите короткие заметки вместо записи.
4. Запустите workflow анализа.
5. Проверьте `summary_results`, `action_items` и `followup_drafts`.
6. Отклоните один follow-up через approval.
7. Одобрите один follow-up через approval.
8. Проверьте `sent_messages_log` и `audit_log`.

Что нельзя автоматизировать в первой версии

• отправку внешнего follow-up без approval;
• обещания по цене, срокам, договору и безопасности;
• изменение стадии сделки без менеджера;
• отправку клиенту внутренних рисков и оценок;
• обработку записи без согласия;
• удаление спорных пунктов без лога;
• создание задач с низкой уверенностью;
• принятие юридически значимых договоренностей;
• массовую обработку всех встреч компании без правил доступа.

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

Можно ли агенту самому отправлять follow-up клиенту?

В первой версии лучше нет. Пусть агент готовит письмо, а менеджер подтверждает отправку. Автоотправку можно включать позже для простых внутренних встреч или типовых follow-up без цены, сроков и обязательств.

Нужна ли запись каждой встречи?

Нет. Для части встреч достаточно ручных заметок или короткого transcript. Запись полезна для точности, но требует согласия участников, понятных правил хранения и ограничения доступа.

Что важнее: полный transcript или action items?

Action items важнее. Transcript нужен как источник, но результат появляется только тогда, когда после встречи есть задачи, владельцы, дедлайны и следующий шаг.

Как не отправить клиенту внутренние заметки?

Храните `internal_notes` отдельно от `client_followup`. В prompt явно запрещайте переносить внутренние риски, маржу, сомнения, оценки клиента и технические детали во внешний текст.

Что делать, если агент не уверен в решении?

Ставить `confidence = low`, добавлять цитату из transcript и отправлять пункт в `approval_queue`. Неуверенная договоренность не должна автоматически попадать в письмо, CRM или задачу.