Name: Astervis
Availability: InStock
Author: Astervis

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

Большинство руководств по колл-центрам на Asterisk описывают либо базовую установку, либо узкий технический тюнинг. Это руководство другое. Мы разберём всё: от тюнинга производительности Asterisk на системном уровне до конфигурации очередей, управления операторами, оптимизации маршрутизации звонков, стратегий мониторинга и операционных практик, которые напрямую влияют на прибыль.

Неважно, работает у вас 10 операторов или 200 — это руководство поможет выжать из колл-центра на Asterisk максимум производительности.

Зачем оптимизировать колл-центр на Asterisk

Прежде чем переходить к «как», оцифруем «зачем»:

Направление оптимизации	Типичный эффект	Влияние на выручку
Сокращение времени ожидания в очереди	Снижение на 30–50%	На 15–25% меньше сорванных звонков
Рост утилизации операторов	Увеличение на 15–20%	Тот же объём меньшим числом операторов
Рост решения с первого звонка	Улучшение на 10–15%	На 20–30% меньше повторных обращений
Тюнинг производительности системы	Ёмкость по одновременным звонкам в 2–3 раза выше	Отложенный апгрейд железа
Оптимизация маршрутизации	Решение вопроса на 20–30% быстрее	Выше CSAT, ниже отток

Для колл-центра на 50 операторов, который обрабатывает 500 звонков в день, даже 10% прироста эффективности означает $50 000–$150 000 экономии в год.

Часть 1. Тюнинг производительности Asterisk на системном уровне

1.1 Оптимизация железа и ОС

Прежде чем трогать конфигурацию Asterisk, убедитесь, что фундамент надёжен:

Что учитывать по CPU:

—Обработка звонков в Asterisk в основном однопоточная, но для PJSIP и Stasis используется несколько потоков
—Кодеки G.711 (ulaw/alaw) почти не нагружают CPU; транскодинг G.729 — ресурсоёмкая операция
—Ориентир: одно современное ядро CPU тянет около 200 одновременных звонков в G.711
—Если в колл-центре включена запись разговоров, добавьте 30% запаса по CPU

Память:

—Базовый Asterisk: ~50–100 МБ
—На каждый одновременный звонок: ~2–4 МБ (с записью: ~8–10 МБ)
—Обработка CDR/CEL: буфер ~50–100 МБ
—Рекомендация: минимум 4 ГБ на 50 операторов, 8 ГБ на 100+

Хранилище:

—Записи разговоров: закладывайте 1 ГБ на час записи (G.711)
—База CDR: ~1 КБ на запись о звонке
—Под базу CDR и активные записи используйте SSD
—Старые записи переносите на HDD или в облако

Тюнинг ядра Linux:

# /etc/sysctl.conf - базовый тюнинг для колл-центров на Asterisk

# Увеличиваем лимиты файловых дескрипторов
fs.file-max = 655350

# Оптимизация сетевых буферов
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 65536
net.core.wmem_default = 65536

# Увеличиваем conntrack для SIP
net.netfilter.nf_conntrack_max = 131072

# Сокращаем количество сокетов в TIME_WAIT
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Снижаем склонность к свопу (держим Asterisk в RAM)
vm.swappiness = 10

# /etc/security/limits.conf
asterisk  soft  nofile  65536
asterisk  hard  nofile  65536
asterisk  soft  nproc   8192
asterisk  hard  nproc   8192

1.2 Оптимизация пула потоков PJSIP

Пул потоков PJSIP напрямую определяет, насколько быстро Asterisk обрабатывает SIP-транзакции:

; pjsip.conf - секция [system]
[system]
type=system

; Для колл-центра от 50 операторов
threadpool_initial_size=20
threadpool_auto_increment=5
threadpool_idle_timeout=120
threadpool_max_size=100

; Уменьшаем SIP-таймер для более быстрого обнаружения сбоев
timer_t1=100
timer_b=6400

Подбор размера по масштабу колл-центра:

Операторов	Initial Size	Max Size	Auto Increment
10–25	10	50	5
25–50	20	100	5
50–100	30	150	10
100–200	50	200	10
200+	80	300	15

1.3 Тюнинг шины сообщений Stasis

Шина Stasis обслуживает события AMI, обработку CDR и ARI — всё это критично для мониторинга колл-центра:

