Webex Calling への移行の最初のステップは、オンプレミス ネットワークと Webex クラウド間の信頼性が高く安全な インターネット接続 を確保することです。

ほとんどの組織は1つ以上の ファイアウォール または セキュリティデバイスを介してインターネットに接続するため、必要な トラフィックフロー がサポートされていることを検証することが重要です。

ネットワークおよびセキュリティ管理者は、次の点からこれらのフローを理解する必要があります。

• 方向 （インバウンド vs アウトバウンド）

• プロトコル (例: SIP TLS、SRTP、HTTPS)

• Webexサービスで使用されるIPアドレス範囲

• 開くか許可する必要があるポート番号 。

これにより、企業のファイアウォール、NAT デバイス、およびその他のネットワーク インフラストラクチャが適切に構成され、企業のセキュリティ ポリシーを維持しながら Webex Calling トラフィックに対応できるようになります。

IP アドレス、ポート、プロトコルなどの必要なフローの詳細については、 Webex Calling のポート参照情報を参照してください。この情報を使用して、既存の展開内のファイアウォール、プロキシ、およびその他のネットワーク インフラストラクチャを構成し、Webex Calling ネットワーク フローを有効にします。

Webex Calling などのクラウド コラボレーション サービスでは、各ブランチまたはサイトからの分散型インターネット ブレイクアウトが推奨されるアプローチです。トラフィックがローカルから出られるようにすることで、このモデルは次のことを実現します。

• 往復遅延とジッターを削減し、全体的な通話品質を向上します

• より多くのユーザーとサイトが Webex Calling に移行するにつれて、効率的に拡張できます。

• SD-WAN とシームレスに連携し、セッションを最も近い Webex クラウド エントリ ポイントに動的にルーティングしてパフォーマンスを最適化します。

• パブリック IP アドレスに基づいてユーザーの位置を追跡できるため、メディア パスの分析とトラブルシューティングに役立ちます。

さらに、組織は各サイトで十分なインターネット帯域幅を確保する必要があります。帯域幅のサイズは、同時通話の予測数、選択したコーデック (Opus または G.711 など)、シグナリング、再送信、および増加のオーバーヘッドに基づいて決定する必要があります。これは、PPDIO ライフサイクルの準備フェーズと一致しており、移行のための強固な基盤を確立します。

Webex Calling の導入における実装フェーズ内の初期セットアップ サブセクションは、適切に構造化され管理しやすいクラウド通話環境を確立するための基礎となります。この段階には、適切なユーザー管理とセキュリティを確保するために、Control Hub 組織の設定、ライセンスの調達と割り当て、会社のドメインの検証と申請などの重要なタスクが含まれます。さらに、ライセンス テンプレートをプロビジョニングしてユーザー ライセンスの割り当てを自動化したり、シングル サインオン (SSO) を構成してユーザー認証を効率化しセキュリティを強化したり、組織のポリシーやユーザーのニーズに合わせてサービスとクライアントの設定を調整したりすることもできます。これらの初期セットアップ アクティビティを完了すると、Webex Calling 環境がスケーラビリティ、セキュリティ、シームレスなユーザー エクスペリエンスのために適切に構成され、後続の展開および運用フェーズの準備が整います。

実装フェーズでは、パイロット移行を実行することが、Unified CM から Webex Calling への移行を検証する上で重要なマイルストーンとなります。このパイロットでは、1 つ以上の場所の代表的なユーザーのサブセットを Webex Calling プラットフォームにプロビジョニングし、選択された対象集団が多様なユースケースと組織の役割を反映していることを確認します。ユーザーの移行と並行して、ビジネスの継続性とサービスの機能性を維持するために、ボイスメール、自動応答、コールキュー、ハント グループなどの重要なコラボレーション サービスを Webex Calling の同等のものに移行する必要があります。

パイロット移行では、より広範な組織展開のために計画されているシスコ提供のツールとサードパーティの移行ユーティリティの同じ組み合わせを活用し、プロセス、自動化ワークフロー、および統合ポイントが代表的な条件下で徹底的に検証されるようにする必要があります。

