本文へスキップ
tech公開更新約10分で読めます

システム障害で問い合わせが急増したら コールセンターの初動5つの手順

シェア
システム障害で問い合わせが急増したら コールセンターの初動5つの手順

システム障害で問い合わせが急増したとき、コールセンターが最初にやるのは、電話の入口とWebで「障害を把握している」と伝えることです。人を集めるのはその後です。

障害時の電話には、障害そのものではなく情報の不足から生まれるものが多くあります。手順は5つです。第一報を受け取る、IVRで知らせる、Webと文言を揃える、受ける用件を絞る、復旧後を片付ける、の順に進めます。

障害時の入電の中身は、公的な検証で分かっています。総務省の電気通信事故検証報告書によると、2022年7月のKDDIの大規模通信障害では、同社への電話またはメールの問い合わせが約13万件ありました(7月8日12時時点)。

主な内容は「電話がつながらない、使えない」「どれくらいで(いつ)復旧するのか」「補償について確認したい」「障害の原因は何か」などでした。報告書は、2日目、3日目にも多くの問い合わせがあったことから、利用者に必要な情報が十分に提供できていなかったと推定しています。

入電の量は、告知の足りなさを映します。

手順1 障害の第一報をセンターが受け取る経路を平時に決める

センターが障害を最初に知るのが、お客様からの電話であることは珍しくありません。オペレーターが同じ内容の電話が続くと気づき、SVが情報システム部門に問い合わせて、ようやく障害が分かる。この順番では、告知の準備を始める頃には待ち呼が積み上がっています。

総務省の障害発生時の周知・広報に関するガイドラインは電気通信事業者向けですが、業種を問わず使える内容を含みます。設備を運用する部門が、利用者窓口からの報告やSNSの情報で障害を早く検知する体制を整え、訓練することも挙げています。

センターは、障害連絡の受け手であると同時に、最初の検知役でもあるということです。平時に決めておくのは次の3点です。

  • システム部門から障害連絡を受けるセンター側の窓口(SV当番など)と連絡手段。チャットとは別に電話の連絡網を持つ
  • センターから「障害の疑い」を上げる基準と上げる先。基準は、例えば「同じ用件の入電が15分で通常の3倍」のように数字で決める
  • 委託先のセンターや販売代理店への連絡順

委託先の扱いは見落としやすいところです。金融庁は2022年4月の業界団体との意見交換会で、地方銀行など9行のATMが使えなくなった障害を取り上げました。外部委託先で起きた障害でも、金融機関は委託者として管理責任を負うとしています。

そのうえで、委託先を含めた報告態勢と指揮命令系統の検証を求めました。センターを委託している企業は、障害の連絡が委託先の現場まで何分で届くかを一度測っておくと、当日の遅れが読めます。

手順2 IVRの冒頭で障害を知らせ、30秒以内に収める

電話の入口で障害を伝えると、障害が起きているか確かめたいだけの人は、オペレーターにつながる前に用件を終えられます。録音済みの案内に切り替えるだけなので、増員より早く効きます。

ただ、切り替えを当日に作るのでは間に合いません。コールセンターシステムには、緊急時に着信の流れを差し替える仕組みを持つものがあります。

たとえばGenesys Cloudの緊急グループは、火災や自然災害、停電のような緊急の事態で着信の流れを変える機能です。同社は、実際の緊急時より前に有効化と無効化を試しておくよう勧めています。製品は何であれ、緊急用フローを1本作り、誰がどの画面から切り替えるかを手順書に書いて訓練します。

IVRで流す案内は30秒以内に収め、次の4つを入れます。

  1. 障害が起きていること(「現在、◯◯がご利用しづらい状況です」)
  2. 影響を受ける人と受けない人の見分け方
  3. 利用者が今できること、またはしなくてよいこと(「再設定は不要です」など)
  4. 次に情報を更新する時刻と、Webの確認先

抜けやすいのは3と4です。

「次回は◯時に更新します」の一言は、「いつ直るのか」という電話を減らす有力な手段です。復旧の見通しが立っていなくても、更新時刻なら約束できます。

案内文の言い回しは、IVRのガイダンス文言の作り方と同じ規則で書けます。

ボイスボットやチャットボットを入れているセンターは、AIの回答も障害時用に切り替えます。FAQを根拠に答えるAIは、障害を知らないまま通常の操作を案内し、かえって電話を増やします。障害の間は冒頭の応答を固定の告知文に差し替え、通常の回答を止める設定を緊急用フローに含めます。

手順3 Webの告知とIVRの文言を1つの元から作り、更新時刻を決める

手順3 Webの告知とIVRの文言を1つの元から作り、更新時刻を決める

Web、IVR、オペレーターの説明が食い違うと、確かめるための電話が増えます。文言の元は1つにし、Webに出した文をIVRとオペレーターのトークにそのまま使います。

総務省のガイドラインは、時間の目安を具体的に示しています。指定公共機関は事故の発生から原則30分以内に初報を出し、それ以外の事業者もこれに準じてできる限り早く出す。障害情報へのリンクはトップページの分かりやすい位置に常に置き、詳細へは原則ワンクリックで届くようにする。

更新についても目安があります。ガイドラインによると、状況に変化がないことも利用者には重要な情報なので、指定公共機関は更新内容がなくても深夜早朝を除き少なくとも1時間ごとを目安に更新する、としています。通信事業者以外に当てはまる義務ではありませんが、時間の物差しとして借りられます。

ガイドラインは、初報を早く出すために情報発信用のフォーマットを事前に作っておくことも求めています。センターで使える型を置いておきます。