; stasis.conf
[threadpool]
initial_size = 10
idle_timeout_sec = 120
max_size = 60

Совет: если AMI вам не нужен (например, вы используете отдельный аналитический инструмент), отключение res_manager снижает нагрузку на CPU на 5–10% на загруженных системах.

1.4 Порядок идентификации endpoint'ов

Небольшая, но заметная оптимизация — сначала обрабатывать зарегистрированные телефоны:

; pjsip.conf - секция [global]
[global]
type=global
; Телефоны регистрируются (username), транки работают по IP
endpoint_identifier_order=username,ip,anonymous

Так Asterisk не перебирает правила на основе IP для каждого зарегистрированного телефона, экономя миллисекунды на транзакции — а на масштабе это складывается в заметную величину.

Часть 2. Оптимизация конфигурации очередей

Именно в настройке очередей у большинства колл-центров скрыт самый большой потенциал оптимизации. Неправильно настроенная очередь съедает 20–30% рабочего времени операторов.

2.1 Выбор стратегии очереди

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

; queues.conf
[sales]
strategy = rrmemory        ; Круговой обзвон с памятью
timeout = 15               ; Звоним оператору 15 секунд
retry = 1                  ; Повтор сразу после таймаута
wrapuptime = 10            ; 10 секунд постобработки между звонками
maxlen = 50                ; Максимум 50 абонентов в очереди

[support]
strategy = fewestcalls     ; Отдаём оператору с наименьшим числом звонков
timeout = 20               ; Для поддержки звоним чуть дольше
retry = 1
wrapuptime = 30            ; Больше времени на постобработку сложных звонков
maxlen = 30

Сравнение стратегий для колл-центров:

Стратегия	Для чего подходит	Плюсы	Минусы
`ringall`	Небольшие команды (<5)	Самый быстрый ответ	Неравномерная нагрузка
`rrmemory`	Универсальные очереди	Равномерное распределение	Не учитывает навыки
`fewestcalls`	Очереди поддержки	Сбалансированная нагрузка	Новичков заваливает звонками
`leastrecent`	Продажи с большим объёмом	Гарантирует паузу между звонками	Сильные операторы могут простаивать
`random`	Очереди перелива	Невозможно «подкрутить» под себя	Непредсказуемая нагрузка
`wrandom`	Маршрутизация по навыкам	Управление через веса	Сложно настраивать

2.2 Оптимизация таймаутов и повторов

Взаимодействие параметров timeout, retry и wrapuptime критично:

Полный цикл = timeout + retry + wrapuptime

Для очереди с timeout=15, retry=1, wrapuptime=10:

—Одна попытка дозвона до оператора занимает максимум 26 секунд
—Абонент, которого пробуют соединить с 3 свободными операторами, ждёт в худшем случае ~78 секунд

Целевые значения по типам очередей:

Тип очереди	Timeout	Retry	Wrapup	Обоснование
Продажи (входящие)	12 с	1 с	5 с	Решает скорость
Техподдержка	20 с	1 с	30 с	Оператору нужно время на документацию
Биллинг	15 с	1 с	15 с	Средняя сложность
VIP/приоритет	10 с	0 с	5 с	Ответить как можно быстрее
Перелив	25 с	1 с	0 с	Максимизируем шанс ответа

2.3 Вес и приоритет очереди

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

; queues.conf
[vip-support]
weight = 10             ; Наивысший приоритет
strategy = ringall

[standard-support]
weight = 5
strategy = rrmemory

[overflow-support]
weight = 1              ; Самый низкий приоритет
strategy = leastrecent

Если оператор состоит в нескольких очередях, звонки первыми приходят из очередей с бо́льшим весом. Это обязательное условие для управления SLA.

2.4 Динамическое членство в очередях

Статическое членство в очереди тратит ёмкость впустую. Динамическое даёт возможность оптимизировать состав в реальном времени:

; queues.conf
[support]
member => PJSIP/agent101,0,Agent 101,SIP/agent101  ; Статический (резерв)
; Динамические участники добавляются через:
; CLI: queue add member PJSIP/agent102 to support
; AMI: действие QueueAdd
; Диалплан: AddQueueMember()

Диалплан для входа и выхода оператора:

; extensions.conf
[agent-controls]
; *51 = Вход в очередь
exten => *51,1,Answer()
 same => n,AddQueueMember(support,PJSIP/${CALLERID(num)})
 same => n,Playback(agent-loginok)
 same => n,Hangup()

; *52 = Выход из очереди
exten => *52,1,Answer()
 same => n,RemoveQueueMember(support,PJSIP/${CALLERID(num)})
 same => n,Playback(agent-loggedoff)
 same => n,Hangup()

; *53 = Пауза (перерыв)
exten => *53,1,Answer()
 same => n,PauseQueueMember(support,PJSIP/${CALLERID(num)},,Break)
 same => n,Playback(beep)
 same => n,Hangup()

; *54 = Снять паузу (вернулся с перерыва)
exten => *54,1,Answer()
 same => n,UnpauseQueueMember(support,PJSIP/${CALLERID(num)})
 same => n,Playback(beep)
 same => n,Hangup()

2.5 Оптимизация объявлений в очереди

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

[support]
; Объявления о позиции и времени ожидания
announce-frequency = 60          ; Каждые 60 секунд
announce-holdtime = once         ; Сообщить расчётное время ожидания один раз
announce-position = yes          ; «Вы номер X в очереди»
min-announce-frequency = 30      ; Не чаще одного объявления в 30 секунд

; Периодические объявления
periodic-announce = custom/thank-you-for-waiting
periodic-announce-frequency = 45

; Музыка на удержании
musicclass = support-moh         ; Отдельный MOH для этой очереди

; Объявления оператору при подключении
announce-to-first-user = yes

Антипаттерн, которого стоит избегать: announce-frequency=15 при длительности объявления 10 секунд. Получается цикл, где абонент слышит объявления практически без пауз — это увеличивает долю сорванных звонков на 20–40%.

Часть 3. Оптимизация маршрутизации звонков

3.1 Оптимизация IVR: меньше уровней — больше решённых обращений

Каждый уровень IVR стоит вам части звонивших. Отраслевые данные показывают:

Глубина IVR	Доля дошедших до конца
1 уровень	95%
2 уровня	80%
3 уровня	60%
4+ уровня	<40%

Оптимизированная структура IVR:

; extensions.conf
[ivr-main]
exten => s,1,Answer()
 same => n,Set(TIMEOUT(response)=5)
 same => n,Background(custom/welcome-short)  ; Не длиннее 8 секунд
 same => n,WaitExten(3)

; Сразу в отдел - ОДИН уровень вложенности
exten => 1,1,Goto(queue-sales,s,1)        ; Продажи
exten => 2,1,Goto(queue-support,s,1)      ; Поддержка
exten => 3,1,Goto(queue-billing,s,1)      ; Биллинг
exten => 0,1,Goto(queue-reception,s,1)    ; Оператор

; Таймаут/неверный ввод → в общую очередь (без зацикливания!)
exten => t,1,Goto(queue-support,s,1)
exten => i,1,Goto(queue-support,s,1)

Ключевые правила оптимизации IVR:

—Максимум 2 уровня IVR
—Приветствие короче 8 секунд
—Всегда оставляйте вариант «нажмите 0, чтобы связаться с оператором»
—По таймауту — в очередь, а не на повтор меню
—Отслеживайте долю прохождения IVR: если она ниже 80%, упрощайте

3.2 Маршрутизация по навыкам

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

; queues.conf
[support-english]
strategy = wrandom

; Маршрутизация по навыкам через penalty:
; penalty 0 = основной навык, penalty 5 = вторичный, penalty 10 = резерв
member => PJSIP/agent101,0     ; Носитель английского
member => PJSIP/agent102,0     ; Носитель английского
member => PJSIP/agent103,5     ; Средний уровень английского
member => PJSIP/agent104,10    ; Базовый английский (крайний случай)

[support-spanish]
strategy = wrandom
member => PJSIP/agent103,0     ; Носитель испанского
member => PJSIP/agent104,0     ; Носитель испанского
member => PJSIP/agent101,10    ; Базовый испанский (резерв)

Диалплан с эскалацией по penalty (прогрессивная маршрутизация):

