Name: Astervis
Availability: InStock
Author: Astervis

Ваша АТС Asterisk каждый час порождает тысячи точек данных — записи о звонках, события очередей, смены статусов операторов, метрики SIP-каналов и статистику загрузки транков. При этом в большинстве колл-центров на Asterisk эти данные никто не видит в реальном времени. Руководители работают по выгрузкам в конце дня или, что хуже, по ощущениям.

В этом руководстве разбираем, как собрать полноценный дашборд KPI для колл-центра на Asterisk: какие показатели отслеживать, где лежат данные, как их запрашивать и какими способами быстрее всего перейти от нулевой видимости к полной операционной картине.

Зачем колл-центру на Asterisk дашборд KPI

Прежде чем переходить к реализации, честно посмотрим, что происходит без нормальной видимости:

Без дашборда:

—Супервизоры узнают о переполнении очереди спустя часы
—Руководитель не ответит на вопрос «как у нас дела сегодня?», не выгрузив CDR
—Оценка работы операторов строится на субъективных впечатлениях, а не на данных
—Нарушения SLA остаются незамеченными, пока не пожалуется клиент
—Решения по численности смены принимаются по средним значениям, а не по пиковым часам

С грамотно собранным дашбордом:

—Онлайн-табло очередей позволяет супервизору реагировать за секунды, а не за часы
—Результаты дня видны с одного взгляда всем заинтересованным
—Работа с операторами становится обоснованной и справедливой
—Соблюдение SLA отслеживается в реальном времени с автоматическими алертами
—Тепловые карты показывают, когда операторов не хватает (а когда их избыток)

По отраслевым бенчмаркам, колл-центры с аналитическими дашбордами реального времени сокращают среднее время ожидания на 15-25% и повышают решение с первого обращения на 10-15% уже в первый квартал после внедрения.

20 KPI, которые должен отслеживать каждый колл-центр на Asterisk

Не все метрики одинаково полезны. Ниже — рабочая система показателей, разбитая по тому, кому они нужны и как часто их смотреть.

Уровень 1: реальное время (табло) — обновление каждые 5-10 секунд

Это те метрики, которые у супервизора должны быть на экране весь день:

KPI	Формула	Цель	Источник данных
Звонков в очереди	Количество ожидающих абонентов	< 5	AMI QueueStatus
Максимальное ожидание	Наибольшее ожидание среди текущих абонентов	< 60s	AMI QueueStatus
Свободные операторы	Операторы в статусе «Not In Use»	> 20% от общего числа	AMI QueueMember
Уровень сервиса (скользящий)	(Отвечено в пределах порога / Всего поступило) × 100	≥ 80/20	queue_log
Активные разговоры	Количество соединённых каналов	—	AMI CoreShowChannels
Потеряно (за сегодня)	Звонки, где абонент положил трубку в очереди	< 5%	события ABANDON в queue_log

Уровень 2: работа операторов — обновление каждые 30-60 секунд

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

KPI	Формула	Цель	Источник данных
Среднее время обработки (AHT)	(Время разговора + Время удержания + ACW) / Обработано звонков	По отрасли: 4-6 мин	CDR + queue_log
Загрузка оператора	(Общее время обработки / Время в системе) × 100	75-85%	queue_log PAUSE/UNPAUSE
Решение с первого звонка (FCR)	(Звонки, решённые без повторного обращения / Всего звонков) × 100	> 70%	CDR + данные CRM
Звонков в час	Всего обработано звонков / Отработано часов	8-15 (зависит от задач)	события CONNECT в queue_log
Доля удержания	Общее время удержания / Общее время разговора	< 10%	поле holdtime в CDR
Доля переводов	Переводы / Всего звонков × 100	< 15%	события TRANSFER в queue_log
Постобработка (ACW)	Время на оформление после завершения звонка	< 60s	queue_log PAUSE(ACW)

Уровень 3: операционный — обновление каждые 5-15 минут

Эти метрики питают тактические решения в течение дня:

KPI	Формула	Цель	Источник данных
Средняя скорость ответа (ASA)	Общее время ожидания / Отвечено звонков	< 30s	queue_log CONNECT
Доля потерянных звонков	Потеряно / (Отвечено + Потеряно) × 100	< 5%	queue_log
Распределение времени ожидания	Гистограмма ожиданий (0-15s, 15-30s и т. д.)	80% до 30s	queue_log
Загрузка транков	Активные каналы транка / Общая ёмкость × 100	< 70% (запас)	AMI
Успешность обратных звонков	Успешные обратные звонки / Заявки на обратный звонок × 100	> 85%	CDR + логи обратных звонков

