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

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

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

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

• プロトコル（例-SIP TLS、SRTP、HTTPS）

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

• 開封または許可する必要があるポート番号。

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

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

次のようなクラウドコラボレーションサービスには、各支店やサイトからの分散型インターネットブレークアウトが推奨されます。 トラフィックをローカルに流出させることで、このモデルは：

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

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

• SD-WANとシームレスに連携し、セッションを最寄りのクラウドエントリーポイントに動的にルーティングして最適なパフォーマンスを実現できます

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

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

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

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

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

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

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

このパイロット段階で得られた洞察は、 その後の移行波を最適化し、 企業全体でスムーズでリスクの少ない移行を確実にするのに役立ちます。

のPSTNサービスを調達するには、まずでPSTN接続オプションを選択します。

組織がハイブリッドデュアルコール制御（ 図のフェーズ1：ハイブリッドとクラウド） を一時的または無期限に維持することを計画している場合、オンプレミスのPSTNに1つ以上のローカルゲートウェイを導入して、とエンドポイント間の通話を許可する必要があります。

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

で電話番号を設定する前に、選択したプロバイダーと協力して電話番号を注文し、ポートしてください。 電話番号の注文やポート注文の開始は、 オンプレミスのPSTNとCloud Connectでのみ必要/可能です。 Cisco通話プランの場合、Cisco通話プランが利用可能な国では、 ロケーションが作成され次第、Control Hub内から注文と移植が開始されます。 Cisco通話プランの詳細については、「Ciscoプラン入門」を参照してください。

PSTNの実装の一環として、 プロバイダーがあなたの地域のインバウンドとアウトバウンドの両方のPSTNサービスを有効にしていることを確認してください。 さらに、テストコールを実行して、 選択したPSTN接続を介してコールが正しくルーティングされていることを確認します。

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

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

クラウドコネクトまたはCisco通話プランをPSTNオプションとして使用している場所の場合は、 セットアップ時にその場所に対応するPSTNを選択するだけです。 ロケーションでCloud Connect for またはオンプレミスのPSTNを使用している場合は、前のステップで注文した電話番号を追加する必要があります。 電話番号をすぐにコールルーティングに含めたくない場合は、非アクティブとして追加できます。これらの番号は、 後でユーザーや機能に割り当てられたときに有効にできます。

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

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

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

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

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

ユーザーをからに移行する場合、すべてのユーザーを同時に移動できない場合があります。 これには複数の理由が考えられます。サイトやユーザーの数、 サイトやユーザーグループを一度に移行するのにかかる時間、 変更ウィンドウをサポートするITまたはサイトリソースの制限、変更ウィンドウの期間、変更の複雑さなどがありますが、これらに限定されません。

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

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

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

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

• 共有回線

• コールピックアップを使用する

• 同じコールパーク番号を使う

• インターコム

• エグゼクティブ/管理者。

例としては、移行先のハントグループに属しているユーザーがあります。 このユーザーは、ハントグループとハントグループの他のすべてのメンバーに移行します。 したがって、 移行後、 ハントグループとそのメンバーは新しいプラットフォームで電話に正常に応答できます。

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

準備段階で使用したMigration Insightsツールまたはサードパーティツールの出力を使用して、 どのユーザーと機能をグループ化するかを判断してください。 このアウトプットは、 移行計画の作成に使用すべきでした。また、 移行が必要なユーザーと機能をどのようにグループ化するかについての洞察が得られます。

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

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

• すべてのユーザーが参加していることを確認してください

• ユーザーのすべてのTNがに存在することを確認してください

• ディレクトリで正しい電話番号形式を確認してください

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

• ユーザーグループのすべての通話サービスと機能の検証または設定（必要に応じて移行前または移行中）

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

• 活用ツール-ユーザーや機能の移行ツールやサードパーティのツール

• 移行後は、ユーザー/デバイスの電話番号と通話機能/サービスを無効/削除します。

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

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

• ロケーション中心：物理的なスペースに縛られています。

• デバイスフレキシブル：1つまたは複数のデバイス（固定電話、ボードなど）を搭載できます。

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

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

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

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

この記事で説明した手順に加えて、 7800と8800の電話をエンタープライズからMPPファームウェアに移行するのに役立つWebex Calling、「電話の移行先」という組み込みツールがあります。 このツールでは、電話を追加して、適切なユーザーやワークスペースに割り当てることもできます。 ツールの使い方について詳しくは、 「電話を移行する」を参照してください。

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

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

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

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

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