このパイロット展開の主な目的は 2 つあります。1 つ目は、ユーザー プロビジョニング ワークフロー、データ移行手順、エンドポイント構成などのエンドツーエンドの移行プロセスを検証および改良することです。2 つ目は、実際の運用条件下で移行されたサービスの機能を包括的に検証することです。

この段階的なアプローチにより、プロジェクト チームは、制御された環境で技術的または手順上の問題を特定して修正し、新しいプラットフォーム エクスペリエンスに関するユーザー フィードバックを収集し、選択した移行ツールの有効性を評価し、より広範な組織展開に進む前に移行方法に対する信頼を確立することができます。

このパイロットフェーズで得られた知見は、その後の移行ウェーブを最適化し、企業全体のスムーズでリスクが軽減された移行を確実に行うために役立ちます。

Webex Calling の PSTN サービスを取得するには、まずコントロール ハブで PSTN 接続オプションを選択します。

組織がハイブリッドデュアルコール制御（図 [ のフェーズ 1 を維持する予定の場合 段階的コール移行：ハイブリッドおよびクラウド）を一時的または無期限に使用する場合は、Webex Calling と Unified CM エンドポイント間の通話を可能にするために、オンプレミス PSTN 用の 1 つ以上のローカル ゲートウェイを展開する必要があります。

PSTN を含むクラウドへの完全な移行 ( フェーズ 2) が最終目標である場合は、PSTN には Cisco Calling Plan または Cloud Connect for Webex Calling オプションのいずれかが必要になります。

Control Hub で設定する前に、選択したプロバイダーと協力して電話番号を注文および移行してください。電話番号の注文やポート注文の開始は required/possible オンプレミスの PSTN および Webex Calling の Cloud Connect 用。Cisco 通話プランの場合、Cisco 通話プランが利用可能な国では、場所が作成されるとすぐに、Control Hub 内から注文と移行が開始されます。Cisco 通話プランの詳細については、 Cisco プランの開始方法を参照してください。

PSTN 実装の一環として、プロバイダーがお客様の所在地に対して着信および発信の両方の PSTN サービスを有効にしていることを確認します。さらに、テスト通話を実行して、選択した PSTN 接続を介して通話が正しくルーティングされていることを確認します。

Webex Calling にユーザーとデバイスを追加する前に、通話場所をプロビジョニングする必要があります。場所ごとに有効な住所を入力する必要があります。米国とカナダでは、このアドレスは検証され、プラットフォームによって緊急通話の PIDF-LO 位置情報の送信に使用されます。

オンプレミスの PSTN を使用する場所を構成する場合は、それに応じてローカル ゲートウェイを設定する必要があります。Webex Calling では、各ローカル ゲートウェイに対してトランクとルート グループを作成する必要があり、その後、ルート グループがその場所の PSTN 選択肢として割り当てられます。Cisco では、PSTN の選択肢として常にルート グループを選択することを強くお勧めします。この方法により、将来的にトランクの追加が簡単になり、拡張性と冗長性の両方がサポートされます。また、シスコでは、すべての PSTN トランク上でデュアル ID と P-Charge-Info のサポートを有効にすることを推奨しています。これにより、発信直接通話または転送通話の課金対象者の識別が簡素化されます。PSTN プロバイダーが課金に別のヘッダーを使用する場合は、ローカル ゲートウェイの P-Charge-Info ヘッダーから必要な課金ヘッダーに情報をコピーできます。

PSTN オプションとして Cloud Connect for Webex Calling または Cisco Calling Plan を使用する場所では、セットアップ時に場所に応じてそれぞれの PSTN を選択するだけです。場所で Webex Calling 用の Cloud Connect またはオンプレミスの PSTN のいずれかが使用されている場合は、前の手順で注文した電話番号を追加する必要があります。すぐに通話ルーティングに含めたくない番号は、非アクティブとして追加できます。これらの番号は、後でユーザーまたは機能に割り当てられたときにアクティブ化できます。

各場所に必ず代表番号を設定することが重要です。メイン番号は、ユーザーまたは自動応答などの機能に割り当てることができます。その場所でボイスメールを有効にするには、ボイスメール パイロット番号 (ボイス ポータル番号とも呼ばれます) を必ず設定してください。

通話場所の追加設定には、緊急コールバック番号、通知オプション、拡張緊急通話機能などの緊急通話の詳細の構成が含まれます。また、場所ごとに必要に応じて、録音設定、言語設定、デバイス構成を確認して調整する必要があります。組織で企業の重要な番号を使用したサイト間オンネット短縮ダイヤリングを使用している場合は、内部ダイヤル設定で場所の一意のサイト コードを必ず構成してください。最後に、外線ダイヤルに発信ダイヤル番号が必要な場合は、外線ダイヤル設定で必ずこれを設定してください。発信ダイヤル番号が設定されている場合、一貫性を確保するために発信ダイヤル番号の強制を有効にすることを推奨します。

オンプレミスの通話制御と統合するには、トランク、ルート グループ、エンタープライズ ダイヤル プラン、場所とグローバルの両方の設定を構成する必要があります。まず、オンプレミスの通話制御システムとの相互接続を目的としたトランクおよびローカル ゲートウェイを設定します。この手順は、専用トランクが必要な場合にのみ必要です。既存のトランクとルート グループが展開に十分な場合は、追加の構成なしでオンプレミス相互接続に再利用できます。

トランクとルート グループが確立されたら、エンタープライズ ダイヤル プランを作成し、各ダイヤル プランの宛先として適切なルート グループを割り当てます。統合に、異なるトランクを介して接続された複数のオンプレミスの通話制御システムが含まれる場合は、複数のダイヤル プランが必要になります。これらのダイヤル プランには、オンプレミスの宛先への通話をルーティングするために必要なパターンのみが含まれていることを確認することが重要です。

展開で不明な内線ルーティングのサポートが必要な場合は、この機能を場所レベルで有効にする必要があります。さらに、不明な内線ルーティングを有効にすると、Control Hub の通話サービス設定の Webex Calling と構内線間の通話ルーティング セクション 内で、不明な内線の最大長を指定する必要があります。これにより、統合環境におけるシームレスな通話ルーティングと内線ベースのダイヤル シナリオの適切な処理が保証されます。

ユーザーを Unified CM から Webex Calling に移行する場合、すべてのユーザーを同時に移動できない場合があります。これには、サイトやユーザーの数、サイトの移行にかかる時間など、さまざまな理由が考えられます。 and/or 一度に複数のユーザー グループが変更可能であること、変更期間をサポートするための IT またはサイト リソースが限られていること、変更期間の期間、変更の複雑さなど。

ユーザーを段階的に移行する場合、同じ バッチで一緒に移行する必要があるユーザーを特定することが重要です。主な目標は、通話サービスと機能に関して相互に依存しているユーザーを一緒に移行することです。すべての通話機能 (例: コールキュー) が、Unified CM への移行前と同様に、Webex Calling でも完全に機能することを確認する必要があります。

ローカル ゲートウェイを使用して Unified CM と Webex Calling 間の通話インターワーキングを実装した場合でも、この接続を介して共有サービスまたは機能を分割することはできません。したがって、次のような機能に注目して、ユーザー間の依存関係を特定する必要があります。

• BLFを使用して他のユーザーを監視する

• 同じハントパイロット、コールキューなど

• 共有された回線

• コールピックアップの使用

• 同じコールパーク番号を使用する

• インターコム

• Executive/Admin.

例としては、Webex Calling に移行中の Unified CM ハント グループに属しているユーザーが挙げられます。このユーザーは、ハント グループおよびハント グループの他のすべてのメンバーとともに Webex Calling に移行します。したがって、移行後、ハント グループとそのメンバーは新しいプラットフォームで通話に正常に応答できるようになります。

ユーザーがさまざまな通話サービスや機能のためにさまざまなユーザー グループに接続する場合、これはさらに困難になります。これには、複数のユーザー グループと 1 つの通話サービスを同時に Webex Calling に移行する必要があります。

準備 フェーズで使用した Control Hub Migration Insights ツールまたはサードパーティ ツールの出力を使用して、どのユーザーと機能をグループ化するかを決定します。この出力は移行計画を作成するために使用する必要があり、一緒に移行する必要があるユーザーと機能をどのようにグループ化するかについての洞察を提供します。

一連のユーザーを移行する際の主な手順は次のとおりです。

• 一緒に移行するユーザーの特定

• すべてのユーザーがコントロールハブにいることを確認する

• ユーザーのすべてのTNがControl Hubに存在することを確認します

• ディレクトリ内の電話番号の形式が正しいことを確認する

• ユーザーグループのライセンスと設定テンプレートが正しく設定されていることを確認します

• ユーザー グループのすべての通話サービスと機能を確認または構成する (必要に応じて移行前または移行中)

• 企業ディレクトリで、通話が有効なユーザーのグループにユーザーを追加します。

• 活用ツール - Control Hub ユーザーおよび機能移行ツール and/or サードパーティツール

• Disable/Delete user/device 電話番号と通話 features/services 移行後の Unified CM で。

ユーザー グループを移行した後、ユーザーのサブセットをテストして、すべての通話機能とサービスが正しく動作していることを確認します。コール キュー、ハント グループなどの通話機能がユーザー グループとともに移行される場合は、これらの通話サービスが適切に機能するかどうかをテストします。

Webex Calling では、ワークスペースとは、デバイス、内線、ユーザーを割り当てることができる共有場所 (会議室、ハドル スペース、ホット デスクなど) を指します。従来の Unifed CM 電話とは異なり、ワークスペースは次のようになります。

• 場所中心: 物理的な空間に結び付けられます。

• デバイスに柔軟に対応: 1 つ以上のデバイス (デスク フォン、ボードなど) を持つことができます。

Webex Calling への移行の一環としてワークスペースが特定されると、Control Hub のデバイスに追加できます。各ワークスペースにはデバイスの割り当てが必要であり、それらがすでに Unified CM にある場合は、Webex 用にリセットまたは再プロビジョニングする必要があります。ボイスメール、コール転送、コールピックアップなどの Webex Calling 機能を有効または無効にすることができ、必要に応じてビデオ通話、コールパーク、モビリティにポリシーを適用できます。内部および外部の通話、ビデオ、会議、モビリティ機能のテストを行って、各ワークスペースをテストします。最後に、ワークスペースのデバイスと予約に適用されるプロセスをユーザーに知らせます。

Control Hub のワークスペースの詳細については、 ワークスペースを参照してください。

現在 Unified CM に登録されている電話機は、クラウド移行の一環として Webex Calling に移行する必要があります。移行を可能な限り簡単にし、失敗の可能性を最小限に抑えるために、シスコでは物理的なサイトまたは部門を同時に移行することを推奨しています。ただし、機能の依存関係により、ユーザーを一括して移行する必要がある場合があります。詳細については、 ユーザーを一括移行する のセクションを参照してください。

Unified CM から移行する必要がある Webex Calling 対応電話機は、Webex Calling でユーザーまたはワークスペースとして設定する必要があり、物理的な電話機は Webex Calling に登録するように再設定する必要があります。さらに、7800 および 8800 シリーズの電話機では、ファームウェアをエンタープライズ ファームウェアからマルチプラットフォーム フォン (MPP) ファームウェアにアップグレードする必要があります。このプロセスには、Webex Calling 登録に必要な MPP ファームウェアをロードする前に、移行ファームウェアをロードすることが含まれます。適切な移行ライセンスも必要です。Cisco は過去数年にわたってこのプロセスを改善し、エンタープライズ ファームウェア フォンを MPP ファームウェアにアップグレードしやすくしました。ファームウェア アップグレードを完了するための手順の詳細については、 Cisco 7800 および 8800 シリーズ IP 電話をエンタープライズ ファームウェアと MPP ファームウェア間で変換するを参照してください。

この記事で説明されている手順に加えて、Control Hub には 電話を Webex Calling に移行するという組み込みツールがあり、これを使用して 7800 および 8800 電話を Enterprise から MPP ファームウェアに移行できます。このツールを使用すると、電話を Control Hub に追加し、適切なユーザーまたはワークスペースに割り当てることもできます。ツールの使用方法の詳細については、 携帯電話の移行を参照してください。

Unified CM に登録されている 9800 シリーズの電話機には、上記のファームウェア移行要件は適用されません。これらの電話機は、Unified CM と Webex Calling の両方でサポートされている PhoneOS を実行します。これらの電話機を Webex Calling に移行するには、Webex Calling に追加し、ユーザーまたはワークスペースに割り当ててから、電話機を工場出荷時の状態にリセットする必要があります。登録のための PhoneOS ブートシーケンス 下の図は、電話機がまだ Unified CM にプロビジョニングされている場合でも、電話機OS ブートシーケンスと、Control Hub に追加された後に電話機が Webex Calling に登録される方法を示しています。 and/or DHCP オプション (例: 150) が使用されています。

Unified CM は、Webex Calling へのゼロタッチ オンボーディングを可能にするために、PhoneOS デバイスの工場出荷時設定へのリセットをサポートしています。Unified CM 管理者は、CUCM 管理ページから 9800 および 8875 電話機をリモートで工場出荷時の状態にリセットできます。これにより、電話機を Webex Calling にオンボードするために電話機に物理的にアクセスする必要がなくなります。この機能は、2025 年 9 月 9 日以降のデバイス パックでサポートされます。

• CUCM v15 - ユニファイド コミュニケーション マネージャー バージョン 15

• CUCM v14 - ユニファイド コミュニケーション マネージャ バージョン 14。

9800 シリーズの登録プロセスの詳細については、 登録プロセスを参照してください。

Cisco IP 電話に加えて、アナログ電話アダプタ (ATA)、ワイヤレス (Wi-Fi、DECT) 電話、ビデオ デバイス、音声ゲートウェイ、^サード パーティのデバイスや電話などの他のデバイスのプロビジョニングが必要になる場合があります。これらのデバイスの多くには、IP 電話のようにエンタープライズ ファームウェアからクラウド ファームウェアに移行するためのファームウェア アップグレード パスがありません。したがって、これらの各デバイスを Control Hub でプロビジョニングすることになります。これらの一部はWebex Callingに移行できず、同等のWebex Callingモデルに置き換える必要があります（例：ATA 191/192) その他は手動での再設定が必要になります and/or ソフトウェアの変更。

