Идентификация пользователей в чатах

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

Многие компании предоставляют поддержку клиентам через соцсети и мессенджеры. При этом практически все соцсети и мессенджеры не передают данных, по которым можно идентифицировать пользователя. Это создает трудности, ведь нередко потенциальным, новым или VIP-клиентам поддержка оказывается на разных условиях. Более того, иногда без данных по аккаунту в принципе сложно ответить на вопрос клиента.

Идентификация пользователей в чатах — достаточно сложная задача, так как у простых способов есть свои недостатки:

  • если запрашивать у пользователя его данные (например email-адрес или номер телефона), пользователь может прислать как чужие данные, так и общий ящик или телефон компании вместо персонального;

  • если пытаться выполнить идентификацию через другой канал (например, отправлять код в письме на email-адрес или в SMS-сообщении на номер телефона), то не избежать проблем с доставкой таких сообщений из-за политики спама у почтового сервиса или ограничений по сетям и зонам доставки у SMS-провайдеров.

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

Именно это и позволяют сделать:

  • новый тип виджета и новый API-метод, которые генерируют код, связанный с конкретным пользователем;

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

Рассмотрим подробнее новые возможности:

1. Виджет «Идентификация пользователя»

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

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

Рассмотрим подробнее процесс создания виджета и его настройки.

В Омнидеске есть разные типы виджетов, которые создаются по пути: аккаунт администратора → раздел «Каналы» → подраздел «Виджеты». Теперь там же появился еще один тип виджета — «Идентификация пользователя».

У виджета нет дополнительных настроек, только возможность выбрать язык и перевести используемые фразы на все языки, добавленные в настройках локализации в вашем аккаунте.

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

Когда пользователь находится в личном кабинете на вашем сервисе, вам нужно передавать его данные в скрипт виджета в соответствующие поля. Это может быть email-адрес, номер телефона, какой-то ваш кастомный идентификатор пользователя (в таком случае нужно также передавать и идентификатор кастомного канала в Омнидеске) и любые другие данные пользователя в Омнидеске. Например:

<!-- Start of Omnidesk Widget script {literal}—> 
<script> 
window.OmniIndetify = { 
    // Email-адрес текущего пользователя. 
    user_email: 'user@domain.com',
    // Или номер телефона текущего пользователя. 
    user_phone: '+79221110500', 
    // Или ваш кастомный идентификатор пользователя и идентификатор канала в Омнидеске. 
    custom_user_id: 'YOUR_USER_ID_HERE', 
    channel: 'cch000', 
    // И данные для любых полей в данных пользователя в Омнидеске. 
    "cf_7264" : "some data", 
    "cf_7638" : 1, 
    "cf_23" : true 
}; 
!function(e,o){!window.omni?window.omni=[]:'';window.omni.push(o);o.g_config={widget_id:"00000-00000000"}; o.type_widget = "identifier";var r=e.getElementsByTagName("script")[0];c=e.createElement("script");c.type="text/javascript",c.async=!0;c.src="https://omnidesk.ru/bundles/acmesite/js/cwidget0.2.min.js";r.parentNode.insertBefore(c,r)}(document,[]); </script> 
<!-- End of Omnidesk Widget script {/literal}-->

Чтобы виджет открывался по клику на нужный вам элемент, просто добавьте ему атрибут class="omni-identifier-widget":

// Кнопка, по клику на которую будет открываться виджет 
<button class="omni-identifier-widget">Подтверждение аккаунта</button> 
// Ссылка, по клику на которую будет открываться виджет 
<a class="omni-identifier-widget" href="">Сгенерируйте</a> код и отправьте в чат, чтобы пройти проверку.

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

2. Получение кода идентификации через API

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

В параметрах API-запроса тоже можно передавать все нужные данные о пользователе, а в ответ получать код идентификации, который, как и в виджете, действителен только в течение 5 минут.

3. Условия в правилах для автоматизации процесса идентификации

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

Сначала рассмотрим новые условия в правилах, а потом — примеры таких правил.

