Руководство по эксплуатации

SmartCPD это drop-in решение для систем исходящего обзвона. Оно встраивается в существующий контур телефонии и позволяет определять, кто находится на стороне абонента: человек, робот, тишина или иной непродуктивный сценарий вызова.

Основная практическая цель SmartCPD — снижать затраты на обслуживание исходящего обзвона. Система помогает отсекать лишние и непродуктивные вызовы, не передавать их дальше в работу оператору и тем самым уменьшать потери времени, каналов и стоимости обработки.

Интеграция в телефонную инфраструктуру#

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

• SmartCPD подключается к существующей VoIP-инфраструктуре как дополнительный слой обработки вызовов, а не как замена всей телефонии.
• Основные изменения в инфраструктуре обычно ограничиваются настройкой маршрута вызова через SmartCPD.
• Для интеграции с дайлером дополнительно требуется только обработка на его стороне SIP-кодов для вызовов, которые SmartCPD отсек по результатам обработки. Эти коды настраиваются.
• Весь контроль вызовов, маршрутизация и данные остаются внутри контура заказчика и не требуют вывода телефонии “наружу”.
• Внедрение можно делать поэтапно, без остановки всей схемы исходящего обзвона.
• Основной эффект достигается без сложной перестройки инфраструктуры: система начинает отсекать лишние вызовы и снижать нагрузку на операторов и каналы.

Варианты интеграции SmartCPD в существующую VoIP-инфраструктуру.

Возможности VoIP-интеграции#

SmartCPD поддерживает типовые задачи интеграции с существующей телефонной инфраструктурой контакт-центра и позволяет адаптировать обработку вызовов под требования конкретной схемы дозвона.

Базовые возможности интеграции:

• Поддержка SIP-транков как в режиме point-to-point, так и в режиме с авторизацией.
• Получение уникального идентификатора вызова не только из стандартного SIP Call-ID, но и из настраиваемого SIP-заголовка, если это требуется для интеграции с дайлером или внешними системами.
• Настройка передачи обязательных SIP-заголовков из дайлера в сторону ТФоП.
• Преобразование полей From и To, включая подстановку и замену значений по правилам интеграции.
• Выбор исходящего транка в зависимости от типа вызова, правила маршрутизации или выбранного сегмента обработки.
• Поддержка SIP Re-INVITE и SIP REFER при соединении вызовов.

Это позволяет встроить SmartCPD в существующую схему обзвона без отказа от текущих правил идентификации вызовов, маршрутизации и работы с SIP-заголовками.

Варианты развертывания#

SmartCPD может использоваться как в компактной установке для небольших нагрузок, так и в масштабируемой конфигурации для крупных проектов исходящего обзвона.

• Для небольших инсталляций система может быть развернута на одном сервере.
• При росте нагрузки SmartCPD поддерживает горизонтальное масштабирование рабочих компонентов без изменения общей модели использования продукта.
• Для продуктивной эксплуатации поддерживается отказоустойчивая схема развертывания, которая снижает риск остановки обработки новых вызовов при отказе одного или нескольких узлов.

Сегментация вызовов#

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

Сегмент обычно задает:

• правило, по которому вызов попадает в этот сегмент;
• профиль обработки и детекции;
• дальнейший маршрут вызова, включая выбор исходящего транка.

Критерии сегментации задаются гибко и поддерживают правила на основе регулярных выражений.

Сегментация может строиться, в том числе, по:

• SIP-заголовкам;
• полю SIP From;
• полю SIP To.

За счет сегментации можно, например:

• по-разному обслуживать разные кампании или направления обзвона;
• включать разные правила обработки для разных типов трафика;
• проводить A/B-тесты разных сценариев обслуживания и сравнивать их результат;
• направлять вызовы по разным маршрутам в зависимости от сценария обслуживания.

Профиль обслуживания#

Внутри сегмента процесс обработки вызова определяется профилем.

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

• настройки параметров детекции;
• настройку строгости детекции и правил принятия решения;
• настройку таймингов анализа и числа повторных попыток;
• настройки вызова дополнительных сервисов, если они используются;
• настройку действий по результатам этапов обработки: соединить, продолжить обработку или сбросить вызов;
• настройку SIP-кодов, которые передаются в сторону Дайлера при сбросе вызова;
• настройку роликов для “пробития тишины”, чтобы попытаться разговорить абонента.