Уровень 4: стратегический — ежедневные и еженедельные отчёты

На них опираются решения по штату, обучению и бизнесу в целом:

KPI	Формула	Цель	Источник данных
Стоимость звонка	Общие операционные расходы / Всего обработано звонков	Зависит от отрасли	CDR + финансовые данные
Удовлетворённость клиентов (CSAT)	Среднее по ответам в опросах	> 4.2/5	опрос после звонка
Текучесть операторов	Ушедшие операторы / Средняя численность × 100	< 3%/месяц	данные HR

Разбираемся с источниками данных в Asterisk

Прежде чем что-то строить, нужно понимать, где лежат данные. Asterisk хранит информацию колл-центра в нескольких подсистемах:

1. CDR (Call Detail Records)

Таблица CDR — основной источник исторических данных. Каждый завершённый звонок оставляет запись:

asterisk*CLI> cdr show status

Ключевые поля CDR для дашбордов:

-- PostgreSQL CDR table structure (typical)
CREATE TABLE cdr (
    calldate    TIMESTAMPTZ NOT NULL,
    clid        VARCHAR(80),
    src         VARCHAR(80),     -- Caller number
    dst         VARCHAR(80),     -- Dialed number/queue
    dcontext    VARCHAR(80),     -- Dial context
    channel     VARCHAR(80),     -- Originating channel
    dstchannel  VARCHAR(80),     -- Destination channel
    lastapp     VARCHAR(80),     -- Last application (Queue, Dial, etc.)
    lastdata    VARCHAR(80),     -- App arguments
    duration    INTEGER,         -- Total duration (ring + talk)
    billsec     INTEGER,         -- Billable seconds (talk only)
    disposition VARCHAR(45),     -- ANSWERED, NO ANSWER, BUSY, FAILED
    uniqueid    VARCHAR(150),    -- Unique call ID
    linkedid    VARCHAR(150)     -- Linked ID (bridges related legs)
);

CREATE INDEX idx_cdr_calldate ON cdr (calldate);
CREATE INDEX idx_cdr_dst ON cdr (dst);
CREATE INDEX idx_cdr_disposition ON cdr (disposition);

2. queue_log

Это самый богатый источник данных по очередям в реальном времени. Логируется каждое событие очереди:

-- queue_log format: time|callid|queuename|agent|event|data1|data2|data3|data4|data5
1711000000|1711000000.42|support|SIP/agent101|CONNECT|12|1711000000.42|5
1711000000|1711000000.43|sales|NONE|ABANDON|1|1|45

Ключевые события для отслеживания:

Событие	Что означает	Применение в дашборде
ENTERQUEUE	Абонент попал в очередь	Глубина очереди, интенсивность поступления
CONNECT	Оператор ответил	Время ожидания, ASA, уровень сервиса
ABANDON	Абонент бросил трубку в ожидании	Доля потерянных звонков
COMPLETECALLER	Разговор завершил абонент	AHT, длительность звонка
COMPLETEAGENT	Разговор завершил оператор	AHT, длительность звонка
RINGNOANSWER	Оператор не снял трубку	Пропущенные вызовы по оператору
TRANSFER	Звонок переведён	Доля переводов
PAUSE	Оператор на паузе (перерыв, ACW)	Загрузка, доступность
UNPAUSE	Оператор снял паузу	Загрузка, доступность
REMOVEMEMBER	Оператор вышел из очереди	Численность на линии
ADDMEMBER	Оператор вошёл в очередь	Численность на линии

Храните queue_log в базе данных, чтобы запросы работали быстро:

CREATE TABLE queue_log (
    id          BIGSERIAL PRIMARY KEY,
    time        TIMESTAMPTZ NOT NULL,
    callid      VARCHAR(80),
    queuename   VARCHAR(80),
    agent       VARCHAR(80),
    event       VARCHAR(32) NOT NULL,
    data1       VARCHAR(100),
    data2       VARCHAR(100),
    data3       VARCHAR(100),
    data4       VARCHAR(100),
    data5       VARCHAR(100)
);

