Описание возможностей

1. Что такое SmartCPD#

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

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

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

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 поддерживает горизонтальное масштабирование рабочих компонентов без изменения общей модели использования продукта.
• Для продуктивной эксплуатации поддерживается отказоустойчивая схема развертывания, которая снижает риск остановки обработки новых вызовов при отказе одного или нескольких узлов.

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

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

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

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

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

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

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

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

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

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

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

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

4. Детекция#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разметка результатов вызовов#

Разметка — это полученный от оператора или внешней системы заказчика фактический результат вызова. Она позволяет сопоставить решение SmartCPD с тем, что в действительности находилось на линии, и используется для двух основных задач:

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

Наиболее важны результаты human и robot: они используются как для статистики, так и для дальнейшего обучения детекции. Остальные поддерживаемые результаты — ivr, silence, remote_release и mav — позволяют сохранить другие фактические исходы вызова и используются для статистического анализа.

Сопоставление разметки с вызовом#

Чтобы применить разметку, SmartCPD должен однозначно связать полученный результат с соответствующим вызовом. Поддерживаются следующие способы сопоставления:

• по SIP Call-ID вызова;
• по идентификатору вызова из системы заказчика, передаваемому в SmartCPD в отдельном SIP-заголовке;
• по сочетанию времени начала вызова и номера телефона.

Предпочтительно использовать SIP Call-ID или отдельный идентификатор системы заказчика. Они позволяют однозначно проследить вызов между контакт-центром и SmartCPD и обеспечивают наиболее надежное сопоставление.

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

Получение разметки#

Разметка может передаваться в SmartCPD через API или автоматически загружаться из представления либо таблицы в базе данных заказчика. Для загрузки из базы данных поддерживаются PostgreSQL и Oracle. Формат данных, установка и настройка uploader, а также обработка отклонённых записей описаны в техническом документе «Разметка».

Контрольные группы#

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

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

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

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

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

Существует два типа контрольных групп:

• Полная контрольная группа — вызов переводится на операторов КЦ, при этом сохраняются результаты всех проверок конвейера детекции. По разметке оператора фиксируются только ошибки второго типа: если оператор отметил вызов как human, а одна или несколько проверок вернули robot. Ошибки первого типа в этой группе не фиксируются.
• LSTM-контрольная группа — вызов переводится на операторов КЦ в момент передачи на анализ LSTM-моделью, при этом сохраняется результат только этой проверки. По разметке оператора фиксируются ошибки первого и второго типов.

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

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

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

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

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

На данный момент используются две облачные модели:

• Dejavu — сопоставление аудио с заранее известными эталонами по количеству совпавших хешей (как Shazam).
• LSTM — машинное обучение: распознавание аудио на основе закономерностей, выявленных при обучении на размеченных данных.

Также в системе присутствует локальная Dejavu модель, которая обучается через анализатор аудиослепков.

Анализатор аудиослепков#

Анализатор аудиослепков используется для того, чтобы автоматически пополнять локальную модель новыми примерами фраз голосовых помощников. Новые примеры появляются постоянно, так как операторы часто обновляют своих голосовых ассистентов/антиспам-защитников и прочие сущности, которые эмулируют ответ человека. Анализатор аудиослепков каждые 5 минут анализирует последние 2000 записей, которые система пропустила на операторов, и сравнивает каждый с каждым. При нахождении 3 и более одинаковых файлов они добавляются в локальную модель и помечаются как новый шаблон. 3 и более одинаковых файлов считаются достаточным признаком АО/голосового помощника, так как фразы живых людей не могут совпадать между собой полностью. Дополнительно каждый потенциальный шаблон проверяется на случайной выборке из 10000 записей с человеческими “алло”, чтобы исключить возможность попадания шаблона, который будет давать совпадения с “алло” от живых людей.

Также, чтобы не ждать, пока наберется 3 одинаковых примеров, анализатор аудиослепков может добавлять шаблоны по разметке от операторов КЦ:

1. На оператора КЦ попал вызов с голосовым помощником.
2. Оператор КЦ помечает этот вызов как «робот».
3. Анализатор находит аудиозапись и добавляет ее в модель.

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

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

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

Раз в сутки анализатор аудиослепков очищает локальную Dejavu модель от шаблонов старше 7 дней.

Раз в сутки анализатор аудиослепков выполняет ночной longtime-анализ, для сравнения всех записей, которые система пропустила на операторов за день.

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Сценарии использования#

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

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

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

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

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

Подробно всё описано в документе Метрики и статистика.

Статистика#

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

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

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

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

Метрики#

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

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

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

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

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

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

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

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

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

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

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

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

Что задаёт лицензия#

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

• срок действия — даты начала и окончания права на использование;
• льготный период (grace) — опциональный запас после окончания основного срока, чтобы продлить лицензию без немедленной остановки работы;
• функциональные возможности (features) — какие части продукта разрешены;
• лимиты — операционные ограничения на объём использования;
• лицензионные тарифы — условия расчёта потребления услуги для биллинга;
• привязку к инсталляции (fingerprint) — опционально, чтобы лицензию нельзя было свободно перенести на другой контур.

