Pull to refresh

Comments 27

В целом интересно, но я бы сделал не 86400 а 129600, потому что на следующий день клиент может позвонить позже чем он звонил первый раз и уже попадет на секретаря.
Ну вот… Всю тайную тайну раскрыли...))
Теоретически я бы и 3 суток поставил, но заказ был на сутки: хозяин-барин.
Еще нужно иметь ввиду, что разные клиенты могут звонить через SIP и у них может определяться один и тот же номер.
Я думал об этом, но такие случаи не предугадаешь. Точка входа- телефонный номер, вообще можно и по имени (CALLERID(name)) фильтовать, и по IP… Ну в общем все зависит от степени погружения, если можно это так назвать.
Согласен, но можно внести в исключения известные номера SIP провайдеров.
Еще таким же образом, можно сделать в обратном порядке, когда из офиса звонят клиенту и если он перезванивает, то попадает не на секретаря, а на того кто ему звонил последний раз!
Отличная фишка. Очень ее не хватает, когда долго ждешь в очереди, попадаешь на неизвестный ext, долго ему втолковываешь проблему, связь рвется, а ты даже не знаешь с кем разговаривал. И опять все по новой, другому сотруднику. Статья натолкнула на мысль — а не сделать ли анонсирование номера ext перед соединением из очереди или группы.
Вот уже за это плюсанул!
Так же я сразу скажу что делаю все это на голом Asterisk без freePBX так как считаю реализацию этого веб-интерфейса неправильной, нелогичной и ущербной.

А потом продолжил читать. Задумка интересная, правда на небольшой нагрузке я возможно пользовался бы astdb вместо внешней БД.
мне возможностей AstDB для реализации не хватило. Не могу представить как запизнуть 3/4 значения с 2 поля в key/value, да и потом все больше сталкиваюсь с тем что системы растут очень быстро, и вместо того чтобы потом переделывать прихожу к тому, что лучше сразу «запилить» систему с запасом.
Два сценария:
1. клиент через секретаря попадает на менеджера, в процессе общения, менеджер переводит клиента на бухгалтера, звонок срывается. Куда теперь попадёт клиент при попытке перезвонить?
2. клиент совершил свой «первый» звонок в понедельник в 16.30. На следующий день менеджер взял больничный (автофорварды и прочие плюшки по каким-то причинам отключены). Куда теперь попадёт клиент при попытке перезвонить?
1. Сценарий не предполагает перевода клиента на бухгалтера, потому что Зачем? переводить клиента на внутреннюю стуктурную единицу, ну и потом если уж так сильно надо можно же и поменять ход диалплана и записывать в базу например сразу после дозвона менеджеру.

2. В данном диалплане он попадет все равно на своего менеджера, потому что телефон не болеет в отличие от менеджера, как раз для этого можно кастомизировать диалплан поставив скажем перед вызовом менеджера небольшой IVR с предложением позвонить своему менеджеру нажав 1 или набрать секретаря нажав 2. Ведь ничего не мешает это сделать.
1. Зачем? — Это, наверное, риторический вопрос, но требования бизнеса могут быть очень разные :) Если говорить про контору типа books.ru, это, наверное, не потребуется. Если говорить про SMB, то я не сильно задумываясь могу предложить вариант из дружественной мне конторы (поставка оборудования), где для того чтобы сделать клиенту действительно хорошо есть спецы по «направлениям». Один отвечает за компьютеры и комплектуху, второй за сервера и их комплектуху, третий за оборудование аудиомонтажа, четвёртый за оборудование видеомонтажа, пятый занимается исключительно логистикой и доставкой товара клиенту. Ни один, даже самый прекрасный менеджер, не сможет проконсультировать по всем этим видам оборудования, подсказать особенности и недостатки каждого, а так же подсказать, в зависимости от целей клиента, что лучше ему подойдёт.

2. Ну и в таком случае клиент попав первый раз «на своего» менеджера у которого телефон бренчит на столе и ни кому до этого нет дела, т.к. все и так говорят. Будет вынужден звонить еще раз. Скажу честно, если заказ на стадии формирования и т.п., я бы на второй раз начал звонить в соседнюю фирму.

1. Собсвтенно ответ на решение проблемы выше изложен
2. Ни что не мешает настроить последовательную переадресацию скажем снова на группу менеджеров при продолжительности звонка в N секунд. Тогда даже если менеджер не способен ответить- при первом же звонке дольше N секунд звонок будет перведен на группу менеджеров, а дальше как хотите- можете перезаписать агента, можете оставить тем же и использовать переадресацию. Если в ближайшее время появится свободная минутка-постараюсь реализовать этот момент, ЗАмечание то правильное и интересное.
В любом случае сложного тут ничего нет. Диалплан легко поддается кастомизации и расширению — благо там все прозрачно. Как говорится- было бы желание)
Вот за это я Астер и обожаю! Выложил кто-то хорошую идею насчёт какой-то фишки, а потом сидишь и думаешь, что «у меня в чистом виде работать не будет, но вот если добавить… и поменять ..., то выйдет конфетка!»

А в «железячных» решениях такой кастом почти невозможен…
Спасибо кстати за вопросы, первый был неожиданным, но второй я хотел услышать.
Не за что, это на самом деле даже по сути и не вопросы, а примеры ситуаций, которые вы сами могли забыть учесть и из-за которых потом могла начать болеть голова. Так сказать, попытка помощи от коллективного-бессознательного :)
Есть еще вариант как можно было реализовать данный функционал. Включить статистику звонков(cdr), и при каждом входящем звонке проверять одним запросом по базе статистики был ли от этого номера вызов на внутренний номер, сортируя с конца и в интервале нужной даты! Запрос более объемный, зато не нужно дополнительных таблиц и достаточно легко отловить transfer(в базе cdr буква t).
В малонагруженной системе — да, но если это call-центр? Где звонков до 100 000 в день, это достаточно серьезная нагрузка на database и сам запрос будет долгим.
Согласен что запрос будешь выполнятся дольше, тут как раз интересно было бы прогнать на реальной базе. Если меньше секунды, то думаю не будет заметно.
Да, было бы здорово протестировать под нагрузкой. Буду ждать результатов- у самого call центра под рукой нет)
Идея блеск!
Тоже самое что и в статье, но одним запросом к одной таблице БД, в которую астериск еще и сам пишет! Гуру, поделитесь
Постараюсь реализовать это на неделе и протестировать, отпишу вам!
В Asterisk есть функция, называется ODBC_ANTIGF. Пожалуй, озвученный тут вопрос, рассматривает один из немногих случаев, когда ее можно применить.

-= Info about function 'ODBC_ANTIGF' =-
[Synopsis]
Check if a specified callerid is contained in the ex-gf database

Ну это так, каламбур, а вообще, написано по делу.

По поводу вариантов определения номера ответившего, придумал еще один. Если используется логирование событий queue_log в БД, то значит уже «есть» механизм определения ответившего оператора. В БД можно настроить trigger, который будет следить за insert'ами в таблицу queue_log, искать совпадения по event in ('COMPLETEAGENT', 'COMPLETECALLER'), и класть значение agent в таблицу с номерами. На нагруженных системах это сократит количество внешних обращений к базе, что тоже к лучшему.
Я храню в redis, добавление обновления записей lua, только использую freeswitch а не asterisk.
Sign up to leave a comment.

Articles