Как сделать ИИ-агента для автогенерации отчетов руководству

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

Соберем ИИ-агента, который раз в неделю готовит короткий управленческий отчет по продажам, задачам и рискам.

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

1. n8n запускается по расписанию каждый понедельник утром;
2. агент читает таблицы с KPI, CRM-выгрузку и список просроченных задач;
3. LLM превращает цифры в executive summary;
4. результат записывается в Google Sheets как черновик со статусом `draft`;
5. руководитель или аналитик проверяет текст и ставит `approved`;
6. второй workflow отправляет approved-отчет в Telegram или email;
7. в журнал записываются статус, дата отправки, получатели и ошибка, если отправка не прошла.

В первой версии агент не отправляет отчет без проверки, не меняет исходные данные и не придумывает цифры. Он только собирает, объясняет и готовит черновик.

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

• n8n Cloud или self-hosted n8n.
• Google Sheets с доступом на чтение и запись.
• CRM-выгрузка в Google Sheets или CSV, например из AmoCRM, Bitrix24, HubSpot или 1С.
• Таблица задач, например из Trello, Asana, Битрикс24, Jira или обычный Google Sheets.
• API-ключ LLM-провайдера.
• Telegram-бот или почтовый SMTP-ящик для отправки отчета.
• Список получателей отчета.
• 1-2 часа на первую настройку.

Шаг 1. Определите формат отчета

Создайте простой формат, который руководитель реально прочитает за 3-5 минут.

Для первой версии используйте структуру:

1. `Итог недели` - 3-5 предложений;
2. `Ключевые цифры` - выручка, лиды, сделки, конверсия, просрочки;
3. `Что улучшилось` - 2-4 пункта;
4. `Что ухудшилось` - 2-4 пункта;
5. `Риски` - конкретные проблемы с владельцем;
6. `Действия на неделю` - список задач с ответственными.

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

Шаг 2. Создайте таблицу с KPI

В Google Sheets создайте файл:

Executive AI report

Добавьте лист `kpi_weekly`.

Колонки:

week_start
week_end
revenue_plan
revenue_fact
new_leads
qualified_leads
deals_won
deals_lost
pipeline_value
avg_response_minutes
overdue_tasks
support_tickets
churn_risk_accounts
comment

Добавьте тестовую строку:

week_start: 2026-05-18
week_end: 2026-05-24
revenue_plan: 1200000
revenue_fact: 980000
new_leads: 184
qualified_leads: 73
deals_won: 18
deals_lost: 11
pipeline_value: 3400000
avg_response_minutes: 42
overdue_tasks: 17
support_tickets: 31
churn_risk_accounts: 4
comment: просела конверсия из новых лидов в квалифицированные

Проверка: все числовые поля заполнены числами, а не текстом вроде `1,2 млн`.

Шаг 3. Создайте лист с планом и фактом по отделам

Добавьте лист `departments`.

Колонки:

week_start
department
metric
plan
fact
owner
comment

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

2026-05-18 | Продажи | выручка | 1200000 | 980000 | Иван | не хватило 2 крупных оплат
2026-05-18 | Маркетинг | лиды | 160 | 184 | Анна | лидов больше плана, качество ниже
2026-05-18 | Поддержка | SLA | 95 | 91 | Олег | выросла очередь после релиза

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

Шаг 4. Создайте лист с рисками

Добавьте лист `risks`.

Колонки:

week_start
risk
impact
owner
deadline
status
source

Пример:

2026-05-18
4 клиента с высоким риском оттока
можем потерять 360000 рублей MRR
Олег
2026-05-27
open
support_tickets

Проверка: риск сформулирован как бизнес-последствие, а не как абстрактное “есть проблема”.

Шаг 5. Создайте лист с задачами

Добавьте лист `tasks`.

Колонки:

task_id
title
owner
status
due_date
project
priority
comment

Пример:

T-101
Связаться с клиентами из группы риска
Олег
overdue
2026-05-20
Retention
high
нужно согласовать план удержания

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

Шаг 6. Создайте лист для черновиков отчета

Добавьте лист `report_log`.

