「電話は鳴るのに、顧客情報が画面に出ない」「IVRで入力した会員番号がオペレーターに引き継がれていない」。Salesforceとコンタクトセンター基盤を連携した環境では、こうした不具合がオペレーターの対応品質に直結します。電話基盤もSalesforceも、それぞれ単体では正常に動いていることが多く、原因の切り分けにも時間がかかります。本記事では、着信から対応完了までの流れに沿って、確認すべきポイントを整理します。
Service Cloud Voice連携では何を試験しますか？
着信から顧客の特定、担当者への接続、必要な業務記録までを対象構成に合わせて確認します。顧客が見つからない場合や複数候補の場合も、期待する処理を定めます。
1. 連携環境の典型的な構成
Service Cloud Voiceは、Salesforceの画面上で電話応対を扱うための仕組みです。電話基盤との連携方式や、録音・文字起こしなどの利用できる機能は、契約エディションと構成によって異なります。
試験計画の冒頭には、次を明記します。
- 採用エディションと連携方式
- 有効にしている機能（録音、文字起こし等）
- 対象の電話基盤と版
いずれの構成でも、1本の電話はキャリア → 電話基盤（IVR・ルーティング）→ Salesforce（画面・データ）と複数のシステムを通過します。顧客の行動から試験を設計する考え方はカスタマージャーニーからテストへをご覧ください。
2. 流れに沿った検証ポイント
2-1. 着信とIVR
- 着信し、IVRのガイダンス・分岐が正しく動くか
- IVRで取得した情報（会員番号、選択メニュー）が正しく保持されるか
2-2. ルーティングとオペレーター接続
- 意図したキュー・スキルのオペレーターに接続されるか
- Salesforce側のオペレーターのプレゼンス（受付可否）状態が正しく反映されるか
2-3. 画面ポップ
- 着信と同時に、正しい顧客レコードが表示されるか
- 該当顧客がいない・複数該当する場合の表示が想定どおりか
- IVRで取得した情報がオペレーター画面に引き継がれるか
2-4. 通話中〜終了後
- 転送時に顧客情報が転送先にも引き継がれるか
- 通話記録が正しい業務レコードに紐づくか
- 録音・文字起こしは、有効にしている場合のみ試験範囲に含める
通話IDと業務レコードの対応例
| 試験ケース | 通話ID（電話基盤側） | 紐づく通話レコード | 紐づく顧客・ケース | 期待結果 |
|---|---|---|---|---|
| 顧客一致 | （実行時に記録） | 1件作成 | 該当顧客 | 正しい顧客に紐づく |
| 顧客不一致 | （実行時に記録） | 1件作成 | なし→新規/手動選択 | 定めた処理どおり |
| 複数一致 | （実行時に記録） | 1件作成 | 候補一覧表示 | 定めた処理どおり |
| 転送あり | （実行時に記録） | 定めた件数 | 同一顧客 | 転送先でも同じ顧客 |
ボットから担当者へ情報を引き継ぐ構成の場合は、ボットから有人対応への引き継ぎをどうテストする？も参考になります。
3. 不具合が起きやすいタイミング
- Salesforceのリリース：定期リリースの予定をSalesforce公式のリリースノートで確認し、試験日程に組み込む
- 電話基盤側の更新：フロー変更やプラットフォーム更新
- 自社のカスタマイズ：画面レイアウト、項目、権限、フローの変更
- マスタデータの変化：電話番号の登録形式の違いによる照合失敗
どちらか一方の変更でも連携全体に影響するため、両側の変更タイミングで、同じ一連の流れを通しで確認することが重要です。
4. 試験を効率化するコツ
- 試験用の顧客データ（該当あり・なし・複数該当）を用意しておく
- 着信からIVR通過までを自動化し、画面ポップの確認に集中できるようにする
- Salesforceのリリース前後（Sandboxのプレビュー期間を含む）に試験日程を組み込む
ピーク時の連携動作まで確認する場合は、Amazon Connectで負荷試験を行う方法と注意点も参考になります（Amazon Connect連携の構成の場合）。
まとめ
Salesforce連携の品質は、個々のシステムではなく「電話1本の流れ全体」で評価する必要があります。対象構成と有効機能を明記したうえで、着信から記録までを通しで確認するシナリオを用意し、両側の変更タイミングで繰り返し実行してください。
CC Assuranceのサービス
Cyara Velocity：着信からIVR通過、担当者接続までの通話を自動化し、画面・記録の確認に集中できる試験体制をつくります。