Как сделать ИИ-агента для customer success и удержания

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

Соберем ИИ-агента для customer success, который каждый день собирает сигналы по клиентам, считает понятный health score, находит churn risk, готовит краткое резюме для CSM, создает задачи, предлагает follow-up, подсвечивает renewal и отправляет чувствительные действия на согласование.

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

1. клиенты попадают в `account_queue`;
2. CRM-данные сохраняются в `account_profile`;
3. product usage пишется в `usage_signals`;
4. тикеты поддержки пишутся в `support_signals`;
5. переписки и письма пишутся в `conversation_signals`;
6. renewal и договоры пишутся в `renewal_signals`;
7. правила оценки лежат в `health_rules`;
8. итоговый health score сохраняется в `health_scores`;
9. риски оттока пишутся в `churn_risks`;
10. рекомендации для CSM попадают в `csm_actions`;
11. задачи создаются через `task_queue`;
12. черновики сообщений пишутся в `followup_drafts`;
13. value recap перед renewal пишется в `value_recaps`;
14. спорные действия уходят в `approval_queue`;
15. решения людей пишутся в `approval_log`;
16. каждое действие фиксируется в `audit_log`;
17. ошибки попадают в `error_log`;
18. weekly report показывает клиентов в риске и результат работы.

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

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

• n8n Cloud или self-hosted n8n.
• Google Sheets для управляющих таблиц.
• CRM: HubSpot, amoCRM, Bitrix24, Pipedrive или другая.
• Support desk: Zendesk, Intercom, Freshdesk, Help Scout или похожий инструмент.
• Источник product usage: PostHog, Amplitude, GA4, база событий или CSV-выгрузка.
• Канал для задач: CRM tasks, Asana, Jira, ClickUp, Telegram или Slack.
• API-ключ LLM-провайдера.
• Список клиентов за последние 30-90 дней.
• Правила customer success: что считать риском, какие действия допустимы, кто подтверждает спорные решения.

Шаг 1. Выберите один customer success сценарий

Не запускайте агента сразу на всех клиентах и всех процессах.

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

1. клиент купил продукт, но не завершил onboarding;
2. клиент не активен 14 дней;
3. у клиента много открытых тикетов;
4. скоро renewal;
5. клиент написал негативный отзыв;
6. у ключевого пользователя упала активность;
7. клиент пользуется продуктом активно и готов к expansion;
8. CSM готовит weekly risk review.

Самый простой старт - daily risk review: агент каждый день показывает клиентов, которым CSM должен уделить внимание.

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

Шаг 2. Определите границы автоматизации

Запишите, что агенту можно и нельзя.

Можно в первой версии:

• считать health score;
• объяснять причины риска;
• готовить summary по клиенту;
• готовить черновик follow-up;
• создавать внутреннюю задачу CSM;
• предлагать следующий шаг;
• готовить value recap;
• отправлять спорные кейсы на approval.

Нельзя в первой версии:

• обещать скидку или компенсацию;
• менять тариф;
• подтверждать renewal;
• закрывать тикет от имени поддержки;
• отправлять клиенту чувствительное письмо без проверки;
• менять stage сделки без CSM;
• писать клиенту “вы в риске оттока”;
• делать вывод без объяснения сигналов.

Проверка: CSM понимает, где агент помощник, а где решение принимает человек.

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

Создайте Google Sheet:

Customer success agent

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

settings
account_queue
account_profile
usage_signals
support_signals
conversation_signals
renewal_signals
health_rules
health_scores
churn_risks
csm_actions
task_queue
followup_drafts
value_recaps
approval_queue
approval_log
audit_log
weekly_report
error_log

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

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

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

key
value
description
updated_at

Заполните минимальные настройки:

timezone | Europe/Moscow | основная таймзона команды
review_window_days | 30 | период анализа сигналов
inactive_days_threshold | 14 | сколько дней без активности считать тревогой
renewal_warning_days | 45 | за сколько дней до продления поднимать флаг
auto_create_csm_tasks | true | можно создавать внутренние задачи
auto_send_customer_messages | false | внешние письма только после approval
health_score_mode | rules_plus_llm | правила плюс объяснение модели
default_language | ru | язык summary и follow-up
approval_channel | telegram | куда отправлять согласование

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

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

`account_queue` - очередь клиентов на ежедневную проверку.

Колонки:

account_id
crm_company_id
company_name
segment
csm_email
priority
status
last_checked_at
next_check_at
created_at
updated_at

Статусы:

new
collecting
scoring
waiting_approval
done
skip
error

Пример:

ACC-1001 | company_482 | ООО Альфа | mid-market | csm@company.ru | high | new |  | 2026-05-24 09:00

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

