Кастомные каналы связи

Последние изменения: 05.04.2024

Если вы общаетесь с клиентами через нестандартные каналы, которых по умолчанию нет в Омнидеске, эта функциональность позволит добавить их в сервис.

Суть функциональности

В стандартных каналах пользователи определяются по базовым данным (email-адрес, номер телефона, ID в Телеграме и т.д.). Эти данные используются и для отправки ответов сотрудников.

Однако в случае с кастомными каналами в качестве идентификатора пользователя может выступать что угодно (логин у вас в системе, порядковый номер, рандомный набор символов, номер телефона), и эти данные мы получаем от вас. Когда же сотрудник пишет ответ, мы отправляем его на URL, который указан в настройках, чтобы вы могли отобразить этот ответ там, где нужно.

Причём общение по кастомным каналам может осуществляться как по аналогии с почтой, так и в режиме реального времени по типу чатов.

Примеры использования

1. У вас мобильное приложение, из которого клиенты могут напрямую общаться с поддержкой.

Допустим вы реализовали регистрацию в приложении через соц. сети. В этом случае у вас есть ID пользователя от соц. сети. Соответственно, когда пользователь напишет из приложения в поддержку, вы не сможете создать через API обращение по одному из стандартных каналов, ведь для этого у вас должен быть email-адрес или телефон.

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

2. В личном кабинете клиента на вашем сервисе есть раздел «Поддержка», где клиенты могут создавать обращения, видеть предыдущие обращения и получать ответы сотрудников.

Идентификатом клиента в этом случае выступает его логин, а не email-адрес, который можно изменить в настройках.

Вы хотите сделать так, чтобы ответы сотрудников отправлялись только в личный кабинет и не дублировались на почту. Кастомный канал, в отличие от стандартного канала «Email», отлично подойдёт для решения этой задачи.

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

Проблема в том, что таким чатом приходится пользоваться отдельно от всех остальных каналов. Кастомный канал позволит подключить его к Омнидеску, чтобы сотрудники работали в одном интерфейсе.

4. В вашей отрасли есть популярный форум, на котором клиенты очень часто задают вам вопросы и просят помощи.

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

Договоритесь с владельцами форума, чтобы они передавали вам сообщения, отправляемые в ваши топики, и принимали ответы сотрудников через API-запросы. Кастомный канал сделает всё остальное.

Настройка и возможности

1. Добавить кастомный канал можно по пути: аккаунт администратора — раздел «Каналы» — подраздел «Кастомные каналы». При создании есть несколько полей:

ef5362f2d9081c0f749351c00cb48917.png

Webhook URL — адрес, на который мы отправляем все ответы сотрудников.

Тип канала позволяет выбрать, каким образом работает канал: по типу почты (асинхронный) или в режиме реального времени (синхронный).

2. При создании канала мы добавляем его в правила, статистику, права доступа сотрудников и интерфейс аккаунта сотрудника. Поэтому обязательно предоставьте нужным сотрудникам доступ к созданному каналу: аккаунт администратора — раздел «Команда» — подраздел «Сотрудники» — редактирование данных сотрудника. 

3. В API есть раздел «Кастомные каналы» для получения списка кастомных каналов с их параметрами.

4. В API есть возможность создавать обращения по кастомным каналам. Для этого используется стандартный метод вместе с параметрами user_custom_id и channel.

При создании обращения по кастомному каналу в ответе будет указан user_id, который вам нужно сохранить на своей стороне (связать с user_custom_id), чтобы после использовать для других API запросов.

Если передаются и другие данные пользователя (имя, компания и т.д.) их мы тоже фиксируем.

При передаче email-адреса и/или телефона, мы сразу делаем связку профилей, если email/телефон ещё не связаны с другим ID этого же кастомного канала. Подобная связка позволит вам видеть историю переписки с этим пользователем по другим каналам.

5. Ответы сотрудников, отправляемые на указанный вами Webhook URL, имеют следующую структуру:

26.04.18, 20:17:10
POST:Array
(
    [type] => message_new
    [object] => Array
        (
            [message_id] => 42535907
            [case_id] => 21755012
            [staff_id] => 7234
            [user_id] => 20023294
            [custom_user_id] => my_u_id123456
            [content] => Ok!
            [note] => 0
            [sent_via_rule] => 0
            [created_at] => Thu, 26 Apr 2018 20:17:10 +0300
        )
)

Для смайлов мы используем Unicode CLDR Short Name, как и многие другие сервисы.

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

Мы отправляем данные не только при ответах сотрудников, но и в случаях, когда в обращении появляется сообщение, отправленное через правило (sent_via_rule = 1).

Если вы добавили ответ сотрудника через API, то он тоже будет отправлен на указанный вами Webhook URL. При необходимости игнорировать такие ответы сотрудников, ориентируйтесь на параметр b_from_api = 1.

6. Для добавления ответа от лица пользователя используется стандартный метод, а в качестве user_id указывается ID, полученный от нас при создании первого обращения пользователя и в вебхуке с ответом сотрудника. Перед добавлением ответа в синхронном канале нужно получить последний чат с пользователем, так как переписка всегда ведётся только в последнем чате, и проверить его статус:

а) если чат в статусе «закрытое», нужно создавать новое обращение;

б) если «открытое» или «в ожидании», добавлять сообщение в тот же чат;

в) если нового чата, ID которого сохранён на вашей стороне, уже нет, значит, сотрудник объединил его с предыдущим, и вам нужно добавлять ответ именно в предыдущий чат (последний на данный момент).

Получить список чатов можно через метод списка обращений с передачей параметров user_id и show_active_chats = true.

Помогла ли вам статья?