Проигрывание сообщения при достижении 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? Вам же написали в другой ветке...

[harris]

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

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

Нет.
- Alternate destination выполняется сразу же при поступлении вызова в группу при условии занятости всех агентов группы;
- Все речевые сообщения внутри группы привязаны к таймерам (время ожидания в очереди), а не к событиям.

А по событию достижения макс. длины очереди возможна только одна процедура - разъединение вызова.
Вызов может покинуть очередь только сразу же (на входе в группу) по Альтернативе или по таймеру Overflow.
з группы вызов может только сразу же по Альтернативе, или по таймеру Overflow.
Так что в вашем случае, ИМХО, нужно просто держать вызов некоторое время в очереди, а по достижению времени ожидания обслуживания = таймеру Overflow, отправлять дальше (например, в другую группу) или отбивать вызов.
Перед выходом из группы по таймеру Overflow можно выдать речевое сообщение - для этого нужно просто подобрать подходящее значение таймера/ов Voice Announce (таймеры Announce 1/2), которое должно быть меньше таймера Ovverflow (примерно на величину длительности этого сообщения).

[sunturner]

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

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

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

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

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

[sunturner]

Так что в вашем случае, ИМХО, нужно просто держать вызов некоторое время в очереди, а по достижению времени ожидания обслуживания = таймеру Overflow, отправлять дальше (например, в другую группу, и уже там выдавать требуемое речевое сообщение).

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

[Dron]

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

поиск на форуме показал, что в одной из версий прошивок можно было завязать 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 направлять в другую Hunt-группу (пустая, т.е. без агентов), которая будет использоваться только для выдачи речевого сообщения, после чего отбой.

Какая у Вас версия прошивки??

[sunturner]

А почему отбой то?

Сейчас все настроено так:


То есть сообщение "приветствие" - перевод на абонента (если доступен) - сообщение "ждите" - в очередь; если очередь заполнена, отбой (короткие гудки); если таймаут ожидания - сообщение "линии заняты", отбой.

Как я понимаю, можно отказаться от очереди в пользу таймаута ожидания, но тогда возникает вопрос с контролем занятости линий (возможна ситуация, когда звонящие занимают ВСЕ внешние линии).

[sunturner]

Ну так какие проблемы, это же другая задача...
По Alt Dest направлять в другую Hunt-группу (пустая, т.е. без агентов), которая будет использоваться только для выдачи речевого сообщения, после чего отбой.

Какая у Вас версия прошивки??

Прошивка 3.8Ah (указал в первом сообщении).
У меня сейчас при задействованном Alt Dest происходит переброс ДО проверки доступности очереди.
Хотелось бы, чтобы сначала проверялась доступность очереди, и лишь потом проброс на пустую группу с сообщением.

[Dron]

Сейчас все настроено так:


То есть сообщение "приветствие" - перевод на абонента (если доступен) - сообщение "ждите" - в очередь; если очередь заполнена, отбой (короткие гудки); если таймаут ожидания - сообщение "линии заняты", отбой.

Как я понимаю, можно отказаться от очереди в пользу таймаута ожидания, но тогда возникает вопрос с контролем занятости линий (возможна ситуация, когда звонящие занимают ВСЕ внешние линии).

А сколько у вас абонентов в группе прописано?

[sunturner]

А сколько у вас абонентов в группе прописано?

12 станций

[Dron]

..но тогда возникает вопрос с контролем занятости линий (возможна ситуация, когда звонящие занимают ВСЕ внешние линии).

А тут в чем проблема? Ну заняты все внешние линии, И...

[sunturner]

А тут в чем проблема? Ну заняты все внешние линии, И...

Как я понимаю, в этом случае у абонентов возникнут проблемы с звонками "наружу".
А звонящие будут вместо "приветствия" будут попадать на "занято".

[Dron]

Как я понимаю, в этом случае у абонентов возникнут проблемы с звонками "наружу".
А звонящие будут вместо "приветствия" будут попадать на "занято".

Это да! Но, даже и при контроле очереди, звонящие могут слышать "занято" - часть линий заняты входящими вызовами, остальные исходящими...

[sunturner]

Это да! Но, даже и при контроле очереди, звонящие могут слышать "занято" - часть линий заняты входящими вызовами, остальные исходящими...

Завтра предложу техдиректору попробовать схему без очереди, но с длинным Overflow.
Все же очень жаль, что нельзя реализовать мою задачу штатными средствами или перепрошивкой вверх/вниз.

[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.

[stasmar]

А если цикл из 2-х групп сделать - из одной выбрасывается в дгугую по пинку, пардон, максимуму кол-ва аб-в в группе, а в другой сообщение, ожидание и обратно по пинку (пардон) - переполнению в 1-ю группу - и так до посинения, пардон, - до освобождения члена 1-й группы

[Dron]

А если цикл из 2-х групп сделать - из одной выбрасывается в дгугую по пинку, пардон, максимуму кол-ва аб-в в группе, а в другой сообщение, ожидание и обратно по пинку (пардон) - переполнению в 1-ю группу - и так до посинения, пардон, - до освобождения члена 1-й группы

Ты там, упражняясь с тяжестями, не надорвался, случаем? Сам то понял, что написал?
Тихий троечник..

[stasmar]

Ты там, упражняясь с тяжестями, не надорвался, случаем? Сам то понял, что написал?
Тихий троечник..

Простите, если что не так - я пошел спать..

[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]

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

- А возможен третий вариант:
сейчас в группе приема вызовов 12 абонентов. Допустим, я проэмулирую очередь, добавив в группу 16 неиспользуемых станций (номера станций, не обслуживаемые телефонными аппаратами).
Ставлю Overflow в 5 минут, Alternate Destination - на группу с сообщением "все линии заняты, перезвоните позже".
Мои надежды, что это будет работать аналогично Max Queue Count: 12 звонков обслуживает 12 "живых" абонентов, 16 звонков ждут приема от "мертвых" станций (и при освобождении "живых" попадают на нее), 29-й позвонивший слышит сообщение "все линии заняты" и отбой.
Будет ли схема работать так, как я хочу? Не попадут ли звонящие на "мертвые" линии в вечное ожидание?

[Dron]

- А возможен третий вариант:
сейчас в группе приема вызовов 12 абонентов. Допустим, я проэмулирую очередь, добавив в группу 16 неиспользуемых станций (номера станций, не обслуживаемые телефонными аппаратами).
Ставлю Overflow в 5 минут, Alternate Destination - на группу с сообщением "все линии заняты, перезвоните позже".
Мои надежды, что это будет работать аналогично Max Queue Count: 12 звонков обслуживает 12 "живых" абонентов, 16 звонков ждут приема от "мертвых" станций (и при освобождении "живых" попадают на нее), 29-й позвонивший слышит сообщение "все линии заняты" и отбой.
Будет ли схема работать так, как я хочу? Не попадут ли звонящие на "мертвые" линии в вечное ожидание?

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

[sunturner]

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

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

[sunturner]

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

ну теоретически как раз вроде бы должен уйти - это же UCD ("Группа РАВНОМЕРНОГО приема")!
впрочем, я с ldk-300 первую неделю работаю, до конца ни в чем не уверен...

[Dron]

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

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

[harris]

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

Вопросы:

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

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

1) Каких линий??? У Вас аналоговые 2-х проводки или ISDN??
2) Уже несколько Вам писали, что по событию = превышение Max Queue Count станция выполняет разъединение линии и ничего более. Переопределить действие для этого события нельзя!
Какие сигналы Вы хотите сделать разными??? Отбой - он и есть отбой. Станция разъединяет линию ("кладет трубку"), а уже городская АТС генерит для вызывающего абонента сигнал "Занято" (короткие гудки).

[Dron]

ну теоретически как раз вроде бы должен уйти - это же UCD ("Группа РАВНОМЕРНОГО приема")!
впрочем, я с ldk-300 первую неделю работаю, до конца ни в чем не уверен...

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

[sunturner]

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

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

[Dron]

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

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

[sunturner]

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

Мда, пожалуй...

[Dron]

Мда, пожалуй...

Да, и "мертвые" номера должны быть реальные!

[vitalii]

[quote name='sunturner' date='21.6.2011, 10:46' post='51636']
- Overflow всем хорош, но как контролировать нагрузку на линии без Max Queue Count?
У нас есть пул цифровых линий на четыре номера. Один из номеров - Call-center. Если я буду использовать только Overflow, в пиковую нагрузку возможна ситуация, когда весь пул займут ожидающие звонящие в Call-center (все линии "лягут" на телефонный номер call-center). В этом случае остальные три номера не будут доступны, не говоря уже об исходящих из офиса звонках.

30 минус 12(абонентов в позиции ответа) минус такое такое кол-во абонентов в очереди, чтобы остались линии и для занятия для исходящей

[sunturner]

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

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

[sunturner]

30 минус 12(абонентов в позиции ответа) минус такое такое кол-во абонентов в очереди, чтобы остались линии и для занятия для исходящей

вроде того, но как это реализовать БЕЗ Max Queue Count?

[Dron]

И в том, и в другом случае ничего не получается - звонящий либо попадает в вечное ожидание, либо получает отлуп "все линии заняты".

Что и следовало доказать, в общем то!

[sunturner]

Да, и "мертвые" номера должны быть реальные!

Как я понял, в этом случае произойдет "вечное ожидание" - оператор свободен, но не берет трубку; звонящий ждет, когда оператор ответит; и ждать будет до истечения Overflow — так лучше уж сразу его отлупливать, а то больно безнадежно все.

[Dron]

Как я понял, в этом случае произойдет "вечное ожидание" - оператор свободен, но не берет трубку; звонящий ждет, когда оператор ответит; и ждать будет до истечения Overflow — так лучше уж сразу его отлупливать, а то больно безнадежно все.

Да.

[Dron]

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

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

[sunturner]

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

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

[harris]

- А возможен третий вариант:
сейчас в группе приема вызовов 12 абонентов. Допустим, я проэмулирую очередь, добавив в группу 16 неиспользуемых станций (номера станций, не обслуживаемые телефонными аппаратами).
Ставлю Overflow в 5 минут, Alternate Destination - на группу с сообщением "все линии заняты, перезвоните позже".
Мои надежды, что это будет работать аналогично Max Queue Count: 12 звонков обслуживает 12 "живых" абонентов, 16 звонков ждут приема от "мертвых" станций (и при освобождении "живых" попадают на нее), 29-й позвонивший слышит сообщение "все линии заняты" и отбой.
Будет ли схема работать так, как я хочу? Не попадут ли звонящие на "мертвые" линии в вечное ожидание?

Это не будет работать. Длина очереди никак не связана с кол-вом агентов, за исключением случая, когда Max Queue Count = 0. Тогда длина очереди =0, т.е. сколько агентов в группе, столько и вызовов в группу (остальным вызовам - отбой).
Прописать "неживых" агентов - бессмысленно. Если это будут неживые (неподключенные) системники, то это равносильно тому, что они вообще отсуствуют в группе, станция их не будет учитывать при распределении вызовов. Если прописать неподключенные SLT, то станция будет распределять на них вход. вызовы, и в UCD группе эти вызовы уже не вернутся на реально работающего агента, т.е. вызовы будут потеряны (вызов будет выброшен из группы по Overflow).

[Dron]

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

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

[Dron]

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

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

[sunturner]

Это не будет работать. Длина очереди никак не связана с кол-вом агентов, за исключением случая, когда Max Queue Count = 0. Тогда длина очереди =0, т.е. сколько агентов в группе, столько и вызовов в группу (остальным вызовам - отбой).
Прописать "неживых" агентов - бессмысленно. Если это будут неживые (неподключенные) системники, то это равносильно тому, что они вообще отсуствуют в группе, станция их не будет учитывать при распределении вызовов. Если прописать неподключенные SLT, то станция будет распределять на них вход. вызовы, и в UCD группе эти вызовы уже не вернутся на реально работающего агента, т.е. вызовы будут потеряны (вызов будет выброшен из группы по Overflow).

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

[sunturner]

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

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

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

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

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

[harris]

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

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

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

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

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

[sunturner]

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

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

[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 месяца сезона не выгодно: их нужно обучить, а в штате круглый год держать неоправданно.
В рамках моей зоны ответственности (в данном случае настройка АТС) мне мое решение кажется максимально адекватным.
Остальное - человеческий фактор - не в моей власти.

[Dron]

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

Знакомо это все.. И все я понимаю! У нас тоже были клиенты туроператоры, кухня та же..Мысли вслух просто...

[harris]

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

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

[sunturner]

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

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

[harris]

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

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

[Евген_й]

Но тут специфика бизнеса: я работаю в крупном туроператоре, а у нас нагрузка сезонная (ну и по рабочему дню распределение нагрузки не равномерное - большинство звонков поступает с 11:00 по 14:00).

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

[ЛыЖник]

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

Например, по прг.237. Я так думаю, что ежели у вас формат городских приходит, допустим 6 знаков, а межгород 8х, можно в таблице прописать выход по прг.231 на группу приема междугородних звонков. Правда, в этом случе будут попадаться и сотовые звонки, они тоже в 10-ти значном формате. Правда, проверять некогда. Счас посмотрел в прг.237. Там можно использовать знак *. Но не более 20 цифр. Also, прописать маску междугороднего звонка на одну группу. Ну, а городские в обычном порядке. Как-то так.