--- title: "AI email triage в n8n: как разобрать входящие — Nodbot" source_url: "https://nodbot.ru/ai/ai-email-triage/" canonical_url: "https://nodbot.ru/ai/ai-email-triage/" language: "ru" content_type: "AIGuide" section: "ai" generated_at: "2026-05-30" word_count_source: 1472 --- # AI email triage в n8n: как разобрать входящие письма, расставить приоритеты и не потерять клиента ## AI summary AI-гайд для n8n: AI email triage в n8n: как разобрать входящие письма. Архитектура workflow, ограничения, проверки качества, безопасность и cost control. ## Best used for Страница объясняет «AI email triage в n8n: как разобрать входящие — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда нужен AI email triage - Чем triage отличается от обычного классификатора писем - Архитектура workflow в n8n - Что нужно извлекать из письма - Как чистить письмо перед AI - Как считать приоритет - Как генерировать ответ безопасно ## Source outline # 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 | Обычно нет | Да Если у вас пока 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(//gi, ' ') .replace(//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%, не включайте автоматическую маршрутизацию для критичных очередей. ## Контроль качества AI-workflow AI-workflow по теме «AI email triage в n8n» должен иметь измеримый контракт: что модель получает, какие действия ей разрешены, какой JSON она обязана вернуть и при каких условиях включается human review. Без этого качество нельзя отличить от удачного демо. Отдельно фиксируйте версию prompt, модель, источники контекста и причину fallback. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry. - Слой | Что зафиксировать | Зачем - Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «AI email triage в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "request_id": "req_demo_001", "prompt_version": "2026-05-29", "input": "краткое нормализованное сообщение пользователя", "allowed_actions": ["read", "draft", "classify"], "forbidden_actions": ["send_without_review", "change_payment"], "expected_output": { "intent": "technical|support|sales|unknown", "confidence": 0.0, "needs_human_review": true, "sources": [] } } ``` ### Критерий готовности - определён JSON-контракт ответа и validation step после модели - опасные действия проходят через approval или создают только draft - логируются prompt_version, model, sources, cost и fallback_reason - есть eval-набор минимум для happy path, low confidence и prompt injection ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.