Pulseで考える電話サービス監視｜第5回
発信に応答があっても、必要な案内が流れなかったり、ボタンを押した後に進めなかったりすれば、利用者は用事を済ませられません。Pulseの電話監視を設計する際は、接続後のどの段階まで確認するかを明確にします。この記事では音声案内、番号入力、転送の3段階を整理します。
1. 接続できたことと、目的を達成できたことは違う
「電話がつながる」は重要な確認ですが、それだけでは案内内容や転送先の正しさは分かりません。接続、案内、入力への応答、到達先を分け、それぞれの期待結果を定義します。
Cyaraの監視設計の公開例でも、IVR応答、特定の受け側へのルーティング、操作後の応答時間が別の確認として示されています。実際に利用できる検証方法は、対象システムと試験の受け側に合わせて決めます。参考：監視キャンペーンの設計例
2. 音声案内は内容と順番を確認する
「何か音が鳴った」だけでは、正しい案内か判断できません。利用者へ何を伝える必要があるかを基準に、確認する案内と出現順序を決めます。月ごとのキャンペーン文や待ち時間の読み上げなど、変化する部分も洗い出します。
変わる文言を固定の期待結果にすると、サービスは正常でもテストが失敗する場合があります。固定部分と変動部分を分け、採用する照合方法でどう扱うかを確認します。音声認識の結果を利用する場合も、認識の成否だけで人の聞き取り品質すべてを代弁できるとは限りません。
3. 番号入力は、入力後の変化まで見る
DTMFは、プッシュボタンの入力を電話システムへ伝える仕組みです。監視では入力を送ることに加え、その入力で想定したメニューへ進むかを確認します。
「1を入力→契約照会の案内」「2を入力→手続き窓口の案内」のように結果を対応づけます。入力するタイミングも条件の一部です。案内中の入力を受け付けるか、案内後だけ受け付けるかによって動作が変わるため、実際の利用ルールに合わせます。
番号入力と分岐の整理には、IVRの入力と期待結果をテスト項目にするの手順も参考になります。
4. 転送先は、何をもって到達とするか決める
呼び出し音が聞こえただけでは、正しい担当先へ接続した証拠として不十分な場合があります。受け側の応答、専用の試験応答、必要な音声の往復など、確認する範囲を決めます。
試験用の受け側へ転送する構成では、本番と共有する経路と、試験用に分かれる地点を把握します。そこから先の業務キューや実端末まで確認したとは限りません。図の窓口は到達先を示すイメージで、毎回実担当者を呼び出す運用を推奨するものではありません。
どこまで到達すれば正常とするかは、案内・応答時間・転送先の合格条件で項目別に整理できます。
5. 失敗した段階が分かる記録にする
| 最後に成功した段階 | 次に調べることの例 |
|---|---|
| 接続前 | 発信条件、番号、経路、受付側 |
| 最初の案内 | 入力条件、次の処理、期待文言 |
| 番号入力後の案内 | 転送設定、受け側、待ち時間 |
| 受け側の応答 | 音声経路、確認対象の方向、再生状態 |
表は調査の出発点です。原因が自動的に確定するわけではありません。同じ時刻の変更記録や通話ログと合わせて判断します。
6. シナリオ変更も運用に含める
案内を変更するときは、サービスの変更内容と監視の期待結果を一緒に管理します。新しい案内をいつから正常とするか、古い案内へ戻した場合にどう確認するかも決めます。
確認項目を増やす際は、テストの長さ、通話量、受け側への影響を見直します。「つながった後」を細かく見る価値と、継続できる運用負担の両方を考えて範囲を広げてください。
電話サービスの継続監視について相談する
代表番号・重要経路・監視時間・通知先を整理する際は、Pulseによる電話サービスの外形監視をご覧ください。監視する電話番号・経路と運用体制を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。