Процесс обработки вызова#

Обработка вызова в SmartCPD разбита на последовательные этапы. На каждом этапе система принимает решение, нужно ли продолжать обслуживание вызова, соединять его с оператором или завершать.

Каждый этап может вызывать один или несколько сервисов SmartCPD. Основной сервис — это детекция стороны абонента, которая используется всегда. Дополнительно могут использоваться другие сервисы, например определение вероятности успешного дозвона и другие вспомогательные проверки.

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

• продолжить обработку вызова;
• соединить вызов;
• завершить вызов.

Именно за счет этого SmartCPD можно адаптировать под разные сценарии обзвона без изменения общей схемы работы контакт-центра.

Процесс обработки вызова в SmartCPD.

Этапы обработки вызова#

• PreCall Этап до начала дозвона. Он существует всегда, отвечает за первичные проверки, включая проверку лицензионных ограничений, и определяет, нужно ли вообще выполнять вызов.

• PreConnect Этап после снятия трубки, но до основной обработки соединения. На этом шаге анализируется то, как происходил дозвон и что происходило до подтвержденного соединения, включая ранние состояния вызова.

• PostConnect Этап взаимодействия с клиентом и анализа уже установленного соединения. Этот этап может вызываться несколько раз циклично, пока не будет получен итоговый положительный или отрицательный результат в рамках заданных таймаутов.

• PostCall Завершающий этап, который выполняется всегда. На нем регистрируется финальный исход обработки вызова.

Детекция#

Детекция — это анализ ответившей стороны вызова, который позволяет SmartCPD определить, кто находится на линии: человек, робот, IVR, тишина или иной непродуктивный сценарий. Это основной сервис SmartCPD и ключевая функция продукта: именно на основании детекции система принимает решение, стоит ли передавать вызов дальше в работу или его нужно завершить.

Детекция — это не одна проверка, а сложный процесс, который работает на нескольких этапах обработки вызова и включает несколько последовательных шагов анализа.

• На этапе PreConnect анализируется то, что происходило до подтвержденного соединения.
• На этапе PostConnect система пытается получить голос клиента и пригодный для анализа звуковой фрагмент.

Для этого на PostConnect используются заранее подготовленные ролики. После каждой попытки “разговорить” абонента полученный фрагмент анализируется. Если его нельзя проанализировать, система повторяет попытку в рамках заданных таймаутов и числа попыток.

Если на этапе PreConnect система приходит к выводу, что на линии человек, вызов переходит на PostConnect. Если на этом этапе получен иной терминальный результат, вызов может быть завершен с заданным действием и соответствующим SIP-кодом.

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

• временем снятия трубки;
• анализом сообщений дозвона до подтвержденного соединения;
• анализом музыки, голосовых сообщений операторов связи и специальных информационных тонов;
• анализом количества слов и пауз между ними;
• сопоставлением с известными и предопределенными шаблонами;
• переводом речи в текст и анализом его содержания;
• оценкой специализированной AI/ML-модели;
• другими эвристиками и проверками.

Процесс детекции в SmartCPD.

Результаты детекции#

Настройка детекции#

Параметры детекции можно настраивать под конкретный сценарий обзвона.

В частности, профиль позволяет управлять:

• строгостью детекции и порогом принятия решения;
• минимальным временем, которое должно пройти до ответа на вызов;
• максимальным временем ожидания речи;
• количеством повторных попыток анализа при отсутствии речи.

Это позволяет выбирать более консервативную или более агрессивную модель обработки в зависимости от задач кампании и допустимого уровня ошибок.

Пробитие тишины#

Если на этапе PostConnect системе не хватает речи для анализа, используется механизм “пробития тишины”. Для этого SmartCPD проигрывает заранее подготовленные ролики, например “алло” или “здравствуйте”, чтобы получить голосовой ответ клиента и передать его в детекцию.

Ролики входят в поставку, но также могут загружаться дополнительными наборами. Один и тот же клиентский номер в течение дня может получать разные ролики по правилам ротации. По умолчанию при каждом новом вызове в течение дня используется следующий ролик, но правила ротации можно настраивать, в том числе для длинных циклов из большого числа роликов.

