コールセンターシステムの選び方｜RFPに入れる要件と比較ポイント

記事概要：コールセンターシステムの選び方を、業務量、同時通話、電話番号、ルーティング、CRM、録音、セキュリティ、SLAの要件へ落とし込みます。製品比較前にRFPへ記載する条件と、提案書やPoCを同じ基準で評価する方法を解説します。

コールセンターシステムの選び方で先に行うのは、製品一覧を見ることではなく、現場の業務量と制約を要件へ変換することです。コールセンターRFPに同時通話、番号、連携、録音、セキュリティを数値と条件で示すと、各社の提案を同じ基準で比較できます。

現状値とピーク値を分けて記載する

月間入電数だけでは必要容量を決められません。時間帯別入電、平均処理時間、最大待ち呼、発信件数、通常席数、繁忙期席数を記録し、何年後までの増加を見込むかも要件にします。

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

電話番号と着信制御を要件化する

継続利用する番号、追加する番号、発信者番号、営業時間、IVR分岐、ACD規則、優先顧客、コールバックを整理します。番号移行ができない場合の転送費用と切替期間も提案範囲に含めます。

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

CRMとデータ連携の責任範囲を決める

着信時の顧客照合、通話履歴の書き込み、録音URL、チケット作成、顧客情報更新の方向を明記します。API仕様だけでなく、連携障害時の再送、重複、監視、問い合わせ先を確認します。

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

録音・セキュリティ・監査を具体化する

録音対象、保存期間、検索項目、ダウンロード権限、削除手順を決めます。管理者権限、SSO、多要素認証、IP制限、操作ログ、データ保管場所、委託先管理を回答形式まで指定します。

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

提案評価とPoCを分ける

提案書では機能適合、費用、移行、保守体制を採点し、PoCでは通話品質、着信分配、画面表示、録音、在宅接続を実機で確認します。説明資料だけで判定できる項目をPoCへ持ち込まないようにします。

提案評価とPoCを分けるでは、担当者、入力情報、判断基準、成果物、完了条件を一枚の管理表へ落とします。調達担当者、情シス、センター責任者だけで決められない項目は、情シス、法務、購買、現場の確認期限を先に置き、承認待ちを日程へ含めます。

要件確認と実際の業務での検証

調達担当者、情シス、センター責任者がベンダーへ確認する際は、「できますか」と聞くだけでなく、自社の件数、チャネル、権限、例外を示し、実際の動作を回答してもらいます。回答を標準機能、設定、オプション、開発、非対応に分けると、導入後に必要となる追加作業も把握しやすくなります。

Udeskの導入事例でも、3Mは電話業務を用途ごとに整理し、30種類以上のアウトバウンドシナリオを設計しています。製品機能の有無だけで判断せず、実際の業務単位で適用範囲を確認する考え方は、コールセンターシステムの選定でも参考になります。

RFPでは電話機能だけでなく、問い合わせ履歴、ナレッジ、AI支援、品質管理をどこまで一体化するかを明記します。Udeskはクラウド型コールセンターに問い合わせ管理、AIチャットボット、ボイスボット、オペレーター支援を組み合わせられるため、段階導入を含む要件に沿って構成を検討できます。

検証結果と変更履歴を残す

コールセンターシステムの選び方の検証結果は、成功した画面だけでなく、操作日時、入力、期待結果、実際の結果、証跡まで保存します。担当者が交代しても同じ条件で再試験できる形にしておけば、設定変更や障害復旧時の確認にも利用できます。

要件票には必須、希望、対象外だけでなく、その理由と確認方法も記載します。必須条件を満たさない場合に代替運用を認めるか、誰が例外を承認するかまで決めておくと、比較や受入判定が担当者の印象に左右されにくくなります。

運用ルールも一度作って終わりではなく、問い合わせ量、顧客行動、組織、製品機能の変化に応じて見直します。変更理由と適用日を残し、旧ルールで処理中の案件をいつ切り替えるかも決めておきます。

導入後も例外と後工程を確認する

最終判断では通常時の利便性だけでなく、繁忙期、担当者不在、外部サービス停止、契約終了時の動作も確認します。例外時でも顧客への案内方法と対応履歴が残る構成であれば、平常時の効率だけに偏った選定を避けられます。

本番後は利用件数だけでなく、手作業への戻り、再処理、転送、顧客からの再連絡も確認します。処理件数が増えていても後工程の負担が増えた場合は、設定、導線、担当範囲のどこに原因があるかを切り分け、必要に応じて運用を見直します。

こうした導入後の見直しまで考える場合、電話対応だけを個別に管理するのではなく、問い合わせ履歴やAI支援、品質管理を含めて状況を確認できる構成が適しています。Udeskはクラウド型コールセンターに問い合わせ管理、AIチャットボット、ボイスボット、オペレーター支援などを組み合わせられるため、自社の運用状況に応じて対象範囲を調整しながら継続的に改善を進める際の選択肢となります。

FAQ

Q:RFPは何社へ出しますか

A:要件に適合し得る候補へ絞り、回答負担と比較精度の均衡を取ります。

Q:必須と希望は分けるべきですか

A:必須、評価対象、将来要件に分けると過剰な失格や過剰提案を防げます。

Q:PoCは無料ですか

A:製品と検証範囲で異なるため、回線、設定、支援、撤去を含む費用を事前確認します。

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

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