データ管理

コンタクトセンターでは、レポーティングデータからコーリングリストまで、膨大な量のデータを扱います。ときにはCXoneとの間でデータを転送したり、CXone内でデータを扱うことも必要です。StudioスクリプトやAPIでどのようにデータを扱うかは、システムのパフォーマンスやインタラクションの質に影響します。このページの情報は、データ管理を効率的に行うために役立ちます。

仕事に適したツールを使う

Studioの主な目的は、コンタクトのルーティングを制御することです。Studioスクリプトで行うことはすべて、コンタクトに焦点を絞ったものでなければなりません。コンタクトに関連しないデータの処理は、Studioの外部で行う必要があります。Studioは大容量のデータを処理するようには設計されていないので、データの上限が32 KBに設定されています。コンタクトを扱う際にはこれで十分であり、サーバーは効率的に稼動します。

以下は、データ管理を必要とするタスクと、そのタスクを達成するための2つの例です。

タスクの例：エージェントデータを毎日分析し、明らかに長い休憩や予定外の休憩などの潜在的な問題を特定する。

不適切な解決策：毎日実行するスケジュールされたStudioスクリプトを作成する。このスクリプトは、まずAPI呼び出しを行い、その日のエージェントリストを取得し、次にその日のエージェントの状態履歴を取得します。次に、スクリプトは予定外の30分以上の休憩を取ったエージェントがいるかどうかをチェックします。また、4時間のトイレ休憩のようなあからさまに長い休憩も検索します。さらに、利用不可の状態が最も長かったエージェントや、特定のスキル閉じた エージェントのスキル、能力、知識に基づいてインタラクションの配信を自動化するために使用されますに費やす時間が最も多かったエージェントもスクリプトで特定します。

この方法は、以下の理由から適していません。

  • このタスクは1人のコンタクトに焦点を絞っていません。Studioは、この目的に適したツールではありません。

  • Studioは大容量のデータを処理するためのものではなく、コンタクト対応用に設計されています。メモリーに大量のデータがあるためにサーバーのパフォーマンスが劣化し、テナント閉じた CXone環境におけるテクニカルサポート、請求、およびグローバル設定を管理するために使用される上位レベルの組織グループにパフォーマンスの問題が発生する可能性があります。

  • Studioには32 KBのデータ制限があります。この方法では、データを小分けにして制限内に収める必要があります。そのため、スクリプトが長時間実行される可能性があり、リソースを大量に消費します。

  • このタスクは、Studioスクリプトではなく、CXoneAPIを使えるエンジニアが解決する方が適しています。

  • Studioは、特定の状態で過ごした時間が最も長いエージェントや、処理したコール数が最も少ないエージェントなどの情報を取得することによって、最も効果的に機能します。外部サーバーでデータを処理することで、より価値のあるメトリックを作成できます。


良い解決策：これは問題を解決するための1つの方法に過ぎません。実際のシナリオによっては、別のアプローチによる解決策が必要かもしれません。

このタスクを解決する1つの方法として、より処理能力の高いAWSサーバー上でPythonを実行することができます。このサーバーから同じAPI呼び出しを実行して、その日のエージェントリストとエージェント状態の履歴を取得します。得られたデータをテーブルか配列に入れます。将来的にデータをより簡単に比較・分析できるようにするため、データベーステーブルを使用することをお勧めします。返されるデータはメガバイト単位になる可能性があり、これはデータベースとしては問題はありませんが、Studioのデータ上限を超えてしまいます。各エージェントの全状態履歴をメモリー内に格納できるので、Studioスクリプト内の小分けにされたデータではなく、完全なデータセットを1か所で扱うことが可能です。

これで、特定の状態にあった時間に基づくエージェントの順序付きリストなど、希望するメトリックを作成するためのデータ処理を開始できます。データベースは、Studioスクリプトの制限にとらわれず、このデータをシナリオに合った方法で表現するのに役立ちます。

