По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Друг, сегодня покажем простой способ интеграции Е1 – шлюза производства российской компании Eltex модели SMG-1016M и IP – АТС Asterisk. От слов к делу. /p> Настройка со стороны Eltex Начнем с настройки шлюза. Мы настроим SIP – транк в сторону IP – АТС Asterisk, а так же маршрутизацию: при наборе номера 4951234567 (вызовы, которые приходят к нам из PRI, потока) мы будем отправлять вызов в сторону Asterisk. Заходим в интерфейс администратора: Идем в раздел Маршрутизация → Интерфейсы SIP: Для добавления нового транка нажмите на соответствующий значок: Делаем настройки во вкладке Настройка интерфейса SIP: Название - дайте имя для транка; Имя хоста / IP-адрес - укажите IP – адрес Asterisk; Порт назначения SIP сигнализации - укажите порт, на котором слушает chan_sip модуль Asterisk; Переходим в секцию Настройка кодеков/RTP и отметим два кодека – G.711A и G.711U: Сохраняем настройки и переходим к маршрутизации. Для этого, переходим в раздел План нумерации → План #0: Нажимаем на уже знакомый значок «+», который создаст новую сущность: Название - дайте имя для сущности; Транковая группа - выбираем созданные транк; Сохраняем сущность. Далее, находим ее в списке плана нумерации и переходим в ее параметры. В самом низу нажимаем привычный значок «+» и добавляя маску для звонков: Готово. На данном этапе все звонки из E1 потока (DID 4951234567) будут отправляться по SIP в сторону Asterisk. Переходим к настройке Asterisk. Настройка со стороны Asterisk Все настройки выполним через графический интерфейс FreePBX. Итак, первое, что необходимо сделать – создать SIP – транк в сторону Eltex. Переходим в раздел Connectivity → Trunks. Нажимаем Add Trunk. Даем имя транку в поле Trunk Name. Во вкладке sip Settings в секции Outgoing добавляем следующие данные: host=ip_адрес_Eltex type=friend qualify=yes disallow=all allow=ulaw,alaw nat=no Готово. Теперь вы можете настроить входящую и исходящую маршрутизацию согласно требований вашей задачи. Если вы хотите сделать исходящие звонки в город через Eltex шлюз (с уходом через E1 (PRI) линию), то сделайте на транке (от Asterisk) опцию Outbound CallerID, на базе которой создавайте диалплан на шлюзе Eltex (в примере, когда мы создавали сущность с номером 4951234567, мы указали типа Called. В указанном случае тип нужно сделать Calling). В качестве назначения используйте Е1 транковую группу.
img
Порой, в процессе настройки IP-АТС Asterisk возникают ситуации, когда по каким-либо причинам маршруты, транки или же линии становятся недоступными. От этого не застрахован никто. В таких случаях, при проверке доступности линии, позвонив на выданный провайдером номер – мы можем услышать малоинформативное “All circuits are busy now, please try your call later”, а затем последует сброс. В свою очередь, рядовые пользователи услышав в трубке «страшные» звуки или незнакомую речь начнут обращаться к системному администратору и формулировать проблему каждый по - своему. Получается сломанный телефон. Для исключения подобных проблем существует модуль Route Congestion Messages, который позволяет изменить стандартные звуковые сообщения и тональные сигналы, сигнализирующие о недоступности. Аудио - файлы загружаются на сервер через модуль System Recordings. Например, вы можете озвучивать понятное для пользователей сообщение: «В настоящее время невозможно совершить исходящий звонок. Обратитесь к системному администратору с кодом А7 для эскалации проблемы». Для системного администратора этот код будет означать конкретную проблему. Все примеры в статье приведены на FreePBX 13. Настройка Итак, для того, чтобы попасть в модуль Route Congestion Messages, с главной страницы FreePBX, проходим следующий путь: Settings → Route Congestion Messages, открывается вот такое окно: Как видно, функционал данного модуля делится на две части - No Route Available и Trunk Failures. No Route Available В данном разделе можно настроить сообщения, которые будут проигрываться в случае если Вы набираете номер, но этот номер не совпадает ни с одним из исходящих маршрутов. Рассмотрим каждую опцию, доступную в данном разделе. Сразу заметим, что стандартным сообщением – Default, которое по умолчанию стоит в данном разделе, является та самая фраза “All circuits are busy now, please try your call later” Standart Routes - Звуковое сообщение или тональный сигнал, который звучит, когда исходящие маршруты недоступны. Intra-Company Routes - Звуковое сообщение или тональный сигнал, который звучит, когда нет ни одного доступного внутрикорпоративного транка. Применимо только на маршрутах, которые помечены как intra-company Emergency Routes - Звуковое сообщение или тональный сигнал, который звучит, когда недоступными оказываются маршруты экстренных служб. Важно! Если Вы решили изменить данную запись, то убедитесь, что в ней прозвучит предложение звонящему воспользоваться другими средствами связи с экстренными службами. Например, мобильным телефоном или панелью вызова экстренных служб. Trunk Failures Данный раздел позволяет настроить звуковые сообщения, которые проигрываются, когда происходит отказ транка. No Answer - Звуковое сообщение или тональный сигнал, который звучит, когда набранный номер не отвечает. По умолчанию это фраза – “The number is not answering”. Hangupcause 18 или 19. Number or Address Incomplete - Звуковое сообщение или тональный сигнал, который звучит, когда номер, который был набран не закончен. Обычно, это происходит, когда набранный номер слишком короткий. Стандартная фраза - “The number you have dialed is not in service. Please check the number and try again”. Hangupcause 28. Ну, а дальше всё просто. Загружаем звуковой файл с голосовым сообщением или тональным сигналом через модуль System Recordings и он автоматически появляется в Route Congestion Messages . Например, мы решили поменять стандартный сигнал, который звучит, когда исходящие маршруты недоступны - Standart Routes. Congestion Tones - это, собственно, тональный сигнал.
img
Система автоматического исходящего обзвона – это программное обеспечение, с помощью которого любой Call-центр может в разы сократить время и затраты на исходящий обзвон. Существует 4 основных способа организовать обзвон списка номеров: ручной набор - оператор делает набор вручную. Это неэффективное расходование времени оператора (набор номер, писк контакта в базе и так далее); preview – диалер загружает списки контактов, в которых оператор заранее видит информацию по каждому клиенту и принимает решение о звонке самостоятельно. При этом, он не набирает номер телефона и не снимает трубку до того момента, как абонент ответит на звонок; progressive – так же, как и в preview загружаются списки контактов, но в этом варианте у оператора нет возможности отказаться от внешнего звонка. Диалер стремится занять звонками максимальное количество доступных каналов. Это подходит для автоматических извещений, IVR (когда вызываемого абонента нужно подключить на интерактивное меню) и прозвона номеров; predictive dialer – самое интересное. При предиктивном дозвоне используются сложные сценарии и реальный математический расчет. Dialer предназначен для максимального сокращения времени ожидания оператором звонка при минимальных потерях успешных звонков. Для этого используются алгоритмы, «просчитывающие» необходимое количество звонков в следующий момент на основании данных о количестве операторов, которые будут доступны на момент соединения, о средней длительности разговора (ACD), о проценте успешных соединений (ASR) и прочих. У каждого продукта данные секретны и не публичны :). Хочу презентацию продукта! Программный продукт IqDialer В качестве основной телекоммуникационной платформы для IqDialer был выбран Asterisk. Дайлер кроссфункционален и стабилен – он справляется с разными задачами, а его надежность протестирована в десятках инсталляций. Все функциональные возможности диалера (интеграция с внешними компонентами, CRM, например) управляются посредством RESTful API. Работает это примерно так: устанавливается и настраивается оборудование, необходимое для начала работы Call-центра, затем загружается база контактов для обзвона, и операторы входят в систему, занимая свои виртуальные рабочие места и вставая в очередь на телефонии. IqDialer определяет доступные ресурсы для работы, и в этот момент программа начинает расчеты, запрашивает статистику звонков, рассчитывает, сколько нужно взять лидов (контактов для обзвона), занимает расчетное количество операторов, трансформирует лиды в звонки и отправляет все на телефонию. Первый этап закончен :) В следующем этапе звонки, попавшие в телефонию, при дозвоне до клиента попадают в очередь и диалер собирает всю доступную ему информацию о звонке. На основании собранной информации программа отправляет карточки лидов операторам, и те видят на своих экранах всю информацию по контакту и обрабатывают звонок в соответствии с поставленной задачей. На последнем этапе по завершению звонка, оператор дополнительно обрабатывает карточку лида, сохраняя ее (срабатывает интеграция CRM и диалера) дает понять системе сколько длилась дообработка и что оператор готов принять новые вызовы (освобождается в очереди). Система обрабатывает завершенный звонок, производя манипуляции с лидом, меняет его статус и создает задачи для пропущенного звонка. «Под капотом» это выглядит примерно так: Время статистики. Для сравнения эффективности различных режимов набора, мы возьмем 3 (три) самых распространенных варианта обзвона (Preview, Progressive и Predictive), которые практикуют Call - центры, и для примера возьмем Call – центр, где один оператор работает 5 дней в неделю, по 8 часов в день: Действие Preview Progressive Predictive Поиск карточки клиента (сек) 0 0 0 Ознакомление с карточкой клиента (сек) 10 0 0 Набор номера (сек) 0 0 0 Дозвон (сек) 20 20 0 Занятость оператора в разговоре (сек) 90 90 90 Всего времени на звонок (сек) 120 110 90 Звонков в день 240 262 320 Формула получения звонков в день и месяц 8*60*60/120240*22 8*60*60/110262*22 8*60*60/90320*22 Звонков в месяц 5280 5764 7040 Если привести здесь в качестве примера статистику, учитывающую еще и ручной набор, то результатом сравнения будет превосходство предиктивного набора над ручным почти в 2 раза. Даже при таком простом анализе, который не учитывает множество дополнительных факторов и полностью исключает сравнение с ручным набором оператором телефонных номеров, очевидна выгода :) Таким образом, основываясь на вышесказанном, любой Call - центр просто обязан использовать только Predictive (предиктивный) Dialer. Однако не все так просто. Этот режим эффективен в том случае, если число работающих операторов не опускается ниже 20–30. В противном случае predictive dialing вместо пользы будет приносить только вред. Смешанный режим работы оператора В работе каждого Call - центра случаются временное затишье или резкий всплеск количества обращений, которые тяжело прогнозировать. В такой ситуации действенным инструментом поддержания необходимого и достаточного уровня сервиса могут стать работа в смешанном режиме – blended Agent. Смешанный режим позволяет оператору обрабатывать входящие и исходящие обращения по различным каналам коммуникаций в рамках единой очереди. Чтобы проиллюстрировать выгоду, полученную при добавлении исходящих звонков в кейс (рабочие задачи) оператора, можно привести такой пример: допустим, операторы принимают только входящие звонки и при этом в течение одного рабочего дня простаивают 20% своего времени. Тогда в течение дня оператор не работает (8*60*0.2) = 96 минут. Пусть в Call - центре работает 10 операторов, тогда легко вычислить, что колл-центр уже простаивает (96*10/60) = 16 часов в день , а в месяц уже (16*22) = 352 человеко-часа. При этом, у колл-центра могут быть заказы на проведение опросов (исходящая кампания на обзвон), и во время простоя оператору будут подмешиваться звонки с опросами. Производительность и качество обслуживание входящих звонков останутся на должном уровне, а Call - центр получит дополнительную прибыль. Есть определенные тонкости, которые необходимо учитывать при планировании кампаний исходящего обзвона и входящих звонков, дело в том, что смешанный колл-центр будет эффективно работать только в режимах preview и progressive. Поскольку режим predictive подразумевает 100% занятость и любые отвлечения оператора приведут к потерям клиентов. IqDialer: интерфейс и как он выглядит Посмотрите, как выглядит дашборд супервизора, который следит за компаниями исходящего обзвона: Двигаемся к отчетности – ниже отчет агентов по статусам (включает круговую диаграмму): Заказать продукт Отчеты реального времени – кто говорит, сколько времени: Можно посмотреть самую важную информацию по каждой очереди: Тайм – лайны! Смотрим, что делал наш агент на протяжении отрезка времени – звони, говорил, делал пост – ворк (работа после звонка) и так далее: Интересен продукт? Напишите нам на dialer@merionet.ru
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59