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…
