1С:Asterisk. Не заставляйте клиента слушать IVR
«Здравствуйте! Вы позвонили в компанию… Ваш звонок очень важен для нас…» Знакомо, правда?
Когда любой из нас, как постоянный клиент, звонит в компанию в 512-й раз, то все эти голосовые меню точно не добавляют положительных эмоций. И это при наличии всяких CRM-ов, HelpDesk-ов.
Как правило, в учетной системе, например, в «1С:Предприятие», в большинстве конфигураций есть информация о контактных телефонах клиента. Там же, хранится менеджер, который закреплен за клиентом. То есть, уже введены все данные для того, чтобы переключить клиента сразу на его менеджера, но клиентов упорно заставляют слушать IVR-ы. Зачем?
На самом деле, задача решается достаточно просто. Нужно всего лишь «рассказать» Asterisk-у о данных, имеющихся в 1С-е.
Чуть погуглив, находим модуль динамической маршрутизации для Asterisk под названием «DBRoute». Устроен этот модуль очень просто. На стороне Asterisk-а в базе MySQL, создается таблица соответствия номеров клиентов и внутренних направлений, куда их переключать. Содержимым этой таблицы управляет 1С:Предприятие. В качестве дополнительного бонуса, на телефоне также будет отображаться имя клиента.
Ковыряем модуль. Основная таблица dbroute_data состоит из колонок:
- Number — хранится номер телефона клиента
- Name — хранится имя клиента для отображения на телефоне/софтфоне
- Dest — хранит строку внутреннего направления, куда переключать клиента. Внутреннее направление – это либо внутренний номер, либо группа вызова, либо очередь.
- Last_date, Last_user — хранят данные о дате последнего изменения строки и пользователе, выполнившем изменение.
- Link_1c – весьма полезная колонка, которую можно использовать для хранения внешней ссылки на объект 1С, изменение которого привело к изменению строки таблицы DBRoute
Пример строки таблицы:
«+380445556677», «Ivanov A.A», «from-did-direct,201», «2012-01-21 14:00:00», «admin»
Идея замечательная, и захотелось узнать, а как обстоят дела с производительностью модуля? Простым генератором номеров загоняем в таблицу 100 000 строк. Тестируем – полет абсолютно нормальный. MySQL потребовал ресурсов, всего на пару процентов больше, чем с пустой таблицей. Ок, загоняем еще 100 000 записей – еще плюс пару процентов. В конце теста, я дошел до 500 000 строк и повышения нагрузки на 10%
Под конкретного заказчика, в его конфигурацию «Управление торговлей» была добавлена обработка для первоначального заполнения таблицы, а затем и функции автоматом меняющие таблицу DBRoute, если в 1С изменились контактные телефоны или ответственный менеджер.
Не вижу особого смысла публиковать сами функции. Есть море статей на тему, как подключаться к MySQL, чтобы читать/писать в ее таблицы. Сам текст запроса будет примерно следующий:
ТекстКоманды=»INSERT INTO asterisk.dbroute_data (number, name, dest, last_date, last_user, link_1c) VALUES (‘»+Номер+«‘,'»+ИмяТранслит+«‘,'»+Маршрут+«‘,'»+Формат(ТекущаяДата(),«ДФ=»»гггг-ММ-дд ЧЧ:мм:сс»»»)+«‘,'»+Автор+«‘,'»+Ссылка1С+«‘) «+ «ON DUPLICATE KEY UPDATE name='»+ИмяТранслит+«‘, dest='»+Маршрут+«‘, last_date='»+Формат(ТекущаяДата(),«ДФ=»»гггг-ММ-дд ЧЧ:мм:сс»»»)+«‘,'»+Автор+«‘,'»+Ссылка1С+«‘»;
Теперь, постоянные клиенты заказчика больше не слушают IVR…
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Очень интересно, спасибо за статью. Мы этот вопрос решили динамическим переводом звонка на ответственного менеджера через AMI интерфейс. У этого решения есть свои плюсы.
(1) jorikfon,
А как вы делаете через AMI?
Я видел, что люди спасались Redirect-ом из AMI, но под нагрузкой Redirect не успевал.
К тому же, если используется AMI, то на нем постоянно должен сидеть какой-то агент. А если агент упал? Тогда, вся умная маршрутизация загнется.
ИМХО, через диалплан гораздо надежнее, т.к. нет лишних прокладок.
(2) Да, через диалплан много надежнее. Тут надо исходить из задачи и цели.
У меня стояла задача сделать переадресацию звонка на ответственного менеджера в случае если этот менеджер прибыл на рабочее место и запустил CRM.
Логика такая: при запуске, каждое рабочее место формирует собственную таблицу маршрутизации, так сказать на себя. При поступлении звонка на IVR, 1С сравнивает номер звонившего с собственной таблицей, и в случае если такой номер есть, делает редирект на себя.
По поводу большой нагрузки пока сказать ничего не могу, у нас при 20 операторах редирект срабатывает до того как IVR начинает произносить «Здравствуйте…»
Но конечно иногда может стоять другая задача, тогда тогда только вашим вариантом и можно сделать правильно! Мы возьмем на заметку 🙂 Вы каким то образом связаны с разработчиками? Думаю мы могли бы быть друг другу полезны 🙂
(3) jorikfon,
Понятно. Главное, что работает и заказчик доволен — остальное мелочи 🙂
Разработчик самого модуля — компания
Это партнерская компания. Что-то я им подкидываю, что-то они мне. Так и живем 🙂
(4) Хорошие ребята, читаю их блог! 🙂
хорошая и нужная разработка, спасибо, что есть ещё умные люди
(6) TrinitronOTV,
Спасибо 🙂
Отличная публикация.
(8) ms200999,
Спасибо
А я на нынешней работе даже как-то скучаю по астериску, и поюзать эту штуку нет возможности. А вообще порой было прикольно отвлекаться от повседневных задач и писать какую-нибудь самому интересную хрень …
Это пройдет 🙂
Со временем, «написать интересную хрень» плавно перетекает в «написать полезную хрень».
А если вдруг «интересная хрень» = «полезная хрень», тогда толстый профит 🙂
(11) Абсолютно солидарен 🙂
Скажите а есть обработка какая ни будь чтобы при входящем звонке в 1с поднималась накладная?
(15) softest,
Конечно.
Посмотрите публикацию