Проигрывание сообщения при достижении Max Queued Call Count Опции

[sunturner]

Добрый день!
LDK-300, прошивка 3.8Ah.

Пытаюсь добиться проигрывания сообщения "Все линии заняты" в случае, когда очередь Max Queued Call Count в UCD-группе полна.
При попытке реализовать это через Alternate destination (hunt на специальную группу) переход осуществляется ДО проверки очереди (то есть очередь пуста, и вместо очереди звонящий перекидывается на Alternate Destination).
Собственно, вопрос - можно ли как-то реализовать задуманное (проиграть сообщение перед сигналом "занято" по достижении Max Queued Call Count)?

[Dron]

Добрый день!
LDK-300, прошивка 3.8Ah.

Пытаюсь добиться проигрывания сообщения "Все линии заняты" в случае, когда очередь Max Queued Call Count в UCD-группе полна.
При попытке реализовать это через Alternate destination (hunt на специальную группу) переход осуществляется ДО проверки очереди (то есть очередь пуста, и вместо очереди звонящий перекидывается на Alternate Destination).
Собственно, вопрос - можно ли как-то реализовать задуманное (проиграть сообщение перед сигналом "занято" по достижении Max Queued Call Count)?

А Alt if No Member? Вам же написали в другой ветке...

[sunturner]

А Alt if No Member? Вам же написали в другой ветке...

Такое решение ("все операторы заняты" - отбой) фирму не устраивает.
Нужно именно "все операторы заняты, ждите" - [в очередь] - "все линии заняты, перезвоните позже" (если очередь полна)

поиск на форуме показал, что в одной из версий прошивок можно было завязать alternate destination на Max Queued Call Count:

http://www.artcom.ru/forum/index.php?showt...ost&p=20142

Но в моей версии alternate destination срабатывает ДО постановки вызова в очередь.

[harris]

Такое решение ("все операторы заняты" - отбой) фирму не устраивает.
Нужно именно "все операторы заняты, ждите" - [в очередь] - "все линии заняты, перезвоните позже" (если очередь полна)

поиск на форуме показал, что в одной из версий прошивок можно было завязать alternate destination на Max Queued Call Count:

http://www.artcom.ru/forum/index.php?showt...ost&p=20142

Но в моей версии alternate destination срабатывает ДО постановки вызова в очередь.

Вы неправильно поняли тему, на которую ссылаетесь.
- Alt Dest. всегда проверяется на входе в группе, на 1-ом этапе!! Если Alt.Destю назначено и все агенты заняты, то всё - вызов не попадая в группу уходит на альтернативное назначение.
- А вот дальше, "на 2 -ом этапе"... :
до версиии 3.8Ct: если было назначено гарантированное приветствие (Timer1 =0), то оно и выдавалось, и только потом проверялось превышение длины очереди... Если Альтенатива не назначена, но агенты заняты, то получалось так: позвонил клиент, прослуслушал Приветствие ("Здравствуйте, вы позвонили в контору Пупкин и Ко "), и только после станция проверяет длину очереди, и по ее превышению отбивает вызов.... Клиент "оплеван"..

начиная с версии 3.8Сt, на" 2-ом этапе": проверка длины очереди выполняется до выдачи гарантированного приветствия, как мы и запрашивали у корейцев... Т.е. если длина очереди превышена, то вызов просто отбивается (клиент получает банальный сигнал "занято") без какого-либо приветствия... И все.
См. схему ниже (из нашего запроса в Корею).

Странно, что разработчик не предусмотрел нашей ситуации.

Все ситуации невозможно предусмотреть и реализовать... Одним пользователям нужно одна фича, другим - прямо противоложная...

Прикрепленные файлы

 Hunt_Queue.doc ( 25 килобайт ) Кол-во скачиваний: 11

 

[harris]

Такое решение ("все операторы заняты" - отбой) фирму не устраивает.
Нужно именно "все операторы заняты, ждите" - [в очередь] - "все линии заняты, перезвоните позже" (если очередь полна)

