Я настраивал отчётность колл-центра на FreePBX столько раз, что уже сбился со счёта. Сценарий всегда один и тот же: человек ставит FreePBX, запускает очереди, а потом спрашивает: «а где мои отчёты?»
Ответ неприятный. Встроенная отчётность FreePBX не рассчитана на работу колл-центра. Она рассчитана на АТС, у которой просто есть очереди.
Эта разница значит больше, чем кажется большинству команд — ровно до того момента, когда через три месяца они не могут ответить на элементарный вопрос вроде «какое у нас среднее время ожидания по часам?»
Моё мнение: FreePBX — лучший из доступных open-source интерфейсов управления АТС. Но считать его модули отчётности аналитикой колл-центра — это как использовать таблицу вместо CRM: формально работает и так же формально тормозит вас.
Что FreePBX реально даёт (честная оценка)
Прежде чем тратить время на выбор внешних инструментов, разберитесь, что именно идёт в комплекте с FreePBX. Кое-что там лучше, чем принято думать. Большая часть — хуже.
Модуль CDR Reports (бесплатный, встроенный)
С него обычно и начинают. Модуль обращается к таблице cdr в Asterisk и показывает её содержимое через веб-интерфейс.
Что он делает хорошо:
- —Поиск истории звонков по диапазону дат, внутреннему номеру или DID
- —Экспорт в CSV для офлайн-анализа
- —Базовая статистика по длительности звонков
Что он не умеет:
- —Показывать метрики в разрезе очередей (звонки логируются по каналу, а не по контексту очереди)
- —Отслеживать переходы состояний оператора (вход, пауза, готов, постобработка)
- —Считать соблюдение SLA
- —Показывать хоть что-то в реальном времени
Вот SQL, который FreePBX CDR выполняет под капотом:
-- This is essentially what FreePBX CDR module queries
SELECT calldate, src, dst, duration, billsec, disposition, channel, dstchannel
FROM cdr
WHERE calldate BETWEEN '2026-04-01' AND '2026-04-02'
ORDER BY calldate DESC;Обратите внимание, чего здесь нет: ни join с queue_log, ни идентификации оператора, ни расчёта времени ожидания. Модуль CDR работает с источником данных, полностью отдельным от ваших очередей.
Моё мнение: CDR-отчёты нормально подходят для сверки биллинга и базовых проверок «был ли такой звонок». Отчётностью колл-центра они не являются. Если кто-то говорит вам, что CDR-отчётов хватит для аналитики, — этот человек не работал в колл-центре.
Queue Reports (коммерческий модуль — $149)
Sangoma продаёт модуль Queue Reports, и многие команды покупают его в надежде закрыть вопрос с отчётностью.
Что он добавляет к CDR:
- —Счётчики звонков по очередям (отвеченные, потерянные, вышедшие по таймауту)
- —Учёт длительности сессий операторов
- —Базовые средние значения времени ожидания
Что по-прежнему не работает:
- —Нет дашборда в реальном времени (данные обновляются при перезагрузке страницы, а не вживую)
- —Средние значения ожидания скрывают распределение — вы не увидите, что 80% звонков ждут 10 секунд, а 20% — 4 минуты
- —Нет связи между работой оператора и результатами очереди
- —Нет тепловых карт и визуализации закономерностей
- —Нельзя сравнивать показатели за разные периоды
$149 — это разовый платёж, что вполне разумно. Но разрыв между тем, что даёт модуль, и тем, что реально нужно колл-центру на 20 операторов, огромен.
UCP (User Control Panel)
UCP сделан для операторов. Он показывает личную историю звонков, голосовую почту и статус присутствия. Это не инструмент отчётности, и я не буду делать вид, что это не так.
Разрыв в отчётности FreePBX (в цифрах)
Практический пример. Колл-центру на FreePBX с 15 операторами каждый день нужно отвечать на такие вопросы:
| Вопрос | FreePBX CDR | Queue Reports ($149) | Внешняя аналитика |
|---|---|---|---|
| Сколько звонков мы обработали сегодня? | Частично (нет фильтра по очереди) | Да | Да |
| Какое у нас соблюдение SLA прямо сейчас? | Нет | Нет (нет реального времени) | Да |
| У какого оператора самый высокий AHT? | Нет | Частично (только время в системе) | Да |
| В какой час больше всего потерянных звонков? | Нет | Нет (нет разбивки по часам) | Да |
| Хватит ли нам людей на завтра? | Нет | Нет | Да |
| Какой транк работает на пределе? | Нет | Нет | Да |
| Как эта неделя выглядит по сравнению с прошлой? | Ручной экспорт CSV | Нет | Да |
6 из 7 вопросов требуют внешнего инструмента. А единственный вопрос, на который FreePBX частично отвечает (количество звонков), всё равно требует ручной фильтрации.
Как настроить нормальную отчётность на FreePBX
Шаг 1. Включите логирование очередей (критично — этот шаг чаще всего пропускают)
Логирование очередей в FreePBX по умолчанию включено не полностью. Без него вам не поможет ни один внешний инструмент.
В админке FreePBX откройте Applications > Queues и для каждой очереди задайте:
- —
На вкладке Advanced:
- —Event When Called: Yes
- —Event Membership: Yes
- —Queue Logging: Yes (именно этот параметр обычно упускают)
- —
В разделе Timing & Agent Options:
- —Wrap-Up Time: укажите ваше реальное целевое время постобработки (значение 0 по умолчанию означает, что учёта нет)
- —Member Delay: 0 (если вам не нужно объявление перед соединением)
Затем проверьте, что логирование работает:
# Check that queue_log is being written
tail -20 /var/log/asterisk/queue_log
# You should see entries like:
# 1774000000|1774000001|support|CONNECT|15|SIP/200|12
# 1774000012|NONE|support|ADDMEMBER|SIP/201Если queue_log пуст, проверьте конфигурацию Asterisk:
; /etc/asterisk/logger.conf
; Make sure queue_log is enabled
[logfiles]
queue_log => queue_log# After changes:
fwconsole restart
# Or if you want to avoid dropping calls:
asterisk -rx "logger reload"Моё мнение: по моей оценке, у 40% колл-центров на FreePBX логирование очередей настроено не полностью. Они узнают об этом через 3 месяца, когда кто-то спрашивает: «почему данных нет?» Исправьте это сейчас.
Шаг 2. Настройте AMI для внешних инструментов
Любой внешний инструмент мониторинга подключается через Asterisk Manager Interface (AMI). FreePBX управляет этим сам, но вам нужно завести отдельного пользователя.
Откройте Settings > Asterisk Manager Users в FreePBX или отредактируйте конфиг напрямую:
; /etc/asterisk/manager.conf (managed by FreePBX - use GUI when possible)
[monitoring]
secret = generate_a_32_char_password_here
deny = 0.0.0.0/0.0.0.0
permit = 10.0.0.0/255.255.255.0 ; Your monitoring server subnet
read = system,call,log,agent,reporting
write = system,call,agent,reporting
writetimeout = 5000Замечание по безопасности: никогда не используйте permit = 0.0.0.0/0.0.0.0 в продакшене. Ограничьте доступ IP-адресом или подсетью вашего сервера мониторинга. Именно через открытый AMI чаще всего и взламывают АТС.
# Test AMI connection from your monitoring server
telnet freepbx-server 5038
# Then type:
Action: Login
Username: monitoring
Secret: your_password
# You should get: Response: Success
# Then test queue data:
Action: QueueStatus
Queue: your_queue_nameШаг 3. Настройте доступ к базе для исторических отчётов
Для исторической аналитики внешним инструментам нужен доступ к базам CDR и queue_log. FreePBX использует MySQL/MariaDB:
# Create a read-only database user for analytics
mysql -u root -p
CREATE USER 'analytics'@'monitoring-server-ip' IDENTIFIED BY 'secure_password';
GRANT SELECT ON asteriskcdrdb.cdr TO 'analytics'@'monitoring-server-ip';
GRANT SELECT ON asteriskcdrdb.cel TO 'analytics'@'monitoring-server-ip';
FLUSH PRIVILEGES;Если ваш внешний инструмент читает файл queue_log напрямую (а некоторые так и делают), внимательно настройте ротацию логов:
# /etc/logrotate.d/asterisk-queue-log
/var/log/asterisk/queue_log {
monthly
rotate 12
compress
delaycompress
missingok
notifempty
copytruncate # Important: don't move the file, copy and truncate
}Моё мнение: copytruncate здесь обязателен. Если logrotate переместит файл, Asterisk продолжит писать в старый файловый дескриптор до самого перезапуска — и вы потеряете данные. Я видел, как из-за этого возникали жалобы на «пропавшие данные», которые расследовали неделями.
Сравнение инструментов отчётности для FreePBX (честный рейтинг)
1. Astervis - лучший вариант для команд, которым нужен результат, а не проект
Astervis создан специально для АТС на базе Asterisk, включая FreePBX.
Установка на FreePBX:
# On your FreePBX server or a separate machine (recommended)
curl -fsSL https://api.astervis.io/api/releases/install.sh | bash
# Add your FreePBX server in the dashboard
# Queues auto-discovered within 60 secondsЧем он отличается именно для FreePBX:
- —Автоматически определяет конфигурацию очередей FreePBX (не нужно вручную сопоставлять очереди)
- —30+ графиков, включая тепловые карты, динамику показателей операторов и аналитику по транкам
- —Дашборды в реальном времени с обновлением быстрее секунды через события AMI
- —Управление операторами с KPI, рейтингами и планированием смен
- —Интеграция с CRM (Bitrix24, AmoCRM)
- —Self-hosted — ваши данные остаются внутри вашей сети
Цена: от $119 в месяц при любом числе операторов. Бесплатный триал на 14 дней.
Кому подходит: командам, которые используют FreePBX как колл-центр (от 5 операторов) и хотят получить видимость сразу, без отдельного проекта по внедрению.
2. Grafana + собственный стек - лучший вариант для DevOps-команд
Если у вас есть DevOps-инженер и вы хотите полную кастомизацию:
- —Установить Grafana + PostgreSQL/TimescaleDB
- —Написать парсер для
/var/log/asterisk/queue_log - —Сделать слушатель событий AMI для данных в реальном времени
- —Собрать дашборды с нуля
Реалистичные сроки: 40–80 часов до продакшен-качества. И дальше — постоянная поддержка.
# Example: basic queue_log parser to PostgreSQL
# This is the EASY part. The hard part is real-time AMI event processing.
awk -F'|' '{print $1","$2","$3","$4","$5","$6}' /var/log/asterisk/queue_log \
| psql -c "COPY queue_events FROM STDIN WITH CSV"Моё мнение: я уважаю команды, которые строят аналитику сами. Но я видел три проекта «Grafana поверх FreePBX», которые начинались с энтузиазмом и умирали в течение полугода, когда автор увольнялся или переключался на другие задачи. Первоначальная сборка — это 20% стоимости, поддержка — 80%.
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
3. QueueMetrics - вариант из прошлого
QueueMetrics существует с 2004 года и глубоко интегрирован с Asterisk. Но ему нужны Java/Tomcat на вашем сервере FreePBX.
# QueueMetrics installation on FreePBX
yum install java-11-openjdk tomcat # Java + Tomcat on your PBX server
# Download and deploy WAR file
# Configure database, AMI, queue_log path...
# Total setup: 2-4 hours if everything goes rightСпецифическая проблема с FreePBX: Tomcat, работающий рядом с FreePBX на одном сервере, конкурирует за ресурсы. Аппетит Java к памяти (обычно 512 МБ — 1 ГБ) на системе, которая одновременно обрабатывает голос в реальном времени, — не лучшая идея. Продакшен-серверы FreePBX должны отдавать ресурсы обработке звонков.
Смотрите наше подробное сравнение с QueueMetrics с разбором цен и миграции.
4. Asternic Stats - бюджетный вариант
Asternic проще, чем QueueMetrics, и работает на PHP вместо Java:
- —Читает
queue_logнапрямую - —Простой веб-дашборд (интерфейс в эстетике до 2010 года)
- —Меньше потребление ресурсов, чем у QueueMetrics
Честная оценка: Asternic справляется с базовой статистикой по очередям. Если вам нужно «сколько звонков в очереди за день» и больше ничего — этого достаточно. Мониторинга в реальном времени, отслеживания работы операторов и чего-либо похожего на современную аналитику там нет.
Подробности — в нашем сравнении с Asternic.
SQL-запросы для отчётности на FreePBX
Если вы делаете собственные отчёты или хотите проверить, правильно ли считает ваш инструмент аналитики, — вот запросы, которые реально работают на базе FreePBX:
Показатели операторов из queue_log
-- Agent call counts and average handle time (FreePBX queue_log table)
SELECT
agent,
COUNT(CASE WHEN event = 'CONNECT' THEN 1 END) AS calls_answered,
COUNT(CASE WHEN event = 'RINGNOANSWER' THEN 1 END) AS calls_missed,
ROUND(AVG(CASE WHEN event = 'COMPLETECALLER' OR event = 'COMPLETEAGENT'
THEN CAST(data2 AS UNSIGNED) END)) AS avg_talk_seconds,
ROUND(AVG(CASE WHEN event = 'COMPLETECALLER' OR event = 'COMPLETEAGENT'
THEN CAST(data1 AS UNSIGNED) END)) AS avg_hold_seconds
FROM queue_log
WHERE time > UNIX_TIMESTAMP(CURDATE())
AND agent != 'NONE'
GROUP BY agent
ORDER BY calls_answered DESC;Процент потерянных звонков по часам
-- Abandon rate by hour (identifies understaffing windows)
SELECT
HOUR(FROM_UNIXTIME(time)) AS hour,
COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) AS abandoned,
COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END) AS total,
ROUND(100.0 * COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) /
NULLIF(COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END), 0), 1) AS abandon_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(CURDATE() - INTERVAL 7 DAY)
AND queuename = 'your_queue'
GROUP BY HOUR(FROM_UNIXTIME(time))
ORDER BY hour;Соблюдение SLA (80/30)
-- SLA: percentage of calls answered within 30 seconds
SELECT
DATE(FROM_UNIXTIME(time)) AS day,
COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 30 THEN 1 END) AS within_sla,
COUNT(CASE WHEN event = 'CONNECT' THEN 1 END) AS total_answered,
ROUND(100.0 * COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 30 THEN 1 END) /
NULLIF(COUNT(CASE WHEN event = 'CONNECT' THEN 1 END), 0), 1) AS sla_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(CURDATE() - INTERVAL 30 DAY)
AND queuename = 'support'
GROUP BY DATE(FROM_UNIXTIME(time))
ORDER BY day DESC;Загрузка транков (FreePBX CDR)
-- Concurrent call peaks by trunk (capacity planning)
SELECT
DATE(calldate) AS day,
HOUR(calldate) AS hour,
channel,
COUNT(*) AS calls,
MAX(duration) AS max_duration
FROM cdr
WHERE calldate > DATE_SUB(NOW(), INTERVAL 7 DAY)
AND channel LIKE 'PJSIP/trunk%'
GROUP BY DATE(calldate), HOUR(calldate), channel
ORDER BY calls DESC
LIMIT 20;Типичные ошибки в отчётности на FreePBX
1. Принимать duration из CDR за время разговора
Поле duration в CDR включает время дозвона. Поле billsec ближе к времени разговора, но всё ещё включает навигацию по IVR. Ни то, ни другое не отражает реальное время общения оператора с клиентом.
Для точного времени разговора используйте события CONNECT/COMPLETE из queue_log вместе с полями времени удержания (data1) и времени разговора (data2).
2. Не разделять типы очередей
Единая цель по SLA для продаж, поддержки и VIP-очереди не имеет смысла. Настройте отдельные очереди в FreePBX и следите за ними по отдельности:
; queues_additional.conf (FreePBX manages this, but understand the structure)
[sales](!)
servicelevel=20 ; 20-second SLA for sales
strategy=rrmemory
[support](!)
servicelevel=30 ; 30-second SLA for support
strategy=leastrecent
[vip](!)
servicelevel=15 ; 15-second SLA for VIP
strategy=linear ; Always ring best agent first3. Игнорировать постобработку звонка
Значение по умолчанию wrapuptime=0 в FreePBX означает, что оператор получает следующий звонок сразу после того, как положил трубку. Это приводит к:
- —Неточному AHT (постобработка выполняется уже во время следующего звонка)
- —Выгоранию операторов (нет времени на передышку между звонками)
- —Неверным расчётам пропускной способности
Задайте адекватное время постобработки:
; In FreePBX: Applications > Queues > Queue Settings
wrapuptime=30 ; 30 seconds between callsПодробнее о том, как предотвратить выгорание операторов за счёт грамотного распределения нагрузки.
4. Строить отчёты в часы пик
Аналитические запросы к базе CDR конкурируют с обработкой звонков. Планируйте тяжёлые отчёты на непиковое время или, что ещё лучше, реплицируйте данные в отдельную аналитическую базу.
Что настроить на этой неделе
Если у вас FreePBX с очередями и никакой аналитики, кроме CDR-отчётов, вот ваш план действий:
День 1: Включите логирование очередей на всех очередях (Шаг 1 выше). Убедитесь, что queue_log пишется.
День 2: Настройте доступ по AMI для внешнего мониторинга (Шаг 2). Проверьте подключение.
День 3: Установите инструмент аналитики. Попробуйте Astervis бесплатно 14 дней — установка на FreePBX занимает 10 минут.
Дни 4–5: Настройте пороги SLA для каждой очереди. Задайте wrapuptime. Посмотрите первые данные.
Разница между «нам кажется, наш колл-центр работает нормально» и «мы знаем, что в 14:00 у нас SLA 78% и 14% потерянных звонков» — это разница между надеждой и данными.
FreePBX обрабатывает звонки. Аналитика показывает, насколько хорошо он это делает.
Больше об оптимизации колл-центра на FreePBX — в нашем полном руководстве по мониторингу Asterisk, подробном разборе CDR-отчётности и настройке мониторинга очередей в реальном времени.
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.