Служба контекста – это гибкое и защищенное хранилище данных в облаке, которое обеспечивает взаимодействие с клиентом по различным каналам мультимедиа. К каналам мультимедиа относятся голосовая связь, электронная почта, чат, мобильная и веб-связь. Информация из разных каналов мультимедиа часто существует в нескольких приложениях, при этом отсутствует эффективный способ объединения этих данных. Служба контекста позволяет лучше понять разрозненные данные путем создания карты взаимодействия с клиентами. С помощью службы контекста операторы могут отслеживать взаимодействия с клиентами и незамедлительно предоставлять необходимую помощь, что повышает качество обслуживания клиентов и улучшает условия работы операторов. Служба контекста обеспечивает для клиентов Контакт-центр Cisco безупречное многоканальное взаимодействие благодаря настроенной интеграции с продуктами Служба поддержки клиентов Cisco и API для сторонних интеграций.


Объекты службы контекста

  • Данные о клиенте: описывает, кем является определенный клиент. Например, сюда относятся имя, адрес и номер телефона. С помощью типа объекта клиента можно связать персональные данные (PII) с идентификатором клиента.

  • Данные об активности: описание конкретного взаимодействия с клиентом. Активность также называют POD. Каждая активность отражает один этап в процессе взаимодействия с клиентом, который стремится удовлетворить запрос. Например, активность происходит, когда клиент взаимодействует с вашей организацией, выполняя одно из указанных ниже действий.

    • Просмотр веб-сайта вашей организации.

    • Отправка сообщения электронной почты в вашу организацию.

    • Звонок в вашу организацию и использование меню IVR.

    • Чат с оператором.

    Вы можете связать активность с клиентом или запросом.

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

    Клиент переходит в онлайн-режим для оплаты кредитной картой. Клиент сталкивается с проблемой при оплате онлайн и звонит по телефону. Попытка совершить платеж онлайн и телефонный вызов – это две отдельных активности. Эти две активности относятся к одному и тому же запросу – оплате кредитной картой.

    Необходимо связать каждый запрос с клиентом.

  • Подробные данные: дополнительная информация о типе другого объекта. Например:

    • Заметки, сделанные оператором во время активности.

    • Обратная связь от клиента об активности.

    Необходимо связать каждый элемент данных с запросом или активностью.


Поля и наборы полей службы контекста

С помощью полей можно определить структуру данных контекста, которые хранятся в объектах службы контекста. Наборы полей – это логические группирования полей на основании бизнес-потребностей. Например, можно создать набор полей корзины для покупок, состоящий из четырех полей.

  • Элементы в корзине.

  • Элементы в списке пожеланий.

  • Общая цена.

  • Приблизительная стоимость доставки.

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

  • Используйте базовые поля и наборы полей Cisco или создавайте пользовательские поля и наборы полей.

  • Добавьте поле в несколько наборов полей.

  • Свяжите несколько наборов полей с одним объектом службы контекста.

  • Свяжите базовые наборы полей Cisco и пользовательские наборы полей с одним и тем же объектом службы контекста.

  • Добавляйте или удаляйте поля в наборе полей, не изменяя объекты, связанные с этим набором полей.


Каждому объекту службы контекста должен быть назначен по крайней мере один набор полей.

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

Тип поля

Активность, связанная с входящими вызовами

Активность, связанная с совершением покупок в мобильных приложениях

Базовые поля Cisco

  • Context_Notes

  • Context_POD_Activity_Link

Пользовательские поля

  • Выбрано меню IVR

  • Вызывающий абонент аутентифицирован

  • Информация о просмотре

  • Элементы корзины

Для каждого отдельного объекта данных службы контекста установлено ограничение 256 КБ.

Табл. 1. Свойства объектов службы контекста

Свойство объекта

Клиент

Запрос

Активность

Подробности

id: уникальный идентификатор объекта.

parentId: уникальный идентификатор, представляющий родительский объект контекста.

н/д

н/д

✓ Необязательное свойство, связывающее активность с запросом.