• 音声ゲートウェイ - ローカル ゲートウェイを移行するには、 「ローカル ゲートウェイの移行」を参照してください。

  コントロールハブで音声ゲートウェイVG400、VG410、またはVG420を構成する方法の詳細については、 ローカルゲートウェイを参照してください。

• アナログ電話アダプタ (ATA) - Cisco ATA 191 および 192 の使用を開始するには、 Cisco ATAを参照してください。

• Wifi ワイヤレス フォン - Webex ワイヤレス フォン 840 および 860 を統合するには、 「 Webex ワイヤレス フォンの統合」を参照してください。

• DECT ワイヤレス フォン - 新しい Cisco IP DECT 6800 シリーズの使用を開始するには、 Cisco IP DECTを参照してください。

  コントロールハブでデジタルDECTネットワークを構築および管理するには、 DECTネットワークの管理を参照してください。

  Cisco IP DECT 6800の詳細については、 導入ガイドを参照してください。

• 3 サードパーティデバイスと電話 - 3 サードパーティベンダーと連携して device/phone 要件と、Webex Calling をサポートするためにそれらを移行または置き換えるプロセス。

Webex Calling で必要な通話機能は、移行前または移行中にプロビジョニングする必要があります。「ユーザーを一括移行する」セクションで説明したように、通話機能を使用しているユーザーが移行されるときに、通話機能を構成し、移行する必要があります。

