Pulseで考える電話サービス監視｜第1回
「サーバーは動いているのに、お客様から電話がつながらないと言われる」。コンタクトセンターでは、装置の状態と実際の電話の使いやすさが一致しないことがあります。Cyara Pulseは、テストのやり取りを定期的に実行し、利用者の視点でサービスの状態を確認するための監視ソリューションです。
本記事では電話の監視に焦点を当て、Pulseで何を確認するのか、導入時に何を決めるのかを解説します。図は仕組みを説明するイメージで、実際の製品画面ではありません。
1. Pulseは「使ってみる確認」を繰り返す
毎朝、担当者が代表番号に電話し、案内を聞いてボタンを押し、正しい窓口へ進むか確認する。この作業を思い浮かべると、定期的なテストコールの役割を理解しやすくなります。
Pulseは、あらかじめ用意したシナリオに沿って利用者の操作を模擬し、結果を監視します。Cyaraの公式資料では、定期的な合成トランザクション、結果の可視化、異常通知が紹介されています。ここでいう「合成」は、実際のお客様の通話をそのまま解析することではなく、確認用のやり取りを生成するという意味です。参考：Pulseデータシート
2. 電話のどの段階を確認するのか
| 確認する段階 | 設計する確認内容の例 |
|---|---|
| 番号へ発信 | 接続できるか、想定した時間内に応答するか |
| 音声案内 | 必要な案内が流れ、次の操作へ進めるか |
| 番号入力 | 選択したメニューに対応する処理へ進むか |
| 窓口への接続 | 定めた受け側まで到達し、必要な応答を得られるか |
どこまで確認するかはシナリオと受け側の構成によります。案内を聞いて終了する監視と、受け側まで音声を確認する監視では、検証できる範囲が異なります。自動的にすべての窓口・分岐・端末が監視されるわけではありません。
3. 機器監視と組み合わせる
CPU負荷、装置の稼働状態、回線エラーなどを監視する仕組みは、内部の状態を調べるために重要です。Pulseのテスト結果は、利用者が通る経路の結果を確認する視点を加えます。
例えば、電話案内の設定だけを間違えた場合、サーバーの稼働監視は正常でも、案内の確認は失敗する可能性があります。逆にテストが失敗しても、発信側、通信経路、受け側、期待する結果の設定などを調べる必要があり、結果だけで原因装置を確定できるとは限りません。
担当者側の環境も調べたい場合は、PulseとResolveAXの観測範囲の違いを確認し、目的に応じて組み合わせます。
4. 定期監視の結果を正しく読む
正常だったという結果は、確認した時刻、発信条件、経路、判定項目の範囲での結果です。定期監視の合間にだけ起きた障害や、別の発信地域・通信経路で起きた問題を見逃す可能性もあります。
そのため、重要な番号と経路を選び、必要な間隔で継続します。通知までの時間には、次の実行までの待ち、シナリオの所要時間、再確認や通知処理が関係します。「監視しているから、どの障害も発生と同時に分かる」という理解は避けます。
実際にどう電話をかけて確かめるかは、テストコールによる外形監視の仕組みで説明しています。
5. 導入前に決める4項目
- 対象：どの番号の、どの利用目的を確認するか。
- 期待する結果：どの案内・応答・到達先なら正常とするか。
- 実行条件：時間帯、間隔、発信条件、受け側をどうするか。
- 対応：異常時に誰が何を確認し、どこへ連絡するか。
本番の受付担当者へ不要な着信を増やさないよう、受け側とテスト通話の識別方法を設計します。テスト用の受け側を使う場合は、実業務と共通の区間と異なる区間を明記し、確認できる範囲を説明できるようにします。
試行に必要な情報は、Pulse導入前の準備チェックリストを参考に整理できます。
6. 小さく始めて、運用できる範囲を増やす
最初は代表的な一つの経路で、正常時の記録、失敗の見え方、担当者への通知、再確認までを試します。確認できたら、重要番号、時間外、別のメニューへ段階的に広げます。対象数だけを増やしても、通知後に対応できなければ効果は限られます。
なお、CyaraはPulse 360も案内しています。本シリーズはPulseによる定期的な電話監視を中心とし、Pulse 360向けの追加機能を一律にPulseの標準機能として扱いません。利用できる機能や接続条件は、導入する構成で確認してください。参考：Pulse 360移行資料
電話サービスの継続監視について相談する
代表番号・重要経路・監視時間・通知先を整理する際は、Pulseによる電話サービスの外形監視をご覧ください。監視する電話番号・経路と運用体制を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。