✓ Обязательное свойство, связывающее сведения с запросом или активностью.

customerId: уникальный идентификатор, представляющий клиента.

н/д

✓ Обязательное свойство, связывающее запрос с клиентом.

✓ Необязательное свойство, связывающее активность с клиентом.

н/д

created: метка времени создания объекта.

lastUpdated: метка времени последнего изменения объекта.

state: указывает, является ли объект активным или закрытым. Дополнительную информацию см. в разделе Состояние объекта в руководстве SDK службы контекста.

contributors: учетные записи пользователей или компьютеров, которые создали или обновили объект.

mediaType: указывает тип мультимедиа для активности. Существует восемь возможных типов мультимедиа.

  • Голосовая почта

  • Видео

  • Чат;

  • Email

  • Мобильное устройство

  • Общественные

  • Интернет

  • Event

н/д

н/д

н/д

fieldsets: наборы полей, назначенные объекту. Объект должен иметь по крайней мере один назначенный набор полей. Наборы полей определяют, какие поля применяются к объекту.

tags: список тегов для активности.

н/д

н/д

н/д

Значения свойств объекта id, created, lastUpdated, contributors и state автоматически заполняются при создании объекта.

Полный список базовых полей Cisco и информацию о создании пользовательских полей см. в разделе "Поля и наборы полей" руководства SDK службы контекста.


Какие данные должны храниться в объектах службы контекста?

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

  • Какие данные необходимы для решения задач в конкретном сценарии использования?

  • Где хранится нужная вам информация в данный момент?

  • Кому необходим доступ к информации для решения задач в конкретном сценарии использования?

Изучите цикл взаимодействия с клиентом. Это не только поможет ответить на эти вопросы, но также определить наилучший способ объединения разрозненных элементов информации. Например, сначала клиент выполняет некоторые действия онлайн на веб-сайте, а затем звонит по телефону. Известно ли о предыдущем посещении веб-сайта IVR или оператору? Может ли IVR идентифицировать повторно звонящего абонента и предложить различные варианты? Используйте эти наблюдения, чтобы идентифицировать разрозненные данные приложения или организации во взаимодействии с пользователем. Определите пробелы в информации и создайте модель данных службы контекста для построения навигационных цепочек и заполнения пробелов. Например, онлайн-организация розничной торговли хочет узнать, есть ли клиенты, которые добавили товары в корзину, но не купили их. Эта организация также хочет предложить альтернативные решения на основе продукта, который ищет клиент. Для объекта (в данном случае для активности) должно быть предусмотрено два поля. В одном записаны товары в корзине клиента, а в другом перечислены все просмотренные продукты. Проектирование модели данных также является динамическим, т. е. в любое время можно добавить новые наборы полей. Через несколько месяцев онлайн-организация розничной торговли решает, что оценка по результатам опроса приносит пользу. В этом случае можно добавить в проект поле оценки по результатам опроса, не затрагивая существующие данные контекста.

Модель конфиденциальности данных службы контекста

Каждое поле определяется типом данных и классификацией по безопасности.

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

  • Персональные данные (PII): информация, связанная с конкретным пользователем, обратившимся в Support Center. PII хранится и передается в зашифрованном формате, при этом для доступа к данным требуется ключ. При использовании шифрования конечных точек PII можно расшифровать только на стороне клиента.

  • Шифрование без PII: информация, которая не связана с конкретным пользователем, но считается конфиденциальной. Зашифрованные данные хранятся и передаются в зашифрованном формате. Данные зашифрованы в конечной точке, их можно расшифровать только на стороне клиента.

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

Например, имя, адрес электронной почты и номер телефона являются персональными данными. Таким образом, данные этих типов, содержащиеся в полях по умолчанию, классифицируются как персональные данные и шифруются в конечной точке. Баланс на дисконтной карте не относится к персональным данным. Эти данные можно хранить в незашифрованном виде. К полям типа "Шифрование без PII" относится, например, поле "Контекстный заголовок", содержащее заголовок активности.


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

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