Контекстен модел на данни за услуги, полета и Fieldsets

Context Service е гъвкаво и сигурно хранилище на данни в облака, което свързва пътешествието на клиента по различни медийни канали. Тези медийни канали включват глас, имейл, чат, мобилен и уеб. Информация от различни медийни канали често съществува в множество приложения без ефективен начин да я съберете заедно. Context Service ви дава възможност да разбирате по-добре разнородните данни, като създавате карта на взаимодействията на клиентите. Context Service помага на вашите агенти да следват пътешествието на клиента и да предоставят съответна и незабавна помощ, повишавайки както клиента, така и опита на агента. Context Service дава възможност на клиентите на Контактния център на Cisco да доставят безпроблемно преживяване на омничанела чрез интеграция извън кутията с продукти на Cisco Customer Care и с API за интеграция на трети страни.


Обекти на контекстно обслужване

Context Service използва четири типа обекти за съхраняване на контекстни данни:

  • Данни за клиенти—Описва кой е конкретен клиент. Това например включва информация като име, адрес и телефонен номер. Типът на обекта на клиента предоставя начин за свързване на лично идентифицираща се информация (PII) с идентификационен номер на клиент.

  • Данни за дейността— Описва конкретно взаимодействие с клиента. Дейностите са известни и като PoDs. Всяка дейност отразява една стъпка в пътешествието на клиента, тъй като клиентът се стреми да изпълни заявка. Например дейност възниква, когато клиент взаимодейства с вашата организация, като:

    • Преглеждане на уебсайта на вашата организация.

    • Имейл на вашата организация.

    • Извикване на вашата организация и използване на IVR меню.

    • В чата с агент.

    Можете да свързвате дейности с клиент или заявка.

  • Данни за заявка—Описва какво иска клиентът. Заявките се използват и за групиране на дейности заедно, които са свързани с конкретен проблем с клиента. Например:

    Клиент преминава онлайн, за да извърши плащане с кредитна карта. Клиентът се натъква на проблем, извършващ плащането онлайн, и вместо това се обажда по телефона. Опитът за извършване на плащането онлайн и осъществяване на телефонен разговор са две отделни дейности. Тези две дейности принадлежат към една и съща заявка, като извършват плащане с кредитна карта.

    Трябва да свържете всяка заявка с клиент.

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

    • Бележки, направени от агент по време на дейност.

    • Обратна връзка от клиента за дадена дейност.

    Трябва да свържете всеки детайл със заявка или дейност.


Контекстни полета за услуги и Fieldsets

Полетата ви позволяват да дефинирате структурата на контекстните данни, които се съхраняват в обекти на Context Service. Fieldsets са логично групиране на полета въз основа на вашите бизнес нужди. Можете например да създадете полеви набор кошница за пазаруване с четири полета:

  • Артикули в количката.

  • Елементи в списък с желания.

  • Обща цена.

  • Прогнозни разходи за доставка.

Можете да полетата на Context Service и наборите полета, за да създадете гъвкав модел данни. Можете:

  • Използвайте базовите полета и набори полета cisco или създайте свои собствени персонализирани полета и набори полета.

  • Добавяне на поле към няколко набора полета.

  • Свързване на няколко набори полета с един обект на Context Service.

  • Свържете базовите набори полета cisco и вашите собствени потребителски набори полета със същия обект на Context Service.

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

  

Всеки обект на Context Service трябва да има поне един набор полета, присвоени на него.

Бихте могли например да използвате различни полета за дейност за входящи повиквания и дейност за пазаруване на Мобилни приложения:

Тип поле

Дейност за входящи повиквания

Дейност за Пазаруване на мобилни приложения

Базови полета на Cisco

  • Context_Бележки

  • Context_POD_Activity_връзка

 

Потребителски полета

  • Избрано iVR меню

  • Повикващият удостоверен

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

  • Артикули от количката

Всеки отделен обект с данни на Context Service е ограничен до 256 KB.

Свойства на обект на контекстна услуга

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

Дейност

Искане

Клиент

Подробности

id: Еднозначен идентификатор на обект.

parentId: Еднозначен идентификатор, представляващ родителски контекстен обект.

✓ Незадължително свойство, което свързва дейността със заявка.

Няма

Няма

✓ Задължително свойство, което свързва детайла или с заявка, или с дейност.

customerId: Еднозначен идентификатор, представляващ клиент.

✓ Незадължително свойство, което свързва дейността с клиент.

✓ Задължително свойство, което свързва заявката с клиент.

