KG
Заметил если это Микросип то просто отбывает звонок статус на сервере не меняется
Size: a a a
2020 July 01
KG
В консоле астера введмте queue show <номер очеоеди>
has taken 142 calls (last was 493 secs ago)
OS
там напротив мембера должно быть слово paused
OS
если его нет, то он не на паузе
DR
если была бы пауза, то через минуту оно бы не звонило
Ну у фряли есть пункт, что то вроде таймаут сервис левел. После обработки вызова, агенту задается таймвут, через который он снова сможет принимать вызов.
OS
Ну у фряли есть пункт, что то вроде таймаут сервис левел. После обработки вызова, агенту задается таймвут, через который он снова сможет принимать вызов.
не знаю как у фрипбх, но у обычного астера есть такой параметр autopause, но он если поставит на паузу, то назад уже не вернет
OS
и это легко проверить в конфигурации
KG
Если поставит на паузу через микросип то статус не меняется а микросип сам будет отбывать звонки
OS
Если поставит на паузу через микросип то статус не меняется а микросип сам будет отбывать звонки
это уже не пауза, это DND
OS
немного другое
OS
в логе такое можно отследить
KG
у оператора нет другого варианта ставит на паузу, на сипфоне только ДНД есть и все
OS
будут попытки вызова, и busy в ответе
KG
о как раз логирую в базу логи очереди сейчас гляну
KG
Нашел вредителя ) походу ДНД стоит у него туча звонков где RINGNOANSWER
RP
Переслано от Roman Pertsev
Немного о ringall почему его не стоит использовать в кц:
Ringall'ом часто пытаются решить административные проблемы, когда ваши операторы слишком охеревшие и могут не брать трубку, ringall решает эту проблему путем распределения одного вызова на всех операторов и возможно, кто-то и соизволит ответить на этот вызов. Такой подход в корне не верен, потому что есть определенный таймаут за который оператор ОБЯЗАН ответить на вызов, обычно это 5-15 секунд. Если этого не произошло в queue_log создается событие RINGNOANSWER благодаря которому можно и нужно вычислять таких операторов и делать им атата или даже увольнять
При большом количестве операторов в очереди возникают необоснованные нагрузки при входящих вызовах, добавьте сюда парсеры AMI событий которые просто будут утопать в этом ну и т.д.
Так же при большом количестве операторов в очереди, возникает ситуация что некоторым операторам вызовы не будут приходить в принципе, потому что будет парочка умных которые будут либо супер быстро снимать трубку либо вообще использовать автоответ (например на софтфонах), следовательно, деление клиентов между операторами будет с дисбалансом в чью-то сторону. Ну и так как астер выполняет все последовательно то последним операторам вызов реально может успеть и не дойти, такие случаи на практике у нас были.
Куча ненужных записей в CDR
Ну и последнее, при ringall обработка нового вызова не начнется пока кто-то не ответит первому клиенту, и основной смысл очереди это обработка нового клиента любым свободным оператором. К примеру у вас 5 операторов и тут позвонило 10 клиентов, при любой другой стратегии не ringall первые 5 распределятся между вашими 5ю операторами, остальные будут обслуживаться по мере освобождения операторов. А при ringall получится что только первый клиент уйдет на 5ых операторов, остальные курят бамбук. А теперь добавим всевозможные таймауты операторов основные, дополнительные (перерыв) после вызова и в итоге получаем что ringall это стратегия не для колцентров которым дорога каждая секунда.
Ringall'ом часто пытаются решить административные проблемы, когда ваши операторы слишком охеревшие и могут не брать трубку, ringall решает эту проблему путем распределения одного вызова на всех операторов и возможно, кто-то и соизволит ответить на этот вызов. Такой подход в корне не верен, потому что есть определенный таймаут за который оператор ОБЯЗАН ответить на вызов, обычно это 5-15 секунд. Если этого не произошло в queue_log создается событие RINGNOANSWER благодаря которому можно и нужно вычислять таких операторов и делать им атата или даже увольнять
При большом количестве операторов в очереди возникают необоснованные нагрузки при входящих вызовах, добавьте сюда парсеры AMI событий которые просто будут утопать в этом ну и т.д.
Так же при большом количестве операторов в очереди, возникает ситуация что некоторым операторам вызовы не будут приходить в принципе, потому что будет парочка умных которые будут либо супер быстро снимать трубку либо вообще использовать автоответ (например на софтфонах), следовательно, деление клиентов между операторами будет с дисбалансом в чью-то сторону. Ну и так как астер выполняет все последовательно то последним операторам вызов реально может успеть и не дойти, такие случаи на практике у нас были.
Куча ненужных записей в CDR
Ну и последнее, при ringall обработка нового вызова не начнется пока кто-то не ответит первому клиенту, и основной смысл очереди это обработка нового клиента любым свободным оператором. К примеру у вас 5 операторов и тут позвонило 10 клиентов, при любой другой стратегии не ringall первые 5 распределятся между вашими 5ю операторами, остальные будут обслуживаться по мере освобождения операторов. А при ringall получится что только первый клиент уйдет на 5ых операторов, остальные курят бамбук. А теперь добавим всевозможные таймауты операторов основные, дополнительные (перерыв) после вызова и в итоге получаем что ringall это стратегия не для колцентров которым дорога каждая секунда.
OS
Переслано от Roman Pertsev
Немного о ringall почему его не стоит использовать в кц:
Ringall'ом часто пытаются решить административные проблемы, когда ваши операторы слишком охеревшие и могут не брать трубку, ringall решает эту проблему путем распределения одного вызова на всех операторов и возможно, кто-то и соизволит ответить на этот вызов. Такой подход в корне не верен, потому что есть определенный таймаут за который оператор ОБЯЗАН ответить на вызов, обычно это 5-15 секунд. Если этого не произошло в queue_log создается событие RINGNOANSWER благодаря которому можно и нужно вычислять таких операторов и делать им атата или даже увольнять
При большом количестве операторов в очереди возникают необоснованные нагрузки при входящих вызовах, добавьте сюда парсеры AMI событий которые просто будут утопать в этом ну и т.д.
Так же при большом количестве операторов в очереди, возникает ситуация что некоторым операторам вызовы не будут приходить в принципе, потому что будет парочка умных которые будут либо супер быстро снимать трубку либо вообще использовать автоответ (например на софтфонах), следовательно, деление клиентов между операторами будет с дисбалансом в чью-то сторону. Ну и так как астер выполняет все последовательно то последним операторам вызов реально может успеть и не дойти, такие случаи на практике у нас были.
Куча ненужных записей в CDR
Ну и последнее, при ringall обработка нового вызова не начнется пока кто-то не ответит первому клиенту, и основной смысл очереди это обработка нового клиента любым свободным оператором. К примеру у вас 5 операторов и тут позвонило 10 клиентов, при любой другой стратегии не ringall первые 5 распределятся между вашими 5ю операторами, остальные будут обслуживаться по мере освобождения операторов. А при ringall получится что только первый клиент уйдет на 5ых операторов, остальные курят бамбук. А теперь добавим всевозможные таймауты операторов основные, дополнительные (перерыв) после вызова и в итоге получаем что ringall это стратегия не для колцентров которым дорога каждая секунда.
Ringall'ом часто пытаются решить административные проблемы, когда ваши операторы слишком охеревшие и могут не брать трубку, ringall решает эту проблему путем распределения одного вызова на всех операторов и возможно, кто-то и соизволит ответить на этот вызов. Такой подход в корне не верен, потому что есть определенный таймаут за который оператор ОБЯЗАН ответить на вызов, обычно это 5-15 секунд. Если этого не произошло в queue_log создается событие RINGNOANSWER благодаря которому можно и нужно вычислять таких операторов и делать им атата или даже увольнять
При большом количестве операторов в очереди возникают необоснованные нагрузки при входящих вызовах, добавьте сюда парсеры AMI событий которые просто будут утопать в этом ну и т.д.
Так же при большом количестве операторов в очереди, возникает ситуация что некоторым операторам вызовы не будут приходить в принципе, потому что будет парочка умных которые будут либо супер быстро снимать трубку либо вообще использовать автоответ (например на софтфонах), следовательно, деление клиентов между операторами будет с дисбалансом в чью-то сторону. Ну и так как астер выполняет все последовательно то последним операторам вызов реально может успеть и не дойти, такие случаи на практике у нас были.
Куча ненужных записей в CDR
Ну и последнее, при ringall обработка нового вызова не начнется пока кто-то не ответит первому клиенту, и основной смысл очереди это обработка нового клиента любым свободным оператором. К примеру у вас 5 операторов и тут позвонило 10 клиентов, при любой другой стратегии не ringall первые 5 распределятся между вашими 5ю операторами, остальные будут обслуживаться по мере освобождения операторов. А при ringall получится что только первый клиент уйдет на 5ых операторов, остальные курят бамбук. А теперь добавим всевозможные таймауты операторов основные, дополнительные (перерыв) после вызова и в итоге получаем что ringall это стратегия не для колцентров которым дорога каждая секунда.
но у этой стратегии есть и плюсы. Клиент сразу понимает как она работает. Часто он сам заказывает эту стратегию.
PZ
Переслано от Roman Pertsev
Немного о ringall почему его не стоит использовать в кц:
Ringall'ом часто пытаются решить административные проблемы, когда ваши операторы слишком охеревшие и могут не брать трубку, ringall решает эту проблему путем распределения одного вызова на всех операторов и возможно, кто-то и соизволит ответить на этот вызов. Такой подход в корне не верен, потому что есть определенный таймаут за который оператор ОБЯЗАН ответить на вызов, обычно это 5-15 секунд. Если этого не произошло в queue_log создается событие RINGNOANSWER благодаря которому можно и нужно вычислять таких операторов и делать им атата или даже увольнять
При большом количестве операторов в очереди возникают необоснованные нагрузки при входящих вызовах, добавьте сюда парсеры AMI событий которые просто будут утопать в этом ну и т.д.
Так же при большом количестве операторов в очереди, возникает ситуация что некоторым операторам вызовы не будут приходить в принципе, потому что будет парочка умных которые будут либо супер быстро снимать трубку либо вообще использовать автоответ (например на софтфонах), следовательно, деление клиентов между операторами будет с дисбалансом в чью-то сторону. Ну и так как астер выполняет все последовательно то последним операторам вызов реально может успеть и не дойти, такие случаи на практике у нас были.
Куча ненужных записей в CDR
Ну и последнее, при ringall обработка нового вызова не начнется пока кто-то не ответит первому клиенту, и основной смысл очереди это обработка нового клиента любым свободным оператором. К примеру у вас 5 операторов и тут позвонило 10 клиентов, при любой другой стратегии не ringall первые 5 распределятся между вашими 5ю операторами, остальные будут обслуживаться по мере освобождения операторов. А при ringall получится что только первый клиент уйдет на 5ых операторов, остальные курят бамбук. А теперь добавим всевозможные таймауты операторов основные, дополнительные (перерыв) после вызова и в итоге получаем что ringall это стратегия не для колцентров которым дорога каждая секунда.
Ringall'ом часто пытаются решить административные проблемы, когда ваши операторы слишком охеревшие и могут не брать трубку, ringall решает эту проблему путем распределения одного вызова на всех операторов и возможно, кто-то и соизволит ответить на этот вызов. Такой подход в корне не верен, потому что есть определенный таймаут за который оператор ОБЯЗАН ответить на вызов, обычно это 5-15 секунд. Если этого не произошло в queue_log создается событие RINGNOANSWER благодаря которому можно и нужно вычислять таких операторов и делать им атата или даже увольнять
При большом количестве операторов в очереди возникают необоснованные нагрузки при входящих вызовах, добавьте сюда парсеры AMI событий которые просто будут утопать в этом ну и т.д.
Так же при большом количестве операторов в очереди, возникает ситуация что некоторым операторам вызовы не будут приходить в принципе, потому что будет парочка умных которые будут либо супер быстро снимать трубку либо вообще использовать автоответ (например на софтфонах), следовательно, деление клиентов между операторами будет с дисбалансом в чью-то сторону. Ну и так как астер выполняет все последовательно то последним операторам вызов реально может успеть и не дойти, такие случаи на практике у нас были.
Куча ненужных записей в CDR
Ну и последнее, при ringall обработка нового вызова не начнется пока кто-то не ответит первому клиенту, и основной смысл очереди это обработка нового клиента любым свободным оператором. К примеру у вас 5 операторов и тут позвонило 10 клиентов, при любой другой стратегии не ringall первые 5 распределятся между вашими 5ю операторами, остальные будут обслуживаться по мере освобождения операторов. А при ringall получится что только первый клиент уйдет на 5ых операторов, остальные курят бамбук. А теперь добавим всевозможные таймауты операторов основные, дополнительные (перерыв) после вызова и в итоге получаем что ringall это стратегия не для колцентров которым дорога каждая секунда.
А какую стратегию выбирать?
МИ
тут все сложно :)
OS
Pavel Z
А какую стратегию выбирать?
мне нравится стратегия Самый ранний, мне кажется она самая справедливая