シスコのIP電話に加えて、 アナログ電話アダプター（ATA）、ワイヤレス（Wifi、DECT）電話、ビデオデバイス、音声ゲートウェイ、 ^{サードパーティのデバイスや電話など}、他のデバイスのプロビジョニングが必要になる場合があります。 これらのデバイスの多くには、 エンタープライズファームウェアからクラウドファームウェアに移行するためのIP電話のようなファームウェアのアップグレードパスがありません。 そのため、コントロールハブでこれらの各デバイスをプロビジョニングします。 これらの中には移行できないものもあり、同等のモデルに交換する必要があります（例えば ATA 191/192）などは、 手動で再構成したり、ソフトウェアを変更したりする必要があります。

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

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

• アナログ電話アダプター（ATA）-Cisco ATA 191と192を使い始めるには、Cisco ATAを参照してください。

• Wifi ワイヤレス電話-ワイヤレス電話 840 と 860 を統合するには、「 Webex ワイヤレス電話の統合」を参照してください。

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

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

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

• ^{サードパーティのデバイスと電話 -デバイス/電話の要件、およびそれらをサポートに移行または交換するプロセスについては、 サードパーティのベンダーと協力してください。}

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

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

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

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

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

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

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

• 動作モード-動作モードに基づく通話ルーティングについては、「 動作モードに基づく通話ルーティング」を参照してください

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

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

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

• 留守番電話グループ-共有留守番電話と受信FAXボックスを管理するには、「留守番電話の管理」を参照してください。

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

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

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

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

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

PSTNコールフローと発信者IDプレゼンテーション

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

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

オンネットコールフロー

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

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

受け入れテストの重要な側面は、およびサポートされている固定電話を使用して、 ユーザーがどのように通話を処理するかを検証することです。 このプロセスは、 日常の通話ワークフローが直感的で信頼性が高く、 ユーザーが自分の役割に必要なコア機能にシームレスにアクセスできることを確認することに重点を置いています。 テストでは、ユーザーが簡単に電話をかけたり受けたり、保留/再開機能を管理したり、 ブラインド転送と相談転送の両方を実行したりできるかを評価する必要があります。 また、着信転送、 会議、その他の高度な機能（駐車、通話の受信、 アクティベーションなど）がすぐに利用でき、スムーズに動作することを確認することも重要です。

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

コールキュー：エージェントとスーパーバイザーの経験

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

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

ハントグループ：通話分配

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

自動応答：お知らせとメニュー操作

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

ボイスメール操作

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

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

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

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

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

• プロトコル（例-SIP TLS、SRTP、HTTPS）

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

• 開封または許可する必要があるポート番号。

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

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

次のようなクラウドコラボレーションサービスには、各支店やサイトからの分散型インターネットブレークアウトが推奨されます。 トラフィックをローカルに流出させることで、このモデルは：

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

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

• SD-WANとシームレスに連携し、セッションを最寄りのクラウドエントリーポイントに動的にルーティングして最適なパフォーマンスを実現できます

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

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

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

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

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

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

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

このパイロット段階で得られた洞察は、 その後の移行波を最適化し、 企業全体でスムーズでリスクの少ない移行を確実にするのに役立ちます。

のPSTNサービスを調達するには、まずでPSTN接続オプションを選択します。

組織がハイブリッドデュアルコール制御（ 図のフェーズ1：ハイブリッドとクラウド） を一時的または無期限に維持することを計画している場合、オンプレミスのPSTNに1つ以上のローカルゲートウェイを導入して、とエンドポイント間の通話を許可する必要があります。

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

で電話番号を設定する前に、選択したプロバイダーと協力して電話番号を注文し、ポートしてください。 電話番号の注文やポート注文の開始は、 オンプレミスのPSTNとCloud Connectでのみ必要/可能です。 Cisco通話プランの場合、Cisco通話プランが利用可能な国では、 ロケーションが作成され次第、Control Hub内から注文と移植が開始されます。 Cisco通話プランの詳細については、「Ciscoプラン入門」を参照してください。

PSTNの実装の一環として、 プロバイダーがあなたの地域のインバウンドとアウトバウンドの両方のPSTNサービスを有効にしていることを確認してください。 さらに、テストコールを実行して、 選択したPSTN接続を介してコールが正しくルーティングされていることを確認します。

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

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

クラウドコネクトまたはCisco通話プランをPSTNオプションとして使用している場所の場合は、 セットアップ時にその場所に対応するPSTNを選択するだけです。 ロケーションでCloud Connect for またはオンプレミスのPSTNを使用している場合は、前のステップで注文した電話番号を追加する必要があります。 電話番号をすぐにコールルーティングに含めたくない場合は、非アクティブとして追加できます。これらの番号は、 後でユーザーや機能に割り当てられたときに有効にできます。

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

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

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

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

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