Первая часть вашей задачи решается очень просто, т.к. каждый абонент может быть одновременно агентом нескольких Hunt-групп (но группы - одного и того же типа, например, UCD).
Тогда:
- Создаете 2 Hunt-группы одинакового типа и с одним и тем списком агентов. Например, это группы H620 и Н621. В обеих группах прописаны одни и те же абоненты (например, 100, 101, ..., 111)
- Вызовы направляете в первую Hunt-группу, например, Н620. В атрибутах H620 в поле ALT DEST указываете группу H621.
- В атрибутах H621 указываете гарантированное приветствие ("Все операторы заняты, пожалуйста, ожидайте...")
- Если есть свободный оператор, то вызов остается в группе Н620.
- Если все операторы заняты, то вызов перебрасывается в группу Н621 (состоящую из тех же самых операторов), и клиенту гарантированно выдается речевое сообщение (заняты... ожидайте). Вызов будет в очереди пока не осводится агент или не истечет таймер Overflow. Потом можно дать другое сообщение (Извиняйте, перезвоните...).
Но вот связать выдачу второго приветствия с превышением кол-ва вызовов в очереди - не получится.

Длину очереди можно понимать по-разному:
- кол-во вызовов, ожидающих обслуживания (Max Queue Count)
- время, в течении которого данный вызов находится в очереди (Overflow). В вашем случае можно реализовать Overflow.

[sunturner]

Первая часть вашей задачи решается очень просто, т.к. каждый абонент может быть одновременно агентом нескольких Hunt-групп (но группы - одного и того же типа, например, UCD).
Тогда:
- Создаете 2 Hunt-группы одинакового типа и с одним и тем списком агентов. Например, это группы H620 и Н621. В обеих группах прописаны одни и те же абоненты (например, 100, 101, ..., 111)
- Вызовы направляете в первую Hunt-группу, например, Н620. В атрибутах H620 в поле ALT DEST указываете группу H621.
- В атрибутах H621 указываете гарантированное приветствие ("Все операторы заняты, пожалуйста, ожидайте...")
- Если есть свободный оператор, то вызов остается в группе Н620.
- Если все операторы заняты, то вызов перебрасывается в группу Н621 (состоящую из тех же самых операторов), и клиенту гарантированно выдается речевое сообщение (заняты... ожидайте). Вызов будет в очереди пока не осводится агент или не истечет таймер Overflow. Потом можно дать другое сообщение (Извиняйте, перезвоните...).
Но вот связать выдачу второго приветствия с превышением кол-ва вызовов в очереди - не получится.

Длину очереди можно понимать по-разному:
- кол-во вызовов, ожидающих обслуживания (Max Queue Count)
- время, в течении которого данный вызов находится в очереди (Overflow). В вашем случае можно реализовать Overflow.

- Overflow всем хорош, но как контролировать нагрузку на линии без Max Queue Count?
У нас есть пул цифровых линий на четыре номера. Один из номеров - Call-center. Если я буду использовать только Overflow, в пиковую нагрузку возможна ситуация, когда весь пул займут ожидающие звонящие в Call-center (все линии "лягут" на телефонный номер call-center). В этом случае остальные три номера не будут доступны, не говоря уже об исходящих из офиса звонках.

Вопросы:

1. Существует ли альтернативный Max Queue Count вариант контроля линий (ограничения количества линий на один номер), который позволит держать свободные линии для других телефонных номеров?

2. При использовании Max Queue Count возможно переопределить сигнал "занято" на голосовое сообщение "все линии заняты, перезвоните позже"? Отличаются ли с точки зрения АТС сигналы "занято" и "отбой" (в первом случае - нет свободного абонента, во втором - абонент положил трубку), можно ли сделать эти сигналы разными?

[Dron]

- Overflow всем хорош, но как контролировать нагрузку на линии без Max Queue Count?
У нас есть пул цифровых линий на четыре номера. Один из номеров - Call-center. Если я буду использовать только Overflow, в пиковую нагрузку возможна ситуация, когда весь пул займут ожидающие звонящие в Call-center (все линии "лягут" на телефонный номер call-center). В этом случае остальные три номера не будут доступны, не говоря уже об исходящих из офиса звонках.

Вопросы:

1. Существует ли альтернативный Max Queue Count вариант контроля линий (ограничения количества линий на один номер), который позволит держать свободные линии для других телефонных номеров?

2. При использовании Max Queue Count возможно переопределить сигнал "занято" на голосовое сообщение "все линии заняты, перезвоните позже"? Отличаются ли с точки зрения АТС сигналы "занято" и "отбой" (в первом случае - нет свободного абонента, во втором - абонент положил трубку), можно ли сделать эти сигналы разными?