Webex Calling の各機能を設定する方法の詳細については、対応する設定ヘルプ記事を参照してください。

• 自動応答 - 自動応答を管理するには、 自動応答を参照してください。

• コールパーク - コールパークを管理するには、 コールパークを参照してください。

• コールピックアップ - コールピックアップグループを設定するには、 コールピックアップを参照してください。

• コールキュー - コールキューを設定するには、 コールキューを参照してください。

• ハントグループ - ハントグループを管理するには、 ハントグループの管理を参照してください。

• 動作モード - 動作モードに基づいてルーティングをコールするには、 動作モードに基づくルーティングのコールを参照してください。

• ページンググループ - ページンググループを構成するには、 ページンググループを構成するを参照してください。

• 録画 - Webex Calling の通話録画を管理するには、 録画の管理を参照してください。

• 単一番号リーチ - 単一番号リーチ（オフィスのどこでも）を構成するには、 単一番号の構成を参照してください。

• ボイスメール グループ - Webex Calling の共有ボイスメールと着信 FAX ボックスを管理するには、 「ボイスメールの管理」を参照してください。

受け入れテストでは、移行された環境が機能要件を満たし、期待どおりに動作し、すべての通信ワークフローにわたってシームレスなユーザー エクスペリエンスを提供することが保証されます。この検証プロセスは多面的であり、ユーザーのプロビジョニングや番号の割り当てから高度な通話機能の運用パフォーマンスまですべてをカバーします。

