← На главную Портфолио

Enterprise AI Service Desk

Полностью автоматизированная система обработки сервисных заявок на базе n8n, Supabase, GigaChat и Bitrix24
6 модулей
GigaChat AI
4 уровня защиты
n8n 2.27.3
ЗадачаСервисный отдел терял заявки, ошибался в классификации, нарушал SLA. Ручная обработка до 15 мин на заявку.
Моя работаСобрал 7 workflow n8n: приём с дедупликацией, ИИ-классификация (GigaChat), диспетчеризация в Bitrix24, SLA-мониторинг с эскалацией в Telegram, обработка ошибок.
Технологииn8n 2.27.3, Supabase (PostgreSQL), GigaChat, Bitrix24 REST API, Telegram Bot API
РезультатПолная автоматизация жизненного цикла заявки, 4 уровня защиты, 60x больше заявок без расширения штата

1. Название проекта

Название сценария автоматизации:

Enterprise AI Service Desk — интеллектуальная система обработки сервисных заявок

Техническое задание:

«Помощник сервисного отдела» — полная автоматизация жизненного цикла сервисного обращения: от приёма заявки клиента до постановки задачи инженеру в CRM с ИИ-классификацией, SLA-контролем и проактивной эскалацией.

2. Краткое описание проекта

Что это за бизнес, отдел или процесс?

Сервисный отдел промышленного оборудования, принимающий заявки на ремонт, консультации и плановое ТО от корпоративных клиентов.

Какая задача решается с помощью автоматизации?

Полная автоматизация приёма, классификации, диспетчеризации и контроля сроков выполнения заявок без участия человека.

Кто будет пользоваться результатом автоматизации?

Сервисные инженеры (получают задачи в Битрикс24), клиенты (получают email-уведомления), руководитель отдела (получает эскалации в Telegram) и администратор системы (мониторит метрики через SQL-дашборды).

3. Бизнес-проблема

Что раньше делалось вручную?

Диспетчер вручную читал каждое обращение, определял категорию (ремонт / консультация / ТО), приоритет (high/medium/low), профиль специалиста (электрик/механик/программист/универсал), создавал задачу в Битрикс24, писал ответное письмо клиенту и следил за сроками выполнения.

Какие ошибки, задержки или потери могли возникать?

  • Заявки терялись в почте и мессенджерах
  • Неправильная классификация (не тот специалист получал задачу)
  • Задержки обработки до 15 минут на заявку
  • Нарушение SLA-сроков без своевременной эскалации
  • Дублирование задач при повторных обращениях
  • Отсутствие единой истории взаимодействий

Почему этот процесс важно автоматизировать?

Объём заявок растёт, а штат диспетчеров ограничен. Автоматизация позволяет обрабатывать в 60 раз больше заявок с нулевым участием человека для стандартных кейсов, гарантирует соблюдение SLA и прозрачную трассируемость.

4. Цель автоматизации

Главная цель проекта:

Полностью исключить участие человека в обработке стандартных заявок и обеспечить 100% SLA-compliance.

Что должно происходить автоматически после запуска сценария?

Заявка принимается через webhook/email → сохраняется в БД с уникальным хешем → классифицируется ИИ → создаётся задача в Битрикс24 с тегами → отправляется письмо клиенту → каждые 15 минут проверяется SLA → при нарушении эскалируется руководителю.

Какой результат должен увидеть пользователь или сотрудник?

  • Инженер: задача в Битрикс24 с полной информацией и правильным приоритетом
  • Клиент: корпоративное письмо с подтверждением и номером заявки
  • Руководитель: Telegram-уведомление только при нарушениях SLA
  • Администратор: SQL-дашборд с полной статистикой и историей

5. Пользователи сценария

Кто основной пользователь сценария?

Сервисный отдел промышленного оборудования (3 роли: диспетчер, инженер, руководитель).

Какая роль у этого пользователя?

  • Сервисный инженер — получает задачи и выполняет работы
  • Руководитель отдела — контролирует SLA и эскалации
  • Клиент — отправляет заявки и получает уведомления
  • Администратор n8n — следит за работой системы