У вас в группе 12 абонентов. Включаете Alt if No Member на другую группу(к примеру, терминальную), в которой прописан абонет из плана нумерации даже и не существующий физически. В этой группе выставляете Overflow Timer 1 сек., Overflow Destination на VMIB c #(сообщение "все линии заняты, перезвоните позже").
При отсутствии свободных абонентов в первой группе вызов уйдет во вторую, где будет произнесена фраза "все линии заняты, перезвоните позже", после чего соединение будет разорвано. Такой вариант вам не подойдет?
Max Queue Count для первой группы, естественно, больше, чем абонентов в этой группе.

[sunturner]

У вас в группе 12 абонентов. Включаете Alt if No Member на другую группу(к примеру, терминальную), в которой прописан абонет из плана нумерации даже и не существующий физически. В этой группе выставляете Overflow Timer 1 сек., Overflow Destination на VMIB c #(сообщение "все линии заняты, перезвоните позже").
При отсутствии свободных абонентов в первой группе вызов уйдет во вторую, где будет произнесена фраза "все линии заняты, перезвоните позже", после чего соединение будет разорвано. Такой вариант вам не подойдет?
Max Queue Count для первой группы, естественно, больше, чем абонентов в этой группе.

Но ведь при включенном Alt if No Member никто не будет попадать в очередь!
Реализовать выдачу сообщения "перезвоните позже" при отсутствии свободных операторов задача очевидная и легкая. Но нужно другое - в пиковую нагрузку держать пул ожидающих звонящих (иначе мы, выдавая им "занято", их теряем - не факт, что они перезвонят еще раз).
В моем последнем сообщении я изложил еще один вариант реализации очереди - можете посмотреть и сказать, будет ли работать?

[Dron]

Но ведь при включенном Alt if No Member никто не будет попадать в очередь!
Реализовать выдачу сообщения "перезвоните позже" при отсутствии свободных операторов задача очевидная и легкая. Но нужно другое - в пиковую нагрузку держать пул ожидающих звонящих (иначе мы, выдавая им "занято", их теряем - не факт, что они перезвонят еще раз).
В моем последнем сообщении я изложил еще один вариант реализации очереди - можете посмотреть и сказать, будет ли работать?

Да, все так, никто и не спорит!
А вы смотрели вариант, который вчера предложил ув. harris?

[sunturner]

Да, все так, никто и не спорит!
А вы смотрели вариант, который вчера предложил ув. harris?

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

[Dron]

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

А "мертвые" номера вы какие хотите прописывать, те, которые физически имеются, но не используются?

[sunturner]

А "мертвые" номера вы какие хотите прописывать, те, которые физически имеются, но не используются?

И в том, и в другом случае ничего не получается - звонящий либо попадает в вечное ожидание, либо получает отлуп "все линии заняты".
Остается один вариант - использовать Overflow, а линии ограничивать физически (просить телефонного оператора зафиксировать пул линий за номером колл-центра). Это тоже не очень хорошо, так как большую часть времени (кроме пиковой нагрузки) линии не будут использоваться.
Интересно, может ли оператор связи не фиксировать пул, а установить максимум линий на номер (чтобы при низкой нагрузке линии распределялись по номерам, а при пике на номер колл-центра не выделялось линий больше установленного максимума)?

[Dron]

И в том, и в другом случае ничего не получается - звонящий либо попадает в вечное ожидание, либо получает отлуп "все линии заняты".
Остается один вариант - использовать Overflow, а линии ограничивать физически (просить телефонного оператора зафиксировать пул линий за номером колл-центра). Это тоже не очень хорошо, так как большую часть времени (кроме пиковой нагрузки) линии не будут использоваться.
Интересно, может ли оператор связи не фиксировать пул, а установить максимум линий на номер (чтобы при низкой нагрузке линии распределялись по номерам, а при пике на номер колл-центра не выделялось линий больше установленного максимума)?

Ну, ежели это все так критично, берите отдельный поток для номера колл-центра, все свои проблемы решите!

[sunturner]

Ну, ежели это все так критично, берите отдельный поток для номера колл-центра, все свои проблемы решите!

Ну да, и АТС-ку поменять )))
Кстати, интересно - есть какие-нибудь вспомогательные "девайсы", которые помогли бы в этой ситуации (LDK пробрасывает все входящие на вспомогательный АТС, он раздает их абонентам и организует очередь)?

[Dron]

Ну да, и АТС-ку поменять )))
Кстати, интересно - есть какие-нибудь вспомогательные "девайсы", которые помогли бы в этой ситуации (LDK пробрасывает все входящие на вспомогательный АТС, он раздает их абонентам и организует очередь)?

За удобства, знаете ли, приходится платить...