ユーザーをからに移行する場合、すべてのユーザーを同時に移動できない場合があります。 これには複数の理由が考えられます。サイトやユーザーの数、 サイトやユーザーグループを一度に移行するのにかかる時間、 変更ウィンドウをサポートするITまたはサイトリソースの制限、変更ウィンドウの期間、変更の複雑さなどがありますが、これらに限定されません。

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

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

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

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

• 共有回線

• コールピックアップを使用する

• 同じコールパーク番号を使う

• インターコム

• エグゼクティブ/管理者。

例としては、移行先のハントグループに属しているユーザーがあります。 このユーザーは、ハントグループとハントグループの他のすべてのメンバーに移行します。 したがって、 移行後、 ハントグループとそのメンバーは新しいプラットフォームで電話に正常に応答できます。

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

準備段階で使用したMigration Insightsツールまたはサードパーティツールの出力を使用して、 どのユーザーと機能をグループ化するかを判断してください。 このアウトプットは、 移行計画の作成に使用すべきでした。また、 移行が必要なユーザーと機能をどのようにグループ化するかについての洞察が得られます。

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

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

• すべてのユーザーが参加していることを確認してください

• ユーザーのすべてのTNがに存在することを確認してください

• ディレクトリで正しい電話番号形式を確認してください

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

• ユーザーグループのすべての通話サービスと機能の検証または設定（必要に応じて移行前または移行中）

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

• 活用ツール-ユーザーや機能の移行ツールやサードパーティのツール

• 移行後は、ユーザー/デバイスの電話番号と通話機能/サービスを無効/削除します。

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

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

• ロケーション中心：物理的なスペースに縛られています。

• デバイスフレキシブル：1つまたは複数のデバイス（固定電話、ボードなど）を搭載できます。

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

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

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

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

この記事で説明した手順に加えて、 7800と8800の電話をエンタープライズからMPPファームウェアに移行するのに役立つWebex Calling、「電話の移行先」という組み込みツールがあります。 このツールでは、電話を追加して、適切なユーザーやワークスペースに割り当てることもできます。 ツールの使い方について詳しくは、 「電話を移行する」を参照してください。

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

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

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

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

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

シスコのIP電話に加えて、 アナログ電話アダプター（ATA）、ワイヤレス（Wifi、DECT）電話、ビデオデバイス、音声ゲートウェイ、 ^{サードパーティのデバイスや電話など}、他のデバイスのプロビジョニングが必要になる場合があります。 これらのデバイスの多くには、 エンタープライズファームウェアからクラウドファームウェアに移行するためのIP電話のようなファームウェアのアップグレードパスがありません。 そのため、コントロールハブでこれらの各デバイスをプロビジョニングします。 これらの中には移行できないものもあり、同等のモデルに交換する必要があります（例えば ATA 191/192）などは、 手動で再構成したり、ソフトウェアを変更したりする必要があります。

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

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

• アナログ電話アダプター（ATA）-Cisco ATA 191と192を使い始めるには、Cisco ATAを参照してください。

• Wifi ワイヤレス電話-ワイヤレス電話 840 と 860 を統合するには、「 Webex ワイヤレス電話の統合」を参照してください。

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

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

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

• ^{サードパーティのデバイスと電話 -デバイス/電話の要件、およびそれらをサポートに移行または交換するプロセスについては、 サードパーティのベンダーと協力してください。}

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

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

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

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

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

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

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

• 動作モード-動作モードに基づく通話ルーティングについては、「 動作モードに基づく通話ルーティング」を参照してください

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

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

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

• 留守番電話グループ-共有留守番電話と受信FAXボックスを管理するには、「留守番電話の管理」を参照してください。

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

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

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

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

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

PSTNコールフローと発信者IDプレゼンテーション

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

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

オンネットコールフロー

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

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

受け入れテストの重要な側面は、およびサポートされている固定電話を使用して、 ユーザーがどのように通話を処理するかを検証することです。 このプロセスは、 日常の通話ワークフローが直感的で信頼性が高く、 ユーザーが自分の役割に必要なコア機能にシームレスにアクセスできることを確認することに重点を置いています。 テストでは、ユーザーが簡単に電話をかけたり受けたり、保留/再開機能を管理したり、 ブラインド転送と相談転送の両方を実行したりできるかを評価する必要があります。 また、着信転送、 会議、その他の高度な機能（駐車、通話の受信、 アクティベーションなど）がすぐに利用でき、スムーズに動作することを確認することも重要です。

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

コールキュー：エージェントとスーパーバイザーの経験

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

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

ハントグループ：通話分配

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

自動応答：お知らせとメニュー操作

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

ボイスメール操作

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