Name: Astervis
Availability: InStock
Author: Astervis

Управление колл-центром на Asterisk — это не только поддержание транков в рабочем состоянии. Настоящая задача в другом: понять, как работает каждый оператор — кто закрывает вопрос с первого звонка, у кого минимальное время удержания, кто стабильно обслуживает быстро и качественно. Без системного отслеживания показателей вы работаете вслепую.

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

Почему важно отслеживать работу операторов

На оплату труда в колл-центре приходится 60–70% всех операционных расходов. Один слабый оператор, обрабатывающий 80 звонков в день, за год обходится в тысячи долларов потерянных клиентов и впустую выплаченной зарплаты. И наоборот: если выявить привычки лучших сотрудников и распространить их на команду, общая продуктивность вырастает на 15–25%.

Без отслеживания типовые проблемы тихо накапливаются:

—Неравномерная нагрузка — одни операторы принимают втрое больше звонков, другие простаивают
—Высокий процент отказов у отдельных операторов — клиенты не дожидаются медленных сотрудников и кладут трубку
—Затянутое удержание и постобработка — оператор ставит клиента на удержание, чтобы не работать
—Нет ответственности — без данных разбор работы строится на субъективных ощущениях
—Срыв целей по SLA — вы не знаете, кто именно тянет уровень сервиса вниз

Asterisk генерирует огромные объёмы сырых данных: записи CDR, логи очередей, события каналов. Задача — превратить это сырьё в понятную картину по каждому оператору.

Ключевые KPI операторов в колл-центрах на Asterisk

Прежде чем переходить к способам извлечения данных, определите, что именно нужно отслеживать. Вот показатели, которые важнее всего для инфраструктуры на Asterisk:

Метрики объёма звонков

KPI	Что показывает	Формула	Целевой диапазон
Обработанные звонки	Сколько звонков принял оператор	Количество событий CONNECT	Зависит от роли
Пропущенные звонки	Вызовы, на которые не ответили	Количество событий RINGNOANSWER	< 5% от предложенных
Переведённые звонки	Звонки, переданные другому оператору	Количество событий TRANSFER	< 10%
Звонков в час	Скорость обработки	Обработанные звонки / отработанные часы	8–15 (входящие)

Метрики времени

KPI	Что показывает	Формула	Целевой диапазон
Среднее время обработки (AHT)	Полное время на звонок вместе с постобработкой	(Разговор + Удержание + Постобработка) / Звонки	3–7 минут
Среднее время разговора	Фактическая длительность беседы	Сумма billsec / Звонки	2–5 минут
Среднее время удержания	Сколько клиент провёл на удержании	Сумма событий удержания / Звонки	< 60 секунд
Среднее время постобработки	Длительность работы после звонка	AHT – Разговор – Удержание	< 60 секунд
Время дозвона (до ответа)	Как быстро оператор берёт трубку	Интервал между RINGNOANSWER/CONNECT	< 15 секунд
Загруженность (Occupancy)	Доля времени на звонках от доступного	(Разговор + Удержание + Постобработка) / Время в системе	75–85%

Метрики качества

KPI	Что показывает	Формула	Целевой диапазон
Решение с первого звонка (FCR)	Вопросы, закрытые без повторного обращения	1 – (Повторные обращения / Всего обращений)	> 70%
Процент отказов (по оператору)	Клиенты, положившие трубку в очереди оператора	Отказы / Предложенные	< 5%
Уровень сервиса	Звонки, принятые в пределах порога	Принято за X сек / Всего	> 80% за 20 с
Доля переводов	Звонки, потребовавшие эскалации	Переводы / Обработанные	< 10%

Где Asterisk хранит данные по операторам

Данные, относящиеся к работе операторов, Asterisk хранит сразу в нескольких местах. Для точного учёта важно понимать каждый источник.

1. Queue Log (/var/log/asterisk/queue_log)

Лог очередей — основной источник данных о работе операторов в очередях. Каждое событие очереди записывается с меткой времени, именем очереди и идентификатором оператора.

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