Лицензия всегда содержит хотя бы один тариф; тарифы покрывают весь основной срок действия лицензии. Подробнее про тарифы и расчёт — в разделе Биллинг.

Функциональные возможности#

Лицензия включает только те возможности, которые явно разрешены. Типовой набор:

Отсутствие возможности в лицензии означает, что соответствующая функция недоступна.

Лимиты#

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

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

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

Значение «без ограничения» означает, что соответствующий лимит не применяется. Дневные и месячные счётчики ведутся в разрезе тенанта.

Привязка к инсталляции#

Продуктивная лицензия обычно привязывается к конкретной инсталляции SmartCPD (fingerprint кластера). Одна лицензия рассчитана на одну инсталляцию и не должна использоваться на нескольких независимых контурах.

Для первичной установки или теста допускается временная лицензия без привязки: она упрощает развёртывание, пока состав инфраструктуры ещё меняется. После стабилизации контура выпускается продуктивная лицензия с fingerprint.

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

Срок действия и обновление#

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

Лицензию можно заменить в любой момент, в том числе в течение месяца. Уже начавшийся расчётный день биллинга задним числом не пересчитывается: новый лицензионный тариф начинает влиять на биллинг со следующих расчётных суток (см. Биллинг).

Облачная модель#

В облачной (multi-tenant) схеме у тенанта могут сочетаться:

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

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

Загрузка лицензии в портале описана в руководстве пользователя.

9. Биллинг#

Биллинг SmartCPD учитывает потребление услуги по тарифам, накапливает объем за отчетный период и формирует отчеты для сверки и выставления счета. Исходными данными служат записи о вызовах (CDR); на их основе система определяет тарифицируемые единицы, применяет тариф и рассчитывает стоимость.

Что умеет биллинг#

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

Тарифы#

Тариф — набор условий, по которым определяется объем и стоимость оказанных услуг.

По источнику тарифы бывают двух видов:

• лицензионный — поставляется в составе файла лицензии;
• облачный — создается в веб-интерфейсе и используется в инсталляциях с облачной (multi-tenant) функциональностью.

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

В тарифе задаются, в частности:

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

Единицы тарификации#

Тариф считает потребление по одной из единиц:

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

Назначение тарифов#

Чтобы система знала, по какому тарифу считать вызов, используются назначения тарифов — именованные привязки тарифа к вызовам тенанта.

• У каждого тенанта есть назначение default: оно применяется ко всем вызовам, для которых не указано иное назначение. Его нельзя удалить.
• Дополнительные назначения позволяют считать отдельные направления или сегменты SIP-маршрута по другому тарифу. Имя назначения указывается в сегменте маршрута; если имя неизвестно или назначение удалено, вызов считается по default.

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

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

Как считается потребление#

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

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

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

Расчетные границы дней и периодов определяются в часовом поясе биллинга инсталляции. Биллинг — не онлайн-счетчик «здесь и сейчас»: вызовы обрабатываются по мере поступления из CDR, а состояние назначений и окон на границе суток актуализируется отдельно.

Отчеты по биллингу#

В веб-интерфейсе доступен отчет по потреблению за выбранный месяц: объем единиц, стоимость вызовов, абонентская плата, скидки по объему (если заданы) и итог с учетом НДС при наличии ставки в тарифе.

• Отчет за текущий месяц — предварительный: он отражает уже обработанные данные и не является финальной суммой к оплате.
• Итоговый подписанный отчет (PDF) формируется за завершенный календарный месяц и используется как основание для выставления счета.

Настройка тарифов и просмотр отчетов в портале описаны в руководстве пользователя.

10. Multi-Tenancy#

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

• Single-Tenant — выделенная инсталляция для одного заказчика;
• Multi-Tenant (Cloud) — одна инсталляция с несколькими изолированными тенантами.

Multi-Tenant (Cloud)#

При наличии в лицензии платформы возможности Cloud SmartCPD работает как multi-tenant: на одной инсталляции обслуживается несколько клиентов (тенантов) с изоляцией данных и настроек.

Тенант — отдельный клиентский контур (идентификатор — ИНН организации). У каждого тенанта свой набор операционных настроек и учёта.

Что даёт multi-tenant#

