Работа голосовых сервисов в USD группе, ipLDK100 Опции

[Сергей Владимиро...]

На станцию установлен Е1 с многоканальным номером. Все вызова идут на одну группу операторов (USD). Позвонившим воспроизводятся сначала один ролик, после повторяется второй до ответа оператора, в промежутках музыка с внешнего источника. Требуется ограничить количество вызовов, находящихся в ожидании. Проблема в следующем, при привышении лимита вызовов в ожидании все равно проигрывается первое сообщение, а после отбой. Если ставить таймер первого сообщения на 1, то операторы иногда (при низкой загрузке) успевают взять трубку и приветствия не звучит. Как сделать так, чтобы сохранить голосовые сообщения, а при привышении лимита в очереди сразу давать отбой. Скрин:  ldk100.jpg ( 91,3 килобайт ) Кол-во скачиваний: 27

[harris]

На станцию установлен Е1 с многоканальным номером. Все вызова идут на одну группу операторов (USD). Позвонившим воспроизводятся сначала один ролик, после повторяется второй до ответа оператора, в промежутках музыка с внешнего источника. Требуется ограничить количество вызовов, находящихся в ожидании. Проблема в следующем, при привышении лимита вызовов в ожидании все равно проигрывается первое сообщение, а после отбой. Если ставить таймер первого сообщения на 1, то операторы иногда (при низкой загрузке) успевают взять трубку и приветствия не звучит. Как сделать так, чтобы сохранить голосовые сообщения, а при привышении лимита в очереди сразу давать отбой. Скрин:  ldk100.jpg ( 91,3 килобайт ) Кол-во скачиваний: 27

Я правильно понял, что если VMIB Announce Timer 1 = 0 (гарантированное приветствие), то при превышении длины очереди вызов отбивается, но только после воспроизведения этого приветствия №1???? А нужно, чтобы отбой был сразу, без приветствия...???

[Евген_й]

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

[Сергей Владимиро...]

Я правильно понял, что если VMIB Announce Timer 1 = 0 (гарантированное приветствие), то при превышении длины очереди вызов отбивается, но только после воспроизведения этого приветствия №1???? А нужно, чтобы отбой был сразу, без приветствия...???

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

[harris]

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

1. По поводу гарантированного приветствия. Тут изменить ничего нельзя. Гарантированное приветствие имеет более высокий приоритет. Корейцы проверяют занятость операторов и длину очереди после гарантированного приветствия.
Наверное, это не совсем верно, но чтобы они поменяли алгоритм нужно писать запрос. ИМХО, займет несколько недель (если они согласятся изменить софт).
В принципе можно попробовать сделать запрос на изменение.

2. Евгений предлагает Вам другой вариант: если все операторы заняты, то давать на входе какое-либо другое приветствие... Т.е. предупреждать клиента, что он дозванился правильно, но все операторы заняты. Далее он сам может решить ожидать в очереди или отбиться.
Это можно сделать за счет Альтернативного перенаправления вызова. В аттрибутах вашей UCD-группе указать в качестве альтернативного назначения другую (вторую) UCD-группу.
Создать вторую группу, к качестве ее агентов указать точно тех же операторов (агентов первой группы). В качестве гарантированного приветствия во 2-ой группе использовать какое-либо другое соответствующее по смыслу сообщение.
Будет:
- вход. вызов.
- если есть свободный агент, то вызов идет в группу 1.
- если нет свободного агента, то вызов идет в группу 2 (можно давать сообщение и отбивать линию, либо все-таки оставлять в очереди - как Вам будет удобнее).

[Сергей Владимиро...]

Это можно сделать за счет Альтернативного перенаправления вызова. В аттрибутах вашей UCD-группе указать в качестве альтернативного назначения другую (вторую) UCD-группу.
Создать вторую группу, к качестве ее агентов указать точно тех же операторов (агентов первой группы). В качестве гарантированного приветствия во 2-ой группе использовать какое-либо другое соответствующее по смыслу сообщение.
Будет:
- вход. вызов.
- если есть свободный агент, то вызов идет в группу 1.
- если нет свободного агента, то вызов идет в группу 2 (можно давать сообщение и отбивать линию, либо все-таки оставлять в очереди - как Вам будет удобнее).

Это в принципе подходит. Хотя и реализация через одно место..... попробую сделать. Там ещё есть Overflow Timer и Overflow Distanation, есть перевод на ячейку речевого ящика, вот только что будет после проигрывания сообщения, отбой? Т.е. следующий алогоритм :
1 вызов
2 приветствие
3 если нет свободных агентов ждём до истечения таймера
4 если таймер истёк то сообщение (нет операторов) и отбой.

будет ли это работать? (не уверен на счёт отбоя)

и в альтернативе тоже есть перевод на речевик, вот только работает ли он в связке с ограничением очереди?

Уважаемый harris, попробуйте сделать запрос, ибо это не правильно.

[harris]

Это в принципе подходит. Хотя и реализация через одно место..... попробую сделать. Там ещё есть Overflow Timer и Overflow Distanation, есть перевод на ячейку речевого ящика, вот только что будет после проигрывания сообщения, отбой? Т.е. следующий алогоритм :
1 вызов
2 приветствие
3 если нет свободных агентов ждём до истечения таймера
4 если таймер истёк то сообщение (нет операторов) и отбой.

будет ли это работать? (не уверен на счёт отбоя)

и в альтернативе тоже есть перевод на речевик, вот только работает ли он в связке с ограничением очереди?

Уважаемый harris, попробуйте сделать запрос, ибо это не правильно.

1. Оverflow ("переполнение") - это уже выход после ожидания в очереди. Это уже не связано с ограничением длины очереди.
Вызов из очереди можно передать на VMIB (в режим DISA для донабора номера) или на VMIB # (сообщение с последующим отбоем, без возможности донабора номера).
А можно и так: по окончанию таймера Overflow направить вызов в другую Hunt-группу (пустую, т.е. агентом группы прописать какого-либо неподключенного абонента, из последних абонентских портов), выдать в этой группе сообщение ("пардон, перезвоните...") и (если в этой пустой группе нет назначенного Overflow Destination) вызов будет отбиваться.
2. Правильно или неправильно - это все весьма относительно и субъективно. Вам нужно так, другим нужно совсем иначе... У корейцев была своя логика. Гарантированное сообщение - значит его нужно выдавать всегда, при любом вход. вызове.
ОК. На след. неделе попробую сделать запрос на изменение...

[Сергей Владимиро...]

работает ли Max Queued Call Count в связке с Alternate Distanation? Это было бы хорошим решением.

[harris]

работает ли Max Queued Call Count в связке с Alternate Distanation? Это было бы хорошим решением.

Нет.

[Сергей Владимиро...]

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

[Сергей Владимиро...]

Работает ли Max Queued Call Count в связке с Alternate Destination? Если нет и будете делать запрос на изменение прошивки, то логичнее было бы сделать данную связку, чем отбой до гарантированного приветствия. Сам пока не экспериментировал.

[Сергей Владимиро...]

Был вопрос:

работает ли Max Queued Call Count в связке с Alternate Distanation? Это было бы хорошим решением.

ответили:

Нет.

Эксперименты показали, что данная связка всё таки РАБОТАЕТ
Настройки сделаны в соответствии со скринами ниже:
 usd620.jpg ( 153,57 килобайт ) Кол-во скачиваний: 34
и  usd621.jpg ( 81,21 килобайт ) Кол-во скачиваний: 24
621 группа из одного не существующего абонента.

Алгоритм следующий:
1. Всем позвонившим приветствие 1 ("Вы позвонили туда то")
2. Если есть свободные операторы то ответ оператора, иначе - 3.
3. Если есть место в очереди то сообщение 3 ("Дождитесь ответа оператора"), иначе перевод на группу 621
4. Сообщение 4 ("пардон, перезвоните позже") не поместившимся в очередь и отбой.

Соответственно для полного ажура нужно анализировать состояние очереди ДО гарантированного приветствия. и в Alternate Distanation иметь возможность переводить на ячейку голосовой почты.

[harris]

.......
Соответственно для полного ажура нужно анализировать состояние очереди ДО гарантированного приветствия. и в Alternate Distanation иметь возможность переводить на ячейку голосовой почты.

1. Запрос в Корею сделан. Разработчики обещали изменить алгоритм в следующих релизах софта (анализ длины очереди после анализа Альтернативного назначения, но до гарантированного приветствия группы).
Подождем...., посмотрим...
2. По Альтернативе "иметь возможность переводить на ячейку голосовой почты"????
Уточните, чего Вы хотите добиться.

[Сергей Владимиро...]

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

[harris]

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

А чем не устраивает возможность выполнить то же самое через другую группу??
ИМХО, чем больше корейцы будут изменять сервис для Hunt-групп, тем больше вероятность поломать всЁ. Они уже и так не раз поясняли, что изменять софт для группового сервиса опасно - много всего "накручено"... ИМХО, лучше не стоит с этим к ним обращаться, поскольку нужный результат можно получить за счет другой группы.

[Сергей Владимиро...]

..........чем больше корейцы будут изменять сервис для Hunt-групп, тем больше вероятность поломать всЁ... ИМХО, лучше не стоит с этим к ним обращаться.....

....... ну и ладно , не стоит так не стоит, будем пользовать как есть. Когда ( если... ) сделают, то как узнать? Напишите в тему или на почту?

[harris]

....... ну и ладно , не стоит так не стоит, будем пользовать как есть. Когда ( если... ) сделают, то как узнать? Напишите в тему или на почту?

Ок. Сообщу на форуме, в этой теме..., если сделают....

[Сергей Владимиро...]

Ок. Сообщу на форуме, в этой теме..., если сделают....

ню..... сделали или нет? Воды то порядком утекло

[harris]

ню..... сделали или нет? Воды то порядком утекло

Хмм, ну вообще-то, 4 месяца на изменение софта.... по корейским меркам - это совсем немного воды утекло...
Но в данном конкретном случае, да - уже сделали.
Пардон, я просто забыл сообщить Вам сообщить об этом на форуме.

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


Версия, кажется, уже выложена здесь на сайте.

[Сергей Владимиро...]

Ну это уже лучше, если не сказать что хорошо. (то же поправил )