Как сделать ИИ-агента для аналитики продаж

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

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

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

1. сделки выгружаются из CRM или лежат в таблице `deals`;
2. план продаж лежит в `sales_targets`;
3. активности менеджеров лежат в `activities`;
4. n8n запускает расчет каждое утро;
5. workflow считает выручку, pipeline, конверсию, win rate, средний чек и просадки;
6. LLM превращает цифры в короткий sales insight;
7. результат попадает в `sales_metrics` и `insight_queue`;
8. руководитель проверяет выводы и ставит `approved`;
9. approved-задачи уходят менеджерам или руководителю;
10. все расчеты и ошибки пишутся в `analytics_log`.

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

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

• n8n Cloud или self-hosted n8n.
• Google Sheets для первого прототипа.
• CRM-выгрузка сделок: AmoCRM, Bitrix24, HubSpot, Pipedrive, 1С или CSV.
• Таблица плана продаж.
• Таблица активностей менеджеров, если хотите считать звонки, встречи и follow-up.
• API-ключ LLM-провайдера.
• Канал для задач: CRM, Telegram или email.
• Руководитель продаж, который подтвердит метрики и правила.

Шаг 1. Определите период аналитики

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

текущий месяц с детализацией по дням

Не смешивайте сразу:

• месяц;
• квартал;
• год;
• разные валюты;
• несколько воронок;
• несколько бизнес-направлений.

Проверка: все расчеты в первой версии отвечают на вопрос “что происходит с продажами в этом месяце”.

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

Создайте Google Sheet:

Sales analytics AI agent

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

deals
activities
sales_targets
sales_metrics
pipeline_snapshot
insight_queue
analytics_log
settings
test_cases

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

Шаг 3. Создайте лист deals

В листе `deals` сделайте колонки:

deal_id
deal_name
customer_name
manager
source
pipeline
stage
amount
currency
created_at
closed_at
status
lost_reason
next_activity_at
last_activity_at

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

D-1001
Внедрение AI-агента
ООО Север
Иван
site_form
B2B
proposal
240000
RUB
2026-05-03

open

2026-05-24
2026-05-21

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

Шаг 4. Создайте лист sales_targets

В листе `sales_targets` сделайте колонки:

period_start
period_end
manager
revenue_target
new_deals_target
meetings_target
currency

Пример:

2026-05-01
2026-05-31
Иван
1500000
30
12
RUB

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

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

В листе `activities` сделайте колонки:

activity_id
deal_id
manager
activity_type
activity_date
result
comment

Типы активностей:

• `call`;
• `meeting`;
• `email`;
• `demo`;
• `follow_up`;
• `proposal_sent`.

Пример:

A-9001
D-1001
Иван
demo
2026-05-21
done
показали прототип, клиент просит КП

Проверка: активности можно связать со сделками через `deal_id`.

Шаг 6. Создайте лист settings

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

key
value
comment

Заполните:

currency | RUB | валюта первой версии
stale_deal_days | 7 | сколько дней без активности считать риском
low_conversion_threshold | 0.15 | минимальная конверсия из лида в выигранную сделку
pipeline_coverage_min | 3 | pipeline должен быть минимум в 3 раза больше плана
min_deal_amount_for_alert | 50000 | не создавать alert по мелким сделкам

Проверка: пороги можно менять без переписывания workflow.

Шаг 7. Создайте лист sales_metrics

В листе `sales_metrics` сделайте колонки:

metric_id
period_start
period_end
manager
revenue_fact
revenue_target
target_progress
new_deals
won_deals
lost_deals
open_pipeline
weighted_pipeline
avg_deal_amount
win_rate
conversion_to_won
activities_count
meetings_count
stale_deals_count
created_at

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

Шаг 8. Создайте лист pipeline_snapshot

В листе `pipeline_snapshot` сделайте колонки:

snapshot_id
period_start
period_end
stage
deals_count
amount_sum
weighted_amount
created_at

Задайте веса этапов:

new: 0.1
qualification: 0.2
proposal: 0.5
negotiation: 0.7
contract: 0.85
won: 1.0
lost: 0

Проверка: pipeline можно смотреть не только в штуках сделок, но и в деньгах с учетом вероятности.

Шаг 9. Создайте очередь выводов

В листе `insight_queue` сделайте колонки:

insight_id
period_start
period_end
scope
manager
insight_type
summary
risk_level
recommended_action
evidence
review_status
approved_by
task_id
created_at
processed_at

Статусы:

• `draft`;
• `approved`;
• `rejected`;
• `done`;
• `error`.

Проверка: LLM-выводы не уходят менеджерам без проверки.

Шаг 10. Создайте workflow в n8n

Назовите workflow:

