コールセンターの立ち上げ手順を7ステップで解説｜準備事項と進め方

記事概要：コールセンターの立ち上げ手順を、目的設定、入電予測、体制、業務フロー、システム、採用教育、テスト、本番移行の順に整理します。稟議や情報システム部門の確認を含め、各段階で誰が何を決めるかを示します。

コールセンター立ち上げ手順は、システム選定から始めるものではありません。目的と対象業務を決め、入電量から体制を算出し、業務フローと要件を固めてからコールセンターシステム導入へ進むと、開設後の手戻りを抑えられます。

ステップ1　目的と対応範囲を決める

販売相談、注文受付、サポート、苦情、緊急連絡のうち何を扱うかを定めます。応答率、受付時間、一次解決などの開設目的を数値で置き、対象外用件の転送先も決めます。

文書上の要件が決まったら、代表的な用件を使って担当者が一連の操作を再現します。操作できることだけでなく、履歴が残ること、権限を越えないこと、誤りを取り消せることを受入条件にします。

ステップ2　入電予測と必要席数を算出する

既存窓口の履歴、顧客数、販売計画、季節変動から時間帯別入電を予測します。平均処理時間、後処理時間、休憩、欠勤を含め、通常期とピーク期の要員を分けます。

移行や公開の判断は予定日だけで行わず、必須テストの合格、未解決課題の影響、監視と切戻しの準備で決めます。新設センターの責任者、プロジェクト管理者が中止を判断できる閾値を持つと、不完全な状態で進行する圧力を抑えられます。

ステップ3　役割と業務フローを設計する

一次受付、専門窓口、スーパーバイザー、品質管理、システム管理を配置します。着信、本人確認、回答、保留、転送、折返し、記録、完了までを例外処理とともに図にします。

運用開始後は、計画との差、例外件数、問い合わせ理由、担当者の追加作業を短い周期で確認します。設計時に想定できなかった用件は個別対応で終わらせず、手順、権限、ナレッジのどこへ反映するかを決めます。

ステップ4　システム要件と稟議を整える

番号、回線、IVR、ACD、録音、CRM、レポート、セキュリティを要件票へ落とします。事業部門は業務、情シスは技術と安全、購買は契約と費用を確認し、判断期限を日程へ組み込みます。

ステップ4　システム要件と稟議を整えるでは、担当者、入力情報、判断基準、成果物、完了条件を一枚の管理表へ落とします。新設センターの責任者、プロジェクト管理者だけで決められない項目は、情シス、法務、購買、現場の確認期限を先に置き、承認待ちを日程へ含めます。

ステップ5　採用と教育を並行する

採用は製品決定を待たず、必要スキルと勤務時間を基に進めます。教育では商品知識だけでなく、本人確認、保留、転送、記録、苦情、個人情報、障害時の代替手順を練習します。

手順を設計するときは正常系だけでなく、情報不足、担当不在、外部システム停止、期限超過を例外として記載します。例外の連絡先と代替処理が決まっていれば、コールセンターの立ち上げ手順を7ステップで解説の本番開始後に現場判断が分かれにくくなります。

ステップ6・7　テストして段階的に移行する

単体テスト、連携テスト、負荷テスト、ロールプレイを行い、合格条件を記録します。本番は対象番号やチームを限定して開始し、監視担当と旧窓口へ戻す条件を決めてから全面移行します。

ステップ6・7　テストして段階的に移行するの完了判定は、資料の作成だけで終えず、担当者が実データに近い条件で作業を再現できるかまで確認します。未完了項目は影響範囲、暫定対応、解消期限を記録し、本番可否の判断材料にします。

立ち上げ時の検証条件を残す

コールセンターの立ち上げでは、正常に動作した画面だけでなく、操作日時、入力内容、期待結果、実際の結果、証跡まで保存します。担当者が交代しても同じ条件で再試験できる形にしておけば、設定変更や障害復旧時の確認にも利用できます。

UdeskのCapital Metro事例では、電話による経路や運賃の問い合わせに対し、音声認識やNLPを業務システムと接続したボイスボットが導入されています。このように電話受付だけでなく、その後の情報照会や処理まで含めて設計する事例は、立ち上げ時に電話、業務システム、対応フローを別々に考えないことの参考になります。事例と自社では条件が異なるため、実際の問い合わせ内容を使った検証が必要です。

要件と運用ルールを継続して管理する

要件票には、コールセンター立ち上げ時の必須、希望、対象外を記すだけでなく、その理由と確認方法も添えます。必須条件を満たせない場合に代替運用を認めるか、誰が例外を承認するかまで決めておけば、受入判定が担当者の印象に左右されにくくなります。

運用ルールも一度作って終わりにせず、問い合わせ量、顧客行動、組織体制、製品機能の変化に合わせて見直します。変更理由と適用日を記録し、旧ルールで対応中の案件をどの時点から切り替えるかも決めておきます。

本番後の結果を見ながら構成を見直す

正式稼働後は、利用件数だけでなく、手作業への戻り、再処理、転送、顧客からの再問い合わせも確認します。処理件数が増えていても後工程の負担が増えている場合は、設定、問い合わせ導線、担当範囲のどこを修正すべきかを切り分けます。

また、通常時だけでなく、繁忙期、担当者不在、外部サービス停止などの例外時にも顧客への案内と対応履歴を残せるか確認します。Udeskはクラウド型コールセンターにチケット管理、AIチャットボット、ボイスボット、オペレーター支援などを組み合わせられるため、開設時に必要な範囲から始め、問い合わせ量やチャネルの変化に応じて構成を検討できます。

FAQ

Q:立ち上げには何カ月かかりますか

A:規模と連携で変わりますが、要件、調達、番号、採用教育の所要期間を別々に見積もります。

Q:採用とシステム導入はどちらが先ですか

A:要件決定後は並行し、教育環境を本番前に使える日程にします。

Q:開設日に全件を移すべきですか

A:影響が大きい場合は番号、顧客群、時間帯で段階移行します。

》》Udesk コールセンターの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください

本記事はUdeskのオリジナルであり、転載する際は出典を明記してください：https://www.udesk.jp/blog/news/guide/6265/