ADDMEMBER      — Оператор вошёл в очередь
REMOVEMEMBER   — Оператор вышел из очереди
RINGNOANSWER   — Очередь предложила звонок, оператор не ответил
CONNECT        — Оператор ответил (содержит время удержания и время дозвона)
COMPLETECALLER — Клиент положил трубку первым (содержит время удержания и разговора)
COMPLETEAGENT  — Оператор положил трубку первым (содержит время удержания и разговора)
TRANSFER       — Оператор перевёл звонок
PAUSE          — Оператор на паузе (перерыв/обед)
UNPAUSE        — Оператор вернулся с паузы
ABANDON        — Клиент отключился, не дождавшись ответа

Пример записи queue_log о завершённом звонке:

1710806400|1710806389.42|support|SIP/agent101|COMPLETEAGENT|18|145|1

Расшифровка: оператор SIP/agent101 в очереди support ответил после 18 секунд удержания, говорил 145 секунд и завершил звонок первым. Позиция в очереди была 1.

2. CDR (Call Detail Records)

CDR даёт данные на уровне звонка: длительность, статус завершения, информацию о каналах. Хранится в /var/log/asterisk/cdr-csv/ либо в базе данных (MySQL, PostgreSQL), если настроен cdr_adaptive_odbc.

Полезные поля CDR для анализа операторов:

src          — Номер звонящего
dst          — Набранный номер/внутренний
dcontext     — Контекст назначения
channel      — Исходный канал
dstchannel   — Канал назначения (канал оператора)
billsec      — Тарифицируемые секунды (фактический разговор)
duration     — Общая длительность вместе с дозвоном
disposition  — ANSWERED, NO ANSWER, BUSY, FAILED
calldate     — Метка времени
uniqueid     — Уникальный идентификатор звонка

3. CEL (Channel Event Logging)

CEL даёт самые детальные данные на уровне событий. Он фиксирует каждое изменение состояния за время жизни звонка, поэтому позволяет точно рассчитать время удержания, цепочки переводов и длительность конференций.

Ключевые события CEL:

CHAN_START     — Канал создан (звонок инициирован)
ANSWER        — На канале ответили
BRIDGE_ENTER  — Вход в бридж (соединение со второй стороной)
BRIDGE_EXIT   — Выход из бриджа
HOLD          — Поставлен на удержание
UNHOLD        — Снят с удержания
HANGUP        — Канал завершён

4. AMI (Asterisk Manager Interface)

AMI отдаёт данные в реальном времени через события. Подходит для live-дашбордов, но не для исторического анализа.

QueueMemberStatus  — Изменение состояния оператора
AgentCalled        — Очередь пытается дозвониться до оператора
AgentConnect       — Оператор ответил на звонок из очереди
AgentComplete      — Оператор завершил звонок из очереди

Извлечение метрик операторов с помощью SQL

Если данные CDR и queue_log хранятся в базе (рекомендуемый вариант), метрики по операторам можно доставать SQL-запросами. Ниже — готовые к работе запросы для PostgreSQL. Для MySQL адаптируйте имена колонок.

Запрос 1: Сводка по работе оператора за день