このセクションでは、受け入れテスト中に考慮すべき例を示し、重要な側面を強調していますが、網羅的または包括的なチェックリストとして機能することを意図したものではありません。

ユーザーのプロビジョニングと番号の割り当て

受け入れテストの基本的な側面には、Webex Calling 内ですべてのユーザーが正確かつ完全にプロビジョニングされていることを確認することが含まれます。これには、ソース (Unified CM) ディレクトリと新しく確立された Webex Calling ユーザー ベースを徹底的に比較して、すべてのユーザー アカウントが、内線番号や直通ダイヤル (DID) の割り当てなどの関連属性とともに正しく移行されていることを確認する必要があります。プロビジョニングの完全性は、初日からの操作性だけでなく、継続的な管理とサポートにとっても重要です。

番号割り当ての検証には、各ユーザーに正しい内線番号と外線番号が割り当てられていること、およびこれらの番号が内部 (オンネット) と外部 (PSTN) の両方のコールフローで正しくルーティングされていることを確認することが含まれます。通話ルーティング エラーやサービスの中断につながる可能性のある重複、割り当ての欠落、または構成ミスがないか確認することが重要です。

PSTN コールフローと発信者 ID 表示

堅牢な受け入れテスト手順には、PSTN コールフローのエンドツーエンドの検証が含まれる必要があります。これには、着信コールと発信コールの両方のシナリオが含まれます。着信 PSTN 通話の場合、テスト チームは、通話が個々のユーザー、通話キュー、ハント グループ、自動応答のいずれであっても、目的のエンドポイントに配信されることを確認する必要があります。発信者 ID 情報の正しい配信と表示に特に注意しながら、発信 PSTN 通話を正常に行う必要があります。これには、組織のポリシーと規制要件に従って、正しい発信者名と番号が外部の受信者に表示されるようにすることが含まれます。

