ワークアイテム

エージェントがチャット、電子メール、インバウンドボイスなどの他のチャネルでインタラクションを受信するのと同じように、エージェントがワークアイテムを受信できるようにチャネルを構成できます。 たとえば、組織は、Salesforceまたは別のCRMアプリケーションからチケットまたは問題を受け取る場合があります。 これらのアイテムは、定義したStudioスクリプト、ACDスキル、およびポイントオブコンタクト(PoC)に基づいて処理するために、エージェントに直接ルーティングできます。 エージェントは、他のやり取りと同様に、エージェントアプリケーションで作業項目を処理して処理します。

ボニータ・ピープは、Classics, Inc.の営業部門のマネージャーです。 彼女のチームであるシェパードは、現場の代表者から失われたデモブックの主張を扱っています。 彼女は、電話または現場担当者が使用する新しいアプリを介してチームに請求を提出することを望んでいます。 電話で送信されると、応答エージェントは通話中にクレームを作成します。 ただし、アプリケーションを介して申請された請求の場合、Bonita は CXone Mpower で作業項目の連絡先を設定して、請求をチームメンバーに転送します。 アプリから送信された申し立ては、電話で受け取った順に処理されます。

Bonita は、Classics のスクリプト開発者の 1 人である CXone Mpower Professional Services と協力して、CXone Mpowerを構成し、アプリを通じて請求を受け取るためのStudioスクリプトを作成しました。 彼らはこの順序で働きました：

  1. Bonita はワークアイテムのスキルを作成しました。
  2. 次に、Bonita は Classics チームに、ワークアイテムの請求をエージェントにルーティングするために Studio プロフェッショナルサービスが行う作業のプレースホルダーとして、「Claim ワークアイテム」という空のCXone Mpowerスクリプトを作成させました。
  3. 次に、Bonita は CXone Mpowerで作業項目の連絡先を作成し、その中でスキルと空のStudioスクリプトを参照しました。
  4. Bonita は Classics の開発者に、現場の営業担当から必要な請求情報を収集する請求アプリケーションを作成させました。 アプリのコードで CXone Mpower ワークアイテム API 呼び出しを使用して、Bonita が作成した連絡先を通じてCXone Mpowerに請求を提出しました。

    API呼び出しは、次の情報をに送信しますCXone Mpowerアプリから：

    • pointOfContact: Bonita が作成したポイントオブコンタクト(PoC)の名前。
    • workItemID: この取引先責任者の一意の ID で、Bonita のシステムでは増分の一意の番号でした。
    • workItemPayload: 情報エージェントがクレームを処理する必要があります。 これは、JSON 文字列に似た形式の文字列で、次のような順序付けられたペアがあります。

      {"RepID": 1234567,"RepFirstName": "Bonita","RepLastName": "Peep","ClaimInfo": "Book lost on Rocky Ridge","ClaimValue": "$127.36","FurtherInfo": "この請求について質問がある場合は、(123) 123-1234 までお電話ください。"}

    • workItemType: "Lost Book Claim" など、作業項目の種類を区別するために推奨される説明文字列。
    • from：ワークアイテムが「FieldRepClaimAPI」からどこから来たものかを説明する選択の「from」の文字列。 これは、連絡先履歴レポートなどのレポート専用です。
  5. Bonita はCXone Mpowerプロフェッショナルサービスのプログラマーと協力して、以前に作成した空のスクリプトを置き換えるスクリプトを作成しました。 Classics APIがポイントオブコンタクト(PoC)にクレームを送信するたびに、スクリプトが実行されます。 APIコールから情報を受信し、適切なスキルのエージェントにリクエストし、作業項目を受信すると、RunAppアクションを通じて応答エージェントに提示します。

Bonita の作業は、ワークアイテムの設定のタスクの指示とスクリーンショットで確認できます。

ワークアイテムに関する重要情報

  • ワークアイテムには、プロフェッショナルサービスによる初期構成が必要です。
  • ワークアイテムは着信アイテムにのみ使用できます。
  • Bonita Peep の例では、ワークアイテム API 呼び出しのペイロードはかなり詳細でした。 情報が少ないペイロードの場合は、代わりにスキルのスクリーンポップをオンにして、ペイロードの生のコンテンツを自動的に表示することができます。
  • ワークアイテムスキルを設定するときに、ワークアイテムが最初にリアルタイムキューに入るか、永続キューに入るかを指定できます。 永続キューにより、ReqAgentアクションが発生してから作業項目がエージェントに配信されるまでの間、作業項目スクリプトがスリープ状態になります。 その間、作業項目に対してアクションを実行することはできませんが、それでも通常どおり追跡および報告されます。 永続キューを利用すると、静的配信環境で最大100,000個のワークアイテムをキューイングし、動的配信環境で最大5,000個のワークアイテムをキューイングできます。

  • 作業項目が転送されると、 CXone Mpowerは最初の接触間の関係を維持します（ マスター連絡先ID閉じた 1つまたは複数の関連するコンタクトのマスターまたは親ID。 コンタクトが3回以上転送されると、新しいマスターコンタクトIDが割り当てられます。 ）および新しい連絡先（転送）。 以下は、Classicsの別の学部の例です。

    作業項目がシステムに入り、マスター連絡先 ID と連絡先 ID の両方と同じ値 (234) が割り当てられます。 エージェントドロシーゲイルがワークアイテムを受け取ります。

    ドロシーはアイテムを処理できず、ジョン・ティンマンに転送します。 転送されたアイテムのマスターコンタクトIDは234で、コンタクトIDは567です。 元のアイテムとの関係は保持されます。

    John がワークアイテムを再度転送する必要がある場合、新しく転送されたアイテムのマスター連絡先 ID は 567 で、連絡先 ID は 891 になります。