Колонки:

report_id
period_start
period_end
summary
metrics_block
improvements
problems
risks
actions
confidence
review_status
review_comment
approved_by
approved_at
sent_to
sent_at
error
created_at

Статусы:

• `draft` - агент подготовил отчет;
• `approved` - человек разрешил отправку;
• `rejected` - отчет отклонен;
• `sent` - отчет отправлен;
• `error` - workflow упал.

Проверка: есть отдельное место, где хранится итоговый текст, approval и лог отправки.

Шаг 7. Подготовьте Telegram-канал или чат для отчета

Если отправляете отчет в Telegram:

1. Создайте приватный чат или канал `Executive reports`.
2. Создайте бота через `@BotFather`.
3. Добавьте бота в чат или канал.
4. Дайте право отправлять сообщения.
5. Узнайте `chat_id`.

Проверочный запрос:

curl -X POST "https://api.telegram.org/botBOT_TOKEN/sendMessage" \
  -d "chat_id=CHAT_ID" \
  -d "text=Тест отчета от AI-агента"

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

Шаг 8. Создайте первый workflow в n8n

Назовите workflow:

Executive report draft

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `kpi_weekly`;
3. `Google Sheets` - чтение `departments`;
4. `Google Sheets` - чтение `risks`;
5. `Google Sheets` - чтение `tasks`;
6. `Code` - сбор единого контекста;
7. `LLM` или `HTTP Request` к LLM API;
8. `Code` - проверка JSON;
9. `Google Sheets` - запись строки в `report_log`.

Проверка: workflow создан, но пока не активирован.

Шаг 9. Настройте расписание

В `Schedule Trigger` задайте:

Mode: Every Week
Weekday: Monday
Hour: 08
Minute: 30
Timezone: Europe/Moscow

Если компания работает в другом часовом поясе, выберите фактический часовой пояс команды.

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

Шаг 10. Прочитайте KPI за нужную неделю

В узле `Google Sheets` для листа `kpi_weekly` настройте чтение строк.

Фильтр:

week_start = дата понедельника прошлой недели

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

2026-05-18

Проверка: узел возвращает одну строку KPI, а не всю историю.

Шаг 11. Прочитайте отклонения по отделам

Во втором узле `Google Sheets` прочитайте лист `departments`.

Оставьте только строки нужной недели и добавьте вычисление:

deviation = fact - plan
deviation_percent = (fact - plan) / plan * 100

Правило для попадания в отчет:

abs(deviation_percent) >= 10

Проверка: в отчет не попадут мелкие шумовые отклонения на 1-2%.

Шаг 12. Прочитайте риски

В третьем узле `Google Sheets` прочитайте `risks`.

Фильтр:

week_start = текущий отчетный период
status = open

Сортировка:

1. высокий impact;
2. ближайший deadline;
3. отсутствие владельца.

Проверка: агент видит открытые риски, а закрытые не тащит в новый отчет.

Шаг 13. Прочитайте задачи

В четвертом узле `Google Sheets` прочитайте `tasks`.

Оставьте:

• задачи со статусом `overdue`;
• задачи с `priority = high`;
• задачи без владельца;
• задачи с дедлайном в ближайшие 3 дня.

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

Шаг 14. Соберите контекст для LLM

Добавьте узел `Code` и сформируйте объект:

{
  "period": {
    "start": "2026-05-18",
    "end": "2026-05-24"
  },
  "kpi": {
    "revenue_plan": 1200000,
    "revenue_fact": 980000,
    "new_leads": 184,
    "qualified_leads": 73,
    "deals_won": 18,
    "deals_lost": 11,
    "pipeline_value": 3400000,
    "avg_response_minutes": 42,
    "overdue_tasks": 17
  },
  "department_deviations": [
    {
      "department": "Продажи",
      "metric": "выручка",
      "plan": 1200000,
      "fact": 980000,
      "owner": "Иван",
      "comment": "не хватило 2 крупных оплат"
    }
  ],
  "risks": [
    {
      "risk": "4 клиента с высоким риском оттока",
      "impact": "можем потерять 360000 рублей MRR",
      "owner": "Олег",
      "deadline": "2026-05-27"
    }
  ],
  "tasks": [
    {
      "title": "Связаться с клиентами из группы риска",
      "owner": "Олег",
      "status": "overdue",
      "priority": "high"
    }
  ]
}