Можно создавать разные наборы роликов и привязывать их к разным профилям обслуживания. На уровне профиля также задаются момент начала проигрывания ролика после ответа на вызов и длительность тишины перед его запуском.

Реакции на результат детекции#

По каждому результату детекции можно настроить, что система будет делать дальше.

Это позволяет отдельно определить поведение для разных исходов, например:

• соединять вызов с оператором;
• продолжать обработку;
• завершать вызов.

При необходимости на оператора можно переводить не только вызовы с результатом human, но и другие сценарии, например ivr, silence или отсутствие речи.

Для каждого сценария завершения вызова можно задать свой SIP-код ответа в сторону Дайлера. Это позволяет оптимизировать поведение системы дозвона и по-разному обрабатывать разные причины завершения вызова.

Контрольные группы и разметка операторов#

Результат детекции всегда является оценкой с высокой вероятностью, но не абсолютной гарантией. Поэтому для контроля качества важны ошибки двух типов:

• ошибки первого типа — когда до оператора доходит робот, автоответчик или иной непродуктивный вызов;
• ошибки второго типа — когда вызов с человеком ошибочно классифицируется как непродуктивный и не попадает к оператору.

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

SmartCPD также включает сервис markup, который позволяет получать результаты разметки операторов через API или через подключение к базе данных заказчика. Это нужно для контроля объема ошибок и для дальнейшего улучшения качества детекции.

Важно: без разметки операторов через markup невозможно объективно выявлять и контролировать процент ошибок второго типа, то есть случаев, когда вызов с человеком был ошибочно отнесен к непродуктивным и не попал к оператору.

Модели детекции#

В детекции используются несколько разных моделей и подготовленных наборов данных. Они работают на разных шагах анализа и вместе формируют итоговое решение системы.

В состав поставки входят необходимые модели, заранее подготовленные на облачном контуре SmartCPD на большом объеме данных и на трафике разных клиентов. В системе также есть модуль, который периодически обновляет модели из облака автоматически. При необходимости модели можно получить из облака вручную и загрузить через веб-интерфейс управления.

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

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

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

Такое обновление работает в два этапа:

• каждые 15 минут система проверяет последние вызовы на наличие схожих паттернов с одинаковым исходом;
• один раз в сутки, ночью, выполняется более широкий анализ вызовов за предыдущие сутки.

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

Статистика и метрики#

SmartCPD предоставляет два основных способа анализа результатов работы системы: статистику и метрики.

Статистика#

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

Статистика обновляется каждые 15 минут. Поэтому между фактической обработкой вызова и его появлением в таблице возможна штатная задержка.

В этом разделе используются определения Попытка вызова, Детекция и Анализируемый вызов.

Статистика используется в тех случаях, когда нужно:

• найти конкретный вызов;
• проверить результат его обработки;
• разобраться в спорной ситуации;
• выгрузить список вызовов для анализа.

Метрики#

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

Метрики используются в тех случаях, когда нужно:

• оценить общую картину работы системы;
• контролировать динамику показателей;
• сравнивать разные направления, кампании и профили;
• анализировать качество работы системы в целом, а не по одному вызову.

Разница между статистикой и метриками#

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

Метки в аналитике#

Для аналитических разрезов в метриках используются метки (labels).

Метки могут назначаться, в том числе:

• профилям;
• входящим транкам;
• исходящим транкам.

Одна и та же метка может объединять несколько сущностей одного типа, если их нужно анализировать как одну группу.

Биллинг#

Раздел биллинга нужен для контроля текущего расчетного периода, накопленного потребления в течение месяца и формирования итогового отчета за операционный месяц.

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

Для каждой даты фиксируются:

• тариф, по которому был выполнен расчет;
• общее количество соединений, попавших в расчет;
• количество тарифицируемых соединений;
• сумма списания за день;
• накопительное количество тарифицируемых соединений на конец дня в рамках месяца.

История периодов и сформированных отчетов относится к этому же контуру расчетов и используется для сверки итогового месячного результата.

В контексте биллинга используются следующие определения:

Попытка вызова#