Шаг 6. Загрузите профиль клиента из CRM

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

account_id
crm_system
crm_company_id
company_name
segment
industry
plan
mrr
contract_start
renewal_date
csm_email
main_contact_email
last_contact_at
open_deals
open_tasks
crm_notes
created_at

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

CS account intake

Цепочка:

1. Cron Trigger раз в день;
2. CRM node или HTTP Request к CRM API;
3. выбрать активных клиентов;
4. нормализовать поля;
5. записать клиентов в `account_queue`;
6. записать профиль в `account_profile`.

Проверка: в таблице есть клиент, CSM, тариф, renewal date и основной контакт.

Шаг 7. Добавьте product usage

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

account_id
period_start
period_end
active_users
key_actions_count
last_seen_at
feature_usage_json
usage_trend
activation_done
first_value_done
created_at

Минимальные сигналы:

active_users
last_seen_at
key_actions_count
activation_done
first_value_done
usage_trend

`usage_trend`:

up
flat
down
no_data

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

Шаг 8. Добавьте сигналы поддержки

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

account_id
period_start
period_end
open_tickets
critical_tickets
sla_breaches
avg_first_reply_hours
negative_tickets
top_ticket_topics
last_ticket_at
support_summary
created_at

Из Zendesk или Intercom подтягивайте:

1. количество открытых тикетов;
2. критичные тикеты;
3. нарушения SLA;
4. темы обращений;
5. негативные формулировки;
6. давность последнего обращения.

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

Шаг 9. Добавьте переписки и письма

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

account_id
source
conversation_id
contact_email
last_message_at
sentiment
topics
unanswered_question
needs_csm_attention
summary
created_at

Статусы sentiment:

positive
neutral
negative
mixed
unknown

Правило:

если есть unanswered_question = true больше 2 рабочих дней, создать csm action

Проверка: важный вопрос клиента не теряется в переписке.

Шаг 10. Добавьте renewal signals

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

account_id
renewal_date
days_to_renewal
contract_value
plan
renewal_owner
renewal_status
last_value_recap_at
commercial_risk
created_at

`renewal_status`:

not_started
prepare_value_recap
in_progress
risk
renewed
lost
unknown

Правило:

если days_to_renewal <= 45 и нет value recap, создать задачу CSM

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

Шаг 11. Опишите health_rules

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

rule_id
signal
condition
points
severity
reason_template
recommended_action
is_active
updated_at

Примеры правил:

HR-001 | usage | last_seen_at older than 14 days | -25 | high | Клиент не был активен больше 14 дней | Написать клиенту и уточнить статус внедрения
HR-002 | onboarding | activation_done = false after 10 days | -20 | high | Onboarding не завершен | Назначить короткий созвон
HR-003 | support | critical_tickets > 0 | -30 | critical | Есть критичные тикеты | Эскалировать в поддержку и CSM
HR-004 | renewal | days_to_renewal <= 45 and no value_recap | -15 | medium | Скоро renewal без value recap | Подготовить value recap
HR-005 | usage | key_actions_count grew by 30 percent | +15 | positive | Использование растет | Проверить expansion opportunity

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

Шаг 12. Рассчитайте health score правилами

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

CS health scoring

Цепочка:

1. взять клиента из `account_queue`;
2. загрузить `account_profile`;
3. загрузить `usage_signals`;
4. загрузить `support_signals`;
5. загрузить `conversation_signals`;
6. загрузить `renewal_signals`;
7. загрузить активные `health_rules`;
8. применить правила;
9. записать результат в `health_scores`;
10. перевести клиента в `done` или `waiting_approval`.

Проверка: score считается даже без LLM.

Шаг 13. Запишите health_scores

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

score_id
account_id
score
status
reasons_json
positive_signals_json
negative_signals_json
confidence
calculated_at

Статусы:

green
yellow
red
unknown

Правило перевода:

80-100 = green
55-79 = yellow
0-54 = red
no_data = unknown

Пример `reasons_json`:

[
  {
    "rule_id": "HR-001",
    "reason": "Клиент не был активен больше 14 дней",
    "points": -25
  },
  {
    "rule_id": "HR-003",
    "reason": "Есть критичный тикет по интеграции",
    "points": -30
  }
]

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

Шаг 14. Добавьте LLM-объяснение

LLM нужен не для магического score, а для короткого объяснения.

Prompt:

Ты помощник customer success manager.
Используй только переданные сигналы.
Не выдумывай факты.
Объясни health score коротко и практично.
Верни JSON:
{
  "summary": "до 700 символов",
  "main_risks": ["риск"],
  "recommended_next_action": "одно действие CSM",
  "customer_message_angle": "как мягко написать клиенту",
  "do_not_promise": ["что нельзя обещать"],
  "needs_review": true
}