Проверка: LLM получает только подготовленные данные, а не сырую таблицу целиком.

Шаг 15. Добавьте prompt для отчета

System prompt:

Ты аналитик, который готовит короткий еженедельный отчет для руководителя.
Пиши только по данным, которые получил.
Не придумывай цифры, причины, владельцев и сроки.
Если данных недостаточно, прямо укажи, что именно нужно уточнить.
Тон: деловой, короткий, без канцелярита.
Верни только валидный JSON.

User prompt:

Данные недели:
{{ JSON.stringify($json.context) }}

Верни JSON строго по схеме:
{
  "summary": "3-5 предложений, главный вывод недели",
  "metrics_block": ["цифра: пояснение"],
  "improvements": ["что стало лучше"],
  "problems": ["что стало хуже"],
  "risks": ["риск + влияние + владелец"],
  "actions": ["действие + владелец + срок"],
  "confidence": 0.0,
  "missing_data": ["каких данных не хватает"]
}

Проверка: модель возвращает JSON, а не Markdown-статью.

Шаг 16. Проверьте JSON перед записью

Добавьте узел `Code` после LLM.

Правила валидации:

• `summary` не пустой;
• `metrics_block` содержит минимум 3 пункта;
• `actions` содержит владельца в каждом пункте;
• `confidence` от `0` до `1`;
• в тексте нет выдуманных чисел, которых не было в контексте;
• если `revenue_fact < revenue_plan`, отчет не пишет “план выполнен”.

Если проверка не прошла, запишите строку в `report_log`:

review_status: error
error: JSON validation failed

Проверка: плохой ответ LLM не попадает руководителю.

Шаг 17. Запишите черновик в report_log

В узле `Google Sheets` добавьте строку:

report_id: {{$execution.id}}
period_start: дата начала недели
period_end: дата конца недели
summary: из JSON
metrics_block: пункты через перенос строки
improvements: пункты через перенос строки
problems: пункты через перенос строки
risks: пункты через перенос строки
actions: пункты через перенос строки
confidence: из JSON
review_status: draft
created_at: текущая дата

Проверка: в таблице появился черновик, но сообщение руководству еще не отправлено.

Шаг 18. Проверьте отчет руками

Откройте строку `draft`.

Проверьте:

• все цифры совпадают с исходными таблицами;
• вывод не противоречит данным;
• у рисков есть владелец;
• у действий есть срок;
• отчет не обвиняет людей и не делает выводов без данных;
• нет внутренних технических деталей вроде `JSON`, `LLM`, `workflow`.

Если все хорошо, заполните:

review_status: approved
approved_by: ваше имя
approved_at: текущая дата

Если отчет плохой:

review_status: rejected
review_comment: что исправить

Проверка: без `approved` отправки не будет.

Шаг 19. Создайте второй workflow для отправки

Назовите workflow:

Executive report send

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `report_log`;
3. `Filter` по `review_status = approved`;
4. `Code` - сбор текста сообщения;
5. `Telegram` или `Email Send`;
6. `Google Sheets` - обновление статуса.

Проверка: workflow не смотрит на `draft` и `rejected`.

Шаг 20. Соберите текст сообщения

В узле `Code` соберите короткий формат:

Еженедельный отчет: 18-24 мая 2026

Итог:
{{summary}}

Ключевые цифры:
- {{metrics_block}}

Улучшения:
- {{improvements}}

Проблемы:
- {{problems}}

Риски:
- {{risks}}

Действия:
- {{actions}}

Ограничение: если текст длиннее 3500 символов, обрежьте подробности и оставьте ссылку на Google Sheets.

Проверка: сообщение читается на телефоне без горизонтальной прокрутки.

Шаг 21. Отправьте отчет в Telegram

Если используете Telegram, отправьте сообщение через Bot API:

curl -X POST "https://api.telegram.org/botBOT_TOKEN/sendMessage" \
  -d "chat_id=CHAT_ID" \
  -d "parse_mode=HTML" \
  --data-urlencode "text=Еженедельный отчет: 18-24 мая 2026"

В n8n используйте узел `Telegram` или `HTTP Request`.

Проверка: approved-отчет пришел в нужный чат, а draft-отчет не пришел.

Шаг 22. Или отправьте отчет по email

Если отчет нужен в почте, используйте узел `Email Send`.

Поля:

To: ceo@example.com, coo@example.com
Subject: Еженедельный отчет: 18-24 мая 2026
Body: текст отчета

Для первой версии отправляйте plain text, а не сложный HTML-шаблон.

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

Шаг 23. Обновите статус после отправки

После успешной отправки обновите строку:

review_status: sent
sent_to: Telegram CHAT_ID или список email
sent_at: текущая дата
error: пусто

Если отправка упала:

review_status: error
error: текст ошибки Telegram, SMTP или n8n

Проверка: по `report_log` видно, какой отчет был отправлен, кому и когда.

Шаг 24. Добавьте контроль дублей

Перед отправкой проверьте:

period_start + period_end + review_status = sent

Если за этот период уже есть `sent`, второй раз не отправляйте.

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

Шаг 25. Добавьте проверку качества данных

Перед LLM добавьте узел `Code`, который проверяет исходные данные.

Минимальные правила:

• `revenue_plan` и `revenue_fact` заполнены;
• `week_start` и `week_end` есть во всех листах;
• у каждого риска есть `owner`;
• у каждой high-задачи есть `due_date`;
• число просроченных задач не отрицательное;
• факт не записан строкой с валютой вместо числа.

Если проверка не прошла, создайте строку:

review_status: error
error: data quality failed: нет owner у риска

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

Шаг 26. Добавьте ежемесячную версию

После стабильной недельной версии сделайте отдельный workflow:

Executive monthly report

Отличия:

• запуск 1 числа месяца;
• период - прошлый календарный месяц;
• больше внимания динамике к прошлому месяцу;
• отдельный блок `решения, которые нужны от руководства`;
• отправка только после approval.

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

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

Прототип работает, если выполняются все пункты:

• workflow по расписанию читает KPI, отделы, риски и задачи;
• в `report_log` создается строка `draft`;
• отчет содержит цифры, проблемы, риски и действия;
• человек может поставить `approved` или `rejected`;
• только approved-отчет отправляется в Telegram или email;
• после отправки появляется статус `sent`;
• повторный запуск не дублирует отчет;
• при ошибке в таблице виден статус `error` и причина;
• отчет можно прочитать за 3-5 минут.

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

• отправку отчета без approval;
• изменение планов и KPI в исходных таблицах;
• автоматическое назначение виновных;
• финансовые выводы без подтвержденных данных;
• отправку отчета внешним получателям;
• массовую рассылку по всей компании;
• удаление строк из журналов;
• скрытие проблемных данных ради красивого summary.

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

Можно ли подключить CRM напрямую, а не через таблицу?

Да. Но для первой версии проще выгружать CRM-метрики в Google Sheets: так видно, какие данные попали в отчет, проще проверить цифры и легче объяснить ошибку.

Почему нужен approval, если отчет только внутренний?

Потому что отчет для руководства влияет на решения. AI может неверно объяснить причину просадки, перепутать владельца риска или сделать слишком уверенный вывод по неполным данным.

Что делать, если отчет получился слишком длинным?

Ограничьте prompt: не больше 5 предложений в summary, не больше 5 рисков и не больше 7 действий. Подробные таблицы оставьте по ссылке, а не в сообщении.

Как понять, что агент не придумывает цифры?

Добавьте проверку: все числа из ответа должны встречаться в исходном контексте или быть простыми вычислениями из него. Если число не найдено, отправляйте отчет в `error`.

Какой минимум нужен для запуска?

Один лист KPI, один лист рисков, один лист задач, n8n, LLM API, лист `report_log`, Telegram-бот или email и правило: отправлять только строки со статусом `approved`.