コンテキスト サービスは、クラウド内の柔軟で安全なデータ ストアであり、さまざまなメディア チャネルにわたる顧客のジャーニーをつなぎます。 これらのメディア チャネルには、音声、メール、チャット、モバイル、および Web が含まれます。 異なるメディア チャネルからの情報は、それをまとめる効果的な方法がなくても複数のアプリケーションにわたって存在することがよくあります。 コンテキスト サービスを使用すると、顧客とのやり取りのマップを作成して、さまざまなデータをより深く理解できます。 コンテキスト サービスは、お客様のエージェントが顧客のジャーニーをたどり、適切かつ即時のアシスタンスを提供するのを促し、顧客とエージェントの両方のエクスペリエンスを向上させます。 コンテキスト サービスCloud Contact Centerを使用すると、顧客は製品との統合、およびサードパーティとの統合のための API を使用してCisco カスタマー ケア 、シームレスなオムニチャネルエクスペリエンスを提供できます。


コンテキスト サービス オブジェクト

  • 顧客データ—特定の顧客が誰であるかを説明します。 例えば、名前、アドレス、電話番号などの情報が含まれます。 顧客オブジェクト タイプは、個人を特定できる情報 (PII) と顧客 ID を関連付ける方法を提供します。

  • アクティビティ データ—特定の顧客とのやり取りについて説明します。 アクティビティは POD とも呼ばれます。 各アクティビティは、顧客がリクエストを満たすことを求めている際の顧客のジャーニーのワンステップを反映しています。 たとえば、次のようにして顧客が組織と対話すると、アクティビティが発生します。

    • お客様の組織のウェブサイトを閲覧する。

    • お客様の組織にメールする。

    • お客様の組織に電話して、IVR メニューを使用する。

    • エージェントとチャットする。

    アクティビティを顧客またはリクエストと関連付けることができます。

  • リクエスト データ—顧客が希望するものを説明します。 リクエストは、特定の顧客の問題に関連するアクティビティをまとめてグループ化する際にも使用されます。 例:

    顧客がオンラインでクレジットカードによる支払いを行います。 顧客はオンラインでの支払の際に問題に遭遇し、電話をかけます。 オンラインで支払いをしようとすることと、通話をすることは、別個のアクティビティです。 これら 2 つのアクティビティは同じリクエスト、クレジットカードでの支払い、に属します。

    各リクエストを顧客に関連付ける必要があります。

  • 詳細データ: 別のオブジェクトタイプに関する追加情報を提供します。 例:

    • アクティビティ中にエージェントが作成したノート

    • アクティビティに関する顧客からのフィードバック

    各詳細を、リクエストまたはアクティビティに関連付ける必要があります。


コンテキスト サービス フィールドとフィールドセット

フィールドを使用すると、コンテキスト サービス オブジェクトに保存されているコンテキスト データの構造を定義できます。 フィールドセットは、ビジネス ニーズに基づいてフィールドを論理的にグループ化したものです。 例えば、4 つのフィールドを持つショッピング バスケットのフィールドセットを作成することができます。

  • カートにある項目。

  • ウィッシュリスト内にある項目。

  • 合計料金。

  • 推定の出荷費用。

コンテキスト サービス フィールドとフィールドセットを使用して、柔軟なデータモデルを作成できます。 次の操作を実行できます。

  • Cisco 基本フィールドとフィールドセットを使用するか、独自のカスタムフィールドとフィールドセットを作成します。

  • フィールドを複数のフィールドセットに追加します。

  • 複数のフィールドセットを単一のコンテキスト サービス オブジェクトに関連付けます。

  • Cisco 基本フィールドセットと独自のカスタム フィールドを同じコンテキスト サービス オブジェクトに関連付けます。

  • フィールドセットに関連付けられているオブジェクトを変更することなく、フィールドを追加または削除します。


各コンテキスト サービス オブジェクトには、少なくとも 1 つのフィールドセットを指定する必要があります。

たとえば、着信通話のアクティビティとモバイル アプリのショッピングのアクティビティには異なるフィールドを使用できます。

フィールド タイプ

着信通話のアクティビティ

モバイル アプリのショッピングのアクティビティ

Cisco 基本フィールド

  • Context_Notes

  • Context_POD_Activity_Link

カスタム フィールド

  • 選択された IVR メニュー

  • 認証された発信者

  • 情報をブラウジング

  • カートの項目

個々の コンテキスト サービス データ オブジェクトはそれぞれ 256 KB に制限されています。

表 1. コンテキスト サービス オブジェクトプロパティ

オブジェクト プロパティ

顧客

リクエスト

アクティビティ

詳細

id: 独自のオブジェクト識別子

parentId: 親コンテキスト オブジェクトを表す固有識別子。

該当なし

該当なし

✓ アクティビティをリクエストと関連付けるオプションのプロパティ。

✓ リクエストまたはアクティビティのいずれかの詳細にリンクする必須プロパティ。

customerId: 顧客を表す一意の識別子。

該当なし

✓ リクエストを顧客と関連付ける必須プロパティ。

✓ アクティビティを顧客と関連付けるオプションのプロパティ。

該当なし

作成: オブジェクト作成のタイムスタンプ。