以下の手順は、定義された列マッピングを持つ新しい呼び出しリストを作成するための手順とAPI呼び出しの例を示しています。

  1. 認証を行います：
    1. authentication discoveryを実行し、トークンリンクを取得します。結果のトークンはキャッシュ可能です。
    2. 前のステップで発見したトークンエンドポイントから、トークンをリクエストします：
      1. https://cxone.niceincontact.com/auth/tokenに、x-www-form-urlencodedのボディを持つPOSTリクエストを作成します。
      2. client_secretとclient_idのように、5つのキーと値のペアを取得します。
  2. APIエンドポイントの検出を行います：
    1. 上記のステップ1で返されたトークンからtenantIdを抽出します。
    2. https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID}にGETリクエストを行います。応答例：
      {
	"private": false,
	"area": "na1",
	"cluster": "B32",
	"domain": "niceincontact.com",
	"acdDomain": "nice-incontact.com",
	"uhDomain": "nice-incontact.com",
	"ui_endpoint": "https://na1.nice-incontact.com",
	"auth_endpoint": "https://na1.nice-incontact.com",
	"api_endpoint": "https://api-na1.niceincontact.com",
	"tenantId": "11eb0358-724b-3970-97e5-0242ac110003"
}
    3. Extract the "area" and "domain" fields from the reply.
    4. Construct a base URI in the form of: https://api-{area}.{domain}.

  3. POST /lists/call-lists を使ってコーリングリストのマッピングを作成します。

    このAPIは、{listId}で識別されるコーリングリストを作成します。各呼び出しは、ソース列名からCXoneフィールドへのデータマッピングを更新します。一般に、データの列ヘッダーが変更された場合にのみ、この操作を実行します。このAPIでは、値をクエリーパラメーターとして定義し、destinationMappingsペアの配列を持つJSONボディを提供する必要があります。各ペアは、fieldNameとfieldValueで構成されます。これらは、以下のステップ4でアップロードされたデータをマッピングするために使用します。

    ここでCXoneによって定義されるフィールド名は、オンラインヘルプで検索できます。フィールド値は、CXoneフィールドにマッピングするソースデータの列名です。

    POSTの例は次のようになります：https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue}。ボディにはJSONを使用します。応答ボディのある200コードが返されます：

    {
	"listId": 0
}

  4. POST /lists/call-lists/{listId}/upload を使用して、ステップ3で作成したlistIdでコーリングリストのデータをアップロードします。listIdはAPI呼び出しのパスで指定され、実際のコーリングリストデータはリクエストボディで提供されます。

    ここではファイルのフォーマットが重要となります。listFileパラメーターには、コーリングリストデータをbase64エンコードされたファイルとして格納されています。

    また、リクエストボディの一部として"startSkill"フラグを"true"に設定することで、アップロード完了時にダイヤラースキルを開始するように選択できます。

    POSTの例は次のようになります：https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload。

The Jungle社のコンタクトセンターは、アクティブコールの最中にCRMから顧客データを取得してエージェントアプリケーションに表示したいと考えています。同社はStudioで、まずアカウント番号のような基本的な識別情報をコンタクトから取得します。次に、スクリプトがCRMにGETリクエストを行い、情報が顧客レコードと一致するかどうかをチェックします。レコードが存在する場合は、すべての顧客データを返します。しかし、The Jungleはすべての顧客データを表示したいわけではなく、APIでは返すデータを指定することができません。

そこで解決策として、StudioとCRMの間にミドルウェアを構築することにします。APIはミドルウェアにJSONを返し、ミドルウェアが必要な顧客の詳細を解析します。そして、その詳細をStudioに渡します。これにより、同社は32 KBのデータ制限内に収めることも可能になります。

プッシュ vs ポール

一般的には、プッシュベースのアーキテクチャを使うのが理想的です。ポーリングによって何かが起こるのを待機する場合、当然ながらリソースを消耗します。一方、データのプッシュはオンデマンドで行われ、不要なときにリソースを消費することはありません。一般に、データをプッシュすることで、より小さなデータ片を扱うことができます。データのプッシュは、アクティブな1人のコンタクトのようなリアルタイムのニーズに対してよく行われます。ポーリングは統合に使われることが多く、細分化やセグメント化はそれほどできません。

たとえば、電話を保留にする際にエージェントのUIを更新したいとします。スクリプトで/get-next-eventAPIを使用して、エージェントクライアントからの保留イベントをリッスン(またはポーリング)した場合、スレッドが常にブロックされます。その代わりに、サーバーリソースの常時使用を避けるため、1つのインスタンスを使ってデータをプッシュする方が効率的です。同様の例として、たとえばCRMとの統合などで、リクエストが返されるのを待機する代わりに、API呼び出しを使ってデータをプッシュし、スレッドを解放します。その後、シグナルAPIを使用して、スクリプトにデータを送り返します。また、API呼び出しを行い、そのリクエストが終了したかどうかを確認し、終了していればデータを送信することもできます。

大量のデータを処理する

コンタクトセンター全体の履歴データなど、大規模なデータセットを管理したい場合、CXone APIを使用します。大規模な環境ではSnowflakeを使用して、ビジネスユニットのすべてのデータをプルすることができます。規模がそれほど大きくない場合、上述のタスク例 が最適かもしれません。膨大な量のデータを持たない中小企業や、特定のメトリックを調べたい企業の場合、同様のタスクを処理する小さなアプリを構築できます。たとえば、特定の状態に長時間留まる従業員がいる場合に管理職にメールを送るアプリなどを作成できます。

スクリプトでの大規模なデータセットを避ける例

以下は、Studioスクリプトで大きなデータセットの使用を避けることができる、一般的なシナリオの例です。CRMからStudioに多くの顧客データが転送されるのを避ける、上記の例も参照してください。

  • API応答をフィールドでフィルタリングする：

    一部のAPIには、どの情報が返されるかをフィルターする機能が備わっています。たとえば、CRMにケースの情報を返すようにリクエストする場合、CRM APIによっては、返したい情報のフィールドを正確に指定することができます。使用しているAPIにこの機能がある場合、必要な情報だけを扱うことにより、大規模なデータセットを避けることが可能です。ベンダーのAPIにこの機能がない場合は、ベンダーと協力してオプションを追加するか、ミドルウェアを構築することができます。ミドルウェアは、Studioの前にデータを受け取って、不要なものをフィルタリングしてからStudioにデータを返すことができます。

  • API応答を時間でフィルタリングする：

    APIで時間によるフィルタリングができる場合は、この機能を使ってデータ量を最小限に抑えます。1日分や1週間分のデータのみが必要な場合は、その時間範囲内のデータのみが含まれるように回答をフィルタリングしてください。

  • 個々のコンタクトのデータをフィルタリングする：

    Studioはデータ管理ツールではなく、コンタクト管理ツールです。StudioとStudioアクションの機能によって、主に個々のコンタクトに焦点を当ててデータを扱うことができます。IVRで情報を収集したり、CRMのデータを一度に1レコードまたは1ケースずつ取得したりする手法で、データを個々のコンタクトに特化させることができます。

データストレージ

データの保存には多くの選択肢があります。Snowflakeアカウントをお持ちの場合は、Studioを使用して、CXoneからSnowflakeにコンタクトセンターのデータを移動できます。NICEではデータが24か月間保存され、Snowflakeから取り出すことができます。また、Cloud Storage Servicesを使用して、コールレコーディングやチャットトランスクリプトなどのファイルを保存したり、独自のサーバーに移動したりすることもできます。詳細については、CXoneのサポート担当者にお問い合わせください。

予期せぬコスト

一般的に、API呼び出しの回数が多すぎるなどの理由で追加コストが発生することはありません。しかし、特定のデータをどのように保存するかによって、コストが発生する可能性はあります。以下に、データストレージの不適切な使用によって想定外の課金が発生した例を示します。

  • 多くのスクリプト変数を作成してコンタクトごとにテキストファイルに保存しており、それらのファイルをクレンジングするプロセスがない場合。

  • IVRプレスパスの情報を後で使用できるようにファイルに保存している場合。たとえば、将来レポーティングの目的で情報を使用したいことがあります。

  • APIの結果をファイルに保存しており、新しい結果が追加されるごとにファイルが継続的に拡張される場合。時間の経過とともにファイルサイズが大きくなると、ストレージコストが発生します。

  • CXone クラウドストレージにファイルを保存している場合。クラウドストレージを使用する場合は、ストレージに関するパラメーターを確認してください。クラウドストレージのヘルプコンテンツを参照するか、サポート担当者にお問い合わせください。

StudioからのAPI呼び出し

APIは、効率的かつ効果的にデータを扱うのに役立ちます。StudioからAPI呼び出しを行うには、以下のアクションを使用できます。このリストでは、それぞれのアクションを使用する際の技術的な違いを説明しています。

  • SNIPPET：スクリプトにカスタムコードを追加できます。このアクションを使用して、API呼び出しの実行、ペイロードの準備、ダイナミックデータオブジェクトの解析などを行うことができます。このアクションでAPI呼び出しを行う場合は、応答速度に注意してください。このアクションは、アクティブになっている間ずっとスレッドを使用します。応答が遅い場合、つまりスレッドがずっとブロックされている場合、サーバーのパフォーマンスに悪影響を及ぼす可能性があります。たとえば、すべてのスレッドが一度に使用された場合、発信者には何も聞こえない状態になる可能性があります。

  • REST API：REST APIを呼び出すことができ、サーバーリソースをあまり使用しません。API呼び出しを行う際はなるべくこのアクションを使うべきですが、特にJSONを受け入れます。APIがJSONを返さない場合、代わりにSNIPPETアクションを使う必要があるかもしれません。SNIPPETはペイロードの準備のような処理ができるので、タスクによっては、このアクションをSNIPPETと組み合わせて使う必要があります。

  • ConnectAuth：Integration Hubで作成されたコネクターを認証します。Integration Hubは、CXoneからサードパーティのプラットフォームへの統合を構築、管理、実行するための集中ソースです。このアクションはスレッドをブロックしません。

  • ConnectRequest：認証された後、Integration Hubリクエストをトリガーします。このアクションはスレッドをブロックしません。

その他のデータ関連のStudioアクション

Studioには、他のスクリプトからデータにアクセスできるようにするために、データベーステーブルから少量のデータを一時的に保存したり取得したりするアクションがいくつかあります。これらのアクションは、フィールドや値のリストのように動作します。複数の値、または他のスクリプトでさらに必要な値を格納するためにそれらを使用します。アクションの全リストは以下のとおりです：PUTVALUE、GETVALUE、REMVALUE、GETLIST、CLEARLIST。

これらのアクションは、この一連のStudioアクションを使用してのみアクセスできる、一意のデータタイプを使用します。他の方法でデータにアクセスすることはできません。ユーザーは、アクセス許可に関係なく、このデータベースにアクセスして使用することはできません。

この値は、PUTVALUEアクションのTTL hrs (time to life)プロパティで設定されているように、限定された期間の間、データベースのテーブルにリストされます。デフォルトは24時間ですが、1時間から168時間(7日間)までの範囲で指定できます。REMVALUEアクションを使用すると、TTL時間の前にデータを削除できます。これにより、スクリプト内のデータを完全に制御できます。ベストプラクティスは、使わなくなった値は削除し、TTLをデフォルトの24時間のままにすることです。

メモ：

  • 他のスクリプトやコンタクトがいくつかの変数にアクセスする必要がある場合、通常はデータベースが最良のソリューションとなります。
  • 非永続的なパブリック変数は、それらの変数を設定するスクリプトの存続期間を通じて、他のスクリプトやコンタクトによって共有される可能性があります。変数は、解放されると自動的にクリーンアップされます。
  • これらのアクションには、リスト内のアイテム数が1000個までという制限があります。また、1つのアイテム(1片のデータ)は5 KBに制限されます。