Sales analytics daily

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

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `settings`;
3. `Google Sheets` - чтение `deals`;
4. `Google Sheets` - чтение `activities`;
5. `Google Sheets` - чтение `sales_targets`;
6. `Code` - нормализация данных;
7. `Code` - расчет метрик;
8. `Code` - расчет pipeline;
9. `LLM` - формирование insights;
10. `Code` - проверка JSON;
11. `Google Sheets` - запись `sales_metrics`;
12. `Google Sheets` - запись `pipeline_snapshot`;
13. `Google Sheets` - запись `insight_queue`;
14. `Google Sheets` - запись `analytics_log`.

Проверка: workflow создан и запускается вручную.

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

В `Schedule Trigger` поставьте:

Mode: Every Day
Hour: 08
Minute: 00
Timezone: Europe/Moscow

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

Шаг 12. Нормализуйте сделки

В узле `Code` приведите суммы, даты и статусы к одному формату.

function money(value) {
  return Math.round(Number(String(value || '0').replace(',', '.')) * 100) / 100;
}

function dateOnly(value) {
  return String(value || '').slice(0, 10);
}

function normalizeStatus(value) {
  const status = String(value || '').toLowerCase();
  if (['won', 'success', 'paid'].includes(status)) return 'won';
  if (['lost', 'fail', 'closed_lost'].includes(status)) return 'lost';
  return 'open';
}

Проверка: `Won`, `success` и `paid` не считаются разными статусами.

Шаг 13. Отфильтруйте период

Для текущего месяца берите сделки:

created_at внутри месяца
или closed_at внутри месяца
или status = open

Не включайте в расчет:

• сделки в другой валюте;
• тестовые сделки;
• сделки без суммы, если они не должны участвовать в pipeline;
• дубли.

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

Шаг 14. Посчитайте план-факт

Для каждого менеджера:

revenue_fact = сумма won-сделок за период
revenue_target = план из sales_targets
target_progress = revenue_fact / revenue_target

Пример:

revenue_fact: 900000
revenue_target: 1500000
target_progress: 0.60

Проверка: если менеджер закрыл 900000 при плане 1500000, прогресс 60%, а не “почти план”.

Шаг 15. Посчитайте win rate и conversion

Формулы:

won_deals = количество status = won
lost_deals = количество status = lost
win_rate = won_deals / (won_deals + lost_deals)
conversion_to_won = won_deals / new_deals

Если знаменатель равен нулю:

вернуть null, а не 0

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

Шаг 16. Посчитайте pipeline

Для открытых сделок:

open_pipeline = сумма amount по status = open
weighted_pipeline = сумма amount * stage_weight
pipeline_coverage = open_pipeline / revenue_target

Если `pipeline_coverage < pipeline_coverage_min`, создайте insight:

тип: pipeline_risk
риск: pipeline меньше плана в 3 раза

Проверка: агент видит будущий риск до того, как план уже провален.

Шаг 17. Найдите зависшие сделки

Сделка считается зависшей, если:

status = open
last_activity_at старше stale_deal_days
amount >= min_deal_amount_for_alert

Для каждой такой сделки подготовьте:

deal_id
manager
customer_name
stage
amount
days_without_activity
next_activity_at

Проверка: крупная сделка без активности 8 дней попадает в список рисков.

Шаг 18. Посчитайте активности

Для каждого менеджера:

activities_count = все активности за период
meetings_count = activity_type = meeting или demo
follow_up_count = activity_type = follow_up
proposal_sent_count = activity_type = proposal_sent

Не оценивайте менеджера только по количеству активностей. Используйте активности как объяснение к pipeline и конверсии.

Проверка: агент не делает вывод “мало звонков = плохой менеджер” без связи с результатом.

Шаг 19. Соберите объект для LLM

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

{
  "period": {
    "start": "2026-05-01",
    "end": "2026-05-31"
  },
  "team_metrics": {
    "revenue_fact": 2800000,
    "revenue_target": 4000000,
    "target_progress": 0.7,
    "open_pipeline": 9200000,
    "weighted_pipeline": 4100000,
    "win_rate": 0.32,
    "stale_deals_count": 6
  },
  "managers": [
    {
      "manager": "Иван",
      "target_progress": 0.6,
      "win_rate": 0.28,
      "open_pipeline": 2100000,
      "stale_deals_count": 3
    }
  ],
  "top_risks": [
    {
      "deal_id": "D-1001",
      "manager": "Иван",
      "amount": 240000,
      "days_without_activity": 8
    }
  ]
}

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

Шаг 20. Добавьте prompt для sales insights

System prompt:

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

User prompt:

Данные продаж:
{{ JSON.stringify($json.sales_context) }}