Няма

Няма

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

последноПоддържан: Времеви печат на кога обектът е бил променен за последен път.

състояние: Показва, ако обектът е активен или затворен. За повече информация вижте обект състояние в контекстната услуга SDK ръководство.

сътрудници: Акаунти на потребители или машини, които са създали или актуализирали обект.

медияТип: Показва вида на носителя в активността. Има осем възможни типа медии:

  • Глас

  • Видео

  • Чат

  • Имейл

  • Мобилен

  • Социални

  • Интернет

  • Събитие

Няма

Няма

Няма

набори полета: Наборите полета, присвоени на обекта. Обектът трябва да има присвоен поне един набор полета. Fieldsets определят кои полета се отнасят за обекта.

Тагове: Списък на маркерите за дейността.

Няма

Няма

Няма

ИД на свойствата на обекта , създаден , lastUpdated, сътрудници и състояние се попълват автоматично, когато създавате обект.

За пълен списък на базовите полета на Cisco и информация за създаване на персонализирани полета вижте Полета и Fieldsets в Ръководството за SDK на context Service.


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

Context Service предоставя начин за вас да събирате силозена информация и създава галета, които ви позволяват да следвате пътешествие на клиента. Можете да проектирате данните, съхранявани в обектите на Context Service въз основа на вашите бизнес изисквания и работни потоци. Преди да решите какви данни да съхранявате, помислете за тези въпроси:

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

  • Къде се съхранява информацията, от която се нуждаете в момента?

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

Разгледайте пътуването, което следва вашият клиент. Това помага не само да се отговори на тези въпроси, но и да се намери най-добрият начин за обединяване на разнородните парчета информация заедно. Например клиентът започва онлайн на уеб сайт и проследява телефонно обаждане. Вашият IVR или агент знае ли за предишното посещение на уебсайта? Може ли вашият IVR да идентифицира повторен повикващия и да предложи различни опции? Използвайте тези наблюдения, за да идентифицирате приложение силози или организационни силози в потребителското пътуване. Идентифицирайте пропуските в информацията и изградете модел за данни на Context Service, за да предоставите галетата, необходими за запълване на празнините. Например онлайн организация на дребно, която иска да види дали клиентите са добавили артикули в количката си и не са ги купили. Организацията също така иска да предложи алтернативни предложения въз основа на продукта, които клиентите търсят. Обектът, дейност тук, трябва да има две полета. Такъв, който записва артикулите в кошницата на клиента и такъв, който изброява всички продукти, сърфирани. Дизайнът на модела на данни също е динамичен, т.е. можете да изберете да добавяте нови набори полета по всяко време. Онлайн организацията на дребно решава след няколко месеца, това проучване резултат информация добавя стойност. След това те могат да добавят поле за оценка на проучването към дизайна, без да оказват влияние върху съществуващите данни от Context.

Модел на конфиденциалност на данни за контекстни услуги

Всяко поле се определя от тип данни и класификация на защитата.

Context Service предоставя криптиране на крайна точка, така че чувствителните данни да не се съхраняват или транспортират в обикновен текст. Когато дефинирате поле, задавате как полето класифицира данните. Можете да класифицирате данните като:

  • Лично разграничима информация (PII)— Информация, свързана с физическо лице, което се свързва с вашия център за поддръжка. PII се съхранява и транспортира в шифрован формат и изисква ключ за достъп до данните. С криптиране на крайна точка PII може да се дешифрира само при клиента.

  • Не-PII шифровани—Информация, която не е свързана с физическо лице, но се счита за поверителна. Шифрованите данни се съхраняват и транспортират в шифрован формат. Шифровани в крайна точка, тези данни могат да бъдат дешифрирани само при клиента.

  • Нешифрована—Информация, която не е PII и не е поверителна. Нешифрованите данни се съхраняват като обикновен текст, но се транспортират по шифрован слой (HTTPS).

Например името, имейлът и телефонният номер са лично разпознаваеми. Затова полетата по подразбиране, които държат тези видове данни, класифицирани като PII, и са крайна точка шифровани. Салдата на картите с награди може да не са PII. Можете да ги съхранявате като Нешифровани. Полетата, които не са piI шифровани, може да са полета като "Контекстно заглавие", заглавието на дадена дейност.

  

Context Service не ви пречи да въвеждате PII или поверителна информация в нешифровани полета. Гарантирайте, че вашите данни се съхраняват в съответното поле с правилната класификация.

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

Беше ли полезна тази статия?