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の導入における実装フェーズ内の初期設定サブセクションは、構造化され管理しやすいクラウド通話環境を確立するための基礎となります。この段階では、適切なユーザー管理とセキュリティを確保するために、コントロールハブ組織の設定、ライセンスの取得と割り当て、会社のドメインの検証と取得といった重要なタスクを実行します。さらに、ユーザーライセンスの割り当てを自動化するためのプロビジョニングライセンステンプレート、ユーザー認証を効率化しセキュリティを強化するためのシングルサインオン（SSO）の設定、組織のポリシーやユーザーのニーズに合わせてサービスおよびクライアント設定を調整する機能も含まれています。これらの初期設定作業を完了することで、Webex Calling環境が拡張性、セキュリティ、およびシームレスなユーザーエクスペリエンスのために適切に構成され、その後の展開および運用フェーズへの準備が整います。

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

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

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

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

このパイロットフェーズで得られた知見は、その後の移行作業を最適化し、企業全体にとってスムーズでリスクの少ない移行を実現する上で非常に重要です。

Webex Calling用のPSTNサービスを調達するには、まずコントロールハブでPSTN接続オプションを選択してください。

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

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

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

PSTN導入の一環として、ご利用の地域でプロバイダがPSTNの着信および発信サービスを有効にしていることを確認してください。さらに、テストコールを実行して、選択したPSTN接続を介して通話が正しくルーティングされていることを確認してください。

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

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

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

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

発信場所に関する追加設定には、緊急時の折り返し電話番号、通知オプション、高度な緊急通報機能などの緊急通報の詳細設定が含まれます。また、場所ごとに必要に応じて、録画設定、言語設定、およびデバイス構成を確認し、調整する必要があります。組織内で企業共通番号を使用した短縮ダイヤル方式のサイト間オンネットダイヤルを使用している場合は、内部ダイヤル設定でその場所に固有のサイトコードを設定することを忘れないでください。最後に、外線発信に発信番号が必要な場合は、外線発信設定で必ずその番号を設定してください。発信ダイヤル番号を設定する場合、一貫性を確保するために、シスコは発信ダイヤル番号の強制適用を有効にすることを推奨します。

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

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

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

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

ユーザーを段階的に移行する場合、どのユーザーを 同じバッチで一緒に移行する必要があるかを特定することが重要です。主な目的は、通話サービスや機能において相互に依存しているユーザーをまとめて移行することです。Webex Callingでは、Unified CMへの移行前と同様に、すべての通話機能（例：コールキュー）が完全に機能するようにする必要があります。

Unified CMとWebex Calling with Local Gateways間で通話の相互接続を実装したとしても、この接続を介して共有サービスや機能を分割することはできません。したがって、次のような特徴に着目して、ユーザー間の依存関係を特定する必要があります。

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

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

• 共有された回線

• 通話ピックアップ機能を使用する

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

• インターコム

• Executive/Admin.

例えば、Webex Callingへの移行が行われているUnified CM Hunt Groupに所属するユーザーが挙げられます。このユーザーは、ハントグループおよびハントグループの他のすべてのメンバーとの通話において、Webex Callingに移行します。したがって、移行後、ハントグループとそのメンバーは、新しいプラットフォーム上で問題なく電話対応を行うことができます。

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

準備 フェーズで使用したControl Hub Migration Insightsツールまたはサードパーティツールの出力を使用して、どのユーザーと機能をグループ化する必要があるかを判断します。この出力結果は、移行計画の策定に活用されるべきものであり、移行が必要なユーザーと機能をどのようにグループ化するかについての洞察を与えてくれます。

複数のユーザーを移行する際の主な手順は以下のとおりです。

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

• すべてのユーザーがコントロールハブに登録されていることを確認してください。

• コントロールハブにユーザーのすべてのTNが存在することを確認します。

• ディレクトリ内の電話番号の形式が正しいことを確認してください。

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

• ユーザーグループ向けに、すべての通話サービスと機能を検証または構成する（移行前または移行中に、状況に応じて実施）。

• 社内ディレクトリで、通話可能なユーザーグループにユーザーを追加します。

• ツールを活用する - コントロールハブのユーザーおよび機能移行ツール and/or サードパーティツール

• Disable/Delete user/device ディレクトリ番号と通話 features/services 移行後の統合CMについて。

ユーザーグループの移行後、ユーザーの一部を対象にテストを実施し、すべての通話機能とサービスが正しく動作していることを確認します。コールキューやハントグループなどの通話機能がユーザーグループと共に移行される場合は、これらの通話サービスが正しく機能するかどうかをテストしてください。

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