[queue-support]
exten => s,1,Answer()
 same => n,Set(QUEUE_MAX_PENALTY=0)         ; Сначала пробуем основных операторов
 same => n,Queue(support,,,,30)             ; Ждём 30 с основных
 same => n,Set(QUEUE_MAX_PENALTY=5)         ; Эскалация на вторичных
 same => n,Queue(support,,,,30)             ; Ждём ещё 30 с
 same => n,Set(QUEUE_MAX_PENALTY=10)        ; Подключаем всех операторов
 same => n,Queue(support,,,,60)             ; Последняя попытка
 same => n,VoiceMail(support@default,u)     ; Откат на голосовую почту
 same => n,Hangup()

3.3 Маршрутизация по времени

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

[inbound-handler]
exten => s,1,Answer()
 same => n,GotoIfTime(09:00-18:00,mon-fri,,?business-hours,s,1)
 same => n,GotoIfTime(09:00-13:00,sat,,?saturday-hours,s,1)
 same => n,Goto(after-hours,s,1)

[business-hours]
exten => s,1,Goto(ivr-main,s,1)

[saturday-hours]
exten => s,1,Set(QUEUE_MAX_PENALTY=0)   ; По субботам только основные операторы
 same => n,Queue(support,,,,60)
 same => n,VoiceMail(support@default,u)
 same => n,Hangup()

[after-hours]
exten => s,1,Playback(custom/after-hours-message)
 same => n,VoiceMail(support@default,u)
 same => n,Hangup()

3.4 Приоритетная маршрутизация по Caller ID

Распознавайте повторно звонящих и VIP-клиентов:

[inbound-handler]
exten => s,1,Answer()
 ; Проверяем, VIP ли это клиент (по базе или файлу)
 same => n,Set(VIP=${DB(vip/${CALLERID(num)})})
 same => n,GotoIf($["${VIP}" = "yes"]?vip-queue,s,1)
 ; Проверяем, звонил ли абонент за последние 24 часа
 same => n,Set(RECENT=${DB(recent/${CALLERID(num)})})
 same => n,GotoIf($["${RECENT}" != ""]?priority-queue,s,1)
 ; Обычная маршрутизация
 same => n,Goto(ivr-main,s,1)

[vip-queue]
exten => s,1,Queue(vip-support,,,,120)   ; VIP-очередь с увеличенным таймаутом
 same => n,Hangup()

Часть 4. Оптимизация работы операторов

4.1 Управление статусами операторов

Корректный учёт статусов не даёт появляться «мёртвым душам» — операторам, которые залогинены, но на самом деле недоступны:

; Настройка мониторинга состояния устройства в pjsip.conf
[agent101]
type=endpoint
device_state_busy_at=1    ; Помечать занятым после 1 активного звонка

Ключевые статусы операторов, которые нужно отслеживать:

Статус	Описание	Что оптимизировать
Доступен	Готов принимать звонки	Следить за равномерным распределением
На линии	Идёт разговор	Контролировать время разговора
Постобработка	Работа после звонка	Ограничивать по времени
Пауза (перерыв)	Плановый перерыв	Контролировать соблюдение графика
Пауза (обучение)	На обучении	Ставить на часы низкой нагрузки
Недоступен	Не отвечает	Автовыход после 3 пропущенных звонков

4.2 Автовыход неотвечающих операторов

Оператор, который не берёт трубку, крадёт время у каждого абонента в очереди:

; queues.conf
[support]
autopause = yes           ; Автопауза после пропущенного звонка
autopausedelay = 0        ; Немедленно
autopausebusy = no        ; Не ставить на паузу при «занято» (может говорить по другой очереди)
autopauseunavail = yes    ; Ставить на паузу при недоступности

Продвинутый вариант: автовыход после N пропущенных звонков (диалплан + AGI):

; Считаем пропущенные звонки по каждому оператору
[queue-support]
exten => s,1,Queue(support,,,,30)
 same => n,ExecIf($["${QUEUESTATUS}" = "TIMEOUT"]?Set(DB(missed/${MEMBERINTERFACE})=$[${DB(missed/${MEMBERINTERFACE})} + 1]))
 same => n,ExecIf($[${DB(missed/${MEMBERINTERFACE})} >= 3]?PauseQueueMember(support,${MEMBERINTERFACE},,AutoPaused-3-missed))

4.3 Оптимизация времени постобработки

