Перейти к содержанию

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

Надёжная схема выглядит так:

  1. Email Trigger / IMAP / Gmail Trigger — получает новое письмо.
  2. Thread cleaner — отделяет новое сообщение от цитат, подписей, дисклеймеров и пересылок.
  3. Sender resolver — определяет клиента, компанию, домен, CRM/contact ID.
  4. Information Extractor — достаёт order_id, invoice_id, phone, company, deadline, product, language.
  5. Text Classifier или LLM classification — ставит intent/category.
  6. Priority scorer — считает срочность по правилам и AI-сигналам.
  7. Risk gate — выявляет жалобы, возвраты, персональные данные, юридические формулировки, угрозу оттока.
  8. Router — выбирает очередь: support, sales, billing, legal, spam, vendor, internal.
  9. Draft generator — готовит черновик ответа, а не всегда отправляет его.
  10. Human review или auto-reply — зависит от риска и confidence.
  11. CRM/ticket update — записывает результат и SLA.
  12. 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 даже для спама.

Типовые ошибки

  1. Автоответ на всё подряд. Быстро, но опасно: один неверный ответ клиенту дороже экономии на операторе.
  2. Нет отделения цитат. Модель классифицирует старую переписку, а не новое письмо.
  3. Слишком много категорий. 40 категорий дают иллюзию точности. Начните с 8–12 рабочих очередей.
  4. Нет confidence threshold. Низкая уверенность должна отправлять письмо человеку.
  5. Нет обратной связи. Если правки операторов не сохраняются, качество не растёт.
  6. 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%, не включайте автоматическую маршрутизацию для критичных очередей.