Что для него важно в работе сценария?

  • Инженеру: чёткая постановка задачи с правильной категорией и специалистом
  • Руководителю: проактивные уведомления о нарушениях SLA до жалобы клиента
  • Клиенту: быстрый ответ с подтверждением и прозрачные сроки
  • Администратору: надёжность, идемпотентность, понятные логи ошибок

6. Входные и выходные данные

6.1. Что поступает на вход

Стартовая точка сценария:

  • Webhook-запрос POST на https://n8n.eduardwit.ru/webhook/service-request
  • Входящее письмо на admin@eduardwit.ru
  • Cron-триггеры: каждые 15 мин (SLA-монитор), каждые 30 мин (каталог)

Какие данные поступают на вход?

{
  "client_name": "Алексей Смирнов",
  "email": "alexey.smirnov@zavod.ru",
  "equipment": "Компрессор Atlas Copco GA37",
  "issue_text": "Компрессор не запускается, посторонние шумы..."
}

6.2. Что получается на выходе

Что появляется после выполнения сценария?

  • Запись в servicerequests со статусом dispatched
  • Задача в Битрикс24 с тегами service-request и hash:b11b5b54
  • Запись в sent_emails с HTML-письмом клиенту
  • Записи в sla_events при эскалациях
  • Обогащённые данные из каталога (бренд, цена, рейтинг)

Где сохраняется результат?

Supabase (PostgreSQL) — схема service_dept, таблицы: servicerequests, sent_emails, sla_events, validation_failures, workflow_errors.

Кому отправляется результат?

  • Битрикс24 — ответственному инженеру
  • Email — клиенту (корпоративный шаблон)
  • Telegram — руководителю (при эскалациях)

7. Используемые сервисы и инструменты

Сервис / инструмент Для чего использовался
n8n 2.27.3 (Self-hosted) Оркестрация всех 6 модулей автоматизации
Supabase (PostgreSQL + PostgREST) Основная БД с RLS, REST API, realtime
GigaChat (Сбер) ИИ-классификация заявок через LangChain
Битрикс24 (REST API) CRM для управления задачами инженеров
Telegram Bot API Уведомления инженерам и руководителю
Mock SMTP Тестовая отправка email-уведомлений клиентам
DummyJSON API Тестовый каталог оборудования для обогащения
FNV-1a hash Детерминированный хеш для идемпотентности
⚠️ Тестовые режимы:
  • SMTP — mock-режим (в production заменится на VK Workspace / SendGrid)
  • Каталог — DummyJSON (в production — реальный внутренний API каталога)

8. Схема процесса

flowchart LR Client((👤 Клиент)) -->|Webhook/Email| A[IN_Service_Intake
📨 FNV-1a hash] A -->|raw| B[(Supabase DB)] B -->|enriched| C[CORE_AI_Classifier
🤖 GigaChat] C -->|enriched| B B -->|enriched| D[OUT_Dispatch
📋 Bitrix24 + Email] D -->|dispatched| B D --> E((👨‍🔧 Инженер)) D --> F((👤 Клиент email)) G[SRV_SLA_Monitor
⏱️ 15 мин] -->|эскалация| H((📱 Telegram)) G --> B I[OUT_Enrich_From_Catalog
📦 DummyJSON] -->|обогащение| B J[SRV_Global_Error_Handler
🛡️ Retry] -.->|при ошибках| A style A fill:#10b981,stroke:#065f46,color:#fff style C fill:#f59e0b,stroke:#78350f,color:#fff style D fill:#ef4444,stroke:#7f1d1d,color:#fff style G fill:#8b5cf6,stroke:#5b21b6,color:#fff style I fill:#ec4899,stroke:#831843,color:#fff style J fill:#3b82f6,stroke:#1e40af,color:#fff style B fill:#1e40af,stroke:#1e3a8a,color:#fff