Время постобработки — убийца ёмкости №1, которого обычно не замечают. Слишком много — теряете ёмкость. Слишком мало — страдает качество данных.

Ориентиры по типам звонков:

Тип звонка	Рекомендуемая постобработка	Примечания
Простой вопрос	5–10 с	Автоматическая простановка результата
Звонок по продаже	10–15 с	Нужно обновить CRM
Техподдержка	20–30 с	Создание тикета
Сложная эскалация	45–60 с	Критична подробная документация

Реализация с кодами результата:

[post-call]
exten => s,1,Set(WRAPUP_START=${EPOCH})
 same => n,Read(DISPOSITION,,1,,,5)  ; 5 секунд на ввод кода результата
 same => n,Set(CDR(disposition)=${DISPOSITION})
 same => n,Set(WRAPUP_TIME=$[${EPOCH} - ${WRAPUP_START}])
 same => n,UserEvent(WrapupComplete,Agent: ${CALLERID(num)},Duration: ${WRAPUP_TIME},Disposition: ${DISPOSITION})
 same => n,Hangup()

Часть 5. Оптимизация качества связи и записи разговоров

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

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

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

5.1 Подбор кодеков для колл-центра

; pjsip.conf - шаблон endpoint для операторов колл-центра
[agent-template](!)
type=endpoint
allow=!all,ulaw,alaw       ; Только G.711 - минимум CPU, лучшее качество в LAN
dtls_auto_generate_cert=yes

Гид по выбору кодека:

Кодек	Полоса	CPU	Качество	Где применять
G.711 ulaw	87 кбит/с	Минимум	Отличное	Операторы в LAN, локальные транки
G.711 alaw	87 кбит/с	Минимум	Отличное	Стандарт для ЕС
G.722	87 кбит/с	Низкий	HD-звук	Премиальные очереди
G.729	31 кбит/с	Высокий	Хорошее	Удалённые операторы, WAN
Opus	Переменная	Средний	Отличное	WebRTC-операторы

Для колл-центров: внутри LAN (операторы) используйте G.711, а с транками договаривайтесь по их предпочтениям. По возможности избегайте транскодинга — он добавляет задержку и нагрузку на CPU.

5.2 Практики записи разговоров

; Записываем все звонки в очереди поддержки
[queue-support]
exten => s,1,Set(MONITOR_FILENAME=/var/spool/asterisk/monitor/${STRFTIME(${EPOCH},,%Y/%m/%d)}/${UNIQUEID})
 same => n,MixMonitor(${MONITOR_FILENAME}.wav,b)
 same => n,Queue(support)
 same => n,StopMixMonitor()

Как оптимизировать запись:

—Пишите в WAV (низкая нагрузка на CPU), а ночью по cron конвертируйте в MP3
—Раскладывайте по датам (/YYYY/MM/DD/) — так проще архивировать
—Настройте права доступа к записям, чтобы оператор не мог слушать чужие разговоры
—Введите политику хранения: 90 дней в оперативном доступе, год в архиве, затем удаление
—Следите за местом на диске — оповещение при заполнении на 80%

# Ночная задача cron для конвертации
# /etc/cron.d/asterisk-recording-convert
0 2 * * * asterisk find /var/spool/asterisk/monitor/$(date -d yesterday +\%Y/\%m/\%d) -name "*.wav" -exec sox {} {}.mp3 \; -delete

5.3 Настройка jitter buffer

Для удалённых операторов и SIP-транков с нестабильной задержкой:

; pjsip.conf
[remote-agent-template](!)
type=endpoint
allow=!all,g729,ulaw
; Фиксированный jitter buffer для стабильного качества связи
jbimpl=fixed
jbmaxsize=200           ; Буфер максимум 200 мс
jbtargetextra=40        ; Дополнительная буферизация
jblog=no                ; В продакшене логирование отключаем

Часть 6. Мониторинг и аналитика — множитель для всей оптимизации

Без данных все описанные выше оптимизации остаются догадками. Мониторинг превращает догадки в науку.

6.1 Обязательные метрики колл-центра

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

Метрики для дашборда в реальном времени:

