Создание колл-центра на базе Salesforce с помощью Twilio TaskRouter

ThinkVoice предоставляет бизнесу инструменты для создания исключительных впечатлений от взаимодействия с клиентами. Генеральный директор ThinkVoice Брайан Койл знает, что даже такая простая и мощная вещь, как звонок телефона, может быть трудной для реализации в крупном масштабе. Именно здесь на помощь приходит ThinkVoice. Чтобы гарантировать, что они предоставляют своим клиентам надежные и масштабируемые решения для связи, ThinkVoice использует Twilio.

После запуска Twilio TaskRouter ThinkVoice добавил в свой арсенал новый инструмент, который позволяет им управлять традиционно трудными аспектами данных колл-центра, такими как состояние агента, информация о очереди и многое другое.

В следующей статье Брайан Койл показывает, как создать колл-центр на базе Salesforce с помощью Twilio TaskRouter.

Это руководство для начинающих по созданию колл-центра с поддержкой нескольких каналов непосредственно в вашей CRM-системе Salesforce, используя Salesforce Open CTI, Twilio TaskRouter и Twilio Client. Исходный код решения доступен здесь. Урок предназначен для разработчиков, которые хотят создать колл-центр внутри Salesforce или просто хотят узнать больше о TaskRouter. Если вы просто хотите посмотреть готовый продукт, вы можете развернуть его на Heroku сразу же.

Если вы хотите добавить телефонные звонки в свою CRM-систему Salesforce, вы, в лучшем случае, интегрируете отдельный облачный продукт колл-центра с предварительно созданными соединителями или, в худшем случае, интегрируете локальную устаревшую систему PBX через несколько слоев интеграции. В любом случае вы управляете своим колл-центром через несколько систем, что оставляет вам головную боль, которая чрезвычайно дорога и склонна к ошибкам. Следующая статья направлена на решение этой проблемы, уменьшая зависимость от сторонних решений и оставляя как можно больше конфигураций в Salesforce.

**Омниканальность**

Демонстрация показывает возможность обработки нескольких каналов связи с помощью Twilio TaskRouter для управления единой очередью сообщений, поступающих из разных каналов. Это была настоящая проблема, поскольку решения для конкретных задач могут обрабатывать только один или два канала связи, и немногие поддерживают SMS в качестве канала.

**Краткий обзор используемых технологий**

Урок основан на фантастическом демонстрационном примере встраиваемого автоматического распределителя вызовов Salesforce с помощью Twilio Client Чарльза Оппенгеймера из Twilio. Большое спасибо Чарльзу за то, что он поделился этим демонстрационным примером. Мы просто взяли этот демонстрационный пример и вставили TaskRouter для обработки распределения вызовов и добавления текстовых сообщений.

Salesforce Open CTI — это открытый API, который позволяет сторонним производителям CTI подключать каналы телефонной связи к интерфейсу CRM-системы Salesforce. В нашем демонстрационном примере мы используем Open CTI для размещения нашего программного телефона и управления функциональностью «нажать, чтобы позвонить/отправить текст». Демонстрационный пример не требует плагинов или установленного программного обеспечения благодаря конструкции Open CTI. Для получения дополнительной информации см. руководство разработчика.

**Salesforce Open CTI**

Twilio Client — это интерфейс WebRTC для Twilio. В нашем демонстрационном примере мы используем библиотеку JavaScript, которая дает нам API и соединение с Twilio для получения вызова внутри нашего браузера Salesforce, доставляя вызов через WebRTC. Twilio Client также дает нам возможность контролировать вызов через наш программный телефон.

**Twilio Client**

**Twilio TaskRouter**

TaskRouter — это очередь и машина состояний, к которой наши пользователи Salesforce подключаются через программный телефон Open CTI. Мы направляем все наши вызовы и текстовые сообщения через TaskRouter, который управляет очередью этих сообщений. TaskRouter также отслеживает состояние наших пользователей Salesforce, отправляя им вызовы и текстовые сообщения, когда они становятся доступными. То, что отличает TaskRouter от традиционных облачных или локальных телефонных систем, заключается в том, что он полностью управляется через API, поэтому мы можем размещать все административные функции внутри Salesforce.