CREATE INDEX idx_qlog_time ON queue_log (time);
CREATE INDEX idx_qlog_queue_event ON queue_log (queuename, event);
CREATE INDEX idx_qlog_agent ON queue_log (agent);

3. AMI (Asterisk Manager Interface)

AMI отдаёт текущее состояние системы через TCP-сокет:

Action: QueueStatus
Queue: support

Response: Success
...
Event: QueueParams
Queue: support
Calls: 3
Holdtime: 15
TalkTime: 245
Completed: 87
Abandoned: 4
ServiceLevel: 80.2
ServicelevelPerf: 85.1
...
Event: QueueMember
Queue: support
Name: Agent 101
StateInterface: SIP/agent101
Status: 1           -- 1=Not In Use, 2=In Use, 6=Ringing
Paused: 0
CallsTaken: 12
LastCall: 1711000000

4. CEL (Channel Event Logging)

Для детального разбора хода звонка (удержания, переводы, конференции):

CREATE TABLE cel (
    id          BIGSERIAL PRIMARY KEY,
    eventtype   VARCHAR(30),     -- CHAN_START, ANSWER, HOLD, UNHOLD, BRIDGE_ENTER, etc.
    eventtime   TIMESTAMPTZ,
    cid_name    VARCHAR(80),
    cid_num     VARCHAR(80),
    exten       VARCHAR(80),
    context     VARCHAR(80),
    channame    VARCHAR(80),
    linkedid    VARCHAR(80),
    uniqueid    VARCHAR(80),
    extra       TEXT              -- JSON with additional data
);

Как построить дашборд: сравниваем три подхода

Подход 1: своими силами на Grafana + PostgreSQL

Время на сборку: 60-120 часов | Стоимость: бесплатно (OSS) | Сопровождение: 5-10 ч/месяц

Самый распространённый вариант. Вы настраиваете Asterisk на запись CDR и queue_log в PostgreSQL, а затем собираете дашборды в Grafana на SQL-запросах.

Шаг 1. Настроить запись CDR в PostgreSQL

Правим /etc/asterisk/cdr_pgsql.conf:

[global]
hostname=localhost
port=5432
dbname=asterisk
user=asterisk
password=your_secure_password
table=cdr

Шаг 2. Настроить запись queue_log в базу

В /etc/asterisk/extconfig.conf:

[settings]
queue_log => pgsql,asterisk,queue_log

Шаг 3. Написать SQL-запрос под каждый KPI

Вот запрос уровня сервиса в реальном времени для Grafana:

-- Service Level (80/20) for the last hour, by queue
WITH events AS (
    SELECT
        queuename,
        event,
        CAST(data1 AS INTEGER) AS wait_time
    FROM queue_log
    WHERE time >= NOW() - INTERVAL '1 hour'
      AND event IN ('CONNECT', 'ABANDON')
)
SELECT
    queuename AS "Queue",
    COUNT(*) FILTER (WHERE event = 'CONNECT') AS answered,
    COUNT(*) FILTER (WHERE event = 'ABANDON') AS abandoned,
    ROUND(
        100.0 * COUNT(*) FILTER (WHERE event = 'CONNECT' AND wait_time <= 20)
        / NULLIF(COUNT(*), 0), 1
    ) AS "Service Level %"
FROM events
GROUP BY queuename
ORDER BY queuename;

Тепловая карта нагрузки по часам:

-- Heatmap: calls by hour and day of week (last 4 weeks)
SELECT
    EXTRACT(DOW FROM calldate) AS day_of_week,
    EXTRACT(HOUR FROM calldate) AS hour,
    COUNT(*) AS call_count
FROM cdr
WHERE calldate >= NOW() - INTERVAL '28 days'
  AND dst IN ('support', 'sales', 'billing')
GROUP BY 1, 2
ORDER BY 1, 2;

Карточка эффективности оператора:

-- Agent performance: today
WITH agent_calls AS (
    SELECT
        agent,
        COUNT(*) FILTER (WHERE event = 'CONNECT') AS calls_taken,
        AVG(CAST(data2 AS INTEGER)) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')) AS avg_talk_time,
        AVG(CAST(data1 AS INTEGER)) FILTER (WHERE event = 'CONNECT') AS avg_wait_given,
        COUNT(*) FILTER (WHERE event = 'RINGNOANSWER') AS missed_rings,
        COUNT(*) FILTER (WHERE event = 'TRANSFER') AS transfers
    FROM queue_log
    WHERE time >= CURRENT_DATE
      AND agent != 'NONE'
    GROUP BY agent
),
agent_pauses AS (
    SELECT
        agent,
        SUM(
            EXTRACT(EPOCH FROM
                LEAD(time) OVER (PARTITION BY agent ORDER BY time) - time
            )
        ) FILTER (WHERE event = 'PAUSE') AS total_pause_seconds
    FROM queue_log
    WHERE time >= CURRENT_DATE
      AND event IN ('PAUSE', 'UNPAUSE')
    GROUP BY agent
)
SELECT
    ac.agent AS "Agent",
    ac.calls_taken AS "Calls",
    ROUND(ac.avg_talk_time) || 's' AS "Avg Talk",
    ROUND(ac.avg_wait_given) || 's' AS "Avg Wait Given",
    ac.missed_rings AS "Missed",
    ac.transfers AS "Transfers",
    COALESCE(ROUND(ap.total_pause_seconds / 60), 0) || ' min' AS "Break Time"
FROM agent_calls ac
LEFT JOIN agent_pauses ap ON ac.agent = ap.agent
ORDER BY ac.calls_taken DESC;

Плюсы: бесплатно, гибко настраивается, всё под вашим контролем Минусы: 60-120 часов на сборку, нужна экспертиза в SQL, в Grafana нет данных AMI в реальном времени (требуется своя прослойка), дашборды ломаются при смене версии Asterisk, постоянные затраты на сопровождение

Подход 2: QueueMetrics

Время на внедрение: 2-4 часа | Стоимость: CHF 8 за оператора в месяц | Сопровождение: 2-3 ч/месяц

QueueMetrics — классическое решение для отчётности по очередям Asterisk. Читает queue_log и отдаёт готовые отчёты.

Что вы получаете:

—Готовые исторические отчёты (более 30 штук)
—Базовое онлайн-табло
—Страницу оператора с показателями работы
—Контроль SLA

Ограничения:

—Написано на Java (нужна JVM, высокое потребление ресурсов)
—Устаревший интерфейс (никакой современной визуализации данных)
—Нет интеграции с AMI в реальном времени для состояния каналов
—Нет тепловых карт и продвинутых визуализаций
—Нет мониторинга транков
—Нет интеграции с CRM
—Цена растёт с числом операторов (дорого на масштабе: 50 операторов = $400/месяц)
—Только self-hosted, обновления вручную

Подход 3: Astervis (современное решение под задачу)

Время на внедрение: 15 минут | Стоимость: от $119/месяц | Сопровождение: ноль (автообновления)

Astervis подключается к вашей АТС Asterisk напрямую через AMI и CDR и даёт более 30 готовых дашбордов с данными в реальном времени:

Что вы получаете:

—Более 30 графиков, включая тепловые карты, линии трендов и распределения
—Онлайн-табло (обновление каждые 5 секунд через AMI)
—Дашборды по операторам с балльной оценкой KPI
—Аналитику очередей с контролем SLA
—Мониторинг загрузки транков
—Встроенное прослушивание записей разговоров
—Интеграцию с CRM (Bitrix24, AmoCRM)
—Планирование смен и графиков операторов
—Установку одной командой: curl -fsSL https://api.astervis.io/api/releases/install.sh | bash
—Self-hosted: данные остаются на вашем сервере

Устали угадывать, что происходит в очередях?

Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.

Попробовать бесплатно

Сравнение возможностей: все три подхода

Возможность	Grafana своими силами	QueueMetrics	Astervis
Время внедрения	60-120 часов	2-4 часа	15 минут
Данные в реальном времени	Ограниченно (без AMI)	Базово	Полностью AMI + CDR
Частота обновления	Обновление вручную	30-60 секунд	5 секунд
Готовые дашборды	Нет (собираете сами)	~30 отчётов	30+ графиков
Тепловые карты	Нужен свой SQL	❌	✅ Встроены
Карточки операторов	Нужен свой SQL	Базово	✅ Продвинутые
Мониторинг транков	Своя разработка	❌	✅
Интеграция с CRM	Своя разработка	❌	✅ Bitrix24, AmoCRM
Записи разговоров	Отдельный инструмент	Базово	✅ Встроенный плеер
Работа с телефона	Как настроите	❌	✅ Адаптивный интерфейс
Алерты	Алерты Grafana	Только e-mail	✅ Несколько каналов
Сопровождение	5-10 ч/месяц	2-3 ч/месяц	Ноль
Стоимость (50 операторов)	Бесплатно (+ ваше время)	~$400/месяц	$449/месяц
Современный интерфейс	Зависит от навыков	❌	✅