Какие условия добавились:

  • во всех типах правил: «Пользователь — идентифицирован / не идентифицирован» — это условие проверяет, если профиль пользователя из конкретной соцсети или мессенджера успешно прошёл идентификацию;

  • во всех типах правил: «Пользователь создан — после/до» — это условие поможет, если вы захотите настроить идентификацию только для новых пользователей, а с уже существующими продолжить работать как раньше;

  • в правилах для изменённых: «Код идентификации — не был отправлен / некорректный / корректный» — это условие поможет настроить правила для проверки сообщений пользователя с кодом.

Примеры правил для идентификации пользователей

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

Блок-схема этого сценария:

Рассмотрим необходимые настройки. Понадобится создать кастомное поле со списком тарифов и правила — для входящих и измененных обращений, учитывающие все возможные сценарии, а именно:

  • правило для входящих для отправки запроса кода идентификации

  • правило для входящих для пользователей с тарифом «Стандартный»

  • правило для входящих для пользователей с тарифом «VIP»

  • правило для входящих для пользователей без аккаунта

  • правило для изменённых, когда пользователь не прислал код идентификации

  • правило для изменённых, когда пользователь прислал некорректный код идентификации

  • правило для изменённых, когда пользователь с тарифом «Стандартный» прислал корректный код идентификации

  • правило для изменённых, когда пользователь с тарифом «VIP» прислал корректный код идентификации

  • правило для изменённых, когда пользователь ответил, что у него нет аккаунта

  • правило для изменённых, когда пользователь, у которого не было аккаунта, получил аккаунт и хочет пройти идентификацию

Шаг 1: Создать кастомное поле с принадлежностью «поле пользователя» типа «выпадающий список» с вариантами тарифов и опцией «нет аккаунта». Активировать это поле можно в формах «Данные пользователя» и «Страница пользователя» Подробнее о создании дополнительных полей.

Шаг 2: Создать правила для входящих обращений для каждого варианта в выпадающем списке — в нашем случае это пустое поле, «Стандартный», «VIP», «Нет аккаунта».

а. Правило для входящих обращений, которое будет срабатывать в чатах от неидентифицированных пользователей при пустом поле «Тариф». Оно будет отправлять в чат автоответ с запросом кода и завершать чат в статусе «в ожидании», чтобы сотрудники не отвлекались на него.

Если хотите, чтобы идентификацию проходили только новые пользователи, добавьте в блоке «ВСЕ заданные условия» дополнительное условие «Пользователь создан — после — [дата]».

б. Также понадобятся три отдельных правила для входящих обращений, когда поле «Тариф» не пустое:

— правило для тарифа «Стандартный:

— правило для тарифа «VIP»:

— правило для пользователя без аккаунта:

На этом все правила для входящих обращений, то есть для новых чатов, готовы.

Шаг 3: Создать правила для измененных обращений, которые будут проверять новые ответы пользователей в чатах.

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

г. Создадим правило для измененных обращений, если пользователь прислал сообщение с кодом идентификации, то есть текст совпадает по формату с кодом, но код некорректный. Например, уже прошло более 5 минут с момента его формирования, и код стал недействительным.

д. На случай когда пользователь прислал корректный код, нужны два правила для измененных обращений, чтобы учесть оба тарифа:

— правило для тарифа «Стандартный»:

— правило для тарифа «VIP»:

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

ж. Осталось создать правило для измененных обращений для ситуации, когда пользователь изначально выбрал вариант «без аккаунта», но затем зарегистрировался и хочет пройти идентификацию. Для такого случая в автоответах предыдущих правил пользователю предлагалось прислать цифру «5» или слово «начать».

На этом все правила для автоматической идентификации готовы.

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

Примеры правил для общих сценариев можно найти в нашей базе знаний. Логику правил автоматизации мы подробно разбираем в видеоруководствах по правилам и чатам, которые можно найти тут.

4. Обновление данных пользователей в Омнидеске

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

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