Сначала я настоятельно рекомендую ознакомиться с исходным проектом client-acd от Чарльза, поскольку он охватывает все основные настройки, включая настройку Twilio. Наш файл README описывает дополнительные шаги настройки необходимых компонентов TaskRouter. На высоком уровне мы заменили любой код, который управлял состоянием агента или очередью вызовов, на код TaskRouter, включая удаление всех кодов MongoDB. Обратите внимание на версию twilio-gem. Функции TaskRouter доступны после 3.15. Остальная часть статьи будет посвящена реализации TaskRouter.

**Маршрутизация вызовов с TaskRouter**

Давайте начнем с маршрутизации входящих вызовов в TaskRouter. В нашем приложении Sinatra мы собираемся изменить действие /voice, чтобы отправить вызов в наш рабочий процесс через Twiml. Это сразу же направит наш входящий вызов в очередь, которая теперь управляется TaskRouter и нашим рабочим процессом. Теперь у нас есть вызов в очереди, ожидающий агента. Очень просто!

Давайте теперь подключим состояние агента.

Благодаря работе, проделанной в исходном проекте, было очень легко подключить агента к TaskRouter. Когда программный телефон загружается внутри браузера Salesforce, код softphone.js уже извлекал идентификатор агента из API Salesforce и регистрировался как клиент Twilio. Как только у нас есть клиент Twilio, мы затем регистрируем агента в TaskRouter. Как и при регистрации клиента Twilio, нам нужно получить токен от сервера с правильными разрешениями. В нашем коде мы передаем идентификатор пользователя Salesforce в вызов AJAX, чтобы мы могли использовать его для сопоставления с правильным рабочим, определенным в TaskRouter.

На сервере мы используем REST API Twilio для создания клиента TaskRouter. С помощью REST API мы можем перебрать всех рабочих, определенных для нашего рабочего пространства, найти рабочего, соответствующего нашему агенту Salesforce, и сгенерировать токен для этого рабочего. Мы возвращаем этот токен на сторону клиента, где наша функция JavaScript создает рабочего через библиотеку worker.js.

Worker.js — это библиотека JavaScript SDK, которая дает нам возможность получать работу из очереди и управлять состоянием агента. В этом примере мы регистрируемся на обратный вызов activity.update, который сообщит нашему клиенту, когда состояние агента изменится, и когда это произойдет, мы обновляем пользовательский интерфейс. Worker.js также позволяет нам получить список действий или состояний, которые может иметь агент. Каждое действие (или состояние) либо доступно, либо недоступно, то есть может принимать работу или нет. В этом демонстрационном примере мы предполагаем, что одно действие доступно, и мы сохраним идентификатор одного доступного действия и одного недоступного действия. Мы используем эти идентификаторы для установки состояния агента позже.

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

Когда мы настроили обработку входящих вызовов в client-acd.rb /voice, мы просто перенаправили вызов в рабочий процесс TaskRouter с помощью Twiml. Поскольку мы сделали это, есть немного магии, встроенной в TaskRouter, которую мы можем использовать. Сначала давайте поймем, как работают маршруты TaskRouter. Вызов поступил в Twilio и был направлен в рабочий процесс. Рабочий процесс знает о рабочих (агентах), которые имеют атрибуты, которые рабочий процесс может использовать для определения того, кто должен принять эту работу. В этом демонстрационном примере рабочий процесс действует как простая очередь, зная, кто был бездействующим в течение самого долгого времени. Когда мы входим в систему Salesforce и нажимаем кнопку «Готов», worker.js сообщает TaskRouter, что наш рабочий/агент доступен. TaskRouter назначает действие (в данном случае вызов) агенту. Рабочий процесс настроен на отправку этого назначения в наше приложение Sinatra по адресу /assignment. Когда приложение получает этот POST, мы просто говорим TaskRouter, чтобы он вывел вызов из очереди в идентификатор клиента Twilio агента, который настроен как атрибут рабочего {«contact_uri»: «client:salesforce_login_id»}… магия!

TaskRouter действительно упростил наш код, поскольку мы не нуждаемся в управлении состоянием агента. Мы все еще поддерживаем соединение веб-сокета и опрос для отправки статистики в режиме реального времени в наш программный телефон, давая нашему агенту количество зарегистрированных агентов и количество элементов в очереди. Мы используем REST API TaskRouter, чтобы получить эту информацию.

В следующей части этого демонстрационного примера мы добавим маршрутизацию текстовых сообщений в наш колл-центр Salesforce. Оставайтесь с нами.