Как проектировать работающую компоновку дашбордов

Какой бы подход вы ни выбрали, эти принципы делают дашборд по-настоящему полезным:

Модель «трёх экранов»

Самые эффективные колл-центры используют три вида дашбордов, каждый — под свою аудиторию:

Экран 1: операционное табло (для супервизоров и операторов)

Выводится на большой телевизор, видимый всему залу:

┌─────────────────────────────────────────────────────┐
│  SERVICE LEVEL: 87%    │  CALLS IN QUEUE: 2         │
│  ████████████░░  80/20 │  LONGEST WAIT: 0:23        │
├─────────────────────────────────────────────────────┤
│  AVAILABLE AGENTS      │  TODAY'S STATS              │
│  ● Agent 101 (idle)    │  Answered: 234              │
│  ● Agent 102 (talking) │  Abandoned: 8 (3.3%)        │
│  ● Agent 103 (ringing) │  Avg Wait: 18s              │
│  ○ Agent 104 (break)   │  Avg Talk: 4:22             │
│  ● Agent 105 (talking) │  ASA: 14s                   │
├─────────────────────────────────────────────────────┤
│  HOURLY VOLUME          call volume by hour graph    │
│  8am ████████████ 45                                 │
│  9am ██████████████████ 67                           │
│ 10am ████████████████████████ 89  ← peak             │
│ 11am ██████████████████ 65                           │
└─────────────────────────────────────────────────────┘

Правила оформления табло:

—Максимум 6-8 метрик (перегруз информацией убивает пользу)
—Цветовое кодирование: зелёный (в норме), жёлтый (предупреждение), красный (нарушение)
—Размер шрифта, читаемый с 5 метров
—Автообновление каждые 5-10 секунд
—Никакой прокрутки — всё видно сразу

Экран 2: дашборд руководителя (для тимлидов и менеджеров)

Здесь принимаются тактические решения:

┌────────────────────────────────────────────────────────────┐
│ QUEUE PERFORMANCE (Today)                                  │
│ ┌──────────┬─────────┬──────────┬──────┬──────┬─────────┐ │
│ │ Queue    │ Offered │ Answered │ Abn% │ SL%  │ ASA     │ │
│ ├──────────┼─────────┼──────────┼──────┼──────┼─────────┤ │
│ │ Support  │ 156     │ 148      │ 5.1% │ 82%  │ 22s     │ │
│ │ Sales    │ 89      │ 87       │ 2.2% │ 91%  │ 12s     │ │
│ │ Billing  │ 67      │ 61       │ 9.0% │ 71%  │ 38s  ⚠ │ │
│ └──────────┴─────────┴──────────┴──────┴──────┴─────────┘ │
├────────────────────────────────────────────────────────────┤
│ AGENT LEADERBOARD              │ WAIT TIME DISTRIBUTION    │
│ 1. Agent 103 — 34 calls, 92%  │ 0-15s:  ████████████ 45%  │
│ 2. Agent 101 — 31 calls, 88%  │ 15-30s: ████████ 28%      │
│ 3. Agent 105 — 28 calls, 85%  │ 30-60s: ████ 15%          │
│ 4. Agent 102 — 26 calls, 79%  │ 60-90s: ██ 8%             │
│ 5. Agent 104 — 22 calls, 75%  │ 90s+:   █ 4%              │
├────────────────────────────────────────────────────────────┤
│ HOURLY HEATMAP (Mon-Fri)                                   │
│      8am  9am 10am 11am 12pm 1pm  2pm  3pm  4pm  5pm      │
│ Mon  ░░   ██  ████ ████ ██   ░░   ██   ████ ████ ██       │
│ Tue  ░░   ██  ████ ██   ██   ██   ██   ████ ██   ░░       │
│ Wed  ██   ████ ████ ████ ██   ██   ████ ████ ████ ██       │
│ Thu  ░░   ██  ████ ██   ██   ░░   ██   ██   ████ ██       │
│ Fri  ░░   ██  ██   ██   ░░   ░░   ██   ██   ██   ░░       │
└────────────────────────────────────────────────────────────┘

