Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
В целом интересно, но я бы сделал не 86400 а 129600, потому что на следующий день клиент может позвонить позже чем он звонил первый раз и уже попадет на секретаря.
Еще таким же образом, можно сделать в обратном порядке, когда из офиса звонят клиенту и если он перезванивает, то попадает не на секретаря, а на того кто ему звонил последний раз!
Отличная фишка. Очень ее не хватает, когда долго ждешь в очереди, попадаешь на неизвестный ext, долго ему втолковываешь проблему, связь рвется, а ты даже не знаешь с кем разговаривал. И опять все по новой, другому сотруднику. Статья натолкнула на мысль — а не сделать ли анонсирование номера ext перед соединением из очереди или группы.
Вот уже за это плюсанул!
А потом продолжил читать. Задумка интересная, правда на небольшой нагрузке я возможно пользовался бы astdb вместо внешней БД.
Так же я сразу скажу что делаю все это на голом Asterisk без freePBX так как считаю реализацию этого веб-интерфейса неправильной, нелогичной и ущербной.
А потом продолжил читать. Задумка интересная, правда на небольшой нагрузке я возможно пользовался бы astdb вместо внешней БД.
Два сценария:
1. клиент через секретаря попадает на менеджера, в процессе общения, менеджер переводит клиента на бухгалтера, звонок срывается. Куда теперь попадёт клиент при попытке перезвонить?
2. клиент совершил свой «первый» звонок в понедельник в 16.30. На следующий день менеджер взял больничный (автофорварды и прочие плюшки по каким-то причинам отключены). Куда теперь попадёт клиент при попытке перезвонить?
1. клиент через секретаря попадает на менеджера, в процессе общения, менеджер переводит клиента на бухгалтера, звонок срывается. Куда теперь попадёт клиент при попытке перезвонить?
2. клиент совершил свой «первый» звонок в понедельник в 16.30. На следующий день менеджер взял больничный (автофорварды и прочие плюшки по каким-то причинам отключены). Куда теперь попадёт клиент при попытке перезвонить?
1. Сценарий не предполагает перевода клиента на бухгалтера, потому что Зачем? переводить клиента на внутреннюю стуктурную единицу, ну и потом если уж так сильно надо можно же и поменять ход диалплана и записывать в базу например сразу после дозвона менеджеру.
2. В данном диалплане он попадет все равно на своего менеджера, потому что телефон не болеет в отличие от менеджера, как раз для этого можно кастомизировать диалплан поставив скажем перед вызовом менеджера небольшой IVR с предложением позвонить своему менеджеру нажав 1 или набрать секретаря нажав 2. Ведь ничего не мешает это сделать.
2. В данном диалплане он попадет все равно на своего менеджера, потому что телефон не болеет в отличие от менеджера, как раз для этого можно кастомизировать диалплан поставив скажем перед вызовом менеджера небольшой IVR с предложением позвонить своему менеджеру нажав 1 или набрать секретаря нажав 2. Ведь ничего не мешает это сделать.
1. Зачем? — Это, наверное, риторический вопрос, но требования бизнеса могут быть очень разные :) Если говорить про контору типа books.ru, это, наверное, не потребуется. Если говорить про SMB, то я не сильно задумываясь могу предложить вариант из дружественной мне конторы (поставка оборудования), где для того чтобы сделать клиенту действительно хорошо есть спецы по «направлениям». Один отвечает за компьютеры и комплектуху, второй за сервера и их комплектуху, третий за оборудование аудиомонтажа, четвёртый за оборудование видеомонтажа, пятый занимается исключительно логистикой и доставкой товара клиенту. Ни один, даже самый прекрасный менеджер, не сможет проконсультировать по всем этим видам оборудования, подсказать особенности и недостатки каждого, а так же подсказать, в зависимости от целей клиента, что лучше ему подойдёт.
2. Ну и в таком случае клиент попав первый раз «на своего» менеджера у которого телефон бренчит на столе и ни кому до этого нет дела, т.к. все и так говорят. Будет вынужден звонить еще раз. Скажу честно, если заказ на стадии формирования и т.п., я бы на второй раз начал звонить в соседнюю фирму.
2. Ну и в таком случае клиент попав первый раз «на своего» менеджера у которого телефон бренчит на столе и ни кому до этого нет дела, т.к. все и так говорят. Будет вынужден звонить еще раз. Скажу честно, если заказ на стадии формирования и т.п., я бы на второй раз начал звонить в соседнюю фирму.
1. Собсвтенно ответ на решение проблемы выше изложен
2. Ни что не мешает настроить последовательную переадресацию скажем снова на группу менеджеров при продолжительности звонка в N секунд. Тогда даже если менеджер не способен ответить- при первом же звонке дольше N секунд звонок будет перведен на группу менеджеров, а дальше как хотите- можете перезаписать агента, можете оставить тем же и использовать переадресацию. Если в ближайшее время появится свободная минутка-постараюсь реализовать этот момент, ЗАмечание то правильное и интересное.
В любом случае сложного тут ничего нет. Диалплан легко поддается кастомизации и расширению — благо там все прозрачно. Как говорится- было бы желание)
2. Ни что не мешает настроить последовательную переадресацию скажем снова на группу менеджеров при продолжительности звонка в N секунд. Тогда даже если менеджер не способен ответить- при первом же звонке дольше N секунд звонок будет перведен на группу менеджеров, а дальше как хотите- можете перезаписать агента, можете оставить тем же и использовать переадресацию. Если в ближайшее время появится свободная минутка-постараюсь реализовать этот момент, ЗАмечание то правильное и интересное.
В любом случае сложного тут ничего нет. Диалплан легко поддается кастомизации и расширению — благо там все прозрачно. Как говорится- было бы желание)
Вот за это я Астер и обожаю! Выложил кто-то хорошую идею насчёт какой-то фишки, а потом сидишь и думаешь, что «у меня в чистом виде работать не будет, но вот если добавить… и поменять ..., то выйдет конфетка!»
А в «железячных» решениях такой кастом почти невозможен…
А в «железячных» решениях такой кастом почти невозможен…
Спасибо кстати за вопросы, первый был неожиданным, но второй я хотел услышать.
Есть еще вариант как можно было реализовать данный функционал. Включить статистику звонков(cdr), и при каждом входящем звонке проверять одним запросом по базе статистики был ли от этого номера вызов на внутренний номер, сортируя с конца и в интервале нужной даты! Запрос более объемный, зато не нужно дополнительных таблиц и достаточно легко отловить transfer(в базе cdr буква t).
В Asterisk есть функция, называется ODBC_ANTIGF. Пожалуй, озвученный тут вопрос, рассматривает один из немногих случаев, когда ее можно применить.
Ну это так, каламбур, а вообще, написано по делу.
По поводу вариантов определения номера ответившего, придумал еще один. Если используется логирование событий queue_log в БД, то значит уже «есть» механизм определения ответившего оператора. В БД можно настроить trigger, который будет следить за insert'ами в таблицу queue_log, искать совпадения по event in ('COMPLETEAGENT', 'COMPLETECALLER'), и класть значение agent в таблицу с номерами. На нагруженных системах это сократит количество внешних обращений к базе, что тоже к лучшему.
-= 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.
а как это сделать на freepbx distro?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Asterisk. Разгружаем секретаря/диспетчера/первую линию тех. поддержки