Проверка: объяснение не меняет score, а делает его понятным.

Шаг 15. Запишите churn_risks

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

risk_id
account_id
risk_level
risk_reasons
evidence
recommended_action
owner_email
status
created_at

`risk_level`:

low
medium
high
critical
unknown

Правила:

1. critical ticket плюс падение активности = `high`;
2. renewal меньше 30 дней плюс нет value recap = `high`;
3. негативное письмо плюс нет ответа CSM = `medium`;
4. нет product usage data = `unknown`, а не `low`;
5. один слабый сигнал не должен давать `critical`.

Проверка: каждый риск имеет evidence и владельца.

Шаг 16. Сформируйте csm_actions

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

action_id
account_id
action_type
action_text
priority
owner_email
due_date
source_risk_id
status
created_at

`action_type`:

send_followup
schedule_call
prepare_value_recap
escalate_support
check_onboarding
update_crm
review_usage_drop
expansion_check

Пример:

ACT-1001 | ACC-1001 | schedule_call | Назначить 20-минутный созвон по незавершенному onboarding | high | csm@company.ru | 2026-05-25

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

Шаг 17. Настройте task_queue

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

Колонки:

queue_id
action_id
task_system
task_payload_json
approval_required
status
created_at
processed_at
error_message

Пример payload:

{
  "title": "Связаться с ООО Альфа по onboarding",
  "assignee": "csm@company.ru",
  "due_date": "2026-05-25",
  "description": "Health score red: нет активности 16 дней, onboarding не завершен, есть открытый тикет.",
  "source": "customer_success_agent"
}

Проверка: задача сначала попадает в очередь, потом создается в CRM или task manager.

Шаг 18. Подготовьте followup_drafts

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

draft_id
account_id
contact_email
subject
body
tone
reason
contains_discount
contains_compensation
contains_contract_terms
approval_required
status
created_at

Prompt:

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

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

Шаг 19. Проверяйте опасные обещания

Перед отправкой follow-up добавьте deterministic checks.

Флаги:

contains_discount
contains_compensation
contains_refund
contains_contract_terms
contains_security_claim
contains_deadline_promise
contains_negative_label

Запрещенные формулировки:

мы гарантируем
точно успеем
дадим скидку
вернем деньги
изменим договор
вы в риске оттока
у вас проблема

Правило:

если есть любой опасный флаг, approval_required = true

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

Шаг 20. Подготовьте value_recaps

Перед renewal агент должен собрать пользу, которую клиент уже получил.

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

recap_id
account_id
period_start
period_end
outcomes
usage_highlights
resolved_issues
open_risks
recommended_plan
draft_text
status
created_at

Prompt:

Подготовь value recap для CSM перед renewal.
Используй CRM, usage, support и conversation signals.
Не выдумывай метрики.
Если точных чисел нет, не придумывай их.
Верни:
- что клиент использовал;
- какие проблемы решены;
- какие риски остались;
- что обсудить на renewal call;
- черновик короткого текста для клиента.

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

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

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

approval_id
account_id
object_type
object_id
reason
preview
approver_email
status
created_at
decided_at

`object_type`:

followup_draft
value_recap
crm_update
task
high_churn_risk
renewal_action

Статусы:

pending
approved
rejected
needs_edit
expired

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

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

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

CS approval

Цепочка:

1. взять `approval_queue` со статусом `pending`;
2. отправить preview в Telegram;
3. добавить кнопки `Approve`, `Needs edit`, `Reject`;
4. обновить строку после решения;
5. записать решение в `approval_log`;
6. продолжить отправку письма или создание задачи только после approve.

Сообщение:

Нужно согласовать follow-up клиенту ООО Альфа
Причина: внешний клиент + renewal меньше 30 дней

Preview:
Добрый день! Хотел сверить, как у вас идет onboarding...

[Approve] [Needs edit] [Reject]

Проверка: без approve письмо не отправляется.

Шаг 23. Запишите approval_log

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

approval_log_id
approval_id
account_id
approver_email
decision
comment
decided_at

Решения:

approved
rejected
needs_edit
expired

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

Шаг 24. Обновляйте CRM через черновики

Не давайте агенту менять CRM напрямую в первой версии.

Создавайте draft update:

{
  "company_id": "company_482",
  "health_status": "red",
  "health_reasons": [
    "нет активности 16 дней",
    "onboarding не завершен",
    "есть критичный тикет"
  ],
  "next_step": "CSM назначает созвон",
  "next_step_due": "2026-05-25"
}

Правило:

health score можно записывать автоматически, stage, renewal status и commercial fields - только после approval

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

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

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

audit_id
account_id
actor
action
object_type
object_id
before_json
after_json
created_at