Метрика	Цель	Порог оповещения	Действие
Звонков в очереди	<10	>15	Подключить операторов из перелива
Максимальное ожидание	<60 с	>120 с	Немедленная эскалация
Свободных операторов	>20% от общего числа	<10%	Отменить перерывы
Service Level	>80% за 20 с	<60%	Экстренно выводить людей на линию
Доля сорванных звонков	<5%	>8%	Включить обратные звонки

Метрики для исторического анализа:

Метрика	Зачем нужна	Как часто смотреть
Среднее время обработки (AHT)	Эффективность оператора	Ежедневно
Решение с первого звонка (FCR)	Индикатор качества	Еженедельно
Утилизация операторов	Планирование ёмкости	Еженедельно
Стоимость звонка	Финансовое здоровье	Ежемесячно
Удовлетворённость клиентов (CSAT)	Качество клиентского опыта	Ежемесячно

6.2 Мониторинг в реальном времени через AMI

Asterisk Manager Interface (AMI) отдаёт поток событий в реальном времени:

; manager.conf
[monitoring]
secret = strong_password_here
permit = 127.0.0.1/255.255.255.255
read = call,agent,reporting
write = command
eventfilter = Event: QueueMember*
eventfilter = Event: QueueCaller*
eventfilter = Event: AgentConnect
eventfilter = Event: AgentComplete

Ключевые события AMI для мониторинга колл-центра:

Событие	Какие данные даёт	Для чего использовать
`QueueCallerJoin`	Очередь, позиция, caller ID	Глубина очереди в реальном времени
`QueueCallerLeave`	Причина (ответили, сорвался, таймаут)	Учёт сорванных звонков
`AgentConnect`	Время ожидания, оператор	Расчёт service level
`AgentComplete`	Время разговора, время удержания	Анализ AHT
`QueueMemberPause`	Причина, длительность	Соблюдение графика перерывов
`QueueMemberStatus`	Состояние устройства	Доступность оператора

6.3 Анализ CDR и CEL

CDR (Call Detail Records) и CEL (Channel Event Logging) — сырьё для всей исторической отчётности:

; cdr.conf
[general]
enable=yes
unanswered=yes          ; Учитываем и неотвеченные звонки
congestion=yes          ; Учитываем события перегрузки
endbeforehexten=no      ; Завершать CDR до расширения h

; cdr_adaptive_odbc.conf (для хранения в базе)
[asterisk-cdr]
connection=asterisk
table=cdr
alias start => calldate
alias clid => clid
alias src => src
alias dst => dst
alias dcontext => dcontext
alias channel => channel
alias dstchannel => dstchannel
alias lastapp => lastapp
alias lastdata => lastdata
alias duration => duration
alias billsec => billsec
alias disposition => disposition
alias uniqueid => uniqueid

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

-- Почасовой профиль нагрузки (для планирования смен)
SELECT
    EXTRACT(HOUR FROM calldate) AS hour,
    COUNT(*) AS total_calls,
    COUNT(CASE WHEN disposition = 'ANSWERED' THEN 1 END) AS answered,
    COUNT(CASE WHEN disposition = 'NO ANSWER' THEN 1 END) AS abandoned,
    ROUND(AVG(CASE WHEN disposition = 'ANSWERED' THEN billsec END), 1) AS avg_talk_time,
    ROUND(AVG(duration - billsec), 1) AS avg_wait_time
FROM cdr
WHERE calldate >= CURRENT_DATE - INTERVAL '7 days'
    AND dcontext LIKE 'queue-%'
GROUP BY EXTRACT(HOUR FROM calldate)
ORDER BY hour;

-- Рейтинг операторов по результативности
SELECT
    dstchannel AS agent,
    COUNT(*) AS calls_handled,
    ROUND(AVG(billsec), 1) AS avg_talk_time,
    ROUND(AVG(duration - billsec), 1) AS avg_wait_before_answer,
    MAX(billsec) AS longest_call,
    SUM(billsec) / 3600.0 AS total_hours
FROM cdr
WHERE disposition = 'ANSWERED'
    AND dcontext LIKE 'queue-%'
    AND calldate >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY dstchannel
ORDER BY calls_handled DESC;