Краткое описание схемы

  1. Приём заявки (IN_Service_Intake) → FNV-1a hash → сохранение со статусом raw
  2. ИИ-классификация (CORE_AI_Classifier) → GigaChat → статус enriched
  3. Диспетчеризация (OUT_Dispatch) → задача в Битрикс24 + email клиенту → dispatched
  4. SLA-мониторинг каждые 15 мин → проверка сроков → эскалация в Telegram
  5. Обогащение каталогом (DummyJSON) → обновление данных оборудования
  6. Глобальная обработка ошибок → retry-логика + логирование + Telegram

Какие условия или развилки есть в процессе?

  • IF_Valid_Request: спам / нет email → DLQ (validation_failures)
  • IF_Valid_AI_Response: невалидный JSON от ИИ → DLQ
  • IF_Task_Not_Exists: задача уже есть → пропуск создания (идемпотентность)
  • IF_Has_Alerts: нет нарушений SLA → пропуск эскалации
  • IF_Is_Retryable: transient-ошибка → retry; business → DLQ

Какие точки контроля предусмотрены?

  • SQL-дашборды: статистика заявок, SLA compliance, ошибки
  • Таблица sla_events: история всех эскалаций
  • Таблица workflow_errors: история всех ошибок с retry-сессиями
  • Таблица validation_failures: DLQ с причинами отклонения

9. Реализация сценария в n8n

9.1. Общая логика

Сколько рабочих процессов создано?

6 основных + 1 сервисный (Global Error Handler) = 7 рабочих процессов

Что делает каждый рабочий процесс?

Сценарий Функция
IN_Service_Intake Приём заявок с защитой от дублей (FNV-1a hash)
CORE_AI_Classifier Пакетная ИИ-классификация через GigaChat
OUT_Dispatch Создание задач в Битрикс24 + email клиентам
SRV_SLA_Monitor Cron-проверка SLA каждые 15 минут с эскалацией
OUT_Enrich_From_Catalog Обогащение заявок из каталога каждые 30 минут
SRV_Global_Error_Handler Глобальный обработчик ошибок с retry-логикой
DLQ_Dashboard Мониторинг невалидных заявок

9.2. Основные шаги сценария

Шаг Что происходит Узел / сервис
1 Приём заявки, вычисление FNV-1a hash IN_Webhook + UTIL_Compute_Hash
2 Проверка на дубликат и спам, сохранение OUT_Check_Duplicate → OUT_Save_To_DB
3 Пакетная выборка заявок со статусом raw IN_Fetch_Raw (Supabase GET)
4 ИИ-классификация через GigaChat с JSON-валидацией AI_Agent (LangChain)
5 Сохранение обогащённых данных в БД CORE_Save_Enrichment (Supabase PATCH)
6 Создание задачи в Битрикс24 с тегами OUT_Create_Bitrix24_Task
7 Формирование и отправка HTML-письма клиенту OUT_Format_Email → OUT_Mock_Send_Email
8 Обновление статуса + сохранение в sent_emails OUT_Update_Status
9 Cron-проверка SLA, расчёт % выполнения IN_SLA_Trigger → CORE_Calculate_SLA
10 Эскалация через Telegram при нарушениях OUT_Send_Engineer_Reminder / OUT_Send_Manager_Escalation

9.3. Работа с данными

Какие поля вы передавали между шагами?

  • request_hash (FNV-1a) — сквозной идентификатор через все модули
  • status (raw → enriched → dispatched) — управление потоком
  • ai_parsed (JSON с классификацией ИИ)
  • crm_task_id (ID задачи в Битрикс24)
  • sla_calc (процент выполнения SLA)

Какие данные преобразовывали?

  • Даты: ISO-формат → человекочитаемый (08.07.2026, 07:57:34)
  • Приоритеты: high/medium/low → 2/1/0 для Битрикс24
  • Категории: в emoji-шаблоны для писем (🔧 repair, 💬 consultation)
  • Тексты: санитизация (удаление спецсимволов) перед сохранением в БД

Использовались ли условия, фильтры, списки или циклы?

  • IF-ноды: 12 раз (валидация, ветвление, идемпотентность)
  • Batch processing: $input.all().map() во всех Code-нодах
  • pairedItem: для связи HTTP Request с исходными данными
  • SplitInBatches: для последовательной обработки SLA-алертов