Инициированная системой дозвона процедура установления соединения с вызываемой стороной, вне зависимости от факта ответа или успешности завершения вызова.

Детекция#

Последовательность из одного или более этапов анализа аудиопотока; если хотя бы один этап завершился без ошибки, считается, что детекция была выполнена, и вызов является анализируемым.

Анализируемый вызов#

Вызов, в рамках которого была выполнена хотя бы одна успешная операция детекции аудиопотока (без возникновения ошибки), вне зависимости от полученного результата.

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

• CDR является исходной записью строгой отчетности;
• на его основе формируется статистика и расчетные данные;
• на их основе выполняется расчет биллинга и накапливается история списаний за период.

Как рассчитывается биллинг#

Биллинг пересчитывается один раз в сутки, после полуночи.

При очередном расчете система обрабатывает:

• предыдущие сутки;
• а также более ранние сутки, если по ним расчет не был выполнен ранее.

Это означает, что биллинг не является онлайн-показателем. Данные в этом разделе отражают уже выполненный суточный расчет.

Тариф и лицензия#

Тариф является частью лицензии и используется системой как основание для расчета потребления услуги.

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

Практически это означает, что изменение лицензии в течение дня не пересчитывает уже начавшиеся сутки задним числом. Новый тариф начинает влиять на биллинг со следующих расчетных суток.

Тарификация зависит от выбранного тарифа. В зависимости от условий лицензии расчет может вестись:

• по попыткам вызова;
• по анализируемым вызовам.

При этом анализируемый вызов безусловно является попыткой дозвона, но не каждая попытка становится анализируемым вызовом.

Отчетный период#

По завершении операционного месяца необходимо сформировать отчет за период и передать его в Altuera для последующего выставления счета.

Отчет по периоду является итоговым расчетным документом по операционному месяцу. Он используется как основание для дальнейшего выставления счета и должен формироваться после завершения соответствующего месяца.

Лицензирование#

SmartCPD работает на основании лицензии, которая определяет допустимый состав функциональности и параметры использования системы.

С практической точки зрения лицензия нужна для трех вещей:

• определения доступного состава возможностей системы;
• задания допустимых ограничений использования;
• ограничения недопустимого использования вне согласованной инсталляции;
• задания тарифа, по которому рассчитывается потребление услуги.

Лицензия привязывается к конкретной инсталляции. При полной переустановке системы или существенном изменении инфраструктурного контура может потребоваться перевыпуск лицензии.

Лицензия поставляется отдельным файлом.

В лицензии задаются:

• доступная функциональность системы;
• параметры допустимой нагрузки и использования;
• тариф, по которому рассчитывается потребление услуги и формируется основание для выставления счета;
• лимиты, действующие для конкретной инсталляции.

Ограничения, заданные лицензией, могут включать, в том числе:

• количество одновременно используемых линий;
• количество наборов или детекций в сутки;
• количество наборов или детекций в месяц.

Лицензия может обновляться в любой момент, в том числе в течение уже идущего месяца. Это не требует остановки эксплуатации, но влияет на последующие расчетные периоды биллинга в соответствии с тарифом, который был актуален на начало конкретных суток.

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

Эксплуатационная практика#

Что контролировать#

В регулярной эксплуатации SmartCPD в первую очередь нужно контролировать не отдельные низкоуровневые метрики, а признаки того, что система работает в ожидаемом режиме и сохраняет качество обработки вызовов.

Минимальный обязательный набор контроля:

• Нагрузка и объем вызовов — чтобы понимать текущий объем трафика, пиковые значения и возможное приближение к инфраструктурным ограничениям.
• Дозваниваемость и контактность — чтобы отличать проблему дозвона от проблемы детекции или маршрутизации.
• Результаты детекции — чтобы видеть распределение вызовов между human, robot, ivr, silence, no_speech и замечать смещение структуры трафика.
• Ошибки и недоступность сервисов — чтобы вовремя обнаруживать техническую деградацию, сбои интеграции и ситуации, в которых SmartCPD перестает полноценно обрабатывать вызовы.
• Контрольные группы — чтобы отслеживать ошибки первого и второго типа и понимать, требуется ли корректировка профилей, реакций или моделей.
• Статистику отдельных вызовов — чтобы разбирать спорные кейсы и подтверждать, что агрегированные показатели соответствуют реальным вызовам.
• Биллинг и накопление потребления — чтобы контролировать суточные списания, накопление за месяц и корректность формирования отчетного периода.
• Актуальность моделей и срок действия лицензии — чтобы не допускать постепенной деградации качества детекции и остановки обработки вызовов по лицензионным причинам.

