Проигрывание сообщения при достижении 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 пробрасывает все входящие на вспомогательный АТС, он раздает их абонентам и организует очередь)?

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

[sunturner]

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

Обсудил сложившуюся ситуацию и возможности выхода с руководством.
Принято решение:

1. От очереди отказываемся
2. Выставляем Overflow в 1 минуту (в случае загрузки всех линий - уменьшаем до 30 секунд)

Спасибо всем принявшим участие в обсуждении!
Персональная благодарность пользователям Dron и Harris.

П.С. мне тему закрывать или оставить открытой?

[harris]

Обсудил сложившуюся ситуацию и возможности выхода с руководством.
Принято решение:

1. От очереди отказываемся
2. Выставляем Overflow в 1 минуту (в случае загрузки всех линий - уменьшаем до 30 секунд)

Спасибо всем принявшим участие в обсуждении!
Персональная благодарность пользователям Dron и Harris.

П.С. мне тему закрывать или оставить открытой?

А что подразумевается под закрытием темы??? Как Вы собираетесь ее "закрыть"??
Или Вы хотите подвезти ящик пива и тем самым закрыть вопрос??? (Шутка, и только шутка!!)

[sunturner]

Рано закрыл тему.
После недолгих раздумий все же сохранил очередь.
Окончательный результат выглядит так:

1. Фиксируем очередью максимальное число доступных для колл-центра линий (по формуле Max Queue Count = "Число линий для колл-центра" минус "число станций в группе").
2. Подбираем время ожидания (Overflow) таким образом, чтобы при пиковой нагрузке очередь не достигала максимального значения (в моем случае - 2 минуты).

В результате никого не выбрасывает по достижению предела очереди (все выбрасываются по истечении времени ожидания); междугородние клиенты не висят по 5-6 минут с последующим отлупом; у человека, перезвонившего после выброса по времени ожидания, больше шансов дозвониться (очередь двигается заметно быстрее).

[Dron]

Рано закрыл тему.
После недолгих раздумий все же сохранил очередь.
Окончательный результат выглядит так:

1. Фиксируем очередью максимальное число доступных для колл-центра линий (по формуле Maq Queue Count = "Число линий для колл-центра" минус "число станций в группе").
2. Подбираем время ожидания (Overflow) таким образом, чтобы при пиковой нагрузке очередь не достигала максимального значения (в моем случае - 2 минуты).

В результате никого не выбрасывает по достижению предела очереди (все выбрасываются по истечении времени ожидания); междугородние клиенты не висят по 5-6 минут с последующим отлупом; у человека, перезвонившего после выброса по времени ожидания, больше шансов дозвониться (очередь двигается заметно быстрее).

Так у вас работает Overflow! Количество вызовов в очереди не достигает просто значения Maq Queue Count, вот и все! А если превысит, то будет отлуп...
Работает все так, как оно работает.
Вывод один - если все это так при пиковой нагрузке, чего ж вы боялись, что не останется линий для исходящей связи?

[sunturner]

Так у вас работает Overflow! Количество вызовов в очереди не достигает просто значения Maq Queue Count, вот и все! А если превысит, то будет отлуп...
Работает все так, как оно работает.
Вывод один - если все это так при пиковой нагрузке, чего ж вы боялись, что не останется линий для исходящей связи?

Я описал то, как решил поставленную проблему (то, как все настроил 10 минут назад).
Раньше Overflow тоже был (5 или 6 минут), но за это время очередь увеличивалась до максимума и клиенты получали отлуп без голосового оповещения.
Делать Overflow без очереди я не рискнул, так как в этом случае не контролируется загруженность линий.
Собственно, мое решение - это "золотая середина": я сократил время ожидания, тем самым уменьшив вероятность заполнения очереди.

[Dron]

Я описал то, как решил поставленную проблему (то, как все настроил 10 минут назад).
Раньше Overflow тоже был (5 или 6 минут), но за это время очередь увеличивалась до максимума и клиенты получали отлуп без голосового оповещения.
Делать Overflow без очереди я не рискнул, так как в этом случае не контролируется загруженность линий.
Собственно, мое решение - это "золотая середина": я сократил время ожидания, тем самым уменьшив вероятность заполнения очереди.

А у вас клиенты сейчас через 2 минуты получают отлуп с голосовым оповещением?
Или их успевают обслужить?

[sunturner]

А у вас клиенты сейчас через 2 минуты получают отлуп с голосовым оповещением?
Или их успевают обслужить?

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

[Dron]

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

Т.е., так, или иначе клиенты могут получить отлуп. Позвонив по межгороду ответа так и не дожидаются...
Зато линии загружены не все...

[sunturner]

Т.е., так, или иначе клиенты могут получить отлуп. Позвонив по межгороду ответа так и не дожидаются...
Зато линии загружены не все...

Ну почему - по межгороду они попадают на приветствие (17 сек.), затем - в ожидание (97 сек.), в итоге перед ними извиняются (5 сек.) и отключают. Они попадают на 1 мин. 59 сек. (оплата межгорода за 2, а не за 3 минуты).
Раньше они ждали до победного (5-6 минут), или слышали приветствие (17 сек.) и получали отлуп без сообщения (очередь заполнена), оплачивая 1 мин. непонятно чего.

Зато плюсы очевидны: если отлупливают, то с извинением; очередь крутится гораздо быстрее: дозвониться больше шансов - раньше многие попавшие в очередь сбрасывали звонок через несколько минут ожидания, так и не дождавшись - "клиент упущен", а вместе с ним упущены те клиенты, которые не попадали в очередь (получали отлуп без сообщения) из-за ее заполненности). Линии не простаивают - интервал ожидания подбирается таким образом, чтобы при максимальной нагрузке длина очереди была максимально близка к заданному ограничению. Кроме этого, линии, не занятые колл-центром, обслуживают остальной офис (у нас цифровой канал).

[Dron]

Ну почему - по межгороду они попадают на приветствие (17 сек.), затем - в ожидание (97 сек.), в итоге перед ними извиняются (5 сек.) и отключают. Они попадают на 1 мин. 59 сек. (оплата межгорода за 2, а не за 3 минуты).
Раньше они ждали до победного (5-6 минут), или слышали приветствие (17 сек.) и получали отлуп без сообщения (очередь заполнена), оплачивая 1 мин. непонятно чего.

Зато плюсы очевидны: если отлупливают, то с извинением; очередь крутится гораздо быстрее: дозвониться больше шансов - раньше многие попавшие в очередь сбрасывали звонок через несколько минут ожидания, так и не дождавшись - "клиент упущен", а вместе с ним упущены те клиенты, которые не попадали в очередь (получали отлуп без сообщения) из-за ее заполненности). Линии не простаивают - интервал ожидания подбирается таким образом, чтобы при максимальной нагрузке длина очереди была максимально близка к заданному ограничению. Кроме этого, линии, не занятые колл-центром, обслуживают остальной офис (у нас цифровой канал).

Да все это понятно! Просто, по моему разумению, стремиться надо, чтобы очереди не было, чтобы человеку ответили.
А получил он отлуп с извинениями, или без...
Меня вот всегда добивает избитая фраза "ваш звонок очень важен для нас"..и ждешь, когда же на этот ВАЖНЫЙ звонок тебе ответят.

[sunturner]

Да все это понятно! Просто, по моему разумению, стремиться надо, чтобы очереди не было, чтобы человеку ответили.
А получил он отлуп с извинениями, или без...
Меня вот всегда добивает избитая фраза "ваш звонок очень важен для нас"..и ждешь, когда же на этот ВАЖНЫЙ звонок тебе ответят.

Очевидно, что узкое место проблемы - недостаточное количество операторов в колл-центре для обработки всех поступающих звонков. Но тут специфика бизнеса: я работаю в крупном туроператоре, а у нас нагрузка сезонная (ну и по рабочему дню распределение нагрузки не равномерное - большинство звонков поступает с 11:00 по 14:00).
Увеличивать штат операторов на 2 месяца сезона не выгодно: их нужно обучить, а в штате круглый год держать неоправданно.
В рамках моей зоны ответственности (в данном случае настройка АТС) мне мое решение кажется максимально адекватным.
Остальное - человеческий фактор - не в моей власти.

[harris]

Очевидно, что узкое место проблемы - недостаточное количество операторов в колл-центре для обработки всех поступающих звонков. Но тут специфика бизнеса: я работаю в крупном туроператоре, а у нас нагрузка сезонная (ну и по рабочему дню распределение нагрузки не равномерное - большинство звонков поступает с 11:00 по 14:00).
Увеличивать штат операторов на 2 месяца сезона не выгодно: их нужно обучить, а в штате круглый год держать неоправданно.
В рамках моей зоны ответственности (в данном случае настройка АТС) мне мое решение кажется максимально адекватным.
Остальное - человеческий фактор - не в моей власти.

А при входящих вызовах по потоку провайдер присылает вам номер (CLIP) вызывающего абонента или нет??
Если присылает, то в каком формате приходит местный (городской) номер, и в каком формате номер межгорода??

[sunturner]

А при входящих вызовах по потоку провайдер присылает вам номер (CLIP) вызывающего абонента или нет??
Если присылает, то в каком формате приходит местный (городской) номер, и в каком формате номер межгорода??

Не знаю, но думаю, что да (сейчас уточню).
Вы ведете к тому, чтобы межгород обслуживать отдельно?
Можно поподробнее?

[harris]

Не знаю, но думаю, что да (сейчас уточню).
Вы ведете к тому, чтобы межгород обслуживать отдельно?
Можно поподробнее?

Подробнее пока нечего сказать... Просто подумал о возможности использования ICLID (маршрутизация по АОНу).
Если была бы возможность отловить вызовы от МГ, то можно было направлять эти вызовы в отдельгую Hunt-группу.