lastUpdated: オブジェクトが最後に更新された時刻のタイムスタンプ。

状態: オブジェクトがアクティブかまたはクローズかを示します。 詳細については、「コンテキスト サービス SDK のオブジェクトの状態に関するガイド」を参照してください。

投稿者: オブジェクトを作成または更新したユーザー アカウントまたはマシン アカウント。

mediaType: アクティビティのメディアのタイプを示します。 可能なメディアタイプには次の 8 つがあります。

  • 音声

  • ビデオ

  • チャット

  • メール

  • モバイル

  • ソーシャル

  • ウェブ

  • イベント

該当なし

該当なし

該当なし

フィールドセット: オブジェクトに指定されているフィールドセット。 オブジェクトには少なくとも 1 つのフィールドセットが指定されている必要があります。 フィールドセットは、どのフィールドがオブジェクトに適用されるかを定義します。

タグ: アクティビティのタグのリスト。

該当なし

該当なし

該当なし

オブジェクトを作成すると、オブジェクトのプロパティ idcreatedlastUpdatedcontributors、およびstateが自動的に入力されます。

Cisco 基本フィールドの完全なリストとカスタム フィールドの作成に関する情報については、 [Fields and Fieldsets in the Context Service SDK Guide] を参照してください。


どのデータをコンテキスト サービス オブジェクトに保存する必要がありますか。

コンテキスト サービスは、サイロ化された情報を収集する方法を提供し、顧客のジャーニーに寄り添うことを可能にするブレッドクラムを作成します。 ビジネス要件とワークフローに基づいて、コンテキスト サービス オブジェクトに保存されているデータを設計できます。 どのデータを保存するか決定する前に、次の質問について検討します。

  • 特定のユース ケースを解決するために、どのような種類のデータが必要ですか?

  • 現在保存する必要がある情報はどこにありますか?

  • 特定のユース ケースを解決するために、情報にアクセスする必要があるのは誰ですか?

顧客が辿っていくジャーニーを確認します。 これは、この質問に答えるだけでなく、ばらばらの情報をまとめるための最善の方法を見つけるのにも役立ちます。 例えば、顧客はウェブサイト上でオンラインで開始し、フォローアップとして電話をかけます。 お客様の IVR またはエージェントは、以前の Web サイト訪問について知っていますか? IVR はリピート発信者を識別し、さまざまなオプションを提供できますか? これらの観察結果を使用して、ユーザーのジャーニーにおけるアプリケーション サイロまたは組織サイロを識別します。 情報のギャップを識別し、ギャップを埋めるために必要なブレッドクラムを提供するためにコンテキスト サービス データ モデルを構築します。 たとえば、顧客が自分のカートに項目を追加し、それを購入しなかったかどうかを確認したいと考える、オンライン小売の組織です。 組織はまた、顧客が探している製品に基づいて代替提案を提供したいと考えています。 このオブジェクト、ここにあるアクティビティには、2 つのフィールドが必要です。 顧客のカートに入っている項目を記録するものと、参照したすべての項目を一覧にするものです。 データ モデルの設計も動的です。つまり、いつでも新しいフィールドセットを追加することができます。 オンライン小売組織が、調査スコア情報に価値があると判断するのは、数ヶ月後です。 その後、既存のコンテキスト データに影響を与えることなく、調査スコア フィールドを設計に追加できます。

コンテキスト サービスのデータ プライバシー モデル

各フィールドは、データ タイプとセキュリティ分類によって定義されています。

コンテキスト サービスは、機密データがプレーン テキストで保存または転送されないようにエンドポイントの暗号化を提供します。 フィールドを定義する際には、フィールドがどのようにデータを分類するかを指定します。 データは次のように分類することができます。

  • 個人を特定できる情報 (PII)— Support Center に連絡する個人に関連する情報。 PII は暗号化された形式で保存され、データにアクセスするにはキーを必要とします。 エンドポイントの暗号化を使用している場合、PII はクライアントでのみ暗号化解除できます。

  • PII ではないが暗号化されているもの—個人に関連付けられていないが機密と見なされる情報。 暗号化されたデータは、暗号化された形式で保存および転送されます。 エンドポイントで暗号化されているため、このデータはクライアント側でのみ復号化できます。

  • 暗号化されていないもの—PII ではなく、機密でもない情報。 暗号化されていないデータはプレーンテキストとして保存されますが、暗号化されたレイヤー (HTTPS) に転送されます。

例えば、名前、メール、電話番号は、個人識別可能なものです。 したがって、PII として分類されているこのタイプのデータを保存する場合、デフォルトのフィールドはエンドポイントで暗号化されています。 ポイント カードの残高は、PII ではない場合があります。 これを暗号化せずに保存することはできます。 暗号化されているが非 PII のフィールドは、例えば「コンテキスト タイトル」のようなもので、アクティビティのタイトルである場合があります。


コンテキスト サービスによって、PII や機密情報を暗号化されていないフィールドに入力することを妨げられることはありません。 データが正しい分類で適切なフィールドに保存されていることを確認してください。

ラボ モードとプロダクション モードを使用して、データに追加の境界を定義することもできます。 詳細については、「コンテキスト サービス モード」を参照してください。