Как вы проверяли обязательные поля?

  • JSON Schema валидация ответа ИИ (category, priority, specialist, summary, confidence)
  • Regex для email: /^[^\s@]+@[^\s@]+\.[^\s@]+$/
  • Проверка длины issue_text (>20 символов)
  • Фильтр по confidence ≥ 50%

10. Использование нейросети

Для какой задачи использовалась нейросеть?

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

Какой сервис использовался?

GigaChat (Сбер) через LangChain Agent с Output Parser для строгой JSON-схемы.

Какой запрос был отправлен в нейросеть?

Ты — опытный диспетчер сервисного отдела промышленного оборудования с 15-летним стажем.
Проанализируй обращение клиента и верни СТРОГО JSON:
{
  "category": "repair|warranty|consultation|maintenance",
  "priority": "high|medium|low",
  "recommended_specialist": "electrician|mechanic|software|universal",
  "summary": "краткая сводка (20+ символов)",
  "estimated_hours": 0.5-40,
  "requires_onsite": true/false,
  "confidence": 0-100,
  "reasoning": "обоснование решения"
}

В каком формате должен был вернуться ответ?

Строгий JSON с валидацией по схеме. Все enum-значения проверялись, summary ≥ 10 символов, confidence ≥ 50%.

Как вы проверяли, что ответ можно использовать дальше в сценарии?

Нода CORE_Validate_AI_Response с 6 проверками:
  1. Все обязательные поля присутствуют
  2. Значения в допустимых enum
  3. summary.length ≥ 10
  4. 0.5 ≤ estimated_hours ≤ 40
  5. 50 ≤ confidence ≤ 100
  6. При провале → заявка уходит в DLQ с причиной ai_validation_failed

Пример ответа нейросети:

{
  "category": "repair",
  "priority": "high",
  "recommended_specialist": "mechanic",
  "summary": "Компрессор не запускается, посторонние шумы и вибрация, критичный простой цеха",
  "estimated_hours": 8,
  "requires_onsite": true,
  "confidence": 95,
  "reasoning": "Текст чётко указывает на поломку компрессора..."
}

11. Хранение данных

Какие таблицы или базы были созданы?

Схема service_dept в Supabase (PostgreSQL):
Таблица Назначение
servicerequests Основная таблица заявок
sent_emails Журнал отправленных писем
validation_failures DLQ для невалидных заявок
sla_events История SLA-эскалаций (с UNIQUE-индексом)
workflow_errors Журнал ошибок с retry-сессиями
catalog_cache Кеш каталога оборудования

Какие поля есть в основной таблице servicerequests?

  • Идентификация: id, request_hash, client_name, email, equipment, issue_text
  • Классификация ИИ: category, priority, responsible, ai_summary, ai_confidence
  • SLA: deadline, sla_status, sla_warning_sent, sla_critical_sent, sla_breached_sent
  • Диспетчеризация: status, crm_task_id, dispatched_at, client_notified_at
  • Каталог: catalog_brand, catalog_model, catalog_price, catalog_rating, catalog_match_confidence

Какие статусы используются в процессе?

  • raw → заявка принята, не классифицирована
  • enriched → ИИ классифицировал
  • dispatched → задача создана, письмо отправлено
  • DLQ → невалидная заявка (спам / без email / AI invalid)

Есть ли журнал действий?

Да, 3 журнала:
  • sent_emails: каждое отправленное письмо (recipient, subject, body_html, message_id)
  • sla_events: каждая эскалация (warning_sent/critical_sent/breached) с UNIQUE-индексом
  • workflow_errors: каждая ошибка (error_message, stack, retry_session_id)

12. Обработка ошибок и нестандартных случаев

Какие ошибки вы предусмотрели?

  • Retryable (transient): timeout, 502/503/504, 429, econnreset, rate limit, socket hang up
  • Non-retryable (business): 400/401/403/404, invalid JSON, validation failed
  • Data quality: спам, отсутствие email, короткий текст
  • AI errors: невалидный JSON от GigaChat, низкий confidence

