Comments 23
в течение года мы смогли воплотить все что Вы увидите в текущей версии статистики
Добрый день.
Поглядел сайт, весьма интересный продукт. Возник вопрос.
Немного предыстории. Так случилось, что нам уже пришлось делать аналитику для распределенных колл-центров на астерисках.
Изначально поглядели на
- Asterisk Call Center Stats;
- Asterisk CDR Viewer Mod.
- [авторская поделка администратора]
Ничего не пошло. В силу того, что диалплан весьма непростой и специфичный для каждого астериска; используются макросы; показатели, посчитанные тремя разными программами отличаются в разы; нужна еще интеграция с внешними источниками; не все настройки астерисков в зоне нашего влияния.
Поэтому на первом этапе мы вынуждены были перейти на событийную модель расчета и использовать только queue log. Фактически, ведем построение callflow, самостоятельный перерасчет временных показателей по временным меткам в логе и последующий честный расчет всех показателей.
Интересно, что переход на call-flow позволяет делать приятные вещи типа process mining. Много чего любопытного вскрылось.
Да и сама методика расчета KPI операторов\абонентов весьма разветвленна, просто время разговора мало кого интересует. Например, в зависимости от сценария разговора может быть организован мост с третьим лицом, так вот кроме общих показателей разные плечи надо выцеплять и учитывать в разных KPI.
Делали все на R, чтобы не быть голословным, прикладываю ряд скриншотов.
На втором этапе подумываем сесть на AMI события.
Вопросы таковы:
- как вы валидируете правдивость статистических показаний, особенно на чужих астерисках, настройки которых вы менять не можете?
- можете ли предоставить детальную аналитику по плечам и звонку в целом, когда звонок состоит из трех участников: абонент-оператор-третья сторона и звонок собирается через attendent transfer из двух плеч? второе плечо инициируется оператором.
на самом деле, вопросов гораздо больше, но на часть из них может ответить только бизнес — нужно согласиться с той или иной методологией подсчета. Простой пример — кейс, когда абонент не один раз попадает в очередь (в ту же или в другую, а перевел его после диалога с уточнением потребностей первый взявший оператор). Считать ли это за один звонок или за несколько (событий ENTERQUEUE несколько)? Что каждому из операторов включать в KPI? Делать ли различие по сценариям повторного попадания в ту же очередь?
Фактически, мы за 2 недели собрали прототип. Прототип не в коде, а в математике поскольку теперь можно и нужно прорабатывать специфические метрики для адекватного описания работы колл-центра с точки зрения бизнес-процессов, которые он обслуживает. Готовых ответов ни у кого нет.
И на этом моменте становится непонятно, насколько коробочные продукты потенциально готовы удовлетворить такую потребность. Вы думали уже в этом направлении?
Нужный кастом мы описали в вики, например — wiki.vistep.ru/doku.php?id=configure_freepbx_for_cloud_version
2. В базовом функционале — нет.
В этом случае, по запросу клиента, пилим спец. отчеты (пример в статье «Дополнительный отчеты»).
Безусловно, как вы правильно заметили, — серебрянной пули нет,
но мы стараемся выплавить нечто универсальное и растем в каждой итерации за счет фидбека и новых кейсов в настройке АТС клиентов.
Была идея написания своего модуля к Asterisk, дабы в отдельную БД все складывалось как нам необходимо, но уже не раз убедились, что весь путь звонка можно собрать из трех стандартных таблиц и представить его в нужно виде.
Свои данные можно отправить нам посредством linux-демона (ставится к вам на АТС).
Ну к примеру у меня кластер из АТС.
Я бы не прочь иметь обертку для статистики которой я смог бы поставить свои данные со своей АТС, чтобы она их проанализировала и отрисовала (не хочу например писать свой frontend и аналитику, готов на облако, но не хочу свою АТС в облако загонять)
Обзвон имеется в виду автоинформирование. Есть база абонентов, им нужно донести какую-то информацию. Записывается сообщение, программа дозванивается и проигрывает звуковой файл.
Автоинформатор — в недрах нашего редмайна и гита есть такой проект, но в свет мы его пока не готовы выпустить.
Астериск даже в 13 версии очень так себе работает через этот транспорт. Не продакшн.
Дальше будем смотреть.
Дело именно в Астериске — его WebRTC к продакшну не готов.
Web-интерфейс для вашей Asterisk. Статистика для call-центров, отделов продаж, прослушивание звонков и многое другое