Что включить:

—Сравнительную таблицу по очередям
—Рейтинг операторов с ключевыми показателями
—Гистограмму распределения времени ожидания
—Почасовую тепловую карту для планирования смен
—Линию тренда SLA (за 7 и за 30 дней)

Экран 3: отчёт для руководства (для директоров и топ-менеджмента)

Недельный или месячный срез, сфокусированный на трендах и влиянии на бизнес:

—Динамика объёма звонков месяц к месяцу с прогнозом
—Динамика стоимости звонка
—Оценки удовлетворённости клиентов во времени
—Тренд соблюдения SLA (должен улучшаться)
—Показатели эффективности использования штата
—Основные причины обращений (из данных IVR или кодов завершения)

Лучшие практики проектирования дашбордов

—
Начинайте с вопросов, а не с метрик. Какие решения принимает конкретный зритель? Показывайте только те данные, которые помогают эти решения принять.
—
Раскрывайте детали постепенно. Сводные цифры на главном экране, детали — по клику. Не нужно втискивать всё в один экран.
—
Цвет должен что-то значить. Зелёный/жёлтый/красный должны последовательно означать норму/предупреждение/нарушение. Не используйте цвет как украшение.
—
Реальное время ≠ история. Разделяйте их. Дашборды реального времени отвечают на вопрос «что происходит сейчас?», исторические — «что произошло и почему?».
—
Задавайте ориентиры для всего. Голые цифры без целей бессмысленны. «ASA — 34 секунды» не говорит ни о чём. «ASA — 34 секунды (цель: 20s) — ⚠ на 70% выше цели» побуждает действовать.
—
Показывайте динамику, а не только снимок. Уровень сервиса 75% — это плохо. Но если на прошлой неделе было 60%, значит, вы растёте. Контекст важен.
—
Проверяйте читаемость. Если супервизор не может разобрать табло со своего рабочего места, толку от него нет.

Готовые SQL-запросы для дашборда Asterisk

Вот запросы боевого качества, которые подойдут к любому инструменту визуализации:

Уровень сервиса по очередям в реальном времени

WITH hourly_events AS (
    SELECT
        queuename,
        event,
        CAST(NULLIF(data1, '') AS INTEGER) AS wait_seconds
    FROM queue_log
    WHERE time >= NOW() - INTERVAL '1 hour'
      AND event IN ('CONNECT', 'ABANDON')
)
SELECT
    queuename,
    COUNT(*) AS total_offered,
    COUNT(*) FILTER (WHERE event = 'CONNECT') AS answered,
    COUNT(*) FILTER (WHERE event = 'ABANDON') AS abandoned,
    ROUND(
        100.0 * COUNT(*) FILTER (
            WHERE event = 'CONNECT' AND wait_seconds <= 20
        ) / NULLIF(COUNT(*), 0), 1
    ) AS service_level_pct,
    ROUND(AVG(wait_seconds) FILTER (WHERE event = 'CONNECT'), 0) AS avg_speed_answer
FROM hourly_events
GROUP BY queuename;

Загрузка операторов (за сегодня)

WITH agent_sessions AS (
    SELECT
        agent,
        event,
        time,
        LEAD(time) OVER (PARTITION BY agent ORDER BY time) AS next_time,
        LEAD(event) OVER (PARTITION BY agent ORDER BY time) AS next_event
    FROM queue_log
    WHERE time >= CURRENT_DATE
      AND agent != 'NONE'
      AND event IN ('ADDMEMBER', 'REMOVEMEMBER', 'CONNECT',
                     'COMPLETECALLER', 'COMPLETEAGENT', 'PAUSE', 'UNPAUSE')
),
talk_time AS (
    SELECT
        agent,
        SUM(EXTRACT(EPOCH FROM next_time - time)) AS total_talk_seconds
    FROM agent_sessions
    WHERE event = 'CONNECT'
    GROUP BY agent
),
login_time AS (
    SELECT
        agent,
        SUM(EXTRACT(EPOCH FROM
            COALESCE(next_time, NOW()) - time
        )) AS total_login_seconds
    FROM agent_sessions
    WHERE event = 'ADDMEMBER'
    GROUP BY agent
)
SELECT
    t.agent,
    ROUND(t.total_talk_seconds / 3600, 1) AS talk_hours,
    ROUND(l.total_login_seconds / 3600, 1) AS login_hours,
    ROUND(100.0 * t.total_talk_seconds /
        NULLIF(l.total_login_seconds, 0), 1) AS utilization_pct