-- Расчёт service level (% отвеченных за 20 секунд)
SELECT
    DATE(calldate) AS day,
    COUNT(*) AS total_calls,
    COUNT(CASE WHEN disposition = 'ANSWERED'
               AND (duration - billsec) <= 20 THEN 1 END) AS within_sla,
    ROUND(
        100.0 * COUNT(CASE WHEN disposition = 'ANSWERED'
                           AND (duration - billsec) <= 20 THEN 1 END)
        / NULLIF(COUNT(*), 0), 1
    ) AS service_level_pct
FROM cdr
WHERE calldate >= CURRENT_DATE - INTERVAL '30 days'
    AND dcontext LIKE 'queue-%'
GROUP BY DATE(calldate)
ORDER BY day;

6.4 Почему готовая аналитика выигрывает у самописной

Строить дашборды на сырых CDR можно, но на настройку и поддержку уйдёт 40–80 часов. Вам придётся:

—Писать и поддерживать SQL-запросы (обновляя их при смене версий Asterisk)
—Собирать дашборды для визуализации (Grafana, самописные веб-приложения)
—Настраивать правила оповещений
—Заниматься хранением и архивацией данных
—Делать отчёты по работе операторов
—Создавать вол-борды реального времени

Поэтому команды переходят на специализированные инструменты аналитики для Asterisk — например, Astervis. Одна команда установки, и вы получаете:

—30+ готовых графиков: тепловые карты, рейтинги операторов, аналитика по транкам
—Дашборды в реальном времени: глубина очереди, время ожидания, статусы операторов — вживую
—Управление операторами: KPI, оценка результативности, графики работы
—Интеграция с CRM: Bitrix24, AmoCRM — звонки привязаны к сделкам
—Прослушивание записей: поиск и фильтры прямо в дашборде
—Установка за 15 минут: curl -sSL https://api.astervis.io/api/releases/install.sh | bash

Никаких SQL-запросов. Никакой поддержки дашбордов Grafana. Никакого самописного кода.

Часть 7. Операционные практики

7.1 Как планировать ёмкость

Используйте исторические данные, чтобы прогнозировать потребность в персонале:

Входные данные для формулы Erlang C:

—Среднее число звонков в час (из CDR)
—Среднее время обработки (разговор + постобработка)
—Целевой service level (например, 80% за 20 секунд)

Быстрая таблица по численности (SLA 80/20):

Звонков/час	AHT (мин)	Нужно операторов	Занятость
50	4	5	67%
100	4	9	74%
200	4	17	78%
300	4	25	80%
500	4	40	83%

Внимание: занятость операторов выше 85% ведёт к выгоранию. Планируйте максимум 75–80% устойчивой занятости.

7.2 Стратегия перелива очередей

Не заставляйте абонентов ждать бесконечно. Внедрите прогрессивный перелив:

0-30 с:    Основная очередь (операторы с нужными навыками)
30-60 с:   Вторичная очередь (тот же отдел, ниже уровень навыка)
60-90 с:   Очередь перелива (любой свободный оператор)
90-120 с:  Предложение обратного звонка
120 с+:    Голосовая почта с обещанием перезвонить

; extensions.conf - прогрессивный перелив
[queue-support-overflow]
exten => s,1,Set(QUEUE_MAX_PENALTY=0)
 same => n,Queue(support,,,,30)          ; 30 с: основные операторы
 same => n,Set(QUEUE_MAX_PENALTY=5)
 same => n,Queue(support,,,,30)          ; 60 с: вторичные операторы
 same => n,Set(QUEUE_MAX_PENALTY=10)
 same => n,Queue(support,,,,30)          ; 90 с: все операторы
 same => n,Goto(callback-offer,s,1)      ; Предлагаем обратный звонок

7.3 Управление SLA

Определите и контролируйте SLA по каждой очереди:

Очередь	Целевой SLA	Как измеряем
VIP-поддержка	95% за 10 с	Промахи недопустимы
Продажи	80% за 20 с	Прямое влияние на выручку
Общая поддержка	80% за 30 с	Отраслевой стандарт
Биллинг	70% за 45 с	Ниже срочность
Email/обратный звонок	Ответ в течение 24 часов	Другой тип SLA

7.4 Цикл непрерывных улучшений

Оптимизация — не разовый проект. Запустите еженедельный цикл разбора:

Еженедельный разбор оптимизации (30 минут):