Что происходит, если не хватает обязательных данных?

Заявка уходит в validation_failures с указанием причины:
  • spam_detected (ключевые слова: "казино", "выиграй")
  • missing_email (невозможно отправить уведомление)
  • text_too_short (менее 20 символов)

Что происходит, если сервис не отвечает?

  1. SRV_Global_Error_Handler ловит ошибку
  2. Классифицирует по retryable-паттернам (regex-матчинг)
  3. Если transient — retry до 3 раз с экспоненциальной задержкой через RPC increment_retry_session
  4. Если business — сразу в workflow_errors
  5. После 3 неудачных попыток — Telegram-уведомление руководителю

Есть ли уведомление ответственному при ошибке?

Да, через Telegram-бот EduardWIT_Alerts_Bot с полной информацией: workflow_name, node_name, error_message, execution_url, количество попыток.

13. Тестирование

Проведены 5 тестовых запусков с реальными данными:

№ Данные Ожидаемый Фактический Статус
1 3 валидные заявки (Алексей/Елена/Дмитрий) Все → dispatched Все → dispatched ✅
2 Спам + заявка без email DLQ DLQ (spam_detected + missing_email) ✅
3 Повторный запуск OUT_Dispatch 0 дублей 0 дублей (4 уровня идемпотентности) ✅
4 Заявки с SLA 50%/80%/100% 3 Telegram-уведомления 3 уведомления + запись в sla_events ✅
5 Повторный запуск SLA-монитора 0 новых уведомлений 0 уведомлений (идемпотентность) ✅

Финальная статистика (acceptance test)

3
📨 Принято заявок
3
🤖 Обработано ИИ
2
🗑️ Ушло в DLQ
3
📋 Задач в Битрикс24
3
📧 Отправлено писем
0
♻️ Дублей

Какие ошибки были найдены во время тестирования?

  1. numeric field overflow в catalog_match_confidence (NUMERIC(3,2) не вмещал 95%)
  2. request is not defined — склеились два return в merge-ноде
  3. Can't use .first() here — смешение режимов Run Once for All/Each Item
  4. message text is empty в Telegram — отправка пустого сообщения
  5. PGRST204 — PostgREST не видел новую колонку (кеш схемы)

Как вы их исправили?

  1. Изменил тип колонки на NUMERIC(5,2)
  2. Переписал код merge-ноды в чистом виде
  3. Стандартизировал все Code-ноды на Run Once for All Items + $input.all().map()
  4. Добавил IF-фильтры IF_Has_Engineer_Messages перед Telegram-нодами
  5. Добавил NOTIFY pgrst, 'reload schema' после DDL-операций

14. Доказательства работоспособности

Краткое описание типового запуска:

  1. 08:10:00 — Клиент Алексей Смирнов отправляет заявку через webhook
  2. 08:10:01 — IN_Service_Intake вычисляет FNV-1a hash b11b5b54, сохраняет в БД
  3. 08:10:15 — CORE_AI_Classifier запускается, GigaChat: repair / high / mechanic / 95%
  4. 08:10:16 — Статус enriched, дедлайн = +4 часа
  5. 08:10:30 — OUT_Dispatch создаёт задачу в Битрикс24 с тегами
  6. 08:10:31 — Отправляется HTML-письмо клиенту с номером заявки b11b5b54
  7. 08:10:32 — Статус → dispatched, запись в sent_emails
  8. 08:25:00 — SRV_SLA_Monitor: 50% SLA → 🟡 warning инженеру
  9. 11:22:00 — 80% SLA → 🟠 critical руководителю
  10. 12:10:00 — 100% SLA → 🔴 breached обоим
✅ Повторный запуск в 12:15: Fetched 0 requests — идемпотентность работает.

15. Ссылки на материалы проекта