【障害発生】◯◯がご利用しづらい状況について(M月D日 HH:MM時点)

・発生日時: M月D日 HH:MM頃から継続中
・影響: ◯◯(サービス名)で、◯◯ができない/しづらい状況です
・対象: ◯◯をご利用のお客さま(◯◯をご利用のお客さまは影響ありません)
・お客さまへのお願い: ◯◯の再設定や再申込は不要です
・復旧見通し: 確認中です
・次回の更新: HH:MM頃にこのページでお知らせします
・お問い合わせ: 電話は大変混み合っています。最新の状況はこのページでご確認ください

IVRの案内は、この文から作ります。更新のたびに見出しの時点表記を変え、IVRの録音も差し替えます。

差し替えの担当者と、録音を作る方法も事前に決めます。音声合成で即時に作れるなら、更新のたびに人が録り直す必要はありません。

手順4 電話で受ける用件を3つに分け、人員を寄せる

告知で減らせない電話は残ります。KDDIの例で言えば、補償の確認や、自分の場合はどうすればよいかという個別の相談です。初動の後半は、電話で受ける用件を絞り、そこに人を寄せる作業になります。

障害が続いている間は、受付を3つに分けて考えます。

区分 例 扱い
今すぐ人が受ける 安全・健康・金銭の損失に関わる、期限が迫っている手続き 専用の選択肢か番号で優先して受ける
障害の説明で済む 発生の確認、復旧時期、原因 IVRとWebの告知で答える。つながった場合も告知文で答える
後日でよい 障害と関係ない通常の用件、補償の詳しい手続き 受付時間の後ろ倒し、折返し予約、Webフォームに回す

※区分の例は説明用です。何を「今すぐ」に入れるかは業種で変わります。

オペレーターには、告知文と同じ内容のトークと「答えてはいけないこと」の一覧を配ります。原因や復旧時期を個人の推測で話すと、Webと食い違って問い合わせが増えるからです。補償は、方針が決まるまで「決まり次第このページでお知らせします」で統一します。

人員は、他の業務からの応援と、通常業務の一時停止で作ります。応援者には障害の説明だけを受け持ってもらえば、短い説明だけで入ってもらいやすくなります。

メール、チャット、SNSの返信も、同じ告知文で答えます。総務省のガイドラインも、自社サイトに加えてSNSやアプリなど複数の伝達手段を使うことを挙げています。販売代理店にも情報を共有し、相談窓口の対応マニュアルを用意しておくことも同じガイドラインにあります。

手順5 復旧後も告知を残し、時系列と用件の内訳を記録する

復旧を告知しても、電話はすぐには平常に戻りません。補償の手続き、障害中にできなかった手続きのやり直し、原因の説明を求める電話が続きます。

復旧の告知には、利用者がやり直す必要のある操作と補償の扱いを入れ、しばらくはIVRの案内も残します。総務省のガイドラインは、復旧後も原因や影響の概要を、分かりやすい場所に少なくとも1年程度は掲載しておくとしています。

記録は2つ残します。1つは時系列で、障害の発生、センターが知った時刻、IVRを切り替えた時刻、Webの初報と各更新の時刻、入電のピークを並べます。手順1で決めた経路が何分で動いたかが、これで分かります。

もう1つは、入電の用件の内訳。告知で先回りできたはずの用件がどれだけあったかを集計すると、次の告知文で足すべき一文が見えます。

障害の日の入電実績は、呼量予測のデータから黙って消さないでください。障害日の印と理由を付けて残しておけば、通常日の予測を乱さずに、次の障害の規模を見積もる材料になります。

まとめ

障害の当日に効くのは、平時に作っておいたものだけです。緊急用フロー、告知文の型、連絡網のどれかが欠けていると、その穴は待ち呼の長さになって表れます。

手順書に「障害を知ってからIVRの案内が流れるまで何分か」が書かれていなければ、次の訓練で一度測ってください。総務省のガイドラインが指定公共機関に求める初報は原則30分以内です。それより遅ければ、告知が出る前に電話があふれるおそれがあります。

よくある質問

障害の原因が分からないうちに告知を出してもよいですか。

出してかまいません。原因は「確認中」とし、会社が障害を把握していることを先に伝えるほうが、確かめるための電話を減らせます。総務省のガイドラインも、初報は判明している範囲で早く出すことを求めています。

IVRの案内はどのくらいの長さにすべきですか。

30秒ほどに収めます。詳しい説明はWebに任せ、電話では次にいつ情報が出るかを伝えれば足ります。

障害中は通常の問い合わせも止めるべきですか。

安全や金銭の損失に関わる用件と、期限のある手続きは受け続けます。それ以外は折返し予約やWebフォームに回します。全面停止は、障害と関係のない緊急の用件まで止めてしまいます。

ボイスボットは障害時にどう扱えばよいですか。

障害の間は通常の回答を止め、告知文だけを返す状態に切り替えます。切り替えはIVRと同じ緊急用の手順に入れておきます。

注記

確認日: 2026年11月4日。総務省のガイドラインは電気通信事業者を対象としたもので、他業種に法的義務を課すものではありません。本稿は時間や項目の目安として参照しています。KDDIの問い合わせ件数は、総務省の検証報告書に記載された同社の説明によります。Genesys Cloudの機能は同日時点の公式ドキュメントによります。表や告知文の例は説明用の型です。本稿はAI著者によるデスクリサーチと編集部の実務設計案で、特定の製品を推奨するものではありません。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア