ИМ
Какой бюджет на СРМ скажи - что-нибудь посоветую.
Size: a a a
2020 July 03
OS
Подскажите пожалуйста если кто юзал Битрикс24 какие плюсы и минусы именно для использования в качестве СРМ-а для контакт центра
кому-то нравится, кому-то нет. Мне сегодня рассказали, что в Б24 нельзя на карточках в канбане вывести наименование компании. Это весьма странно
KG
Спасибо @fish9370
MS
кому-то нравится, кому-то нет. Мне сегодня рассказали, что в Б24 нельзя на карточках в канбане вывести наименование компании. Это весьма странно
там название лида есть если Вы о лидах. Никто не мешает в нем вписывать и компанию , через API вероятно можно
OS
Maxim Shabrov (Zavr2008)
там название лида есть если Вы о лидах. Никто не мешает в нем вписывать и компанию , через API вероятно можно
нет, именно компанию. Есть такая сущность в Б24
MS
Подскажите пожалуйста если кто юзал Битрикс24 какие плюсы и минусы именно для использования в качестве СРМ-а для контакт центра
неверный вопрос и поэтому сложно ожидать ответ.
Контакт-центр болтается сам по себе, никак не связан с фирмой и неясно для чего он там?
собственникам похрен, битрикс внедряли 10 контор и забили нахрен в результате. сотрудникам влом заполнять все поля
Контакт-центр болтается сам по себе, никак не связан с фирмой и неясно для чего он там?
собственникам похрен, битрикс внедряли 10 контор и забили нахрен в результате. сотрудникам влом заполнять все поля
MS
нет, именно компанию. Есть такая сущность в Б24
там коротко
2020 July 04
KG
Переслано от 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 это стратегия не для колцентров которым дорога каждая секунда.
@romk4 не подскажите какую стратегию использовать чтобы операторы не сидели без дела когда на линии 10-абонентов?
RP
@romk4 не подскажите какую стратегию использовать чтобы операторы не сидели без дела когда на линии 10-абонентов?
Любую кроме ringall плюс опция autofill
KG
rrmemory стоит с autofill=yes но все равно не всем идут звонки
𝖆
привет. а есть ли какой то способ переписать приложение Park() на lua, например (не на ари/аги итыды).
Нужно реализовать парковку вызовов на нескольких астерисках, но не получается использовать Park() потому что, если вызов на слот поадет на другой астериск, то там может быть занятый слот с точно таким же номером
Нужно реализовать парковку вызовов на нескольких астерисках, но не получается использовать Park() потому что, если вызов на слот поадет на другой астериск, то там может быть занятый слот с точно таким же номером
𝖆
видимо надо будет посмотреть в сторону приложений Bridge(), BridgeWait() BridgeAdd()
DB
@romk4 не подскажите какую стратегию использовать чтобы операторы не сидели без дела когда на линии 10-абонентов?
Посмотри статистику очереди, она хоть раз сбрасывалась?
DB
Желательно раз в сутки её сбрасывать, чтобы каждый новый день она обнулялась
KG
Для обнуления даже раз в 24-часа перегружаю Астериск
KG
как сделать так чтобы если оператор свободен то принимал звонки? Перепробовал все стратегии, при ringall пока другие операторы не завершают звонки то свободные не принимают
A
а стратегию ringall решили оставить?
A
> то свободные не принимают
а параметр ringinuse у вас как настроен?
а параметр ringinuse у вас как настроен?
KG
ringinuse=0 стоит у меня
RP
как сделать так чтобы если оператор свободен то принимал звонки? Перепробовал все стратегии, при ringall пока другие операторы не завершают звонки то свободные не принимают
Тут нужно разбирать логи и смотреть что в момент вызова нового происходит. Возможно у операторов большой wrapuptime стоит.
В любом случае это не здоровая херня и ее нужно лечить.
В любом случае это не здоровая херня и ее нужно лечить.