Отдельно рекомендуется контролировать обновление облачных моделей. Если автоматическое обновление не настроено или временно недоступно, модели необходимо обновлять вручную по мере выхода новых версий.

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

• заметное ухудшение дозваниваемости;
• рост доли роботов на операторе;
• рост доли ошибок, unavailable или других нештатных исходов;
• ухудшение показателей контрольной группы;
• расхождение между ожидаемым и фактическим поведением статистики, метрик или биллинга.

Пример типового сценария использования#

A/B-тестирование#

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

1. В рамках одной кампании разделить трафик на равные доли с использованием регулярных выражений (например, по последней цифре номера телефона).
2. Обеспечить накопление статистически значимого объёма данных.
3. По итогам анализа оставить активным профиль, который показывает лучшие целевые бизнес-показатели:
   • контактность;
   • долю выявленных роботов;
   • ключевую бизнес-метрику кампании.

Диагностика типовых инцидентов#

Резкое увеличение доли роботов на операторах#

Необходимо последовательно проверить:

1. Актуальность используемых моделей.
2. Доступность и корректную работу нод.
3. Срок действия лицензии.
4. Наличие изменений в фразах голосовых помощников операторов.

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

Подозрение на ошибочное сбрасывание живых абонентов#

Рекомендуется:

1. Настроить выделение контрольной группы.
2. Проанализировать показатель ошибок второго типа (false negative).
3. При необходимости скорректировать параметры классификации и повторно оценить метрики.

Приложения#

Приложение 1. Справочники#

Результат соединения (dialstatus)#

Результат соединения показывает итог дозвона до абонента на уровне телефонного вызова.

Действие (action)#

Действие показывает, какое решение было получено системой на соответствующем этапе обработки вызова.

Это не всегда означает, что данное действие успело быть фактически применено до завершения вызова. Например, вызов может быть прерван со стороны Дайлера раньше, чем система реализует полученное решение.

remote_release проставляется на уровне SIP-слоя, если удаленная сторона (абонент) завершила вызов во время обработки, то есть до того, как система завершила свой сценарий обслуживания.

Ошибки#

Ниже приведены типовые ошибки, которые могут возникать в процессе обработки вызова.

unavailable выделяется отдельно: это означает, что полноценная обработка вызова фактически не состоялась, потому что SIP-слой не смог достучаться до интеграционного уровня.

Остальные ошибки относятся к вызовам сервисов на отдельных этапах обработки.

Приложение 2. Структура статистики#

Статистика показывает конечное состояние вызова на момент последней зафиксированной обработки. Это не журнал всех промежуточных изменений, а итоговое представление вызова в прикладном виде.

Смысл этапов обработки вызова описан в разделе Этапы обработки вызова.

Текущий состав полей статистики:

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

Поле Действие показывает решение, полученное системой на этапе обработки, но не всегда означает, что это решение было фактически реализовано до завершения вызова.

Приложение 3. Структура CDR#

CDR показывает конечное состояние вызова в более техническом виде, чем пользовательская статистика. Это итоговая запись вызова, которая фиксирует последнее зафиксированное состояние обработки.

CDR является таблицей строгой отчетности и используется как источник данных для статистики, биллинга и последующего анализа.

Смысл этапов обработки вызова описан в разделе Этапы обработки вызова.

CDR не является журналом всех внутренних событий вызова. Это финальная техническая запись, в которой сохраняется результат последнего состояния обработки вызова на момент его завершения.

Основные группы полей CDR:

В отличие от статистики, CDR предназначен не для повседневного просмотра оператором или бизнес-пользователем, а для более детального технического анализа и использования системой как источника данных.

Служебные поля#

Данные вызова и телефонии#

Схема основных таймингов вызова в CDR.

Интеграционные поля#

Сервисные поля#

Технические поля#