—Service Level (5 мин): выполнили ли целевые SLA? Какие очереди провалились?
—Работа операторов (10 мин): лучшие и худшие. Кому нужен коучинг?
—Анализ профиля звонков (5 мин): были ли новые всплески объёма? Есть ли сезонность?
—Конфигурация очередей (5 мин): актуальны ли текущие timeout и wrapup?
—Здоровье системы (5 мин): динамика CPU, памяти, диска. Есть ли риски по ёмкости?

Часть 8. Типичные ошибки оптимизации

Ошибка 1: чрезмерная погоня за AHT

Когда операторов давят сокращением времени обработки, обычно растёт число повторных звонков. Смотрите вместо этого на решение с первого звонка.

Ошибка 2: слишком много объявлений в очереди

Объявления о позиции каждые 15 секунд бесят абонентов. Ставьте announce-frequency минимум на 45–60 секунд.

Ошибка 3: нет стратегии перелива

Абонент, который ждёт больше 2 минут без альтернатив, бросит трубку — и уже не перезвонит. Всегда держите запасной вариант: обратный звонок или голосовую почту.

Ошибка 4: жёсткая привязка операторов

Держать операторов в фиксированных очередях — значит терять ёмкость при колебаниях нагрузки. Используйте динамическое членство в очередях вместе с маршрутизацией по навыкам.

Ошибка 5: игнорирование звонков в нерабочее время

Многие компании теряют 15–20% потенциальной выручки, просто не обрабатывая звонки вне рабочего времени. Внедрите voicemail-to-email, запись на обратный звонок или маршрутизацию на удалённых операторов в других часовых поясах.

Ошибка 6: отсутствие мониторинга

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

Чек-лист оптимизации

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

Системный уровень:

— Ядро Linux настроено (файловые дескрипторы, сетевые буферы, swap)
— Пул потоков PJSIP рассчитан на ваше число операторов
— Пул потоков Stasis настроен
— Порядок идентификации endpoint'ов оптимизирован
— Ненужные модули отключены

Конфигурация очередей:

— Стратегия обзвона соответствует назначению очереди
— Timeout/retry/wrapup подобраны под каждую очередь
— Веса очередей настроены под приоритеты
— Включено динамическое членство
— Объявления звучат не слишком часто

Маршрутизация звонков:

— В IVR максимум 2 уровня
— Внедрена маршрутизация по навыкам
— Настроена маршрутизация по времени
— Есть стратегия перелива
— Доступен вариант обратного звонка

Управление операторами:

— Включена автопауза при пропущенных звонках
— Время постобработки адекватно каждой очереди
— Статусы операторов корректно отслеживаются
— Метрики результативности видны супервайзерам

Мониторинг:

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

Главное

—Начинайте с измерений. Поставьте мониторинг до изменений, чтобы улучшения можно было оцифровать.
—Системный тюнинг имеет значение. Пул потоков PJSIP и настройки ядра способны увеличить ёмкость по одновременным звонкам в 2–3 раза.
—Конфигурация очередей даёт максимальный ROI. Стратегия, таймауты и веса напрямую влияют на опыт каждого абонента.
—Маршрутизация по навыкам сокращает переводы на 30–40%, повышая и эффективность, и удовлетворённость клиентов.
—Оптимальная утилизация операторов — 75–80%. Выше — выгорание, ниже — переплата по фонду оплаты труда.
—Прогрессивный перелив спасает от сорванных звонков. Никогда не оставляйте абонента ждать без альтернатив.
—Постепенные улучшения работают лучше разовой большой перестройки. Еженедельные 30-минутные разборы дают накопительный эффект.

Начните оптимизацию сегодня

Не нужно внедрять всё сразу. Начните с того, что даёт максимальный эффект:

—Поставьте мониторинг, чтобы зафиксировать точку отсчёта
—Оптимизируйте таймауты и стратегии очередей
—Внедрите маршрутизацию по навыкам
—Настройте перелив и обработку обратных звонков
—Запланируйте еженедельные разборы оптимизации

Чтобы мгновенно увидеть, что происходит в вашем колл-центре на Asterisk, попробуйте Astervis — 30+ графиков в реальном времени, контроль работы операторов и интеграция с CRM. Установка за 15 минут, без настройки.

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

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

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

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

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

Полное руководство по оптимизации колл-центра на Asterisk