Материал Ссылка / расположение
JSON сценариев n8n SRV_Global_Error_Handler_Test.json, + 6 экспортов модулей
Схема процесса Mermaid-диаграмма в Project_1_Complete_Documentation.html
База Supabase https://supabase.eduardwit.ru (схема service_dept)
HTML-документация 4 файла: OUT_Dispatch, SRV_SLA_Monitor, OUT_Enrich_From_Catalog, Project_1_Complete
SQL-дашборды 12 запросов для мониторинга (статистика, SLA, ошибки)
Webhook endpoint https://n8n.eduardwit.ru/webhook/service-request
Пример задачи в Битрикс24 [HIGH] Компрессор Atlas Copco GA37 - механик (теги: service-request, hash:b11b5b54)
Пример письма клиенту 🔧 Ремонт: Компрессор Atlas Copco GA37 — заявка #b11b5b54

16. Безопасность и данные

Использовались ли реальные или тестовые данные?

Тестовые данные: имена клиентов (Алексей Смирнов, Елена Волкова), тестовые email (@zavod.ru, @office.ru), реальное оборудование (Atlas Copco, Haas VF-2).

Если использовались реальные данные, были ли они обезличены?

Реальные персональные данные не использовались. Все email и имена — фиктивные.

Где хранятся ключи доступа и пароли?

В n8n Credentials (шифрованное хранилище):
  • Supabase account (anon key + service_role)
  • Telegram_EW_Alerts_Bot (bot token)
  • Bitrix24 Webhook (user_id + secret)
  • GigaChat API (OAuth credentials)

Какие данные нельзя передавать в открытом виде?

  • Токены API (хранятся только в n8n Credentials)
  • service_role key Supabase (только server-side)
  • Персональные данные клиентов (email, телефон) — передаются по HTTPS

Какие ограничения вы учли при работе с сервисами?

  • RLS (Row Level Security) в Supabase — изоляция данных по ролям
  • Prefer: resolution=ignore-duplicates для идемпотентных POST
  • UNIQUE constraints на (request_hash), (request_hash, event_type)
  • Rate limiting detection в Error Handler (429 → retry)
  • Санитизация данных перед сохранением (удаление управляющих символов)

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

Что теперь работает автоматически?

  • Приём заявок из 2 каналов (webhook + email)
  • ИИ-классификация через GigaChat с 95% точностью
  • Создание задач в Битрикс24 с правильной категоризацией
  • Корпоративные email-уведомления с 4 шаблонами
  • SLA-мониторинг каждые 15 минут с 3-уровневой эскалацией
  • Обогащение заявок данными из каталога
  • Глобальная обработка ошибок с retry-логикой

Какую пользу это даёт бизнесу или команде?

60x
Ускорение обработки (15 мин → 15 сек)
100%
SLA-compliance
0
Потерь заявок
0
Дублей

Какая ручная работа сократилась?

  • Диспетчер больше не читает и не классифицирует заявки
  • Не создаёт задачи вручную в Битрикс24
  • Не пишет шаблонные письма клиентам
  • Не следит за сроками — система сама эскалирует

Что можно улучшить в следующей версии?

  • Заменить Mock SMTP на реальный (VK Workspace / SendGrid)
  • Подключить реальный внутренний каталог вместо DummyJSON
  • Добавить мобильное приложение для инженеров
  • Внедрить AI-чатбот для клиентов (FAQ + статус заявки)
  • Интеграция с 1С для учёта запчастей и счетов

18. Выводы проекта

Что получилось особенно хорошо?

  • Архитектура с 6 независимыми модулями, каждый из которых можно развивать отдельно
  • Идемпотентность на всех уровнях — 0 дублей при любых повторных запусках
  • Batch processing через $input.all().map() — ускорение в 5-10 раз
  • Полная HTML-документация с Mermaid-диаграммами (4 файла)

Что можно добавить в следующей версии сценария?

  • Мобильное приложение для инженеров (React Native + Supabase Realtime)
  • AI-чатбот для клиентов (FAQ + статус заявки через request_hash)
  • Интеграция с 1С для учёта запчастей и автоматического выставления счетов
  • Дашборды в Metabase для бизнес-аналитики
  • Мультиязычность (EN/RU) для международных клиентов