Pull to refresh

Comments 23

Каким количеством человек и каким количеством общего времени вам удалось сделать этот Грааль?
благодарим за интерес к нашему продукту, над проектом работает пока что команда из 3 человек: Евгений, его супруга, в качестве тестировщика и генератора идей, и я
в течение года мы смогли воплотить все что Вы увидите в текущей версии статистики

Добрый день.
Поглядел сайт, весьма интересный продукт. Возник вопрос.


Немного предыстории. Так случилось, что нам уже пришлось делать аналитику для распределенных колл-центров на астерисках.
Изначально поглядели на



Ничего не пошло. В силу того, что диалплан весьма непростой и специфичный для каждого астериска; используются макросы; показатели, посчитанные тремя разными программами отличаются в разы; нужна еще интеграция с внешними источниками; не все настройки астерисков в зоне нашего влияния.
Поэтому на первом этапе мы вынуждены были перейти на событийную модель расчета и использовать только queue log. Фактически, ведем построение callflow, самостоятельный перерасчет временных показателей по временным меткам в логе и последующий честный расчет всех показателей.


Интересно, что переход на call-flow позволяет делать приятные вещи типа process mining. Много чего любопытного вскрылось.


Да и сама методика расчета KPI операторов\абонентов весьма разветвленна, просто время разговора мало кого интересует. Например, в зависимости от сценария разговора может быть организован мост с третьим лицом, так вот кроме общих показателей разные плечи надо выцеплять и учитывать в разных KPI.


Делали все на R, чтобы не быть голословным, прикладываю ряд скриншотов.
Сводный Call-flow по выбранному звонку
Дашборд сводных данных
Сценарии дозвона


На втором этапе подумываем сесть на AMI события.


Вопросы таковы:


  1. как вы валидируете правдивость статистических показаний, особенно на чужих астерисках, настройки которых вы менять не можете?
  2. можете ли предоставить детальную аналитику по плечам и звонку в целом, когда звонок состоит из трех участников: абонент-оператор-третья сторона и звонок собирается через attendent transfer из двух плеч? второе плечо инициируется оператором.

на самом деле, вопросов гораздо больше, но на часть из них может ответить только бизнес — нужно согласиться с той или иной методологией подсчета. Простой пример — кейс, когда абонент не один раз попадает в очередь (в ту же или в другую, а перевел его после диалога с уточнением потребностей первый взявший оператор). Считать ли это за один звонок или за несколько (событий ENTERQUEUE несколько)? Что каждому из операторов включать в KPI? Делать ли различие по сценариям повторного попадания в ту же очередь?


Фактически, мы за 2 недели собрали прототип. Прототип не в коде, а в математике поскольку теперь можно и нужно прорабатывать специфические метрики для адекватного описания работы колл-центра с точки зрения бизнес-процессов, которые он обслуживает. Готовых ответов ни у кого нет.


И на этом моменте становится непонятно, насколько коробочные продукты потенциально готовы удовлетворить такую потребность. Вы думали уже в этом направлении?

1. Мы работаем с cel, cdr и queue_log и, как правило, удается вытащить все так как оно было на самом деле (в этом cel — неоценимый помощник). Настройки Asterisk на стороне клиента правятся, это необходимо для логики работы наших запросов.
Нужный кастом мы описали в вики, например — wiki.vistep.ru/doku.php?id=configure_freepbx_for_cloud_version

2. В базовом функционале — нет.
В этом случае, по запросу клиента, пилим спец. отчеты (пример в статье «Дополнительный отчеты»).

Безусловно, как вы правильно заметили, — серебрянной пули нет,
но мы стараемся выплавить нечто универсальное и растем в каждой итерации за счет фидбека и новых кейсов в настройке АТС клиентов.

Была идея написания своего модуля к Asterisk, дабы в отдельную БД все складывалось как нам необходимо, но уже не раз убедились, что весь путь звонка можно собрать из трех стандартных таблиц и представить его в нужно виде.
Вы работаете только со стандартными средствами логирования астериск (CDR,CEL, Queue_Log) или есть АПИ для того чтобы прикрутить свои данные?
Да, данные все берем из этих трех таблиц + нужен небольшой кастом в настройке АТС (в вики у нас есть эти гайды).
Свои данные можно отправить нам посредством linux-демона (ставится к вам на АТС).
Так API планируется?
Ну к примеру у меня кластер из АТС.
Я бы не прочь иметь обертку для статистики которой я смог бы поставить свои данные со своей АТС, чтобы она их проанализировала и отрисовала (не хочу например писать свой frontend и аналитику, готов на облако, но не хочу свою АТС в облако загонять)
АТС загонять в облако нет нужды.
На АТС ставится демон, который синкает БД и файлы записей разговоров к нам.
Вы заходите на stat.vistep.ru, вбиваете логин и пароль и смотрите все отчеты.
есть ли вариант установки приложения на стороне клиента, чтоб не давать вам информацию о номерах и записях телефонов?
да, у нас есть локальная версия ПО
Думаю что аудитория, которая хочет предложить что-то свое у вас достаточно крупная, но хотелось бы внести предложения/задать вопрос:
рады любым вопросам, задавайте здесь или в личке
А что по поводу возможности обзвонов и убежавших звонков?
Вопрос был, не просто увидеть в отчете, а может, например, оператор, если не успел ответить, нажать кнопочку и перезвонить из программы тому, кто не дождался?

Обзвон имеется в виду автоинформирование. Есть база абонентов, им нужно донести какую-то информацию. Записывается сообщение, программа дозванивается и проигрывает звуковой файл.
Звонок по клику мышкой из интерфейса — да, в одном из следующих релизов будет.
Автоинформатор — в недрах нашего редмайна и гита есть такой проект, но в свет мы его пока не готовы выпустить.
Как будете справляться с WebRTC?
Астериск даже в 13 версии очень так себе работает через этот транспорт. Не продакшн.
В ближайшее время реализация будет через AMI (как в интеграции с amoCRM, например, т.е. жмакнул на ссылку — зазвонил у тебя телефон, берешь трубку — пошел вызов на номер, по которому жмакнул).
Дальше будем смотреть.
Дело тут даже не только в Астериске… но вот проблема которую я не поборол — при каждом звонке приходится нажимать «разрешить» использовать микрофон. Очень бесит
В chrome, вроде бы можно добавлять исключения для url, где запрос на использование микрофона не будет появляться, и он будет доступен по умолчанию, этот момент уже будем обрабатывать, когда начнем внедрять функционал звонков в статистику.
Сервер с нормальным сертификатом + оттуда же загружаем код звонилки = решение проблемы с микрофоном

Дело именно в Астериске — его WebRTC к продакшну не готов.
Only those users with full accounts are able to leave comments. Log in, please.