• 位置情報中心：物理的な空間に結びついている。

• デバイスに柔軟に対応：1つまたは複数のデバイス（デスクフォン、ホワイトボードなど）を設置できます。

Webex Callingへの移行の一環としてワークスペースが特定されたら、コントロールハブの「デバイス」から追加できます。各ワークスペースにはデバイスの割り当てが必要であり、既に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ファームウェアをロードする前に、移行用ファームウェアをロードすることが含まれます。また、適切な移民許可証も必要です。シスコはここ数年でこのプロセスを改善し、エンタープライズ向けファームウェア搭載の電話機をMPPファームウェアにアップグレードしやすくしました。ファームウェアのアップグレードを完了するための手順の詳細については、 Cisco 7800 および 8800 シリーズ IP 電話をエンタープライズ ファームウェアと MPP ファームウェア間で変換するを参照してください。

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

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

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

• CUCM v15 - 統合コミュニケーションマネージャー バージョン 15

• CUCM v14 - 統合コミュニケーションマネージャー バージョン 14。

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

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

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

  Control Hub で音声ゲートウェイ VG400、VG410、または VG420 を設定する方法の詳細については、 ローカルゲートウェイを参照してください。

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

• Wi-Fi ワイヤレス電話 - Webex ワイヤレス電話 840 および 860 を統合するには、 Webex ワイヤレス電話の統合を参照してください。

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

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

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

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

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

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

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

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

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

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

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

• 動作モード - 動作モードに基づく呼び出しルーティングについては、 動作モードに基づく呼び出しルーティングを参照してください。

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

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

• シングルナンバーリーチ - シングルナンバーリーチ（オフィスどこでも）を設定するには、 シングルナンバーの設定を参照してください。

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

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

このセクションでは、受け入れテスト中に考慮すべき重要な点を例を挙げて説明しますが、網羅的または包括的なチェックリストとして使用することを意図したものではありません。

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

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

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

PSTNの通話フローと発信者番号表示

堅牢な受け入れテスト手順には、PSTN通話フローのエンドツーエンドの検証が含まれる必要がある。これには、着信通話と発信通話の両方のシナリオが含まれます。着信PSTNコールについては、テストチームは、コールが個々のユーザー、コールキュー、ハントグループ、自動応答システムなど、意図したエンドポイントに配信されることを確認する必要があります。PSTN回線からの発信通話は、発信者番号情報の正確な配信と表示に特に注意を払いながら、確実に発信されなければなりません。これには、組織の方針および規制要件に従って、発信者の氏名と電話番号が外部の受信者に正しく表示されるようにすることが含まれます。

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

オンネット通話フロー

社内通話、つまりネットワーク内通話の流れは、企業コミュニケーションの基盤を形成する。この分野における受け入れテストでは、組織内のユーザー間の通話が正しくルーティングされ、通話転送、保留、転送、会議などの機能が意図どおりに動作することを確認します。ダイヤルプランの整合性、内線間の接続性、および組織の通話ポリシーへの対応状況をすべて確認する必要があります。

ユーザー呼び出し処理と機能検証

受け入れテストの重要な側面の一つは、ユーザーが Webex アプリ とサポートされているデスクフォンを使用して通話を処理する方法を検証することです。このプロセスでは、日々の通話ワークフローが直感的で信頼性が高く、ユーザーがそれぞれの役割に必要な主要機能にスムーズにアクセスできることを確認することに重点を置いています。テストでは、ユーザーが通話の発信と受信、保留と再開機能の管理、ブラインド転送とコンサルテーション転送の両方を容易に実行できるかどうかを評価するべきである。また、着信転送、電話会議、通話の保留や再開、おやすみモードの有効化といった高度な機能がすぐに利用でき、スムーズに動作することを確認することも不可欠です。

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

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

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

管理者にとっては、デスクトップの操作性について、リアルタイム監視、通話割り込み、キューのパフォーマンスに関する分析や洞察といった機能を評価する必要がある。これには、通話分布、エージェントの活動状況、キューの指標に関する実用的なデータを提供するダッシュボードやレポートツールの検証が含まれますが、これらに限定されません。

ハント グループ: 通話配信

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

自動音声応答: お知らせとメニュー操作

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

ボイスメール操作

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

移行後の環境を監視し、パフォーマンスを検証し、運用上の安定性と効率性を確保するための調整を行うには、 最適化 フェーズを参照してください。