テストでは、到達不能なエンドポイントやネットワークの中断の処理などのフェイルオーバー シナリオにも対処する必要があります。これにより、フォールバック メカニズムと代替ルーティングが適切に機能し、サービスの継続性と信頼性が維持されていることを確認できます。

オンネットコールフロー

内部またはオンネットのコールフローは、企業通信のバックボーンを形成します。この領域の受け入れテストでは、組織内のユーザー間の通話が正しくルーティングされ、通話転送、保留、転送、会議などの機能が意図したとおりに動作することを確認します。ダイヤル プランの整合性、内線間の接続、組織の通話ポリシーのサポートはすべて確認する必要があります。

ユーザーコールの処理と機能の検証

受け入れテストの重要な側面には、 Webex アプリ とサポートされているデスクフォンを使用してユーザーが通話を処理する方法を検証することが挙げられます。このプロセスでは、日常の通話ワークフローが直感的で信頼性が高く、ユーザーが自分の役割に必要なコア機能にシームレスにアクセスできることを確認することに重点を置いています。テストでは、ユーザーが通話を発信および受信したり、保留および再開機能を管理したり、ブラインド転送と協議転送の両方を実行したりすることがどれだけ容易であるかを評価する必要があります。また、通話転送、会議、通話の保留と取得、着信拒否の有効化などの高度な機能がすぐに利用でき、スムーズに動作することを確認することも重要です。

