Cce75 scripting-20100413

  • 839 views
Uploaded on

 

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
839
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. シスコシステムズ合同会社 ソリューションシステムズエンジニアリング 2010 年 2 月 24 日 島崎 直人 Cisco Unified Contact Center Enterprise スクリプティング
  • 2. 基礎編
  • 3. コールルーティングの基礎概念
  • 4. コールルーティングの例
    • 着信番号に基づいて特定のグループへ転送
    • 自動音声応答でメニューを選択させ、選択肢に応じて特定のグループへ転送
    • 特定のグループ内で誰かが応答可能になるまでアナウンスを流して待ち合わせ
    • グループ内に応答可能なエージェントがいない場合、溢れ分を他のグループへ転送
    • エージェントが同時に複数のグループに所属し、どちらのグループへ転送された呼も処理
    • 日付や時刻に基づいて転送先を変更
    • 顧客 DB の情報に基づいて転送先を決定
  • 5. コールルーティングの考察要素
    • 呼の分類
    • ターゲットの選択
    • 待ち合わせ
    • 呼の優先順位付
    • 発信
    • レポーティング
  • 6. 呼の分類
    • 着信番号に基づく分類
    • 日付時刻に基づく分類
    • 自動音声応答メニューに基づく分類
    • 外部データに基づく分類
    • 外部アプリケーションに基づく分類
    • 比率による分類
    • その他一般条件による分類
  • 7. ターゲットの選択
    • ターゲットの例
      • 特定のエージェント
      • エージェントのグループ
      • 音声アナウンス装置や外部システム
    • ターゲット選択規則の例
      • 最も長時間待機しているエージェント
      • 最も技量の大きなエージェント
      • 最も稼働の少ないエージェント
      • 予想待ち時間が最も小さいキュー
  • 8. 待ち合わせと優先順位
    • キュー(待ち行列)
      • キューの配置や考え方はメーカー・製品によって様々
      • キューの振る舞いに関する適切な理解が必須
    • 単一キューへのキューイング
    • 複数キューへの同時キューイング
    • キューからの取り出し順序
    • 順序の飛び越し(優先制御)
    • キューイングのキャンセル
  • 9. レポーティング
    • どの番号にどれだけかかってきたか ?
    • どのグループにどれだけ転送されたか ?
    • どれくらい溢れたか ?
    • 応答までの待ち時間はどれくらいか ?
    • 音声応答にかかった時間と待ち時間の区別
    • どれくらい放棄されたか ?
    • サービスレベル目標への合致率は ?
    • エラーは ?
  • 10. 追加
    • できるだけ絵で表現を
    • 特にコールルーティングのサンプルを絵で表現したほうが良い。字だけでは分かりづらい。
  • 11. CCE のコールルーティング
  • 12. CCE のコールフローとスクリプト Voice GW CCM Agent 2000 Agent 2001 Agent 2002 UCCE IVR Caller 公衆網 Q.931 MGCP JTAPI GED125 SCCP (1) (2) (5) (10) (7) (11) (3) (4) JTAPI 注 : Peripheral Gateway は省略して表現している (6) (9) CCE がトップレベルのスクリプトを実行 IP IVR が CCE の下請けとして音声応答フロー専門のスクリプトを実行
  • 13. 2 種類のスクリプト
    • UCCE のスクリプト
    • UCCE Call Router 上で実行
    • Intelligent Routing を実装
    • IP IVR の CCX Script
    • IP IVR の engine 上で実行
    • 音声応答のフローを実装
  • 14. 2 種類の CCE スクリプト
    • Routing Script
      • 呼毎に実行
      • 各種情報を元に呼の転送先を決定する
    • Administrative Script
      • スケジュールに従って定期的に実行
      • Routing Script の振る舞いに変化を与える
  • 15. Routing Scrip t と管理 Script の連携 変数 1 変数 2 変数 3 変数 4 変更 参照 一定時間毎に実行され実行時の条件に応じて変数の値を更新する 呼毎に実行され、変数の値に応じてルーティング処理の振舞いを変更する 管理 Script Routing Script
  • 16. CCX Script と CCE Script の連携 Caller Entered Digit Peripheral Variables Account Number ECC Variables
  • 17. 着呼から Routing Script 起動まで
    • 顧客からの電話が Dialed Number に着信する
    • Dialed Number, ANI, CED から mapping されている Call Type が検索される
    • Call Type に対してスケジュールされている Routing Script が起動される
      • * CED: Caller Entered Digit
        • スクリプト起動時に CED が設定されているのは、 SS7 等を用いた pre-routing 時。公衆網内に VRU が配置されている場合、 NIC からの routing request に最初から CED が設定されている場合がある。
        • Post routing のみの環境においては、 CED は空
  • 18. 着呼から Routing Script 起動まで ( 続き ) Dialed Number Call Type Routing Script
  • 19. Script Editor
  • 20. 追加
    • 導入部の記述は全体的に見直す必要あり。
    • 概念の説明が不足。
      • Call Type
      • 変数 (call variable, ECC, user variable, persistent vs. non-persistent, call val vs. non-call val)
    • Script Editor の機能説明
      • この場所が適切か?
      • 付録に回すべき?
  • 21. 呼の分類
  • 22. 着信番号による分類
  • 23. 着信番号による呼の分類
    • サービス毎に専用の電話番号を設け、受け付ける。
    • かかってきた番号に基づいて適切なスキルグループへとコールを転送する。
    • サービス毎にサービスレベル等のレポートを行う。あるいは複数の電話番号で統一したレポートを行う。
  • 24. CCE における実現
    • 着信番号に一対一対応するように Dialed Number が設定される。
    • Dialed Number 毎に各々独立した Call Type を作成し、関連付ける。これにより、 Dialed Number 毎の Call Type レポートが生成される。
    • 各々の Call Type から各々異なるルーティングスクリプトを起動し、サービスを提供するスキルグループへとルーティングする。
  • 25. 着信番号による呼の分類 Dialed Number Call Type Skill Group Routing Script 申込 紛失 その他 クレジットカード会社の コンタクトセンター 0120-123-456 0120-123-458 New_Application Lost_Card Account_Service 0120-123-457 New_Apply_Sg Lost_Card_Sg Acct_Svc_Sg New_App_Scr Lost_Card_Scr Acct_Svc_Scr
  • 26. 着信番号による呼の分類(別例) Dialed Number Call Type Skill Group Routing Script 東京 大阪 名古屋 集中受電 03-1111-2222 052-555-6666 Tokyo Osaka Nagoya 06-3333-4444 Front_Line_Sg Front_Line_Scr
  • 27. 着信番号別のレポート
    • 着信番号毎にレポートを分けるには、 Dialed Number 毎に個別の Call Type を設定。
    • サービスレベル等は Call Type 毎に計測される。
    • サービスレベルの評価を複数の着信番号で統一したい場合は、ルーティングスクリプトの冒頭で Call Type ノードを使用して統一レポート用の Call Type に変更する。この場合、 Dialed Number と対応付けられた Call Type は着信数が Over flow 数として計測される。
  • 28. 着信番号別ルーティングのスクリプト例 着信番号毎に Call Type を分け、サービスレベル等のレポートを分離する場合 番号毎に Call Type を関連付け、そこから個別のスクリプトを起動。 Queue to Skill Group ノードは、 available なエージェントが複数いる場合は Longest Available Agent を選択する。
  • 29. 着信番号別ルーティングのスクリプト例 サービスレベル等のレポートを着信番号によらず統一する場合 Call Type ノードを用いて開始時の Call Type を上書きする。サービスレベル等のレポートはここで設定された Call Type に統一される。 番号毎の Call Type には overflow として着信呼数がレポートされる。
  • 30. 日付時刻に基づく分類
  • 31. 日付時刻に基づく呼の分類
    • 平日の営業時間のみエージェントへルーティング、それ以外はアナウンスを流して呼を切断する。
    • 曜日によって営業時間を変える。
    • 祝祭日は休日・時間外運用する。
    • 時間外の着信数をレポートする。
    • 複数の業務で共通の営業時間管理を行う。
    • 管理情報を CCE の外部に持つ。
  • 32. CCE における実現
    • CCE には日付を判定するノードがない。 If ノードにて代用するか、 IVR を用いた外部データに基づく判定を利用する。
    • 曜日を判定するノード、時刻を判定するノードは提供されている。
  • 33. If ノードによる日付の判定 組み込み関数 date() は現在の日付を整数形式で返す。一方 date(YYYY,MM,DD) は YYYY 年 MM 月 DD 日の日付を整数形式に変換する。この二つを組み合わせて、本日が YYYY 年 MM 月 DD 日か否かを判断している。 関数 date() が返す整数は 1602 年 1 月 1 日からの経過日数であるため、大小比較によって現在の日付が指定の日付より前か後かを判定可能。
  • 34. 時間外着信のレポート 営業時間中の場合は Call Type を MainMenu に変更。これにより、営業時間外の着信がレポートに影響してしまうことがない。 休日及び営業時間外に着信したコールは Call Type を ClosedTime に変更。これにより、営業時間外の着信は ClosedTime のレポートに反映される。 土日は下へ。営業日は右へ。 午前 9 時から午後 5 時は MainMenu へ。それ以外は ClosedTime へ。 平日の午前 9 時から午後 5 時までオープンする例
  • 35. 複数スクリプト間でのルールの共有
    • 日付・曜日・時刻の判定ルールがルーティングスクリプト毎に異なり、個別管理される場合は、判定そのものをルーティングスクリプト内で行う。
    • 共通の判定ルールを複数のスクリプトで共有する場合は、管理スクリプトで判定し、結果のみを変数を介してルーティングスクリプトへ渡す。
  • 36. ユーザー定義変数 Persistent を指定することで、 CCE Router プロセスが再起動しても値が失われない。
  • 37. 管理スクリプトによる実装例 平日の午前 9 時から午後 5 時までオープンする例 土日は下へ。営業日は右へ。 午前 9 時から午後 5 時は userOpen 変数を 1 に設定。それ以外は userOpen 変数を 0 に設定。 管理スクリプトが行うのは変数を設定するところまで。 ルーティングスクリプトが設定された変数を参照することでふるまいを変える。 管理スクリプトの実行頻度は時刻管理の粒度に応じて適宜設定
  • 38. ルーティングスクリプトからの参照 ルーティングスクリプトでは直接時刻や曜日の判定はせず、管理スクリプトが判定した結果だけを変数を介して受け取り、ふるまいを変える。
  • 39. 管理情報を CCE 外部に持つ
    • CCE での日付時刻判定の欠点
      • 日付の判定が煩雑かつ管理しづらい
      • ルールの変更にスクリプトの変更権限が必要
    • 日付時刻ルールの外部化
      • IVR を用いてルールを CCE の外部に持つ。
      • IVR の外部 DB アクセス、外部アプリケーションアクセス機能等を活用して日付判定ロジックそのものを IVR もしくはさらに外部のシステムに持たせる。
      • IVR からは結果だけを受け取り、スクリプトの振る舞いを変える。
  • 40. 音声応答・発信者番号・外部データベース 外部アプリケーションに基づく分類
  • 41. 音声応答と外部アプリケーションの課題
    • CCE にはビルトインされた音声応答機能がない。
      • 音声応答は、その内容の難易によらず全て CCE から制御された IVR 装置にて行う必要がある。
    • 大量の発信者番号を扱うには CCE は不適。
      • 発信者が通知する発信者番号は通常極めて数が多くなるため、外部データベースへのアクセスが必然となる。
    • CCE が備えるデータベースアクセスは極めて限定的な機能しか提供していない。
      • 外部データベースへのアクセスは CCE から制御された IVR 装置が備える ODBC/JDBC にて行う方が容易かつ柔軟で優れている。
    • CCE が備える外部アプリケーションへのアクセスはソケットベースで開発が容易でない。
      • 外部アプリケーションへのアクセスは CCE から制御された IVR 装置が備える XML over HTTP によるアクセス機能の方が今日の一般的な連携技術と親和性に優れる。
  • 42. CCE における音声応答と外部連携
    • CCE においては、全ての音声応答と、データベースアクセス、外部アプリケーションへのアクセスを CCE から制御された IP IVR もしくは CVP で行うことが望ましい。
    • 上記のことより、本項のトピックは IVR 連携という一つの技術要素に集約される。
    • 特殊な事情がある場合は、 CCE の機能である DB Lookup や Application Gateway を用いても良いが、一般的とは言えないため、本資料では割愛する。
    • IP IVR または CVP と外部システムとの連携方法は付録を参照。
  • 43. 追加
    • 連携に関する選択肢を一枚でとらえる絵が欲しい
      • 字ばかりで読みづらい
    • CCE: DB Lookup, Application Gateway
    • IP IVR: DB, HTTP, Java
    • CVP: DB, XML API, Java API
    • IP IVR, CVP と外部との連携の詳細は付録へ
  • 44. CCE スクリプトと IVR 装置の連携
    • CCE Script からの VRU Script の実行
      • VRU Script: IVR 装置上で実行されるスクリプト
    • VRU Script へのデータの受け渡し
    • VRU Script からのデータの受け取り
    • VRU Script の終了ステータスコードの受け取り
    • VRU Script の中断
      • キューイング中の待ち合わせアナウンスの再生を中断してエージェントに呼を転送する際に使用。
  • 45. 追加
    • ここに「なぜ translation routing が必要か」を理解するための絵が必要。
  • 46. Translation Route to VRU
    • CM PIM が制御する CTI Route Point に着信した呼を IP IVR へと転送しつつ、制御はそのまま維持する。
    • 複数の IP IVR の間で負荷分散や故障時の切り離しを制御する。
    • 通常、ルーティングスクリプトの冒頭で実行される。
    • IP IVR から他の IP IVR への Translation Routing も可能。
  • 47. 転送先 VRU の指定 ターゲットの追加画面 Translation Route to VRU のプロパティ IP IVR を制御する VRU PIM 上に作成された Service をターゲットとして選択する。
  • 48. VRU 故障時、フル稼働時の切り離し Translation Route to VRU のプロパティ Peripheral.pg1_2.Online && Network.TrunkGroup.ntgivr1.TrunksIdle > 0 名称 “ pg1_2” の VRU PIM が Active になっていないとき、即ち 当該 PIM の制御する VRU が適切に稼働していないとき、変数 Peripheral.pg_2.Online の値が負となる。これにより故障した VRU を切り離せる。 上記 VRU PIM (pg1_2) に設定された Network Trunk Group を用いて VRU の空きポートの把握が可能になる。名称 “ ntgivr1” の Network Trunk Group があるとき、変数 Network.TrunkGroup.ntgivr1.TrunksIdle は当該 VRU の空きポート数を表す。従ってこれがゼロであればポートはふさがっている。 Consider If ( 前提条件 ) の項目を用いて、各 VRU を転送の対象とするかしないかを選別する。 Consider If に設定する数式
  • 49. VRU の負荷分散 (1/2) Network.TrunkGroup.ntgivr1.TrunksIdle タイプの選択 Translation Route to VRU のプロパティ 複数の VRU から最も稼働中のポートが少ない VRU を選びたい場合は、 TrunksInService が最小の VRU を選択するように設定する。この場合、「最小値以上のターゲットを選択」を選ぶ。 逆に空きポートが最も多い VRU を選択したい場合は TrunksIdle が最大の VRU を選択するよう設定する。この場合、「最大値以下のターゲットを選択」を選ぶ。
  • 50. VRU の負荷分散 (2/2) Translation Route to VRU のプロパティ Select Max Value of ( 次の値の最大を選択 ) に設定する数式 ターゲットの VRU PIM に設定された Network Trunk Group “ntgivr1” を用いて VRU の空きポートを参照し、空きポート数が最も多い VRU へ呼を転送する。 Network.TrunkGroup.ntgivr1.TrunksIdle
  • 51. VRU Script と CCE Script の連携 Caller Entered Digit Peripheral Variables Account Number ECC Variables
  • 52. CCE Script から VRU Script への データの受け渡し
    • VRU Script 起動時に、下記変数が自動的に CCE Script から VRU Script へ渡される。すなわち、 VRU Script 開始時に下記変数が CCE Scrirpt 上での値にあらかじめ初期化される。
      • Call.CallEnteredDigit
      • Call.PeripheralVariable1 – 10 (10 個 )
      • Call.AccountNumber
    • 上記で足りない場合、 Expanded Call Context (ECC) 変数を用いる。
      • ECC 変数は CCE 、 IP IVR の CCX Editor 双方で事前に定義しておく必要がある。
  • 53. VRU Script から CCE Script への データの受け渡し
    • VRU Script 終了時に、下記変数が自動的に VRU Script から CCE Script へ渡される。すなわち、 VRU Script 終了時の下記変数の値で CCE Scrirpt 上の各変数が上書きされる。
      • Call.CallEnteredDigit
      • Call.PeripheralVariable1 – 10 (10 個 )
      • Call.AccountNumber
    • 上記で足りない場合、 Expanded Call Context (ECC) 変数を用いる。
      • ECC 変数は CCE 、 IP IVR の CCX Editor 双方で事前に定義しておく必要がある。
  • 54. VRU Script の終了ステータスコード
    • IP IVR の場合、 Set ICM Result Step で終了ステータスコード( true または false )を設定する。
    • VRU Script の実行が終了すると、 Run External Script ノードは終了ステータスコードが true ならば成功側分岐へ、 false ならば失敗側分岐へ処理を進める。
    • VRU Script が実行できなかった場合( Network VRU Script の設定誤り等)も失敗側分岐へ進む。
  • 55. IVR からのデータの評価
    • Caller Entered Digit (Call.CallerEnteredDigit) は、特に音声応答の結果の受け渡しに用いることを意図した定義済み変数。
    • CED ノードを用いて評価できるため、音声応答結果はこの変数で返すことが望ましい。
    • もちろんそうしなくても良い。
    • DB 等からの戻りデータの評価は If ノード等を適宜用いる。
  • 56. CED ノードによる呼の分類
    • Call.CallerEnteredDigit の値に従って分岐
    • 分岐数は任意
    • 一つの分岐に複数の入力番号を割り当て可能
    • 入力番号の桁数は任意。ワイルドカードは使用不可
  • 57. 追加
    • CED 以外の評価方法も書いておかないと CED しか使えないと誤解されないか。
  • 58. その他の条件による分類
  • 59. その他の分類手段
    • 比率による分類
    • 一般条件による分類
    • 手動スイッチによる分類
  • 60. 比率による分類
    • 比率による分類には、 Percent ノードを使用する。
    • Percent ノードは、ノードを通過する処理の分岐先が一定の比率で分散するよう分岐する。
    • 分岐毎に割り当てる配分比率をパーセンテージで指定。
    • 図は接続 A へ 20% 、 B へ 30% 、 C へ 50% 配分している。
  • 61. 一般条件による分類
    • 最も汎用的な分類手段は If ノードを用いた方法。
    • If ノードは任意の条件式を評価して、式の値の真偽により処理を分岐する。
    • 条件を定義した式の評価値が ture ( 非ゼロ ) のときは、成功側の接続へ処理が進む。
    • False ( ゼロ ) のときは、失敗側に処理が進む。
  • 62. 手動スイッチによる分類
    • Switch ノードは、通常は定められた分岐へ処理を進め、必要な時に手動で設定を変更して分岐先を切り替えたい場合に使用する。
    • Script Editor のクイック編集モードで処理の流れを変更可能なため、コネクターの付け替えよりも誤操作の可能性が少なく安全。
  • 63. ターゲットの選択
  • 64. エージェントの選択
    • エージェントリッチな状況、即ち、呼の着信料をサービスのリソースが上回っており、呼の到来時点では必ず複数のエージェントが受信可能な状態にある状況においては、何らかの規則に基づいて複数の受信可能なエージェントから一人を選択しなくてはならない。
    • この様な状況では、エージェントの選択メカニズムの動きが支配的となる。
  • 65. Select ノードによるターゲット選択 Select ノードによってターゲットの選択アルゴリズムを指定 Skill Group ノードにターゲットとなるスキルグループを列挙
  • 66. 標準ターゲット選択規則 (1/3)
    • Always Select
      • 全てのターゲット( Skill Group, Enterprise Skill Group, Service, Enterprise Service )に対応。
      • ターゲットセットの先頭または前回選択したターゲットの直後のターゲット(設定に依存)から順に検索して最初に available なエージェントを含むターゲットを選択する。
    • Longest Available Agent
      • Skill Group, Enterprise Skill Group に対応。
      • ターゲットセットの中から最も available 時間の長いエージェントを含むターゲットを選択する。
    • Next Available Agent
      • Skill Group, Enterprise Skill Group に対応。
      • ターゲットセットの中で最も available なエージェントの比率の高いターゲットを選択する。
  • 67. 標準ターゲット選択規則 (2/3)
    • Minimum Average Speed of Answer
      • Service, Enterprise Service に対応。
      • 直近 5 分間の移動平均で ASA の最も小さかったターゲットを選択する。
    • Minimum Calls in Queue per Position
      • Service, Enterprise Service に対応。
      • ターゲットが含むエージェントの人数に対する現在の待ち呼数の比率が最も小さいターゲットを選択する。
    • Minimum Average Queue Delay
      • Service, Enterprise Service に対応。
      • 直近 5 分間の移動平均でキューイング時間が最も小さかったターゲットを選択する。
  • 68. 標準ターゲット選択規則 (3/3)
    • Minimum Longest Delayed Call
      • Service, Enterprise Service に対応。
      • 各ターゲット毎に最も長くキューイングしている呼のキューイング時間を比較し、最もキューイング時間が短いターゲットを選択する。
    • Minimum Expected Delay (ACD PIM のみ )
      • Service, Enterprise Service に対応。
      • ターゲット内での平均処理時間、現在の待ち呼数、割り当てられているエージェント数等から最も待ち時間が小さいと予想されるターゲットを選択する。
  • 69. 対応していない選択アルゴリズム
    • ブロードキャスト(一斉鳴動)
    • Least Occupied Agent (Most Idle Agent)
  • 70. 選択規則とローカルキューイング
    • Select ノードは、ターゲットを選択してスクリプトを終了するか、何も選ばずに失敗側分岐へ処理を進める。
    • ターゲット選択後のキューイングは Peripheral によるローカルキューイング。 ACD deployment (ICM) ではローカルキューイングも可能だが、 Unified CM による CCE deployment ではローカルキューイングは不可。
    • 従って、 CCE では available なエージェントがいない限り Select ノードが失敗するような選択規則しか使用できない。
  • 71. ローカルキューイングによる 選択規則の分類
    • ローカルキューイングが不要な選択規則
      • Always Select
      • Longest Available Agent
      • Next Available Agent
    • ローカルキューイングが必要な選択規則
      • Minimum Average Speed Answer
      • Minimum Calls in Queue per Position
      • Minimum Average Queue Delay
      • Minimum Longest Delayed Call
      • Minimum Expected Delay
    CCE ( 非 ACD deployment) での実質的な選択肢はこれのみ
  • 72. 略式のエージェント選択とキューイング
    • Select ノードによる Skill Group への呼の転送は省略することができる。
    • Queue to Skill Group ノードは、実行時に available なエージェントが複数いると、その中から Longest Available Agent 規則に従ってエージェントを選択し、直ちに呼を転送してスクリプトを終了する。
    • 従って、 Select と Queue to Skill Group のターゲット Skill Group が同じ場合は、 Select を省略できる。
  • 73. マルチスキルルーティング
    • 一人のエージェントが複数の Skill Group に所属することを、マルチスキルと呼ぶ。
    • CCE はマルチスキルに対応。
    • エージェントに複数の Skill Group を割り当てるだけでマルチスキルの状態になる。
    • ルーティングスクリプト上では、特にマルチスキルを意識する必要はない。
    • レポート上は、ある Skill Group への呼を処理している最中は、他の Skill Group では “ busy other” 状態とみなされる。
  • 74. 特定エージェントへのルーティング
  • 75. 特定エージェントへのルーティング
    • 特定のエージェントを名指しして呼をルーティングしたい場合がある。
    • エージェント間転送
    • スーパーバイザーアシスト
    • ラスト・エージェント転送
      • 同じ caller からの呼はなるべく最後に応対したエージェントへ転送する転送方式のこと。
    • エージェントへの直通ダイヤル
  • 76. エージェントへ転送するノード Peripheral Number による エージェントの指定。 最も広範に利用可能。 Skill Target ID によるエージェントの指定。 主に Supervisor Assist Call に使用。 Enterprise Name による エージェントの指定。 動的指定不可。
  • 77. エージェントの指定方式
    • Peripheral Number (Agent ID) による指定
      • Agent に割り当てられた Peripheral Number を用いる。
      • 擬似内線番号的に利用可能。
      • エージェント間転送やラストエージェントは通常この方式。
    • Skill Target ID による指定
      • Agent 作成時にシステムが発行した ID を使用。
      • DB 上のキーとして自動発行されるため扱いづらい。
      • Supervisor Assist Call で使用。
    • Enterprise Name による指定
      • Agent 作成時に設定されたシステム全体で一意な名前。
      • この方式のみ動的指定ができない。
  • 78. その他のターゲット
  • 79. Skill Group ・ Agent 以外のターゲット
    • 音声アナウンス再生装置、セルフサービス用 IVR
      • CCE の制御化にある VRU を用いて音声アナウンスの再生や caller による無人のセルフサービスを実施する際は、呼を Translation Route to VRU にて VRU へトランスレーションルーティングし、そこで適宜必要なスクリプトを実行する。
      • 上記装置への転送時点で CCE による制御やレポーティングが不要な場合、 Label ノードを用いて呼をターゲットに転送する。
    • オフィスや外部の電話
      • Label ノードを用いて呼をターゲットに転送する。
  • 80. ラベル (Label)
    • Routing Client に対 して Label そのもの を返すことで明示的 に呼の最終的なターゲットを指示する。
    • 応答する Label は事前に設定済みのものまたは計算式によって動的に生成したもの。
    • 実行時の Routing Client が固定しない場合( Routing Client が VRU で負荷分散されている場合等)は可能性のある全ての Routing Client に対応するラベルを設定しておく必要がある。
  • 81. Label ノードの使用 Label のプロパティ 設定済みラベルで最終ターゲットを指示する場合の設定。このラベルが実行される時点で呼を制御している可能性のある全ての Routing Client に対して予めラベルを定義し、ここで指定しておく必要がある。同じラベルノードの Routing Client が実行毎に異なる可能性のある例としては、 Routing Client が負荷分散された VRU の場合が挙げられる。 Label のプロパティ 設定済みラベルによる指定 計算式の結果による指定 ダイナミックラベルで最終ターゲットを指示する場合の設定。計算式により任意のラベルを応答することが可能。 Routing Client にとって有効なラベルを応答しなくてはならない。したがって、このラベルが実行される時点で呼を制御している可能性のある Routing Client が複数ある場合、どのような Routing Client であれ有効なラベルを応答することは計算式の責任となる。 Routing Client 毎に呼の転送時のプレフィックスが異なる場合等に特に注意を要する。
  • 82. Label ノードの Router Re-query
    • Routing Client が Router Re-query に対応している場合、 Label ノードで Router Re-query を使用することが可能。
    • Re-query を使用すると、呼の転送に失敗した場合(宛先が busy 、無応答等)でも CCE による制御を継続できる。
    • 右のスクリプトは中段のノードで re-query が有効になっている。ラベル “ 5557” への転送が失敗すると処理が失敗分岐へ進み、次の Label ノードにより “ 2008” へ転送される。
    • CVP は Router re-query に対応する。 IP IVR は対応していない。
  • 83. 追加
    • Router Re-query については Select の説明の段階で言及すべきではないか?
  • 84. キューイング
  • 85. 呼の待ち合わせ
    • コールリッチな状況、即ち、呼の着信量がサービスのリソースを上回っており、呼を受信可能なエージェントが一人もいないにも関わらず呼が到来する状況においては、エージェントが受信可能になるまでの間、呼を行列に入れて待ち合わせる必要が生じる。
    • このような状況では呼のキューイングメカニズムの動きが支配的となる。
  • 86. CCE におけるキューの動き
  • 87. UCCE のキュー
    • Skill Group 毎に暗黙のキューがそれぞれ存在。
    • 各キューはさらに優先度毎に分かれている。
    • 優先度は 1 – 10 の範囲。 1 が最優先。
    Skill Group A 優先度 1 優先度 2 優先度 3 優先度 4 Skill Group B 優先度 1 優先度 2 優先度 3 優先度 4
  • 88. 呼の優先度
    • 優先度は Queue to Skill Group ノードで指定。
    • キューイング後の変更は Priority ノードを使用。
    • 既定の優先度は 5 。
    Skill Group A 優先度 1 優先度 2 優先度 3 優先度 5 Skill Group B 優先度 1 優先度 2 優先度 3 優先度 4
  • 89. 単一スキルへのキューイング
    • Queue to Skill ノードにて単一のスキルに同一優先度でキューイングした場合、呼は先着順にエージェントへ割り振られる。
    Skill Group A Skill Group B 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 優先度 1 優先度 2 優先度 3 優先度 4 優先度 1 優先度 2 優先度 3 優先度 4 田口 2 2 田川 3 3 田中 4 4 1 1 到着順序 転送順序 田山 1 1
  • 90. 単一スキルへのキューイング
    • Queue to Skill ノードにて単一のスキルに同一優先度でキューイングした場合、呼は先着順にエージェントへ割り振られる。
    優先度 4 Skill Group A Skill Group B 大山 1 小山 前山 横山 杉山 2 3 4 アニメーション 受信可順序 優先度 1 優先度 2 優先度 3 優先度 1 優先度 2 優先度 3 優先度 4 田川 3 3 田中 4 4 1 1 到着順序 転送順序 田山 1 1 田口 2 2
  • 91. 複数スキルへの同時キューイング
    • 複数のスキルに同一優先度でキューイングした場合どこか一つでもエージェントが受信可となると、そのキューの先頭の呼がエージェントに割り振られる。
    優先度 4 優先度 4 Order L1 Order L2 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 優先度 1 優先度 2 優先度 3 優先度 1 優先度 2 優先度 3 田川 3 田中 4 1 1 到着順序 転送順序 田山 1 田口 2 田川 3 3 田中 4 4 田山 1 1 田口 2 2
  • 92. 複数スキルへの同時キューイング
    • 複数のスキルに同一優先度でキューイングした場合どこか一つでもエージェントが受信可となると、そのキューの先頭の呼がエージェントに割り振られる。
    優先度 4 優先度 4 Order L1 Order L2 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 アニメーション 優先度 1 優先度 2 優先度 3 優先度 1 優先度 2 優先度 3 田川 3 田中 4 1 1 到着順序 転送順序 田山 1 田口 2 田川 3 3 田中 4 4 田山 1 1 田口 2 2
  • 93. 複数スキルへの同時キューイング
    • キューへの配置の仕方次第では、後から到着した呼が先にエージェントに接続される場合もある。
    • 「キューが長くなったらバックアップキューにもルーティング」とした場合など。
    Order L1 Order L2 大山 1 小山 前山 横山 杉山 3 2 4 受信可順序 配送順序が 入れ替わる 配送順序が 入れ替わる 優先度 1 優先度 2 優先度 3 優先度 4 優先度 1 優先度 2 優先度 3 優先度 4 田口 3 2 田川 3 田中 4 1 1 到着順序 転送順序 田川 2 3 田中 4 4 田山 1 1
  • 94. 複数スキルへの同時キューイング
    • キューへの配置の仕方次第では、後から到着した呼が先にエージェントに接続される場合もある。
    • 「キューが長くなったらバックアップキューにもルーティング」とした場合など。
    優先度 4 優先度 4 Order L1 Order L2 大山 1 小山 前山 横山 杉山 3 2 4 受信可順序 アニメーション 優先度 1 優先度 2 優先度 3 優先度 1 優先度 2 優先度 3 田川 3 田中 4 1 1 到着順序 転送順序 田川 2 3 田中 4 4 田山 1 1 田口 3 2
  • 95. 優先度付きキューイング
    • 単一のキューに優先度の異なる呼がキューイングされている場合は、優先度の高い呼からエージェントに接続される。
    Skill Group A Skill Group B 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 優先度 1 優先度 2 優先度 3 優先度 4 優先度 1 優先度 2 優先度 3 優先度 4 田口 4 2 田川 1 3 田中 2 4 1 1 到着順序 転送順序 田山 3 1
  • 96. 優先度付きキューイング
    • 単一のキューに優先度の異なる呼がキューイングされている場合は、優先度の高い呼からエージェントに接続される。
    優先度 2 優先度 4 Skill Group A Skill Group B 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 アニメーション 優先度 1 優先度 3 優先度 1 優先度 2 優先度 3 優先度 4 田川 1 3 田中 2 4 1 1 到着順序 転送順序 田山 3 1 田口 4 2
  • 97. 優先度付きキューイング
    • 優先度の高いキューに呼がある限り、低いキューの呼はエージェントに接続されない。
    Skill Group A Skill Group B 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 優先度 1 優先度 2 優先度 3 優先度 4 優先度 1 優先度 2 優先度 3 優先度 4 1 1 到着順序 転送順序 田口 4 2 田川 3 3 田中 1 4 田山 2 1
  • 98. 優先度付きキューイング
    • 優先度の高いキューに呼がある限り、低いキューの呼はエージェントに接続されない。
    優先度 1 優先度 2 優先度 4 Skill Group A Skill Group B 大山 1 小山 前山 横山 杉山 2 3 4 受信可順序 アニメーション 優先度 3 優先度 1 優先度 2 優先度 3 優先度 4 1 1 到着順序 転送順序 田川 3 3 田中 1 4 田山 2 1 田口 4 2
  • 99. 複数キューで同時に受信可となった場合
    • 複数の Skill を持つエージェントが受信可となったとき、それぞれの Skill に待ち呼があると、先にキューイングされていた呼が優先される。
    Skill Group A Skill Group B 大山 小山 前山 横山 杉山 受信可順序 1 2 3 4 優先度 1 優先度 2 優先度 3 優先度 4 優先度 1 優先度 2 優先度 3 優先度 4 田中 4 4 1 1 到着順序 転送順序 田山 1 1 田口 2 2 田川 3 3
  • 100. 複数キューで同時に受信可となった場合
    • 複数の Skill を持つエージェントが受信可となったとき、それぞれの Skill に待ち呼があると、先にキューイングされていた呼が優先される。
    優先度 4 優先度 4 Skill Group A Skill Group B 大山 小山 前山 横山 杉山 受信可順序 アニメーション 1 2 3 4 優先度 1 優先度 2 優先度 3 優先度 1 優先度 2 優先度 3 1 1 到着順序 転送順序 田口 2 2 田川 3 3 田中 4 4 田山 1 1
  • 101. 複数キューに複数優先度の呼がある場合
    • 最も優先度の高いキューの中で、最初にキューイングされた呼から順にエージェントに接続される。
    • 優先度の同じ異なるキューでは、古い呼が優先。
    Skill Group A Skill Group B 大山 小山 前山 横山 杉山 受信可順序 1 2 3 4 優先度 1 優先度 2 優先度 3 優先度 4 優先度 1 優先度 2 優先度 3 優先度 4 1 1 到着順序 転送順序 田川 3 3 田中 2 4 田山 4 1 田口 1 2
  • 102. 複数キューに複数優先度の呼がある場合
    • 最も優先度の高いキューの中で、最初にキューイングされた呼から順にエージェントに接続される。
    • 優先度の同じ異なるキューでは、古い呼が優先。
    優先度 2 優先度 4 優先度 2 優先度 3 Skill Group A Skill Group B 大山 小山 前山 横山 杉山 受信可順序 1 2 3 4 アニメーション 優先度 1 優先度 3 優先度 1 優先度 4 1 1 到着順序 転送順序 田中 2 4 田山 4 1 田口 1 2 田川 3 3
  • 103. キューイングの実装
  • 104. キューイング実装の要点
    • 必ずキューイング開始時点で VRU が Routing Client であること。
      • IP IVR 使用時は、 Translation Route to VRU を事前に実行
      • CVP の場合は事前の Translation Routing は不要
    • Queue to Skill Group ノードを用いてキューイング
    • 優先度の変更はキューイング開始時に Queue to Skill Group ノードで、またはキューイング開始後に Queue Priority ノードで行う。キューイング前には変更できない。
    • Interruptible な VRU Script を待ち合わせアナウンスに使用。
  • 105. シンプルなキューイングの例 事前に Routing Client を VRU に変更 指定の Skill Group に対してキューイング 待ち合わせアナウンスの再生 アナウンスのループ
  • 106. キューイング (Queue to Skill)
    • 指定された Skill Group (または Enterprise Skill Group )へ呼をキューイングする。
    • キューイング時に呼の優先度を設定可能。
    • 実行時の Routing Client は VRU でなければならない。
    • 待ち合わせのアナウンスは Run External Script を続けて実行することで明示的に再生。
  • 107. Queue to Skill Group の設定 (1/3) キューイング先の Skill Group を指定。 複数選択された場合は同時にキューイングされる。 Queue to Skill Group のプロパティ
  • 108. Queue to Skill Group の設定 (2/3) Queue to Skill Group のプロパティ 必要であればここで優先度を変更する。 優先度 1 が最優先。優先度 10 が優先度最低。 CVP の場合、 Router re-query をイネーブルにする。 IP IVR ではこの機能はサポートされていない。
  • 109. Queue to Skill Group の設定 (3/3) Queue to Skill Group のプロパティ Consider If ( 前提条件 ) の設定 SkillGroup.pg1_1.Cisco_Voice.FrontLnSg.LoggedOn > 0 ターゲットの Skill Group にログインしているエージェントが一人もいない状況、即ち、応答の見込みがない j 状況にも関わらずキューイングしてしまうことを防ぐには、 Consider If に上記式を適用してキューイングを回避する。
  • 110. 優先度の変更
    • 既にキューイングされている呼の優先度を変更するには、 Queue Priority ノードを用いる。
      • 最初から優先度を変更するには Queue to Skill Group の優先度設定を用いる。
    • キューイングされている全てのキューに対して、呼の優先度が指定されたものに変更される。
    • 優先度の既定値は 5 。最優先は 1 、最も低い優先度は 10 。
    • Queue Priority の後で Queue to Skill Group を実行すると、その Queue to Skill Group で指定した キュー (Skill Group) に関してのみ優先度が Queue Priority の設定ではなく Queue to Skill Group の設定になる。
  • 111. 優先度の変更例
    • 一旦キューイングした呼を、キュー毎に異なる優先度へ変更することはできない。
    • キュー毎に異なる優先度でのキューイングは、最初にキューイングするタイミングでのみ可能。
    既定値の優先度 5 でキューイング 10 秒間待ち合わせ 優先度を 4 に上昇
  • 112. 異なる優先度でのキューイング
    • Skill Group 毎に異なる優先度でキューイングしたい場合は、キュー毎に Queue to Skill Group ノードを分け、それぞれで優先度を設定する。
    • 上記例のように Queue to Skill Group ノードを重ねると、キューイング先が追加される。(先行キューはキャンセルされない)
    優先度 4 で キューイング 優先度 6 でキューイング
  • 113. キューイングのキャンセル
    • キューイングされた呼を強制的にキューから取り出すには、 Cancel Queuing ノードを使用する。
    • Cancel Queuing は全てのキューから呼を取り出す。
    • 特定のキューからのみ取り出す方法はない。
    • キューから取り出された呼はまだ接続された状態になっているため、適切に処理する必要がある。
  • 114. 特定エージェントへのキューイング
  • 115. 特定エージェントへのキューイング
    • Queue to Agent ノードを用いて、指定のエージェントに対してのみ呼をキューイングすることが可能。
    • 下記設定上の準備が必要
      • Cisco_Voice の Media Routing Domain に属するダミーの Servcie
      • Cisco_Voice の Media Routing Domain に属するダミーの Skill Group とその Route 及び、 Route からの上記ダミーの Serice への参照
      • 上記ダミーの Skill Group を含むダミーの Enterprise Skill Group
      • 上記ダミーの Skill Group に属する Route を含むダミーの Enterprise Route
  • 116. ダミーの Service と Skill Group, Route Agent Queue 用のダミー Service ダミーの Route と ダミー Service への参照 Cisco_Voce Cisco_Voce ダミーの Skill Group Service Explorer Sill Group Explorer
  • 117. ダミーの Enterprise Skill Group と Enterprise Route ダミーの Skill Group ダミーの Skill Group に設定された Route Enterprise Route List Enterprise Skill Group List
  • 118. エージェントへのキューイング スクリプト例 ダミーの Enterprise Skill Group と Enterprise Route Caller Entered Digit Peripheral を指定 エージェントの指定方式は、下記 三種類のいずれかを選択。 Peripheral Number (Agent ID) Skill Target ID Enterprise Name
  • 119. 発信
  • 120. CCE における発信
    • CCE では、 CTI Desktop からの発信が強く推奨される。
    • IP Phone を操作して発信した場合、次の制限事項がある。
      • CCE のレポートが正確に記録されない。
      • Agent ID (Peripheral Number 等 ) を指定しての発信ができないため、フリーシーティングが困難。
      • 他 Agent に向けた発信の場合、相手先離席中の場合でも迂回やキューイングができない。
      • CCE による発信先の規制ができない。
  • 121. CTI OS Agent Softphone の Dial Pad Agent ID (Peripheral Number) も指定可能
  • 122. CTI からの発信の流れ Dialed Number Dialed Number Plan Call Type Routing Script Label Label 一致 一致せず ダイヤルされた 番号で発信 Routing Script が 応答した Label で 発信
  • 123. Dialed Number Plan
    • Agent Desktop による発信を、ダイヤルされた番号 (Called Party) に基づいて分類する。
    • 数字とワイルドカードの文字列によるパターン一致を用いて分類。コンセプトは Communications Manager の Route Pattern に類似。
    • 一致したパターン毎に、いずれかの処理を選択する。
      • ダイヤルされた番号に基づき発信
      • 発信をブロック
      • Post Routing を実行 (Routing Script を起動 ) し、スクリプトが応答した Label に発信
    Agent to Agent 転送は Dial Number Plan の Post Routing 機能を用いて実装される。
  • 124. Dialed Number Plan Bulk ツール Post Routing を行う場合、ここで指定した Dialed Number に関連付けられた Call Type を 通じて Routing Script を起動する このパターンで到達できる 宛先の分類 Post Routing を行わない 場合の番号加工 Yes の場合 Post Routing を行う 発信するエージェントが 属する Routing Client パターン
  • 125. 発信時の番号加工
    • Post Routing を行わない場合、 CTI でダイアルされた番号を加工してから PBX に渡すことが可能。
    • Dial String に記述した番号が PBX に渡される。
    • ? ( クエスチョンマーク ) を指定すると、当該桁の番号はダイヤルされたものがそのまま渡される。
    • X を指定すると、当該桁が削除される。
    • Post Routing を行う場合は Dial String は無効。
  • 126. 発信先の制限
    • Dial Number Plan Type を用いて発信先を分類
      • 国際電話
      • 国内外線
      • 自営網内の他 PBX 内線
      • 同一 PBX 内の内線
      • 中継台
    • 分類毎に発信の許可・不許可を制御
    • Agent Desk Setting 毎に許可する発信先を指定
  • 127. 発信先の制限(続き)
    • エージェントが CTI で発信すると、 CTI からダイヤルされた番号と Dialed Number Plan に設定された全てのパターンとの間でマッチング判定が行われる。
    • パターンがマッチすると、マッチしたパターンの Dial Number Plan Type が発信したエージェントの Agent Desk Setting にある Outbound Access でチェックされているかどうかを調べる。
    • チェックがあればさらに処理を継続、チェックがなければエラーを返す。
    Dialed Number Plan Agent Desk Setting Agent Desktop に 表示されるエラー
  • 128. 発信時の Post Routing
    • マッチしたパターンに指定された Dialed Number を通じてスクリプトを起動する。
    • Dialed Number 選択後の仕組みは通常の inbound 着信と同じ。すなわち、
      • 関連付けられた Call Type の中から CED 等の条件に合致する Call Type を選択。
      • Call Type に対してスケジュールされた Routing Script の中から、時刻条件に合致するものを選択、起動。
    • CTI でダイアルされた番号は CED (Caller Entered Digit) に格納される。
  • 129. シンプルな発信スクリプト CTI でダイヤルされた番号を そのまま PBX へ渡す。
  • 130. シンプルな発信スクリプト(続き) 変数 Call.CallerEnteredDigits に CTI でダイヤルされた番号が 格納されている。 このスクリプトでは CED をそのまま PBX に渡している。 デフォルトの設定済みラベルではなく ダイナミックラベルを選択する。 CallManager routing client は Router re-query に対応していないため、 Router Re-query は無効に指定する。 Label ノードのプロパティダイアログ
  • 131. 発信とレポート
    • Dialed Number Plan による Post Routing を行って発信して初めて適切なレポートが可能になる。
    • Routing Script が実行されることにより、 Call Type が割り当てられ、 Call Type サマリーレポートが生成される。
    • また、 RouterCallKey 等が生成されるため、 cradle to grave レポートも可能になる。
    • 上記理由により、全ての発信を Post Routing することを推奨。
  • 132. 他エージェントへの発信と エージェント間転送
  • 133. 他エージェントへの発信と転送
    • エージェントから他のエージェントへの発信及び、エージェント間の転送は、 Dialed Number Plan による Post Routing と Agent to Agent Transfer ノードを用いて実現する。
    • Dialed Number Plan にエージェントへ発信するためのパターンを設定する。通常は Agent ID (Peripheral Number) もしくはそれにプレフィックスを付加したもの。
    • 入力されたエージェント識別情報をエージェントがログインしている実際の内線番号に対応した Label へ変換するのが Agent to Agent ノードの働き。
  • 134. エージェント間転送用発信設定例
    • Agent ID (Peripheral Number) の使用する番号レンジを Dialed Number Plan のパターンとして登録。この例ではプレフィックスなしにそのままダイアルするオペレーションを想定。
    • エージェント間転送用の Dialed Number と関連付ける。 Dialed Number はさらに専用の Call Type を経てルーティングスクリプトへと関連付けられる。
    • エージェント転送の開始を許可するエージェントの Agent Desk Setting で、 PBX への発信を許可、一方、上記パターンの Dial Number Plan Type を PBX とする。
    Dialed Number Plan Agent Desk Setting
  • 135. エージェント間転送スクリプト
    • エージェント転送ノードは、入力された値を Agent ID (Peripheral Number) とみなして、そのエージェントがログインしている内線に対応した Label を応答し、スクリプトを終了する。
    Peripheral Number によるエージェントの指定 エージェントを収容している Peripheral を選択 Call.CallerEnteredDigits に Agent ID (Peripheral Number) が 格納されているため、これを入力値として指定 対象エージェントが Ready の場合のみ Label を応答。 その他は失敗分岐へ処理を進める。
  • 136. エージェント状態の無視
    • エージェント間転送ノードの一番下にあるチェックボックス「エージェントを使用できない場合はノードも失敗」はチェック状態での使用を推奨。
    • このチェックを外すと、エージェントが離席中でも呼び出してしまう。また、 Outbound Option との併用のために ACD line の busy trigger が 2 以上に設定されている場合は、エージェントが通話中であっても呼び出してしまう。
    • いずれも好ましくないため、明確な理由があり、十分な検討を行った上でない限り、チェックを外すことは推奨しない。
      • 同じ理由で、エージェント IP Phone の第二のラインを直接呼び出すことも好ましくない。(他章で解説)
  • 137. RONA: 無応答時の再ルーティング
  • 138. Reroute on No Answer (RoNA)
    • エージェントに呼が転送されたにもかかわらず、エージェントがその呼に応答しない場合がある。
    • エージェントが「受信可」のままで離席してしまった場合等に発生し得る。
    • 一定時間呼び出しても応答しない場合、その呼を他のエージェントに再転送するか再びキューに戻さなくてはならない。
    • エージェントに対する教育上、 RONA の発生を検知し、発生させたエージェントを特定できることも重要。
  • 139. CVP における RoNA
    • CVP は Router re-query 機能に対応するため、 RoNA はこれを利用する。
    • CVP が Routing Client のときに、エージェントへ呼が転送されると、実際にはコンサル転送が実行され、 CVP が呼に対する制御を保持し続ける。
    • エージェントが応答しないと( RoNA が発生すると) スクリプトの実行が Select ノードや Queue to Skill Group ノードの失敗側分岐へと進み、同じスクリプト上で RoNA 後の処理を行うことができる。
    • 優先度を最大にして再度キューイングする、といった処理が想定される。
    • この仕組みは、無応答以外の何らかの理由で転送が失敗した場合にも利用できる。
  • 140. Router Re-query の有効化 Select ノード、 Queue to Skill Group ノード等で Router Re-query を有効にするチェックボックスにチェックを入れる。 Queue to Skill Group のプロパティ
  • 141. Router re-query を用いた RoNA 回復不能 エラー 失敗理由の判定 転送先話中または無応答ならば右へ さもなければ下へ ここでの失敗も Re-query でリカバリー 既定優先度でキューイング 最優先でキューイング 通常パス Re-query 時のパス
  • 142. Re-query 理由の判定 Call.RequeryStatus 変数の値で判断 Call.RequeryStatus 変数の値 値の意味 REQUERY_ANSWER (0) 内部使用 REQUERY_ROUTE_SELECT_FAILURE(1) ターゲットの選択に失敗 REQUERY_CALLED_PARTY_BUSY (2) 転送先話中 REQUERY_NO_ANSWER (3) 転送先無応答 REQUERY_ERROR (4) 転送先到達不能 REQUERY_TIMED_OUT (5) 内部使用 REQUERY_ABORTED (6) 内部使用
  • 143. IP IVR における RoNA
    • IP IVR は Router Re-query 機能を持たないため、 RoNA もこれを利用できない。
    • IP IVR が Routing Client のときに、エージェントへ呼が転送されると、実際にはブラインド転送が実行され、その時点で IP IVR は呼に対する制御を失う。同時にスクリプトは終了する。
    • エージェントが応答しないと( RoNA が発生すると) Agent Desk Setting の Ring no answer dialed number へ呼が転送される。
    • 直前のスクリプトに関係なく、 RoNA 時に起動されるスクリプトはエージェント当たり一つだけ。
    • この仕組みは、無応答以外の何らかの理由で転送が失敗した場合には利用できない。
  • 144. IP IVR における RoNA の制限事項
    • Router Re-query が使用できない場合の RoNA は、キューイングしたスクリプトが制御を失い、全て Agent Desk Setting に設定された一つのスクリプトへジャンプしてしまう。
    • RoNA 前と同じターゲットへルーティングするには、ターゲット情報をあらかじめコール変数に保持しておく必要がある。
  • 145. 追加
    • IP IVR での RoNA について、サンプルの絵が必要。
    • 特に対象スキルを引き継ぐ方法とその制限。
  • 146. CCM PIM における RoNA
    • エージェントが他のエージェントを呼び出す際、呼び出されたエージェントで RoNA が発生し得る。エージェントが発信する際の Routing Client は Unified CM 。
    • Unified CM は Router re-query 機能を持たないため、 RoNA もこれを利用できない。したがって IP IVR の場合と同じになる。
    • エージェントからの発信時にも Router re-query を利用したい場合は、発信した呼をルーティングするスクリプト上で Translation Routing を行って CVP に一旦呼を渡す。
  • 147. RoNA にまつわるタイマー
    • RoNA 発動までの時間は Agent Desk Setting の Ring no answer timer で決まる。
    • Agent Desk Setting の Ring no answer timer
      • 下記二つのタイマーのいずれよりも短い時間でタイムアウトしなくてはならない。
    • Unified CM の Call Forward No Answer Timer
      • Agent Desk Setting の Ring no answer timer より長くなくてはならない。
    • CVP の RNATimeout
      • Agent Desk Setting の Ring no answer timer より長くなくてはならない。
    • これらが守られないと、 RoNA 時に応答しなかったエージェントの状態が適切に受信不可に遷移しない。
  • 148. 追加
    • Supervisor Assist と Emergency Call の説明が欠けている。
  • 149. レポーティング
  • 150. スクリプトの作りに影響するレポート例
    • 呼が何番の電話に、いくつ着信したか
    • メニュー応答中の放棄はいくつか
    • どのサービスにいくつ着信したか
    • バックアップグループへの「溢れ」はいくつか
    • プレミアム顧客からの着信はいくつか
    • 転送(エスカレーション)はいくつか
    • 時間外の着信はいくつか
    • 何らかのエラーで切断された呼はいくつか
  • 151. 着信番号毎のレポート
    • 着信番号毎に呼がいくつ着信したかレポートしたい。
    • Dialed Number 毎に異なる Call Type を設定。
    • 各 Call Type のレポートから、着信数が分かる。
  • 152. メニュー中放棄と待ち呼中放棄の区別
    • 音声応答メニューの中で放棄された呼の数と、キューイング中に放棄された呼の数を区別してレポートしたい。
    • 音声応答に費やされた時間と、キューイングに費やされた時間を区別してレポートしたい。
    • 音声応答メニューの入り口で専用の Call Type を設定し、メニューが終了した後のターゲット選択の直前でターゲットセット毎に専用の Call Type に変更する。
  • 153. メニューとキューを区別するレポート メニュー用 Call Type この先のスクリプトではキューイングのみ実行
  • 154. 呼の分類に基づくレポート
    • どのサービスにいくつ着信したか
    • プレミアム顧客からの着信はいくつか
    • 時間外の着信はいくつか
    • 何らかのエラーで切断された呼はいくつか
  • 155. エラーのレポーティング例 メニュー用 Call Type この先のスクリプトではキューイングのみ実行 トランスレーションルーティングの失敗 音声応答スクリプト実行の失敗
  • 156. 転送(エスカレーション)のレポート
    • 他エージェントへの発信 (Agent to Agent 転送 ) を実行するスクリプトの Call Type でレポートする。
    • 単純な他エージェントへの発信と顧客からの呼を他エージェントへ転送するためのコンサルコールの発信は、 Call Type レポートでは区別できない。
    • どうしても区別する場合は、単純コール発信時とコンサルコール発信時で使用するプレフィックスを分け、 Dialed Number Plan で異なる Dialed Number をキックするよう設計する。
  • 157. 溢れ呼のレポート例 Skill Group OrderL1Sg で処理された呼をレポート Skill Group OrderL1Sg から溢れた呼をレポート ただし、キューイング後にどちらで処理されたかまでは判断できない。
  • 158. 追加
    • 他に取り上げるべきレポートはないか?
  • 159. 応用編
  • 160. スキルレベルのエミュレーション
  • 161. スキルレベルに基づくルーティングとは
    • エージェントリッチな状況
      • 受信可のエージェントが複数存在する状況で、可能な限りスキルの高いエージェントを選択する。
      • 受信可のエージェントの中でスキルの高いエージェントへ優先的に呼を分配する。同じスキルレベルの中では Longest Available Agent へ転送。
    • コールリッチな状況
      • 複数のスキルに待ち呼が存在する状況で、対応するエージェントのスキルが可能な限り高くなるように呼を選択する。
      • あるエージェントが受信可に遷移したとき、そのエージェントから見て最も高いスキルで待ち合わせている呼を優先的にデキューする。
  • 162. スキルレベルのエミュレーション
    • いわゆるスキルレベル ( あるいは competency routing と言われるルーティング ) は CCE の機能としては提供されていない。
    • 以下に述べる回避策によってスキルレベルをエミュレートする。
    • 同一スキルに対して、高レベルエージェント用と低レベルエージェント用にそれぞれ異なる Skill Group を割り当てる。
    • より多段階のレベルが必要ならばレベルの数だけ Skill Group を設ける。
  • 163. スキルレベルのエミュレーション スクリプト実行ロジック
    • 呼を、最初に高レベルエージェントの Skill Group へ通常の優先度でキューイングする。
      • この時点でエージェントが受信可であれば直ちに転送される
    • 続いて、低レベルエージェントの Skill Group へ 低い優先度 でキューイングする。
      • この時点でエージェントが受信可であれば直ちに転送される
      • キューイング後、あるエージェントが受信可になると、そのエージェントから見て最高レベルの Skill Group に最も高い優先度で呼がキューイングされているため、最高レベルの Skill Group の待ち呼を受信する。
  • 164. スキルレベルのエミュレーション例 スキルレベルをエミュレーションするスクリプトの例 高レベルエージェント用の Skill Group “QandAL1Sg” に最初にルーティングを試みる。受信可なエージェントがいれば直ちに LAA でエージェントを選択、受信可のエージェントがいない場合は優先度 5 でキューイングする。 続いて低レベルエージェント用の Skill Group “QandAL2Sg” にルーティングし、こちらにも受信可のエージェントいれば直ちに選択され、いない場合はより低い優先度 6 でキューイングする。
  • 165. メインスキルでエージェントが受信可
    • 呼を SG A に配信する。最初に SG A L1 へキューイングを実行
    • この段階ですぐにエージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 1 2 3 4 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 1 到着順序 転送順序 田山 1 1
  • 166. メインスキルでエージェントが受信可
    • 呼を SG A に配信する。最初に SG A L1 へキューイングを実行
    • この段階ですぐにエージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 1 2 3 4 アニメーション 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 1 到着順序 転送順序 田山 1 1
  • 167. バックアップスキルでエージェントが受信可
    • 呼を SG A に配信する。最初に SG A L1 へキューイングするが全員受信不可
    • SG A L2 へ追加キューイングし、この段階でエージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 1 2 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 1 到着順序 転送順序 田山 1 田山 1 1
  • 168. バックアップスキルでエージェントが受信可
    • 呼を SG A に配信する。最初に SG A L1 へキューイングするが全員受信不可
    • SG A L2 へ追加キューイングし、この段階でエージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 1 2 アニメーション 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 1 到着順序 転送順序 田山 1 田山 1 1
  • 169. キューイング後、 メインスキルでエージェントが受信可
    • 呼が SG A L1, L2 へキューイング
    • SG A L1 のエージェントが受信可に遷移
    • 当該エージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 1 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 SG B に待ち呼なし 1 1 到着順序 転送順序 田山 1 1 田山 1
  • 170. キューイング後、 メインスキルでエージェントが受信可
    • 呼が SG A L1, L2 へキューイング
    • SG A L1 のエージェントが受信可に遷移
    • 当該エージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 1 アニメーション 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 SG B に待ち呼なし 1 1 到着順序 転送順序 田山 1 1 田山 1
  • 171. キューイング後、 バックアップスキルでエージェントが受信可
    • 呼が SG A L1, L2 へキューイング
    • SG A L2 のエージェントが受信可に遷移
    • 当該エージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 SG B に待ち呼なし 1 1 到着順序 転送順序 田山 1 田山 1 1
  • 172. キューイング後、 バックアップスキルでエージェントが受信可
    • 呼が SG A L1, L2 へキューイング
    • SG A L2 のエージェントが受信可に遷移
    • 当該エージェントへ転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 アニメーション 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 SG B に待ち呼なし 1 1 到着順序 転送順序 田山 1 田山 1 1
  • 173. 複数スキルに待ち呼がある状態で、 マルチスキルのエージェントが受信可
    • SG A に古い待ち呼、 SG B に新しい待ち呼
    • SG A L2 と SG B L1 を持つエージェントが受信可
    • SG B で待ち合わせ中の呼をエージェントに転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 2 1 1 到着順序 転送順序 田山 1 田山 2 1 田口 2 田口 1 2
  • 174. 複数スキルに待ち呼がある状態で、 マルチスキルのエージェントが受信可
    • SG A に古い待ち呼、 SG B に新しい待ち呼
    • SG A L2 と SG B L1 を持つエージェントが受信可
    • SG B で待ち合わせ中の呼をエージェントに転送
    優先度 6 優先度 6 優先度 6 優先度 5 SG A L1 SG B L2 大山 小山 前山 横山 杉山 受信可順序 アニメーション 優先度 5 優先度 5 優先度 5 優先度 6 SG B L1 SG A L2 1 2 1 1 到着順序 転送順序 田山 1 田山 2 1 田口 2 田口 1 2
  • 175. スキルレベルのエミュレーション別例 キューイング時に優先度をつけない場合の例 高レベルエージェント用の Skill Group “OrderL1Sg” に最初にルーティングを試みる。 高レベルエージェントが一人も available でなかった場合、キューイングに備えて呼を VRU へ転送し、その後両方のレベルのエージェント用の Skill Group 、つまり “ OrderL2Sg” と “ OrderL1Sg” に同時にキューイングする。 もし “ OrderL2Sg” に available なエージェントがいた場合はただちにルーティングされる。
  • 176. その他応用トピック
  • 177. カスタム関数
  • 178. カスタム関数 (SkillGroup.%1%.AnswerWaitTimeTo5 + 1) / (SkillGroup.%1%.CallsAnsweredTo5 + 1) この例では引数に Skill Group 名を取り、予想待ち時間を返すカスタム関数を定義している。
  • 179. 予想待ち時間の計算
    • 下記は予想待ち時間の計算をする式の一例
      • (SkillGroup.<Skill Group 名 >.AnswerWaitTimeTo5 + 1) / (SkillGroup. <Skill Group 名 >.CallsAnsweredTo5 + 1)
    • 計算の実際
      • 結果がもっともらしくなるには、 0 秒等の極端な結果を避けるよう「下駄をはかせる」などの調整を入れる必要がある。
      • また、 Skill Group に available なエージェントがいる場合は 即座にルーティングするなど、境界条件での予測を避ける工夫も必要。
  • 180. 予想待ち時間の活用例
    • キューイング中の予想待ち時間アナウンス
    • ルーティングターゲットの拡大・縮小
    • コールバックの提案、架け直しの提案
    • 無人セルフサービスへの誘導
  • 181. 自動適応型ルーティング
    • 呼の待ち時間が長くなるにつれ、キューイングする Skill Group の範囲を徐々に拡大していく。
    • 単純な溢れ処理ではなく、ある程度キューイングしてから溢れさせる。
    • キューイングを伴わない溢れ処理と比較して、短時間の呼のラッシュをキューが吸収可能となり、より多くの呼がスキルの高いエージェントに扱われる可能性が高まる。
    • 単純溢れ処理では対応できないコールリッチな状況にある程度対応できる。
  • 182. 自動適応型ルーティングの例 まずもっともスキルの高いグループにキューイング 20 秒後に 2 番目のグループに対象を拡大 更に 40 秒後に最もスキルの低いグループにまで拡大
  • 183. 動的優先度キューイング
    • 最初は優先度の低い呼であっても、待ち時間が長くなるにつれ優先度を徐々に上げていく。
    • 高優先度の呼が多く到来すると、単純な優先キューイングでは優先度の低い呼が不当に長く待たされる。
    • 優先度の低い呼にもある程度公平に機会を与えるための工夫。
  • 184. 動的優先度ルーティングの例 優先度 5 優先度 4 優先度 3 優先度 2
  • 185. Last Agent ルーティング
    • 同じ顧客からの電話を、なるべく最後に対応したエージェントへとルーティングする。
    • 顧客毎に「 Last Agent 」を記録する、外部データベースが必要。
    • 外部データベースへの書き込みには、 CAD もしくはカスタマイズした CTI OS Agent Desktop と連動してデータベースへ書き込むカスタムアプリが必要。
    • ルーティング時は、外部 DB へアクセスして「 Last Agent 」 ID を取得し、 Agent to Agent ノードを用いてそのエージェントに呼を転送する。
  • 186. 拠点を意識したルーティング
    • 拠点を意識したルーティングを行うには、拠点毎に Skill Group を設定する。
    • 特定拠点の Skill Group に対してまず優先的に呼をルーティングし、溢れたところで、他の拠点用の Skill Group へとルーティングする。
  • 187. 追加
    • 直前2枚についてはより詳しい説明と具体的な絵が欲しい。
  • 188. 付録 Script Editor の各種機能
  • 189. Script Explorer
  • 190. モニターモード
  • 191. 妥当性検証機能
  • 192. シミュレーター
  • 193. 付録 : CCE スクリプトのノード解説
  • 194. 開始 (Start)
    • 全てのルーティングスクリプトは、開始ノードをひとつだけ持つ。
    • スクリプトが呼び出されると、このノードから実行が開始される。
  • 195. 終了 (End)
    • ルーティングスクリプトを終了するノード。
    • 終了ノードはいくつあっても良い。
    • 呼が接続されたままでこのノードに到達すると、切断される。
  • 196. ノードへのコメントの書き込み
    • 殆どのノードには、任意のコメントを書き込むことができる。
    • 多くのノードは、コメントを書き込まないと主要なプロパティの値を表示する。
    • コメントは上記プロパティーの表示を上書きする。
  • 197. コメント (Comment)
  • 198. コネクタ (Connector)
    • コネクタノードは、ノードとノードを接続する直線(コネクタ)を迂回するのに使用する。
    • スクリプトを見やすくする目的。
    • 実行時には何の機能も持たない。
  • 199. 条件 (If)
    • 条件ノードは汎用の条件判断を行う。
    • 条件を定義した式の評価値が ture ( 非ゼロ ) のときは、成功側の接続へ処理が進む。
    • False ( ゼロ ) のときは、失敗側に処理が進む。
  • 200. 変数設定 (Set)
    • 変数設定ノードは、任意の変数に任意の式の値を代入する。
  • 201. スクリプト切替 (Goto)
    • スクリプト切替は、処理を別のスクリプトへと移す。
    • 処理がこのノードに到達すると、このノードが含まれるスクリプトの実行は終了し、代わりにこのノードのプロパティに指定されたスクリプトへ処理が切り替わる。
    • 変数等は切替先のスクリプトに引き継がれる。
  • 202. スクリプト変更 (Requalify Call)
    • スクリプト変更は、 Call Type を変更すると同時に処理を別のスクリプトへと移す。
    • 処理がこのノードに到達すると、このノードが含まれるスクリプトの実行は終了する。 Call Type がノードのプロパティに指定されたもの変更され、変更後の Call Type に関連付けられたスクリプトへ処理が移る。
    • 変数等は変更先のスクリプトに引き継がれる。
  • 203. 曜日 (Day of Week)
    • 曜日ノードは実行時の曜日を条件として分岐する。
    • 分岐数、曜日の組み合わせは任意。
  • 204. 時間 (Time)
    • 時間ノードは、実行時の時刻を条件として分岐する。
    • 分岐数は任意。
    • 一つの分岐に複数の非連続な時間帯を設定することが可能。
    • 図は、 0 時から午前 9 時と午後 9 時から 0 時に接続 A へ分岐し、午前 9 時から午後 5 時は B 、午後 5 時から 9 時は C へ分岐している。
  • 205. 時間 (Time) ( 続き ) 17 時を境に接続 B から 接続 C へ処理の進み先が切り替わっている様子
  • 206. 時間 (Time) ( 続き ) 接続毎にその接続へ分岐する時間帯を追加していく。時間帯を複数指定できるため、不連続な時間帯指定も可能。
  • 207. パーセント配分 (Percent)
    • 処理を指定したパーセンテージで配分するノード。
    • このノードに到達した処理の、指定割合が指定の接続へ進む。
    • 図は接続 A へ 20% 、 B へ 30% 、 C へ 50% 配分している。
  • 208. スイッチ (Switch)
    • 処理の流れを手動できりかえるためのノード。
    • アクティブに設定された接続へと処理が進む。
    • 図は接続 A がアクティブとなっており、処理は全て A へと進む。
  • 209. スイッチ (Switch) ( 続き )
    • 接続 B をアクティブに切り替えた様子。
    • 切り替え実行以後このノードに到達した処理は全て 接続 B へと進む。
  • 210. コールタイプ (Call Type)
    • 処理中の呼の Call Type を指定したものへと変更する。
    • 変更前の Call Type レポートには flow out した呼としてカウントされる。
    • 変更後の Call Type レポートには flow in した呼としてカウントされる。
  • 211. 発信者入力番号 (CED)
    • Call.CallerEnteredDigit の値に従って分岐。
    • 分岐数は任意。
    • 一つの分岐に複数の入力番号を割り当て可能。
    • 入力番号の桁数は任意。ワイルドカードは使用不可。
  • 212. 選択 (Select)
    • 指定したルールに従ってターゲットを選択する。
    • CCE ではターゲットは Skill Group もしくはエージェント。
    • ACD Deployment では Service もターゲットにできる。
    • ターゲットの指定法は次のスライド。
  • 213. 選択ノードにおけるターゲットの指定法
    • 選択ノードのターゲットは、後続のスキルグループノードで指定する。
    • 選択ノードの成功側分岐にスキルグループノードを接続。
    • スキルグループノードのプロパティでターゲットとなる Skill Group を列挙する。
    • ターゲットの選択に成功すると、スクリプトは終了する。失敗すると、失敗側分岐に処理が進む。
  • 214. スキルグループ (Skill Group)
    • 選択ノードのターゲットとなるスキルグループを指定する。
  • 215. スキルグループ (Skill Group)
    • ターゲットの指定方法。
  • 216. エージェント転送 (Agent to Agent) Peripheral Number による エージェントの指定。 最も広範に利用可能。 Skill Target ID によるエージェントの指定。 主に Supervisor Assist Call に使用。 Enterprise Name による エージェントの指定。 動的指定不可。
  • 217. ラベル (Label)
    • Routing Client に対 して Label そのもの を返すことで明示的 に呼の最終的なターゲットを指示する。
    • 応答する Label は事前に設定済みのものまたは計算式によって動的に生成したもの。
    • 実行時の Routing Client が固定しない場合( Routing Client が VRU で負荷分散されている場合等)は可能性のある全ての Routing Client に対応するラベルを設定しておく必要がある。
  • 218. VRU トランスレーションルート (Translation Route to VRU)
    • 異なる Routing Client の VRU へと呼を転送する。転送に伴って Routing Client が変わるのが特徴。
    • 転送も引き続き CCE が新しい Routing Client を通じてその呼を制御する。
    • CCE では、 CM PIM の制御する CTI RP から VRU PIM の制御する IP IVR へ呼を渡す際に用いられる。
    • TDM ACD へ呼を渡す際にも使用される。
    • CVP では必ずしも必要ではないが、 Pre-routing や Release Trunk Transfer では必要になることもある。
  • 219. VRU トランスレーションルート (Translation Route to VRU) のプロパティ Offline またはフル稼働中の VRU を回避する式を設定 空きポート数を返す式を設定 トランスレーションルート
  • 220. スクリプト実行 (Run External Script)
    • VRU 上の音声応答スクリプトを起動する。
    • スクリプトが実行され終了ステータスコードが true ( 成功 ) の場合は成功側分岐へ処理を進める。
    • スクリプトが実行できなかったり、終了ステータスコードが false ( 失敗 ) で終了した場合は失敗側分岐へ処理を進める。
  • 221. キューイング (Queue to Skill)
    • 指定された Skill Group (または Enterprise Skill Group )へ呼をキューイングする。
    • キューイング時に呼の優先度を設定可能。
    • 実行時の Routing Client は VRU でなければならない。
    • 待ち合わせのアナウンスは Run External Script を続けて実行することで明示的に再生。
  • 222. エージェントキューイング (Queue to Agent)
    • 特定のエージェントに対して呼をキューイングする。
    キューイングするエージェントの Agent ID (Peripheral Number) を返す式を設定する。 ここに複数のターゲットを指定すると、即席のスキルグループ的に利用できる。(ただし Skill Group レポートは得られない。) エージェントが属する Peripheral を指定する。 このチェックを外しておくと、エージェントがログインしていない場合にはキューイングせずに失敗側分岐へと処理を進める。
  • 223. キュー優先度 (Queue Priority)
    • 既にキューイングされた呼の優先度を変更する。
    • 最優先が 1 。最低優先度が 10 。
    • 全てのキューで優先度が変更される。
    • Queue Priority ノードの後でキューイングを行った場合、当該キューの優先度はキューイング時の Queue to Skill Group の設定で上書きされる。
  • 224. キャンセルキュー (Cancel Queuing)
    • キャンセルキューノードは、キューイングされた呼を強制的にキューから取り出す。
    • 呼は全てのキューから削除される。
    • 特定のキューからのみ取り出す方法はない。
    • キューから取り出された呼はまだ接続された状態になっているため、適切に処理する必要がある。
  • 225. 付録 : IP IVR の外部システム連携
  • 226. 外部システムとの接続
    • CUCCX がアクセス可能な外部システムは以下のもの
      • SQL DBMS (ODBC)
      • Web アプリケーションサーバ
      • ASR, TTS (MRCP)
      • E-Mail サーバ (SMTP による送信のみ )
    • 外部システム毎に CUCCX サーバ内にサブシステムが動いている
    • 外部システムの定義 ( アドレスなど ) は管理者がサブシステム毎に行う必要がある
    • スクリプトの中で管理者が設定した各外部システムへのアクセス処理を定義する
  • 227. Cisco CUCCX の主要なインタフェース 呼制御 ACD (コール     ルーティング) Communications Manager PSTN Web アプリケーション サーバ Contact Center Express Cisco Agent Desktop Desktop Application CTIQBE (JTAPI) キーイベント CCX CTI Protocol HTTP (GET/POST) SCCP, SIP H.323, MGCP HTML/HTTP, XML/HTTP SQL/ODBC (Read, Write) ODBC 準拠 SQL DBMS Web アプリケーション サーバ IP フォン 音声 ゲートウェイ Java RMI Invoke, Execute RMI enabled Java Application Java class Windows アプリケーション .exe コマンドライン ( 引数付 ) JTAPI / TAPI Telephony Application Servers Web AP サーバ HTTP IP IVR では使用不可
  • 228. 追加
    • CVP と同レベルの粒度の解説が欲しい。
  • 229. 付録 : CVP の外部システム連携
  • 230. はじめに
    • 本資料は、シスコの自動音声応答 (IVR) 製品である Cisco Unified Customer Voice Portal ( 以下 CVP) において CVP とデータベースをはじめとしたバックエンドシステムとの連携を行うための API についての概要を説明する。
  • 231. Unified CVP のバックエンド統合手段
    • JDBC を用いた SQL クエリー発行
    • XML over HTTP による外部 Web アプリケーションサーバーへのリクエストの発行と、 XML によるレスポンスの受信
    • カスタム Java クラスを用いた Java Remote Method Invocation (RMI) によるリモート Java オブジェクトとの連携
  • 232. CVP の外部連携プロトコルと API CVP Server Ingress Gateway Voice XML Gateway (Voice Browser) ASR/TTS Server Unified CCE Web Application Server Java Remote Object Server Database Server SIP SIP VXML/HTTP(S) MRCP SCI XML/HTTP Java RMI JDBC 本資料のスコープ 公衆網
  • 233. CVP サーバーの内部ブロックと API CVP Combo Server Ingress Gateway ASR/TTS Server Unified CCE Web Application Server Java Remote Object Server Database Server SIP SIP VXML/HTTP(S) MRCP SCI XML/HTTP Java RMI JDBC Operating System SIP stack IVR Subsystem CVP Call Server Component CVP VXML Server Component Voice XML Gateway (Voice Browser) 公衆網 Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI
  • 234. 外部 DB へのアクセス Database Server VXML/HTTP(S) JDBC CVP VXML Server Component Voice XML Gateway (Voice Browser) Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI
  • 235. 外部 DB へのアクセス
    • Database Element を使用
    • JNDI で外部 SQL サーバーを point
    • 事前に CVP VXML Server を動かす application server (Tomcat または WebSphere Application Server) 上で JNDI による JDBC 接続を設定しておく必要あり
    • セキュリティは JDBC ドライバーの実装に依存。
  • 236. Database Element
    • Single
      • SQL クエリーを実行し結果としてレコードを一行だけ返す
      • 各カラム(フィールド)名がエレメントデータになる
    • Multiple
      • SQL クエリーを実行し結果として複数のレコードを返す
      • ResultSetList オブジェクトに結果を保持
    • Insert
      • SQL INSERT を実行する
    • Update
      • SQL UPDATE を実行する
    • コマンドタイプ
  • 237. Database Element
    • type
      • コマンドタイプ : Single, Multiple, Insert, Update
    • jndiname
      • SQL data source の JNDI 名
    • key
      • Multiple type クエリーの結果を格納する Session 変数名
    • query
      • SQL Query 文
    • パラメーター
  • 238. Database Element
    • Element Data
      • Single コマンドタイプのみ
      • 各カラム名と同名のエレメントデータを生成
      • データの値は各カラムの値
    • Session Data
      • Multiple コマンドタイプのみ
      • ResultSetList クラスオブジェクトに格納
    • 結果の出力
  • 239. 外部 DB アクセス の冗長化 Database Server VXML/HTTP(S) JDBC CVP VXML Server Component Voice XML Gateway (Voice Browser) JDBC ドライバーによる対応 Database Server JDBC ドライバーが DB サーバーとの接続のキープアライブやバックアップサーバーへの接続の切り替えを自動的に制御。 DB への接続が establish になっていない限りはアプリへ即時にエラーを返すのも JDBC ドライバの動作として実現。 アプリから見て透過的である点が長所。 上記要件を満たす JDBC ドライバーを準備する必要があり、製品の機能に依存することとなる。 Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI
  • 240. 外部 DB アクセス の冗長化 Database Server VXML/HTTP(S) JDBC CVP VXML Server Component Voice XML Gateway (Voice Browser) コネクションプールによる対応 Database Server コネクションプールは、予め DB との接続を確立し、その接続をシステム稼働中ずっと維持することが可能。アプリからの接続要求時は、都度 DB への接続を試みる代わりに、コネクションプール上で既に接続済みのコネクションとアプリを結合し、アプリから解放要求が来ると、アプリとコネクションとの結合を解くのみで DB との接続はそのまま維持する。 コネクションプールは、 DB との接続が確立されていないと直ちにエラーとすることが可能。キープアライブもコネクションプールの機能として実行。 DB ダウン時は、別の DB サーバーへつながるコネクションプールへ接続することでフェイルオーバーする。 標準的な仕組みで実現可能であり、 JDBC ドライバの仕様等への依存性が小さい点が長所。 アプリケーションレベルでフェイルオーバー動作を実装する必要あり。(コネクションプールの機能としてフェイルオーバー可能かどうかは未調査) Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JNDI JDBC JDBC Conn. Pool
  • 241. 外部 DB アクセス の冗長化 Database Server VXML/HTTP(S) JDBC CVP VXML Server Component Voice XML Gateway (Voice Browser) DB クラスタリングによる対応 Database Server DB サーバーのクラスタリングにより、 JDBC ドライバーからは冗長化された DB に対して透過的にアクセスする。 アプリケーション、 JDBC ドライバーに対するインパクトが最小である点が長所。 各種要件を満足する DB クラスタリングに対応した DB サーバー環境が必要。 DB クラスター Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI
  • 242. DB アクセスによる連携のまとめ
    • 長所
      • シンプルな構成
      • カスタム開発作業が最小
      • Web アプリケーション等の中間コンポーネントが不要
    • 短所
      • データベーススキーマ依存性
      • 複雑なロジックは実装困難
      • コールフローアプリケーション内で SQL 構文を取り扱う必要あり
      • 外部 DLL 呼出しは不可能
    • DB との通信の暗号化
      • JDBC ドライバーの仕様に全面的に依存する。
  • 243. XML API を用いた 外部 Web アプリケーションへのアクセス Database Server VXML/HTTP(S) CVP VXML Server Component Voice XML Gateway (Voice Browser) HTTP POST レスポンス Web Application Server 3 rd Party DLL XML XML Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI
  • 244. XML API を用いた 外部 Web アプリケーションへのアクセス
    • 任意の URL に対し HTTP POST メソッドを実行
    • パラメーターは XML でフォーマットされる
    • XML の構文は CVP 独自仕様 (DTD 提供 )
    • Web アプリケーションからの応答も CVP 仕様の XML document にフォーマット
    • Standard Action Element または Standard Decision Element を用いて利用
    • セキュリティは調査中( HTTPS に対応するか否か)
  • 245. XML API を用いた 外部 Web アプリケーションへのアクセス
    • セッション関連情報 (CVP  Web アプリ )
      • Call を識別する ID
      • 呼情報 ( 発信者番号等 )
      • Element Data (Element 実行の結果生成されたデータ )
      • Session Data (Session 内でグローバルな変数 )
    • 応答情報 (Web アプリ  CVP)
      • ステータス、エラー
      • New Element Data (Web アプリを呼び出した Element の Element Data に格納される )
      • New Session Data (Session Data に格納される )
      • ロギング用情報
    • 受け渡せるデータ ( 抜粋 )
  • 246. XML API を用いた 外部 Web アプリケーションの冗長化 Database Server VXML/HTTP(S) CVP VXML Server Component Voice XML Gateway (Voice Browser) HTTP POST レスポンス Web Application Server XML XML 負荷分散装置 負荷分散装置を用いて Web アプリケーションサーバーを冗長化 Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI
  • 247. XML API による連携のまとめ
    • 長所
      • CVP コールフロー内で Java 開発や SQL 文が不要
      • 既存 Web アプリ基盤上に容易にロジックを実装
      • 外部 DLL 呼出し可能
      • データベーススキーマの隠ぺい
      • 一般的な負荷分散技術による冗長化
    • 短所
      • Web アプリケーションサーバーが別途必要
      • XML を応答する専用の Web アプリケーションの追加開発が必要
    • アプリサーバーとの通信の暗号化
      • 現バージョンの XML API では実現できない
      • 回避策は後述
  • 248. Java API を用いた 外部 Web アプリケーションへのアクセス Database Server VXML/HTTP(S) CVP VXML Server Component Voice XML Gateway (Voice Browser) HTTPS リクエスト レスポンス Web Application Server 3 rd Party DLL REST XML Tomcat / WebSphear カスタム音声応答アプリ J2EE JDBC JNDI CVP VXML Server Custom Element (Java)
  • 249. Java API を用いた 外部 Web アプリケーションへのアクセス
    • カスタム Element を作成、 HTTPS アクセスを行う
    • Java API を用いるとコールフローからカスタム Java コードの呼び出しが可能になる
    • 実際には、 Standard Action Element または Standard Decision Element の Java class を継承してカスタム Element を作成し、コールフローから呼び出す
    • カスタム Element 内で J2EE の標準ライブラリ HTTP/HTTPS によりアプリケーションに接続
    • パラメーターの受け渡しは GET による URL 変数渡しもしくは POST による本文渡し
    • Web アプリケーションからの応答は、 HTTP レスポンスの本文 (XML もしくは平文 )
  • 250. カスタム Element のサンプルコード断片 package com.cisco.pt.cvp.vxml.ctrl; import com.audium.server.voiceElement.ActionElementBase; import com.audium.server.voiceElement.ElementInterface; import com.audium.server.voiceElement.Setting; import com.audium.server.voiceElement.ElementData; import com.audium.server.voiceElement.ElementException; import com.audium.server.session.ActionElementData; import com.audium.server.xml.ActionElementConfig; import java.io.IOException; import java.net.HttpURLConnection; import java.net.URL; import java.util.logging.Level; import java.util.logging.Logger; public class VideoCtrl extends ActionElementBase implements ElementInterface { public void doAction(String name, ActionElementData data) throws ElementException { ActionElementConfig cfg = data.getActionElementConfig(); String mov = cfg.getSettingValue(&quot;movie_url&quot;, data); String act = cfg.getSettingValue(&quot;action&quot;, data); String gid = cfg.getSettingValue(&quot;guid&quot;, data); String url = &quot;https://CVP7-VIDEO:8443/cvp/VideoServlet?&quot; + &quot;callGuid=&quot; + gid + &quot;&movieURL=&quot; + mov + &quot;&action=&quot; + act + &quot;&isLive=N&vmsVersion=CVP_7_0_1_0_0_0_1183&quot;; HttpURLConnection c = null; try { System.out.println(&quot;HTTP request = &quot; + url); URL cvpvideo = new URL(url); c = (HttpURLConnection) cvpvideo.openConnection(); } catch (IOException ex) { Logger.getLogger(VideoCtrl.class.getName()).log(Level.SEVERE, null, ex); } } 既存 Element からクラスを継承 HTTPS で URL 指定 Java の HttpURLConnection クラスを利用 HTTPS で URL へ接続 Packeage とクラスを適宜 import
  • 251. Java API を用いた 外部 Web アプリケーションの冗長化 Database Server VXML/HTTP(S) CVP VXML Server Component Voice XML Gateway (Voice Browser) HTTPS リクエスト レスポンス Web Application Server REST XML 負荷分散装置 負荷分散装置を用いて Web アプリケーションサーバーを冗長化 Tomcat / WebSphear カスタム音声応答アプリ J2EE JDBC JNDI CVP VXML Server Custom Element (Java)
  • 252. Java API による連携のまとめ
    • 長所
      • 既存 Web アプリ基盤上に容易にロジックを実装
      • 外部 DLL 呼出し可能
      • データベーススキーマの隠ぺい
      • 一般的な負荷分散技術による冗長化
      • Web アプリケーションを REST で実装することも可能
    • 短所
      • Web アプリケーションサーバーが別途必要
      • XML を応答する専用の Web アプリケーションの追加開発が必要
    • アプリサーバーとの通信の暗号化
      • J2EE ライブラリの持つ HTTPS 接続機能を利用
  • 253. リモート Java オブジェクトへのアクセス Database Server VXML/HTTP(S) CVP VXML Server Component Voice XML Gateway (Voice Browser) Java RMI J2EE JNI JDBC 3 rd Party DLL Remote Object Tomcat / WebSphear CVP VXML Server カスタム音声応答アプリ J2EE JDBC JNDI Local Stub
  • 254. Java RMI による連携の得失
    • 長所
      • データベーススキーマの隠ぺい
      • カスタム Element による柔軟なロジックの実装
      • 外部 DLL 呼出し可能 (JNI:Java Native Interface を用いた wrapper クラスを経由して呼び出し )
      • 大がかりな Web アプリケーションインフラ不要
    • 短所
      • Java のみ対応
      • カスタム開発要素が最大になる可能性大
      • 密結合
      • 冗長化が困難
    • Java RMI サーバーとの通信の暗号化
      • 困難
  • 255.