⚖️ AI-агент «Адвокат клиента»

Проактивная защита клиентов Kazakhtelecom от повторных обращений

ДУКО · Hackathon 22.05.2026 · MVP Iteration 1

Камunda 7 · Spring Boot · Python · PostgreSQL

Проблема

Клиенты обращаются повторно по одному вопросу. Система реактивна, не видит истории, переводит между службами без результата.

КейсОбращенийПериодКаналы
№19816.01–28.08.20254 канала
№65909.07–02.10.20255 каналов
№34621.01–18.12.20253 канала
№51518.02–10.11.20253 канала
№2/4222025 год5 каналов
№72127.01–10.09.20254 канала

FCR ~45%, churn детракторов ~18%, NPS -35

Решение

AI-агент видит историю клиента поперёк каналов, классифицирует боль, маршрутизирует в правильный департамент, контролирует до закрытия — без повторного звонка клиента.

  • 🎯 Детекция аномалий — количественные + качественные + канальные триггеры
  • 🧠 AI-классификация: категория боли + приоритет (🟢🟡🔴⚫)
  • 🚦 Маршрутизация → ASC / NetMon / Finance / СТПК / КЦ
  • 📱 Проактивный контакт через WhatsApp/SMS
  • 👤 Human-in-the-loop для ⚫ ЧЁРНЫХ кейсов

Архитектура

┌── ИСТОЧНИКИ ─────────────────────────────────────┐
│ CRM · КЦ-160 · Omilia · WhatsApp · eOtinish      │
└────────────────────┬─────────────────────────────┘
                     │ Kafka (appeal.created, ticket.closed)
                     ▼
            ┌────────────────────┐
            │  CAMUNDA 7 ENGINE  │  ← BPMN-оркестратор
            │ client-advocate-   │
            │ main + route-to-   │
            │ department         │
            └─────────┬──────────┘
                     │ External Task polling
        ┌────────────┴────────────┐
        ▼                         ▼
  ┌──────────────┐         ┌──────────────────┐
  │ Java Workers │←───────→│   AI Service     │
  │ (Spring Boot)│  REST   │ (FastAPI)        │
  │ 18 handlers  │         │ sentiment+class. │
  └──────┬───────┘         └──────────────────┘
         │
         ▼
  ┌──────────────┐  ┌────────────────────┐
  │ PostgreSQL   │  │ Mock Integrations  │
  │ 5 tables     │  │ CRM·ASC·NetMon·WA  │
  └──────────────┘  └────────────────────┘

BPMN-процесс

[Старт] → EnrichProfile → ClassifyPain → ⟨Приоритет?⟩
   ├─ 🟢 GREEN  → StandardHandling
   ├─ 🟡 YELLOW → NotifySupervisor → Queue → ⏱ SLA 4h
   ├─ 🔴 RED    → RouteToDept → ProactiveContact → Control
   └─ ⚫ BLACK  → HumanTask(директор ДУКО) → PersonalEscal
                ↓
           NotifyResolved → CSAT → ⟨Доволен?⟩
                                ├─ Да  → Close
                                └─ Нет → Reopen (priority+1)

2 BPMN-процесса · 18 external task workers · 5 SLA-таймеров

Логика приоритезации

ПриоритетУсловияДействие
🟢 GREEN1–2 обращенияСтандартная обработка
🟡 YELLOW3–4 обр. / SLA >24ч / sentiment <−0.5Уведомить супервайзера, приоритет в очереди
🔴 RED5+ обр. / открытая заявка + новаяАвтоэскалация, проактивный контакт, компенсация
⚫ BLACK10+ обр. / угроза суда / VIPЭскалация директору ДУКО, персональный менеджер
if (total >= 10 || churnSignal) return "BLACK";
if (total >= 5  || (openTicket && total >= 3)) return "RED";
if (total >= 3  || sentiment < -0.5)  return "YELLOW";
return "GREEN";

Демо

Симуляция

  • 7 кейсов из PRD §1.2
  • Все → ⚫ BLACK (totalAppeals ≥ 10)
  • Маршрутизация по 4 системам:
    • 2× NetMon (NETWORK)
    • 2× ASC (EQUIPMENT)
    • 1× Finance (BILLING)
    • 1× СТПК (INSTALLATION)
    • 1× CC (SERVICE)

Ссылки

В дашборде каждый кейс имеет кнопку «Детали» — карточка оператора + полный лог BPMN-процесса.

Метрики успеха (OKR)

≥70%

FCR (baseline ~45%)

≤1.5

обращений на кейс (было 3.2)

≤48ч

время закрытия (было >10 дней)

≤10%

churn детракторов (было ~18%)

Горизонт — 6 месяцев. Подтверждение через A/B-тест в Итерации 4.

Технологический стек

СлойТехнология
ОркестраторCamunda 7.21 (self-hosted)
Backend / WorkersJava 17 + Spring Boot 3
AI / MLPython 3.11 + FastAPI · BERT · LightGBM
База данныхPostgreSQL 15
ОчередьApache Kafka (Iter 2+)
КэшRedis 7 (Iter 4)
КонтейнеризацияDocker + Kubernetes (Iter 4)
ДашбордStatic HTML (MVP) → Grafana (Iter 3)
МониторингPrometheus + Grafana + ELK

Roadmap

Итер.СрокСодержаниеГотово
1 · MVPНедели 1–4Camunda + workers + моки + 7 кейсов✅ Сейчас
2 · ИнтеграцииНедели 5–8CRM read-only, ASC API, NetMon, WhatsApp, Kafka—
3 · AI-слойНедели 9–12BERT sentiment, LLM-карточки, churn-модель, BI-дашборд—
4 · МасштабНедели 13–16K8s, нагрузочное, A/B-тест, security audit—

Риски

РискВеро.Митигация
CRM-интеграция > 2 мес.ВысокаяНачать с CSV/Excel выгрузки
Ложные срабатывания триггеровСредняяРучная верификация первые 4 недели
Сопротивление операторовСредняяUX-исследование + обучение + геймификация
Утечка персданныхНизкаяМаскировка в логах, RBAC, AES-256 шифрование

Что дальше

  • ✅ MVP готов · 7 кейсов проходят полный pipeline
  • ▶ Согласовать доступ к CRM + ASC API (Итерация 2)
  • ▶ Стартовать обучение sentiment-модели RU+KZ
  • ▶ Подобрать пилот: 1 регион × 4 недели

Связь: ДУКО, Kazakhtelecom · Демо: этот дашборд