SELECT
    agent,
    COUNT(*) FILTER (WHERE event = 'CONNECT') AS calls_answered,
    COUNT(*) FILTER (WHERE event = 'RINGNOANSWER') AS calls_missed,
    COUNT(*) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')) AS calls_completed,
    COUNT(*) FILTER (WHERE event = 'TRANSFER') AS calls_transferred,
    ROUND(AVG(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')), 1) AS avg_talk_sec,
    ROUND(AVG(data1::int) FILTER (WHERE event = 'CONNECT'), 1) AS avg_hold_sec,
    MAX(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')) AS max_talk_sec,
    MIN(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')) AS min_talk_sec
FROM queue_log
WHERE time_id >= CURRENT_DATE
    AND agent != 'NONE'
GROUP BY agent
ORDER BY calls_answered DESC;

Запрос 2: Почасовая активность оператора (данные для heatmap)

SELECT
    agent,
    EXTRACT(HOUR FROM to_timestamp(time_id)) AS hour,
    COUNT(*) FILTER (WHERE event = 'CONNECT') AS calls,
    ROUND(AVG(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')), 0) AS avg_talk
FROM queue_log
WHERE time_id >= EXTRACT(EPOCH FROM CURRENT_DATE)::int
    AND agent != 'NONE'
GROUP BY agent, hour
ORDER BY agent, hour;

Запрос 3: Время в системе и доступность оператора

WITH sessions AS (
    SELECT
        agent,
        time_id AS event_time,
        event,
        LEAD(time_id) OVER (PARTITION BY agent ORDER BY time_id) AS next_event_time,
        LEAD(event) OVER (PARTITION BY agent ORDER BY time_id) AS next_event
    FROM queue_log
    WHERE event IN ('ADDMEMBER', 'REMOVEMEMBER', 'PAUSE', 'UNPAUSE')
        AND time_id >= EXTRACT(EPOCH FROM CURRENT_DATE)::int
        AND agent != 'NONE'
)
SELECT
    agent,
    SUM(CASE WHEN event = 'ADDMEMBER' THEN next_event_time - event_time ELSE 0 END) AS total_logged_in_sec,
    SUM(CASE WHEN event = 'PAUSE' THEN
        LEAST(next_event_time - event_time, 7200) ELSE 0 END) AS total_pause_sec,
    ROUND(
        SUM(CASE WHEN event = 'ADDMEMBER' THEN next_event_time - event_time ELSE 0 END)::numeric / 3600,
        2
    ) AS logged_in_hours
FROM sessions
WHERE next_event_time IS NOT NULL
GROUP BY agent
ORDER BY total_logged_in_sec DESC;

Запрос 4: Рейтинг операторов (составной балл)

WITH metrics AS (
    SELECT
        agent,
        COUNT(*) FILTER (WHERE event = 'CONNECT') AS answered,
        COUNT(*) FILTER (WHERE event = 'RINGNOANSWER') AS missed,
        COALESCE(AVG(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')), 0) AS avg_talk,
        COALESCE(AVG(data1::int) FILTER (WHERE event = 'CONNECT'), 0) AS avg_hold
    FROM queue_log
    WHERE time_id >= EXTRACT(EPOCH FROM (CURRENT_DATE - INTERVAL '7 days'))::int
        AND agent != 'NONE'
    GROUP BY agent
    HAVING COUNT(*) FILTER (WHERE event = 'CONNECT') >= 10
)
SELECT
    agent,
    answered,
    missed,
    ROUND(avg_talk, 1) AS avg_talk_sec,
    ROUND(avg_hold, 1) AS avg_hold_sec,
    ROUND(answered::numeric / NULLIF(answered + missed, 0) * 100, 1) AS answer_rate_pct,
    ROUND(
        (answered::numeric / NULLIF(answered + missed, 0) * 40) +
        (LEAST(300, avg_talk) / 300 * 30) +
        (GREATEST(0, 30 - avg_hold) / 30 * 30),
        1
    ) AS performance_score
FROM metrics
ORDER BY performance_score DESC;

Этот составной балл учитывает процент ответов (40%), эффективность разговора (30%) и скорость ответа (30%). Меняйте веса под свои приоритеты.

Запрос 5: Кому из операторов нужен разбор

SELECT
    agent,
    COUNT(*) FILTER (WHERE event = 'CONNECT') AS calls_answered,
    COUNT(*) FILTER (WHERE event = 'RINGNOANSWER') AS calls_missed,
    ROUND(AVG(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')), 0) AS avg_talk_sec,
    ROUND(AVG(data1::int) FILTER (WHERE event = 'CONNECT'), 0) AS avg_hold_sec,
    CASE
        WHEN COUNT(*) FILTER (WHERE event = 'RINGNOANSWER') >
             COUNT(*) FILTER (WHERE event = 'CONNECT') * 0.2
        THEN 'HIGH MISS RATE'
        WHEN AVG(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')) > 600
        THEN 'LONG CALLS'
        WHEN AVG(data1::int) FILTER (WHERE event = 'CONNECT') > 30
        THEN 'SLOW PICKUP'
        ELSE 'OK'
    END AS flag
FROM queue_log
WHERE time_id >= EXTRACT(EPOCH FROM (CURRENT_DATE - INTERVAL '7 days'))::int
    AND agent != 'NONE'
GROUP BY agent
HAVING CASE
    WHEN COUNT(*) FILTER (WHERE event = 'RINGNOANSWER') >
         COUNT(*) FILTER (WHERE event = 'CONNECT') * 0.2 THEN TRUE
    WHEN AVG(data2::int) FILTER (WHERE event IN ('COMPLETECALLER','COMPLETEAGENT')) > 600 THEN TRUE
    WHEN AVG(data1::int) FILTER (WHERE event = 'CONNECT') > 30 THEN TRUE
    ELSE FALSE
END
ORDER BY flag, agent;

Мониторинг через CLI (быстрые проверки)

Если доступа к базе нет, состояние операторов можно быстро посмотреть командами Asterisk CLI:

Текущее состояние очереди

asterisk -rx "queue show"

В выводе — статус каждого оператора, число принятых звонков, время последнего звонка и penalty:

support has 3 calls (max unlimited) in 'ringall' strategy
   Members:
      SIP/agent101 (ringinuse disabled) (dynamic) (Not in use) has taken 47 calls (last was 142 secs ago)
      SIP/agent102 (ringinuse disabled) (dynamic) (In use) has taken 38 calls (last was 12 secs ago)
      SIP/agent103 (ringinuse disabled) (dynamic) (Paused) has taken 22 calls (last was 891 secs ago)

Разбор queue_log через shell

# Лучшие операторы за сегодня по числу принятых звонков
grep "$(date +%s | cut -c1-6)" /var/log/asterisk/queue_log | \
    grep "CONNECT" | \
    awk -F'|' '{print $4}' | \
    sort | uniq -c | sort -rn | head -10

# Среднее время разговора по операторам (за сегодня)
grep "$(date +%s | cut -c1-6)" /var/log/asterisk/queue_log | \
    grep -E "COMPLETECALLER|COMPLETEAGENT" | \
    awk -F'|' '{agent=$4; talk=$7; sum[agent]+=talk; count[agent]++}
    END {for (a in sum) printf "%s: %.0f sec avg (%d calls)\n", a, sum[a]/count[a], count[a]}' | \
    sort -t: -k2 -n

Построение дашборда по работе операторов

Полноценная система отслеживания должна давать три уровня видимости:

Уровень 1: Wallboard в реальном времени

Показывает супервизорам в зале текущий статус операторов:

—Состояние оператора: свободен, на звонке, на паузе, постобработка, офлайн
—Длительность текущего звонка: сколько уже идёт разговор
—Глубина очереди: сколько клиентов ждёт в каждой очереди
—Звонки за последний час: пульс активности по каждому оператору
—Самый долго ждущий клиент: индикатор срочности

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

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

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

Уровень 2: Дневная сводка по работе

Разбор по итогам смены для руководителей групп:

—Обработанные и пропущенные звонки (по операторам)
—Динамика среднего времени обработки (есть ли прогресс?)
—Время в системе против времени на паузе (реальная доступность)
—Вклад в уровень сервиса (кто помог, а кто испортил SLA)
—Рейтинг с составным баллом

Уровень 3: Недельная и месячная аналитика

Стратегический срез для руководителя:

—Тренды показателей во времени (рост или спад?)
—Heatmap-сравнение операторов (кто когда продуктивен?)
—Корреляционный анализ (связано ли короткое AHT с повторными звонками?)
—Замер эффекта обучения (изменились ли метрики после разбора?)
—Справедливость распределения нагрузки

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

Ошибка 1: Считать только объём звонков

Оператор, который принял 100 звонков, но 40% из них перевёл, не лучший сотрудник. Всегда сочетайте количественные метрики с качественными: доля переводов, время удержания, повторные обращения.

Ошибка 2: Игнорировать паузы и перерывы

Некоторые операторы играют с доступностью, уходя на частые короткие паузы. Отслеживайте частоту пауз, суммарную длительность и время их постановки (пауза прямо перед концом смены — подозрительно).

Ошибка 3: Смотреть средние за день вместо распределения по звонкам

У оператора со средним временем обработки 4 минуты половина звонков может длиться минуту (сорванные), а половина — семь минут (реальная работа). Распределение важнее среднего.

Ошибка 4: Не учитывать привязку к очереди

Сравнивать операторов из разных очередей некорректно. Звонки в техподдержку по определению дольше вопросов по счетам. Нормализуйте метрики по типу очереди.

Ошибка 5: Собирать данные вручную

Если вы раз в неделю выгружаете queue_log в таблицы, вы уже опоздали. Проблемы с показателями нужно видеть в реальном времени, а не задним числом.

Подходы к отслеживанию работы операторов

Своими силами: разбор queue_log + собственные скрипты

Трудозатраты: высокие — нужны скрипты, cron-задачи, самописные дашборды. Плюсы: бесплатно, полная гибкость. Минусы: хрупко, нет режима реального времени, всё нужно поддерживать.

QueueMetrics

Цена: 8 CHF за оператора в месяц. Плюсы: зрелый продукт, много отчётов. Минусы: на Java, сложная установка, дорого на масштабе, устаревший интерфейс.

Asternic Call Center Stats

Цена: нужна коммерческая лицензия. Плюсы: лёгкий, заточен под queue_log. Минусы: мало возможностей в реальном времени, устаревший интерфейс, минимум аналитики по операторам.

Grafana + собственные запросы

Цена: бесплатно (OSS). Плюсы: красивые дашборды, гибкость. Минусы: требует серьёзной настройки, парсера queue_log в комплекте нет, алерты делаете сами.

Astervis

Цена: от $119 в месяц, число операторов не ограничено. Плюсы: создан специально под Asterisk, 30+ графиков из коробки, дашборды по операторам в реальном времени, рейтинги, отслеживание KPI, установка одной командой, интеграция с CRM (Bitrix24, AmoCRM). Минусы: молодой продукт.

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

—Рейтинги операторов с составной оценкой
—Статус операторов в реальном времени на wallboard
—Карточки KPI по каждому оператору (AHT, обработанные звонки, процент ответов, время удержания)
—Графики динамики показателей за любой период
—Heatmap продуктивности каждого оператора по часам
—Учёт графика работы с анализом входов, пауз и доступности
—Автоматические оповещения, когда показатели оператора падают ниже порога

Настройка занимает меньше 5 минут: подключаетесь к своему серверу Asterisk, и Astervis сам забирает данные queue_log и CDR. Без Java, без сложных конфигураций, без обслуживания.

Как внедрить отслеживание в своём колл-центре

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

Шаг 1: Включите логирование очередей

Убедитесь, что queue_log активен и пишет в базу:

; /etc/asterisk/logger.conf
[general]
queue_log = yes
queue_log_to_file = yes
queue_log_name = queue_log

Для хранения в базе (удобно для запросов):

; /etc/asterisk/extconfig.conf
queue_log => odbc,asterisk,queue_log

Шаг 2: Настройте хранение CDR в базе

; /etc/asterisk/cdr.conf
[general]
enable = yes
unanswered = yes
congestion = yes
endbeforehexten = yes

Шаг 3: Определите свои KPI

Начните с пяти базовых метрик:

—Процент ответов — цель > 95%
—Среднее время обработки — зафиксируйте базовый уровень, затем улучшайте
—Звонков в час — задайте минимальную планку
—Загруженность — цель 75–85% (выше 85% ведёт к выгоранию)
—Соблюдение графика — план против фактической доступности

Шаг 4: Настройте отчётность

Выберите подход:

—Быстрый старт: поставьте Astervis и получите дашборды сразу (14 дней бесплатно)
—Своими силами: соберите SQL-запросы (примеры выше) + Grafana или Metabase для визуализации
—Вручную: ежедневный разбор queue_log скриптами по cron

Шаг 5: Введите регулярные разборы

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

Главное

—Отслеживайте правильные KPI — объём без метрик качества ничего не значит
—Опирайтесь на queue_log как на основной источник — в нём самые богатые данные по операторам в Asterisk
—Автоматизируйте сбор данных — ручной учёт всегда медленный и с ошибками
—Сравнивайте честно — нормализуйте метрики по типу очереди и часам смены
—Действуйте по данным — отслеживание без разбора работы бессмысленно
—Начните с простого — пять базовых KPI полезнее пятидесяти метрик, до которых не доходят руки

Грамотное отслеживание работы операторов превращает колл-центр на Asterisk из статьи расходов в подразделение, управляемое по показателям. Соберёте ли вы свой инструментарий или возьмёте готовую платформу вроде Astervis — вложение в прозрачность окупается за счёт продуктивности операторов, меньшего числа сорванных звонков и довольных клиентов.

Хотите видеть работу операторов в реальном времени? Попробуйте Astervis бесплатно 14 дней — банковская карта не нужна.

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

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

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

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

Отслеживание работы операторов в Asterisk: полное руководство