Верни JSON:
{
  "summary": "3-5 предложений о состоянии продаж",
  "insights": [
    {
      "insight_type": "pipeline_risk|conversion_drop|stale_deals|target_gap|activity_gap",
      "scope": "team|manager|deal",
      "manager": "string|null",
      "summary": "короткий вывод",
      "risk_level": "low|medium|high|critical",
      "recommended_action": "конкретное действие",
      "evidence": "на какие цифры опирается вывод"
    }
  ]
}

Проверка: ответ модели - валидный JSON, а не красивый отчет.

Шаг 21. Проверьте JSON и факты

После LLM добавьте узел `Code`.

Правила:

• `insights` не больше 10;
• каждый insight содержит `evidence`;
• `risk_level` только `low`, `medium`, `high`, `critical`;
• в тексте нет цифр, которых нет в контексте;
• нет фраз “менеджер плохо работает”;
• нет действий “уволить”, “лишить бонуса”, “наказать”.

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

step: llm_validation
event: invalid_insight_json
details: причина

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

Шаг 22. Запишите метрики и pipeline

В `sales_metrics` добавьте строки по команде и менеджерам.

В `pipeline_snapshot` добавьте строки по этапам:

stage
deals_count
amount_sum
weighted_amount

Проверка: даже без LLM у вас есть проверяемая таблица с расчетами.

Шаг 23. Запишите выводы в insight_queue

Для каждого insight создайте строку:

insight_id: run_id + номер
period_start
period_end
scope
manager
insight_type
summary
risk_level
recommended_action
evidence
review_status: draft
created_at

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

Шаг 24. Проверьте insight человеком

Руководитель продаж открывает `insight_queue`.

Проверяет:

• цифры в `evidence`;
• не перепутан ли менеджер;
• не является ли просадка сезонной;
• не было ли ручной договоренности по крупной сделке;
• можно ли назначить recommended_action.

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

review_status: approved
approved_by: имя

Или:

review_status: rejected
review_comment: почему отклонено

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

Шаг 25. Создайте workflow отправки задач

Назовите workflow:

Sales insights send approved

Он делает:

1. читает `insight_queue`;
2. берет только `review_status = approved`;
3. создает задачу в CRM или отправляет сообщение в Telegram;
4. записывает `task_id`;
5. меняет статус на `done`.

Пример текста задачи:

Риск по pipeline: у Ивана pipeline coverage 1.4 при минимуме 3.0.
Действие: разобрать 3 крупнейшие открытые сделки и назначить следующий шаг до пятницы.
Доказательство: open_pipeline 2100000, план 1500000, weighted_pipeline 700000.

Проверка: менеджеру приходит конкретная задача с цифрами, а не общий совет “усилить продажи”.

Шаг 26. Сделайте regression test расчетов

В листе `test_cases` сделайте колонки:

case_id
input_deals_set
expected_revenue
expected_win_rate
expected_pipeline
expected_stale_deals
enabled

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

• все сделки выиграны;
• все сделки проиграны;
• нет закрытых сделок;
• одна крупная зависшая сделка;
• разные менеджеры;
• нулевой план;
• сделка без суммы;
• сделка в другой валюте;
• дубль сделки;
• активность без deal_id.

Создайте workflow:

Sales analytics regression test

Он прогоняет тестовые наборы и сравнивает ожидаемые метрики с фактическими.

Проверка: изменение формул не ломает расчет win rate, pipeline и просадок.

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

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

• сделки читаются из `deals`;
• планы читаются из `sales_targets`;
• активности читаются из `activities`;
• считаются revenue_fact, target_progress, win_rate, pipeline и stale_deals;
• метрики записываются в `sales_metrics`;
• pipeline записывается в `pipeline_snapshot`;
• LLM создает insights только по данным;
• выводы попадают в `insight_queue` со статусом `draft`;
• без `approved` задачи не отправляются;
• regression test проверяет формулы.

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

• наказания и выводы о людях без руководителя;
• изменение этапов сделок;
• автоматическое закрытие сделок;
• изменение планов продаж;
• отправку клиентам сообщений;
• прогноз выручки без исторических данных;
• расчет бонусов и зарплат;
• удаление или перезапись CRM-данных.

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

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

Да. Но первую версию проще собрать на Google Sheets или CSV-выгрузке: так видно, какие поля попали в расчет, и легче проверить формулы.

Какие метрики нужны минимум?

Для старта достаточно выручки факт/план, open pipeline, weighted pipeline, win rate, conversion_to_won, stale_deals и активности по менеджерам.

Почему LLM не должен считать метрики?

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

Что делать, если менеджер спорит с выводом?

Открыть `evidence`: сделки, суммы, даты активности и формулу. Если данных не хватает или они ошибочны, исправить источник и перезапустить workflow.

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

Листы `deals`, `activities`, `sales_targets`, `sales_metrics`, `pipeline_snapshot`, `insight_queue`, n8n workflow расчета, LLM summary и approval руководителя перед отправкой задач.