Asterisk. Разгружаем секретаря/диспетчера/первую линию тех. поддержки

[Coolfly]

В целом интересно, но я бы сделал не 86400 а 129600, потому что на следующий день клиент может позвонить позже чем он звонил первый раз и уже попадет на секретаря.

[Ovoshlook]

Ну вот… Всю тайную тайну раскрыли...))
Теоретически я бы и 3 суток поставил, но заказ был на сутки: хозяин-барин.

[Coolfly]

Еще нужно иметь ввиду, что разные клиенты могут звонить через SIP и у них может определяться один и тот же номер.

[Ovoshlook]

Я думал об этом, но такие случаи не предугадаешь. Точка входа- телефонный номер, вообще можно и по имени (CALLERID(name)) фильтовать, и по IP… Ну в общем все зависит от степени погружения, если можно это так назвать.

[Coolfly]

Согласен, но можно внести в исключения известные номера SIP провайдеров.

[beho1der]

Еще таким же образом, можно сделать в обратном порядке, когда из офиса звонят клиенту и если он перезванивает, то попадает не на секретаря, а на того кто ему звонил последний раз!

[Equin0x]

Отличная фишка. Очень ее не хватает, когда долго ждешь в очереди, попадаешь на неизвестный ext, долго ему втолковываешь проблему, связь рвется, а ты даже не знаешь с кем разговаривал. И опять все по новой, другому сотруднику. Статья натолкнула на мысль — а не сделать ли анонсирование номера ext перед соединением из очереди или группы.

[stavinsky]

Вот уже за это плюсанул!

Так же я сразу скажу что делаю все это на голом Asterisk без freePBX так как считаю реализацию этого веб-интерфейса неправильной, нелогичной и ущербной.

А потом продолжил читать. Задумка интересная, правда на небольшой нагрузке я возможно пользовался бы astdb вместо внешней БД.

[Ovoshlook]

мне возможностей AstDB для реализации не хватило. Не могу представить как запизнуть 3/4 значения с 2 поля в key/value, да и потом все больше сталкиваюсь с тем что системы растут очень быстро, и вместо того чтобы потом переделывать прихожу к тому, что лучше сразу «запилить» систему с запасом.

[dreik]

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

[Ovoshlook]

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

2. В данном диалплане он попадет все равно на своего менеджера, потому что телефон не болеет в отличие от менеджера, как раз для этого можно кастомизировать диалплан поставив скажем перед вызовом менеджера небольшой IVR с предложением позвонить своему менеджеру нажав 1 или набрать секретаря нажав 2. Ведь ничего не мешает это сделать.

[dreik]

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

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

[Ovoshlook]

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

[Siorinex]

Вот за это я Астер и обожаю! Выложил кто-то хорошую идею насчёт какой-то фишки, а потом сидишь и думаешь, что «у меня в чистом виде работать не будет, но вот если добавить… и поменять ..., то выйдет конфетка!»

А в «железячных» решениях такой кастом почти невозможен…

[Ovoshlook]

Спасибо кстати за вопросы, первый был неожиданным, но второй я хотел услышать.

[dreik]

Не за что, это на самом деле даже по сути и не вопросы, а примеры ситуаций, которые вы сами могли забыть учесть и из-за которых потом могла начать болеть голова. Так сказать, попытка помощи от коллективного-бессознательного :)

[beho1der]

Есть еще вариант как можно было реализовать данный функционал. Включить статистику звонков(cdr), и при каждом входящем звонке проверять одним запросом по базе статистики был ли от этого номера вызов на внутренний номер, сортируя с конца и в интервале нужной даты! Запрос более объемный, зато не нужно дополнительных таблиц и достаточно легко отловить transfer(в базе cdr буква t).

[Ovoshlook]

В малонагруженной системе — да, но если это call-центр? Где звонков до 100 000 в день, это достаточно серьезная нагрузка на database и сам запрос будет долгим.

[beho1der]

Согласен что запрос будешь выполнятся дольше, тут как раз интересно было бы прогнать на реальной базе. Если меньше секунды, то думаю не будет заметно.

[Ovoshlook]

Да, было бы здорово протестировать под нагрузкой. Буду ждать результатов- у самого call центра под рукой нет)

[Yur4eg]

Идея блеск!
Тоже самое что и в статье, но одним запросом к одной таблице БД, в которую астериск еще и сам пишет! Гуру, поделитесь

[beho1der]

Постараюсь реализовать это на неделе и протестировать, отпишу вам!

[pr0r0k_d]

получилось?

[caiser]

В 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 в таблицу с номерами. На нагруженных системах это сократит количество внешних обращений к базе, что тоже к лучшему.

[chusov]

Я храню в redis, добавление обновления записей lua, только использую freeswitch а не asterisk.

[pr0r0k_d]

а как это сделать на freepbx distro?

[Ovoshlook]

Написать свой диалплан)