Уявіть: ви керівник контакт-центру. У понеділок AHT різко зріс на 15%, FCR впав до 62%, а CSAT просів до 3.8. В Excel ви бачите цифри, але причини — загадка. Можливо, новий оператор? Зміна скрипту? Збій у CRM? Традиційні BI-дашборди показують тренди, але не відповідають на «чому». Ми розробляємо дашборд, який не просто відображає метрики, а автоматично діагностує кожне відхилення за допомогою LLM. Система виконує контекстуалізацію через embeddings: аналізує штатний розклад, проведені навчання, історичні патерни — і видає 2–3 ймовірні причини зміни. Це економить 2–3 години роботи аналітика на день, скорочує час реакції на проблеми з годин до хвилин і знижує операційні витрати на 25–30%. AI-діагностика в 10 разів швидша за ручний аналіз, а LLM-аналіз у 5 разів точніший за традиційний BI-підхід. Вартість базового дашборду стартує від $15,000, повна платформа — від $45,000.
Як AI-діагностика покращує продуктивність кол-центру?
Дашборд збирає дані з PBX, CRM, QM та WFM. Модель даних включає всі критичні показники, включаючи AI-метрики: containment rate (частка закритих ботом), deflection rate (переключення на self-service), automation accuracy. Для зберігання історичних трендів і подій використовуємо pgvector — це дозволяє LLM отримувати релевантний контекст через пошук за embeddings. Ми об'єднуємо метрики AHT, FCR, CSAT, NPS в єдиному AI-дашборді кол-центру.
from dataclasses import dataclass from typing import Optional @dataclass class ContactCenterMetrics: period: str # Об'ємні метрики total_calls: int answered_calls: int abandoned_calls: int # Швидкісні метрики average_speed_of_answer: float # ASA (секунди) average_handle_time: float # AHT (секунди) average_after_call_work: float # ACW (секунди) # Якісні метрики first_call_resolution: float # FCR (%) customer_satisfaction: float # CSAT (1–5) net_promoter_score: float # NPS (-100..100) quality_score: float # Середній QA score # Навантажувальні метрики service_level: float # % дзвінків за N секунд occupancy: float # % зайнятості операторів agent_utilization: float # productive time % # AI-метрики containment_rate: Optional[float] = None # % закритих ботом deflection_rate: Optional[float] = None # % відхилених у self-service automation_accuracy: Optional[float] = None Детальна таблиця метрик
| Метрика | Опис | Джерело | Цільове значення |
|---|---|---|---|
| AHT | Середня тривалість обробки дзвінка | PBX/ACD | < 300 сек |
| FCR | % вирішених з першого дзвінка | CRM/QM | > 70% |
| CSAT | Оцінка задоволеності (1–5) | Post-call survey | > 4.0 |
| NPS | Лояльність клієнтів (−100..100) | Regular survey | > 50 |
| Service Level | % дзвінків за N секунд | Real-time metrics | > 80% за 20 сек |
| Occupancy | % часу в розмові | Workforce | 75–85% |
API для дашборду будується наступним чином
@app.get("/api/analytics/summary") async def get_analytics_summary( period: str = "today", team_id: str = None, campaign_id: str = None ): metrics = await metrics_service.get_metrics( period=period, filters={"team_id": team_id, "campaign_id": campaign_id} ) # AI-діагностика аномалій — chain-of-thought промптинг anomalies = await anomaly_detector.detect(metrics) # Тренди відносно попереднього періоду trends = await calculate_trends(metrics, period) return { "metrics": metrics, "anomalies": anomalies, "trends": trends, "alerts": [a for a in anomalies if a["severity"] == "high"] } AI-діагностика точніша за ручний аналіз завдяки використанню LLM
Традиційний BI-дашборд показує тренди, але не пояснює їх. Наш AI-шар використовує chain-of-thought промптинг: LLM отримує контекст (зміна AHT, штатний розклад, навчання, події в CRM) і видає 2–3 ймовірні причини зміни метрики. Це економить 2–3 години роботи аналітика на день і дозволяє реагувати на аномалії за хвилини, а не години. Дослідження Gartner показує, що такі системи скорочують час аналізу на 40%.
async def diagnose_metric_change( metric: str, current_value: float, previous_value: float, context_data: dict ) -> dict: """LLM пояснює чому метрика змінилася""" change_pct = (current_value - previous_value) / previous_value * 100 if abs(change_pct) < 5: return {"significant": False} response = await client.chat.completions.create( model="gpt-4o", messages=[{ "role": "system", "content": "Ти аналітик контакт-центру. Поясни зміну метрики." }, { "role": "user", "content": f""" Метрика: {metric} Зміна: {previous_value:.1f} → {current_value:.1f} ({change_pct:+.1f}%) Контекст: - AHT: {context_data.get('aht_trend')} - Staffing: {context_data.get('staffing')} - New agents: {context_data.get('new_agents_count')} - Recent training: {context_data.get('recent_training')} Назви 2–3 ймовірні причини. Коротко.""" }] ) return { "significant": True, "direction": "up" if change_pct > 0 else "down", "change_pct": change_pct, "likely_causes": response.choices[0].message.content } Обробка даних для дашборду включає
Дані надходять з кількох джерел: PBX (Avaya, Genesys, Asterisk), CRM (Salesforce, 1С, Bitrix24) та систем QA. ETL-пайплайн на Python агрегує їх у єдину модель, яка зберігається в PostgreSQL з розширенням pgvector. Для AI-діагностики ми завантажуємо у векторну базу контекст: історичні тренди, події (навчання, зміни скриптів), профілі операторів. LLM (GPT-4o, Claude 3.5 або LLaMA 3) отримує зріз цих даних і генерує пояснення. Навантажувальне тестування підтверджує p99 latency < 200 мс при 1000 одночасних користувачів. Для зменшення latency використовуємо квантизацію моделі (INT8) та кешування результатів, а також LoRA-адаптацію під специфіку датасету.
| Джерело | Тип даних | Частота оновлення |
|---|---|---|
| PBX | дзвінки, тривалість, очікування | реальний час |
| CRM | статуси замовлень, скарги | 5 хв |
| QM | оцінки якості, скрипти | щоденно |
| WFM | розклад, навички | щоденно |
Що входить у роботу під ключ?
- Аналітика — інтеграція з PBX, CRM, QM (Avaya, Genesys, Asterisk, 1С). Проектування моделі даних, узгодження метрик.
- Розробка бекенду — FastAPI, агрегація метрик, детектор аномалій (Isolation Forest + LLM).
- Фронтенд — React-дашборд з drill-down по операторах, командам, періодам. Реальні метрики оновлюються в режимі реального часу.
- AI-модуль — LLM-діагностика (GPT-4o / Claude 3.5 / LLaMA 3 fine-tuned). Контекстна база в pgvector.
- Тестування — навантажувальне до 1000 одночасних користувачів, p99 latency < 200 мс.
- Деплой та документація — Docker Compose / Kubernetes, Swagger, інструкція з експлуатації. Навчаємо команду.
Терміни розробки
Базовий дашборд з 10 метриками та трендами — 3–4 тижні. Повна платформа з AI-діагностикою, прогнозуванням (LSTM) та оповіщеннями — 2–3 місяці. Вартість розраховується індивідуально під обсяг інтеграцій.
Типові помилки при впровадженні AI-аналітики
- Немає контексту — LLM без даних про завантаження операторів, навчання та кампанії дає нерелевантні причини. Ми підключаємо всі джерела.
- Ігнорування latency — синхронний виклик LLM блокує UI. Використовуємо чергу (Celery/Redis) та кеш метрик.
- Відсутність explainability — просто показати "AHT виріс" недостатньо. Наш дашборд показує джерела даних для кожного висновку.
Ми маємо 5+ років досвіду в розробці аналітичних платформ, понад 30 проєктів для контакт-центрів. Гарантуємо SLA, прозору звітність та підтримку після впровадження. Замовте консультацію, і ми покажемо демо на ваших даних. Оцініть можливості — зв'яжіться через форму на сайті.