FROM talk_time t
JOIN login_time l ON t.agent = l.agent
ORDER BY utilization_pct DESC;

Анализ потерянных звонков (ищем проблемные часы)

SELECT
    DATE_TRUNC('hour', time) AS hour,
    COUNT(*) FILTER (WHERE event IN ('CONNECT', 'ABANDON')) AS total_offered,
    COUNT(*) FILTER (WHERE event = 'ABANDON') AS abandoned,
    ROUND(
        100.0 * COUNT(*) FILTER (WHERE event = 'ABANDON')
        / NULLIF(COUNT(*) FILTER (WHERE event IN ('CONNECT', 'ABANDON')), 0), 1
    ) AS abandon_rate_pct,
    ROUND(AVG(CAST(NULLIF(data1, '') AS INTEGER))
        FILTER (WHERE event = 'ABANDON'), 0) AS avg_wait_before_abandon
FROM queue_log
WHERE time >= CURRENT_DATE
  AND event IN ('CONNECT', 'ABANDON')
GROUP BY DATE_TRUNC('hour', time)
HAVING COUNT(*) FILTER (WHERE event = 'ABANDON') > 0
ORDER BY hour;

Недельный тренд показателей

SELECT
    DATE_TRUNC('week', time) AS week,
    COUNT(*) FILTER (WHERE event = 'CONNECT') AS answered,
    COUNT(*) FILTER (WHERE event = 'ABANDON') AS abandoned,
    ROUND(
        100.0 * COUNT(*) FILTER (WHERE event = 'CONNECT' AND CAST(NULLIF(data1,'') AS INTEGER) <= 20)
        / NULLIF(COUNT(*) FILTER (WHERE event IN ('CONNECT','ABANDON')), 0), 1
    ) AS service_level_pct,
    ROUND(AVG(CAST(NULLIF(data1,'') AS INTEGER))
        FILTER (WHERE event = 'CONNECT'), 0) AS avg_wait_seconds,
    ROUND(AVG(CAST(NULLIF(data2,'') AS INTEGER))
        FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')), 0) AS avg_talk_seconds
FROM queue_log
WHERE time >= NOW() - INTERVAL '12 weeks'
  AND event IN ('CONNECT', 'ABANDON', 'COMPLETECALLER', 'COMPLETEAGENT')
GROUP BY DATE_TRUNC('week', time)
ORDER BY week;

Как настроить алерты, которые действительно работают

Дашборд без алертов — просто красивая картинка. Разбираем, как сделать осмысленные уведомления:

Иерархия алертов

Уровень алерта	Триггер	Реакция	Канал
Информация	Глубина очереди > 3 в течение 2+ мин	Супервизор берёт на заметку	Смена цвета на табло
Предупреждение	Уровень сервиса < 80% (скользящие 30 мин)	Подключить резервных операторов	Уведомление в Slack/Teams
Критический	Доля потерянных > 10% (скользящие 15 мин)	Экстренное усиление смены	SMS + Slack + e-mail
Авария	Ни одного доступного оператора	Эскалация руководству	Звонок дежурному руководителю

Пример: запрос-алерт на PostgreSQL

Запускайте его по cron каждые 60 секунд:

-- Check for SLA breach in the last 15 minutes
WITH recent AS (
    SELECT
        queuename,
        COUNT(*) AS total,
        COUNT(*) FILTER (
            WHERE event = 'CONNECT' AND CAST(data1 AS INTEGER) <= 20
        ) AS within_sla
    FROM queue_log
    WHERE time >= NOW() - INTERVAL '15 minutes'
      AND event IN ('CONNECT', 'ABANDON')
    GROUP BY queuename
)
SELECT
    queuename,
    total,
    ROUND(100.0 * within_sla / NULLIF(total, 0), 1) AS sla_pct,
    CASE
        WHEN 100.0 * within_sla / NULLIF(total, 0) < 60 THEN 'CRITICAL'
        WHEN 100.0 * within_sla / NULLIF(total, 0) < 80 THEN 'WARNING'
        ELSE 'OK'
    END AS status
FROM recent
WHERE 100.0 * within_sla / NULLIF(total, 0) < 80;

Типичные ошибки при построении дашбордов

1. Перегруз метриками Пятьдесят показателей на одном экране не помогут никому. Начните с 6-8 критичных KPI на каждый вид дашборда. Детализацию всегда можно раскрыть по клику.

2. Отсутствие ориентиров Метрики без целевых значений — просто цифры. Определите, что считается «хорошо» по каждому KPI, ещё до сборки дашборда. Возьмите отраслевые бенчмарки из этого руководства как отправную точку, а затем откалибруйте под свою работу.

3. Игнорирование проверки «и что дальше?» По каждой метрике на дашборде спросите себя: «Если это число изменится, что я стану делать иначе?» Если ответ «ничего» — метрику надо убрать.

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

5. Отсутствие разбивки по очередям Смешанные метрики по всем очередям прячут проблемы. Очередь продаж с SLA 95% легко замаскирует поддержку, тонущую на 60%. Всегда показывайте показатели в разрезе очередей.

6. Забытая приватность операторов Дашборды по эффективности должны быть инструментом развития, а не слежки. Индивидуальные показатели обсуждайте с оператором лично, а на табло выводите средние по команде. Стройте культуру улучшений, а не страха.

7. Настроил и забыл Дашборды нужно дорабатывать. Пересматривайте раз в неделю: метрики всё ещё актуальны? Пороговые значения верные? Что-то изменилось в работе? Дашборд, который не трогали полгода, скорее всего, вас обманывает.

С чего начать: дашборд с нуля за 15 минут

Если хотите пропустить недели самостоятельной настройки и получить полноценный дашборд KPI уже сегодня:

1. Установите Astervis на сервер с АТС:

curl -fsSL https://api.astervis.io/api/releases/install.sh | bash

2. Подключитесь к своему экземпляру Asterisk:

Установщик сам определяет конфигурацию Asterisk и подключается через AMI и CDR.

3. Откройте браузер:

Перейдите на IP-адрес сервера, порт 3000. Все 30+ дашбордов доступны сразу — онлайн-табло, карточки операторов, аналитика очередей, мониторинг транков, тепловые карты и не только.

4. Настройте доступ для команды:

Заведите учётные записи операторов и распределите очереди. Оператор видит свои показатели. Супервизор — свою команду. Руководитель — всё целиком.

Никаких SQL-запросов. Никакой настройки панелей Grafana. Никакой прослойки на сопровождении. Начните 14-дневный бесплатный период — банковская карта не нужна — и получите полную видимость колл-центра меньше чем за 15 минут.

Начать бесплатный период →

Главное

—
Отслеживайте правильные 20 KPI, разложенные по уровням: метрики онлайн-табло, эффективность операторов, операционная эффективность и стратегические бизнес-показатели.
—
Понимайте, где лежат данные в Asterisk: CDR — историческая запись, queue_log — события очередей, AMI — состояние в реальном времени, CEL — детальный ход звонка.
—
Проектируйте дашборды под конкретную аудиторию: табло для зала, тактические дашборды для руководителей, отчёты для топ-менеджмента. У каждого своя задача.
—
Есть три подхода: Grafana своими силами (бесплатно, но 60-120 часов на сборку), QueueMetrics (устаревшее решение, оплата за оператора) или Astervis (современное, 15 минут на внедрение, от $119/месяц).
—
Настраивайте алерты, а не только дашборды. Метрика, нарушение которой никто не увидел, бесполезна. Внедрите многоуровневую систему алертов с автоматической эскалацией.
—
Избегайте типичных ошибок: перегруз метриками, отсутствие ориентиров, смешанные метрики по очередям и подход «настроил и забыл» — всё это обесценивает вложения.
—
Начинайте просто, улучшайте быстро. Получите базовую видимость сегодня, а дальше шлифуйте неделями. Простой дашборд, которым вы реально пользуетесь, лучше сложного и вечно «в работе».

Хватит гадать. Начни видеть.

Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.

Начать бесплатный триал Запросить демо

От $119/мес flat. Без ограничения на операторов. Триал 14 дней.

Дашборд KPI колл-центра на Asterisk