AI email triage в n8n: как разобрать входящие письма, расставить приоритеты и не потерять клиента ¶
Обновлено: 2026-05-29
Короткий ответ ¶
AI email triage — это workflow, который берёт входящее письмо, очищает его от шума, понимает интент, извлекает важные данные, определяет срочность, выбирает очередь или ответственного и готовит безопасный следующий шаг. В n8n такой процесс лучше строить не одним большим prompt, а цепочкой: Email Trigger → очистка письма → classification → extraction → risk scoring → routing → черновик ответа → human review или auto-reply. Главная цель triage — не “ответить красиво”, а сократить время до правильного действия и не пропустить рискованное письмо.
Когда нужен AI email triage ¶
Triage нужен, когда на общий ящик приходит много разных сообщений: заявки, жалобы, счета, вопросы поддержки, коммерческие предложения, уведомления от сервисов, ответы клиентов и внутренние пересылки. Ручной разбор таких писем плохо масштабируется: оператор сначала читает письмо, понимает тему, ищет номер заказа, решает срочность, пересылает коллегам и только потом отвечает. AI может снять с человека первые 60–80% рутины, если процесс хорошо ограничен.
Но AI triage не равен полной автоматической поддержке. У него другая задача: быстро превратить письмо в структурированное событие. После этого обычные workflow-ветки решают, что делать. Если письмо низкорисковое — отправить подтверждение или ссылку. Если есть жалоба — создать тикет с высоким приоритетом. Если письмо похоже на лид — передать в CRM. Если есть деньги, персональные данные, юридический конфликт или отмена заказа — поставить человека в review.
Чем triage отличается от обычного классификатора писем ¶
Email classifier отвечает на один вопрос: “к какой категории относится письмо?”. Triage закрывает весь первый этап обработки.
| Блок | Classifier | Triage |
|---|---|---|
| Категория письма | Да | Да |
| Приоритет | Иногда | Да |
| Извлечение заказа, email, компании | Нет или отдельно | Да |
| Определение риска | Нет | Да |
| Выбор очереди/ответственного | Нет | Да |
| Черновик ответа | Нет | Да |
| Human review | Обычно нет | Да |
| Логи и SLA | Часто нет | Обязательно |
Если у вас пока 20 писем в неделю, начните с classifier. Если 200+ писем, несколько типов обращений и разные SLA, нужен triage.
Архитектура workflow в n8n ¶
Надёжная схема выглядит так:
- Email Trigger / IMAP / Gmail Trigger — получает новое письмо.
- Thread cleaner — отделяет новое сообщение от цитат, подписей, дисклеймеров и пересылок.
- Sender resolver — определяет клиента, компанию, домен, CRM/contact ID.
- Information Extractor — достаёт order_id, invoice_id, phone, company, deadline, product, language.
- Text Classifier или LLM classification — ставит intent/category.
- Priority scorer — считает срочность по правилам и AI-сигналам.
- Risk gate — выявляет жалобы, возвраты, персональные данные, юридические формулировки, угрозу оттока.
- Router — выбирает очередь: support, sales, billing, legal, spam, vendor, internal.
- Draft generator — готовит черновик ответа, а не всегда отправляет его.
- Human review или auto-reply — зависит от риска и confidence.
- CRM/ticket update — записывает результат и SLA.
- Evaluation log — сохраняет prediction, human correction и время обработки.
Такой workflow проще отлаживать, чем один Agent, который “сам разберётся с письмом”. Если ошибка возникла, видно, где она случилась: очистка, extraction, classification, routing или reply generation.
Что нужно извлекать из письма ¶
Минимальный JSON для triage:
{
"message_id": "gmail_18f0a9",
"thread_id": "thread_8821",
"from_email": "client@example.com",
"company_domain": "example.com",
"language": "ru",
"intent": "support_issue",
"priority": "high",
"risk_level": "medium",
"deadline": "2026-05-30",
"entities": {
"order_id": "ORD-10492",
"product": "self-hosted n8n",
"phone": null
},
"summary": "Клиент сообщает, что webhook перестал принимать заявки после обновления.",
"recommended_queue": "technical_support",
"suggested_next_action": "Создать тикет P2 и запросить URL webhook без секретов.",
"requires_human_review": true,
"confidence": 0.82
}
Не пытайтесь извлекать 50 полей сразу. Начните с тех, которые реально используются в downstream: queue, priority, owner, CRM match, reply template, SLA. Всё остальное добавляйте только после появления бизнес-потребности.
Как чистить письмо перед AI ¶
Сырой email содержит цитаты, подписи, HTML, tracking-пиксели, legal footer, старые ответы и пересланные заголовки. Если отправить всё это в модель, она может классифицировать не новое обращение, а старый текст внизу цепочки.
Пример Code node для грубой очистки:
const html = $json.html || '';
const text = ($json.text || html)
.replace(/<style[\s\S]*?<\/style>/gi, ' ')
.replace(/<script[\s\S]*?<\/script>/gi, ' ')
.replace(/<[^>]+>/g, ' ')
.replace(/On .* wrote:/gi, '---quoted---')
.replace(/С уважением,[\s\S]*$/i, ' ')
.replace(/--\s*[\s\S]*$/g, ' ')
.replace(/\s+/g, ' ')
.trim();
const latest = text.split('---quoted---')[0].slice(0, 6000);
return [{ json: { ...$json, clean_email_text: latest } }];
Для production лучше хранить и raw email, и clean version. Raw нужен для аудита, clean — для AI. Никогда не перезаписывайте исходник очищенным текстом.
Как считать приоритет ¶
Не отдавайте приоритет полностью модели. Лучше смешать правила и AI. Правила ловят очевидное: VIP-домен, платный тариф, слова “не работает оплата”, “суд”, “возврат”, “продакшен лежит”, “не можем принимать заявки”. AI помогает понять смысл, если формулировка мягкая: “после вчерашних изменений клиенты не могут записаться”.
Пример scoring:
let score = 0;
const t = ($json.clean_email_text || '').toLowerCase();
if ($json.customer_tier === 'enterprise') score += 30;
if (/оплат|платеж|счет|возврат|refund/.test(t)) score += 20;
if (/не работает|лежит|ошибка|production|продакшен/.test(t)) score += 25;
if (/срочно|сегодня|дедлайн|горит/.test(t)) score += 15;
if ($json.ai_intent === 'complaint') score += 20;
if ($json.ai_confidence < 0.65) score += 10; // лучше review, чем тихая ошибка
const priority = score >= 60 ? 'urgent' : score >= 35 ? 'high' : score >= 15 ? 'normal' : 'low';
return [{ json: { ...$json, priority_score: score, priority } }];
Так проще объяснить, почему письмо стало urgent. Если всё решает модель, оператору сложно доверять результату.
Как генерировать ответ безопасно ¶
Triage может готовить черновик, но не должен автоматически обещать скидки, сроки, возвраты, юридические выводы или технические гарантии. Разделите ответы на уровни.
| Уровень | Можно auto-send | Пример |
|---|---|---|
| Низкий риск | Да | “Получили обращение, вернёмся с ответом” |
| Средний риск | Черновик + review | “Похоже, проблема в webhook URL, пришлите execution ID” |
| Высокий риск | Только review | возврат денег, жалоба, юридическая претензия |
| Критический | Escalation | production outage, утечка данных, VIP-клиент |
Хороший prompt для draft reply должен запрещать выдумывать факты. Он должен использовать только извлечённые данные и разрешённые шаблоны. Если данных не хватает, ответ должен задавать уточняющий вопрос.
Как связать triage с CRM и helpdesk ¶
После triage нужно не просто отправить письмо, а обновить систему учёта. Минимальный набор действий:
- найти контакт по email/domain;
- создать тикет, если это поддержка;
- создать лид, если это коммерческий запрос;
- обновить existing deal, если письмо от текущего клиента;
- записать
intent,priority,risk_level,summary,ai_confidence; - поставить SLA deadline;
- назначить owner или queue;
- прикрепить ссылку на оригинальное письмо.
Если CRM match неоднозначный, не обновляйте случайную карточку. Создайте review-задачу с вариантами совпадений.
Что логировать ¶
Для каждого письма храните:
message_id,thread_id,from_domain;- clean text hash, но не обязательно полный текст в AI logs;
- model, prompt version, schema version;
- extracted entities;
- category, priority, risk, confidence;
- выбранную очередь и owner;
- был ли auto-reply;
- human correction;
- latency и cost;
- финальный статус: resolved, reassigned, reopened.
Эти логи нужны для улучшения качества. Через месяц вы увидите, что, например, AI часто путает счета от подрядчиков с заявками клиентов или поднимает “срочно” в urgent даже для спама.
Типовые ошибки ¶
- Автоответ на всё подряд. Быстро, но опасно: один неверный ответ клиенту дороже экономии на операторе.
- Нет отделения цитат. Модель классифицирует старую переписку, а не новое письмо.
- Слишком много категорий. 40 категорий дают иллюзию точности. Начните с 8–12 рабочих очередей.
- Нет confidence threshold. Низкая уверенность должна отправлять письмо человеку.
- Нет обратной связи. Если правки операторов не сохраняются, качество не растёт.
- PII уходит в логи. Маскируйте телефоны, токены, номера карт, паспортные данные и персональные ссылки.
Тесты перед запуском ¶
Соберите dataset минимум из 100 реальных писем: лиды, поддержка, жалобы, счета, спам, внутренние пересылки, длинные цепочки, письма с вложениями, письма без темы. Для каждого задайте expected category, priority и routing. Затем прогоняйте workflow после каждого изменения prompt/schema/model.
Минимальные метрики:
- category accuracy;
- urgent recall — сколько срочных писем не пропущено;
- false urgent rate;
- correct queue rate;
- average handling time;
- auto-reply complaint rate;
- manual correction rate;
- cost per 1000 emails.
Если urgent recall ниже 95%, не включайте автоматическую маршрутизацию для критичных очередей.