Логируйте:

1. сбор CRM-профиля;
2. сбор usage signals;
3. сбор support signals;
4. расчет health score;
5. создание churn risk;
6. создание CSM action;
7. создание follow-up draft;
8. отправку approval;
9. решение approval;
10. создание задачи;
11. обновление CRM;
12. ошибку API.

Проверка: любое действие агента можно объяснить и восстановить.

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

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

error_id
account_id
workflow_name
node_name
error_type
error_message
payload_snapshot
status
owner_email
created_at

Типы ошибок:

crm_api_failed
usage_data_missing
support_api_failed
llm_invalid_json
approval_timeout
task_create_failed
followup_send_blocked
crm_update_failed

Проверка: если не загрузились usage data, клиент не получает `green` молча.

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

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

week_start
accounts_checked
green_count
yellow_count
red_count
unknown_count
high_churn_risk_count
tasks_created
followups_created
renewals_due_45_days
errors_count
top_risk_reasons
created_at

Минимальный weekly report:

1. сколько клиентов проверено;
2. сколько красных и желтых;
3. сколько high churn risk;
4. сколько задач создано;
5. сколько renewal скоро;
6. какие причины риска самые частые;
7. где агент ломался.

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

Шаг 28. Протестируйте на 20 клиентах

Возьмите 20 клиентов: 10 нормальных, 5 с риском, 5 с неполными данными.

Проверьте:

1. активный клиент не становится красным без причины;
2. клиент без usage data получает `unknown`, а не `green`;
3. критичный тикет влияет на score;
4. близкий renewal создает задачу;
5. незавершенный onboarding создает действие CSM;
6. follow-up не содержит скидок и компенсаций;
7. high churn risk имеет evidence;
8. CSM action имеет владельца и срок;
9. approval блокирует внешнее письмо;
10. ошибки пишутся в `error_log`.

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

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

MVP готов, если:

• клиенты попадают в `account_queue`;
• CRM-профиль пишется в `account_profile`;
• usage пишется в `usage_signals`;
• тикеты пишутся в `support_signals`;
• переписки пишутся в `conversation_signals`;
• renewal пишется в `renewal_signals`;
• правила есть в `health_rules`;
• health score пишется в `health_scores`;
• churn risk пишется в `churn_risks`;
• действия CSM пишутся в `csm_actions`;
• задачи проходят через `task_queue`;
• письма создаются как `followup_drafts`;
• value recap пишется в `value_recaps`;
• опасные действия уходят в `approval_queue`;
• решения пишутся в `approval_log`;
• audit и error logs заполнены;
• weekly report показывает состояние клиентов.

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

1. Добавьте тестового клиента из CRM.
2. Добавьте usage signal с падением активности.
3. Добавьте один критичный тикет.
4. Укажите renewal через 30 дней.
5. Запустите scoring workflow.
6. Проверьте `health_scores` и `churn_risks`.
7. Проверьте `csm_actions` и `followup_drafts`.
8. Отклоните один follow-up через approval.
9. Одобрите одну внутреннюю задачу.
10. Проверьте `audit_log`, `error_log` и `weekly_report`.

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

• обещания скидок, компенсаций и возвратов;
• изменение тарифа или договора;
• подтверждение renewal;
• отправку внешних писем без approval;
• закрытие критичных тикетов;
• вывод “клиент уйдет” без evidence;
• запись коммерческих условий в CRM без CSM;
• обработку персональных данных без правил доступа;
• игнорирование клиента из-за отсутствия usage data;
• удаление спорных решений без audit log.

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

Чем customer success-агент отличается от агента поддержки?

Агент поддержки работает с конкретным обращением. Customer success-агент смотрит шире: onboarding, активность, ценность, тикеты, отношения, renewal, риск оттока и следующий шаг CSM.

Можно ли начать без product analytics?

Да. Для первой версии можно взять CRM, тикеты и переписки. Но клиент без данных по активности должен получать `unknown`, а не зеленый статус. Usage data лучше добавить сразу после первого теста.

Как избежать ложных тревог по churn risk?

Не используйте один сигнал как приговор. Падение активности само по себе может быть нормальным, но вместе с критичными тикетами, близким renewal и отсутствием ответа CSM становится серьезным риском.

Можно ли агенту самому писать клиенту?

Для внешних писем в первой версии лучше использовать approval. Автоотправку можно включать только для безопасных шаблонов: короткое напоминание, ссылка на инструкцию, предложение выбрать время без обещаний и коммерческих условий.

Что должен увидеть CSM каждое утро?

CSM должен получить список клиентов с health status, причинами, evidence, рекомендуемым действием, дедлайном, черновиком сообщения и пометкой, что требует ручного подтверждения.