• несколько тенантов на одной платформе — создание, ведение карточки организации, статус (в том числе отключение тенанта);
• изоляция контуров — настройки и данные тенантов не смешиваются; в портале разделены область платформы (общие объекты инсталляции) и область тенанта;
• свои пользователи и API-ключи у каждого тенанта, с разграничением доступа ролями и областью тенантов (Роли, пользователи и привилегии);
• свои SIP-настройки, профили детекции, статистика и отчёты в пределах тенанта;
• индивидуальные лимиты и features на тенанта — через файловую лицензию тенанта и/или облачную policy (лимиты попыток и детекций, одновременные линии, включение SmartCPD / SmartContact и т.п.);
• разные тарифы — облачные тарифы задаются на уровне платформы и могут быть доступны всем тенантам, выбранным или всем кроме указанных; у каждого тенанта свои назначения тарифов (в том числе default и назначения на сегменты маршрута). Подробнее — Биллинг и Лицензирование.

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

Отключение тенанта приостанавливает его облачную policy (лимиты/features с платформы); при наличии у тенанта собственной действующей файловой лицензии она продолжает определять права этого контура. Без применимых лимитов тенант не обрабатывает новые вызовы.

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

11. Роли, пользователи и привилегии#

SmartCPD разграничивает доступ к порталу и API через пользователей, роли и привилегии.

• Пользователь — учётная запись для входа в веб-интерфейс. Логином служит e-mail; пользователю назначаются одна или несколько ролей и (в multi-tenant) область доступных тенантов.
• Роль — набор привилегий, который назначается пользователю или API-ключу.
• Привилегия — минимальное разрешение на просмотр или изменение раздела, действия или API-метода (например, просмотр статистики, изменение SIP-настроек, управление пользователями).
• Привилегии выдаются только через роли. У субъекта с несколькими ролями привилегии объединяются.

Пользователи#

Продукт позволяет:

• создавать и вести учётные записи сотрудников для работы в портале;
• назначать пользователю роли и тем самым определять доступный набор действий;
• включать и отключать учётную запись (активный / неактивный статус);
• сбрасывать пароль; при первом входе система запрашивает смену пароля;
• в multi-tenant задавать, в каких тенантах пользователь может работать:
  • только свой (основной) тенант;
  • явно выбранный список тенантов;
  • все тенанты, включая создаваемые позже.

Пользователь не может выдать другому доступ к тенанту вне собственной области. Для программного доступа к API используются отдельные API-ключи с собственными ролями и сроком действия — не путать с учётными записями портала.

Привилегии и уровни доступа#

Привилегии делятся на два уровня:

• платформа — общие объекты инсталляции: роли, тенанты, настройки ИБ, аудит, ML-модели, метрики;
• тенант — объекты конкретного клиента: пользователи, API-ключи, SIP, профили детекции, лицензия, биллинг, статистика.

Доступ дополнительно ограничен областью тенантов (tenant scope): в каких клиентских контурах разрешённые роли действуют. Набор привилегий один и тот же во всех тенантах из этой области; сама область не расширяется наличием привилегии.

Типовые стартовые роли при первичной установке — администратор тенанта с полным доступом к объектам тенанта и пользователь тенанта с доступом на просмотр (включая прослушивание записей). Состав ролей можно адаптировать под модель доступа организации.

Настройка ролей и пользователей в интерфейсе — в руководстве пользователя и разделе «Пользователи». Полный справочник понятий, правил UI/API и матрица привилегий — в ролевой модели.

12. Политика ИБ и аудит#

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

Политика ИБ#

Администратор может задать:

• политику паролей для обычных пользователей (требования к сложности и сроку — без применения к административным учётным записям в том же режиме);
• параметры сессии — время бездействия и максимальное время жизни сессии;
• защиту от перебора паролей — число неудачных попыток входа до временной блокировки и длительность блокировки (снимается после успешного входа по истечении тайм-аута или администратором).

Аудит#

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

Настройка в интерфейсе — в разделах «Настройки ИБ» и «Аудит».

13. Интеграция со SmartContact#

SmartContact — отдельный сторонний продукт (не входит в поставку SmartCPD). Он оценивает вероятность успешного контакта с человеком по данным клиента и позволяет до начала телефонного звонка отсекать малоперспективные попытки дозвона.

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

Установка, настройка, администрирование и внутреннее устройство самого SmartContact в этой документации не описываются (out of scope). Здесь только смысл интеграции со стороны SmartCPD. Параметры подключения (URL и др.) задаются при внедрении/setup; реакция на рекомендации — в профиле детекции портала.

Что даёт интеграция (со стороны SmartCPD)#

При работающей интеграции SmartContact:

• блокирует порядка 20% и более попыток звонков на тестовой группе; дальнейшее повышение доли блокировок может увеличить число ложных срабатываний;
• блокирует порядка 2% и менее случаев, которые иначе были бы детекцией человека: например, при 1000 детекций человека на контрольной группе SmartContact пометит как заблокированные около 20 (±10); на контрольной группе попытки не блокируются, а только помечаются;
• позволяет динамически определять контрольную группу звонков;
• не требует от заказчика дополнительных данных сверх контура с облачным SmartCPD; персональные данные, кроме номера телефона, не используются.

Попытки, заблокированные SmartContact, в учёт «попыток вызова» SmartCPD не входят — см. Метрики и статистика.