ユーザーが通話履歴、ボイスメール、統合ディレクトリとどのようにやり取りするかを考慮して、エクスペリエンスの明瞭性と応答性を評価する必要があります。アクティブな通話をデバイス間で移動する機能や、アプリケーション内または物理的な電話機上で通話中のコントロールを効果的に使用する機能にも、さらに注意を払う必要があります。最終的な目標は、移行後のエンドユーザー エクスペリエンスが一貫しており、効率的であり、組織のコミュニケーション ニーズを完全にサポートしていることを保証することです。

通話キュー: エージェントおよびスーパーバイザーの経験

コール キューは、大量の着信コールのシナリオを処理するために頻繁に使用されます。ここでの受け入れテストはいくつかの側面に焦点を当てています。まず、ラウンドロビン、最長アイドル、同時呼び出しなどの設定されたキュー ロジックに従って、コールがエージェントに分散されていることを確認する必要があります。エージェント デスクトップ上のキューに入れられた通話の表示は、明確さと使いやすさについて検査し、エージェントが通話を効率的に受け入れ、保留し、転送できるようにする必要があります。

スーパーバイザーの場合、リアルタイム監視、コール割り込み、キューのパフォーマンスに関する分析や洞察などの機能についてデスクトップ エクスペリエンスを評価する必要があります。これには、コール配分、エージェントのアクティビティ、キュー メトリックに関する実用的なデータを提供するダッシュボードやレポート ツールの検証が含まれますが、これに限定されません。

ハント グループ: コール分配

ハント グループは、事前に定義されたユーザー セットに通話を分配するための重要なメカニズムです。受け入れテストでは、構成されたハンティング アルゴリズムに基づいて通話がグループ メンバーにルーティングされ、オーバーフロー、転送、無応答のシナリオが設計どおりに処理されることを確認する必要があります。グループ メンバーシップとコール ルーティングの動作が、Unified CM で以前に確立されたものと一致することを確認することは、運用の一貫性とユーザー満足度にとって不可欠です。

自動音声応答: アナウンスとメニュー操作

自動応答は、自動通話処理の最前線に立っています。テストでは、アナウンスの再生、録音された挨拶の正確さ、メニュー ツリーの正しい操作をカバーする必要があります。メニュー選択により、発信者は適切な部門、担当者、または外部番号に確実にルーティングされる必要があります。テストには、発信者が明確なガイダンスを受け取ったり、意図したとおりにリダイレクトされたりすることを確認するための無効なシナリオやタイムアウトのシナリオも含める必要があります。

ボイスメール操作

最後に、ボイスメール機能はユーザー エクスペリエンスにとって重要です。受け入れテストでは、ボイスメール ボックスが正しく割り当てられており、組織内とリモートの両方からアクセスできることを確認する必要があります。通知の配信に加えて、メッセージを記録、取得、管理する機能も確認する必要があります。