コールセンターのオムニチャネル化はどこまで必要か ー 統合する履歴・残す窓口の決め方

顧客の70%は、問い合わせ相手が誰であっても会話の文脈を引き継いでいることを期待している。Zendeskの2026年CXガイドによれば、担当者が状況を把握していないと顧客の60%は同じ説明を繰り返すことになり、これが体験を悪化させる主因になっている。一方で、電話・チャット・メール・SNSのすべてを1つのシステムに統合しようとすると、実装コストと保守費が跳ね上がる。ではコールセンター(コンタクトセンター)はオムニチャネル化を、どこまでやるべきなのか。本稿の立場を先に言えば、「全チャネル統合」を目標にするのは順序が逆で、まず用件単位で「履歴を引き継ぐ必要がある窓口」を絞り込み、そこから拡張するのが失敗しにくい。
用件とチャネルを一覧化する

まず技術的な土台を確認したい。Amazon Connectの管理者ガイドでは、音声・チャット・タスク・メールの4チャネルについて、ルーティングプロファイルごとに「同時に何件まで対応させるか」を設定する。音声は同時1件までしか設定できないが、チャットとタスクは1〜10件の範囲で同時対応数を決められる。さらに「クロスチャネル同時対応」(他チャネル対応中でも新しい問い合わせを受けられる設定)と、1チャネルの対応が終わるまで他チャネルを回さない専念モードのどちらを取るかも、チャネルの組み合わせごとに選べる。
この設計自体が、「全チャネル統合」が単純な話ではないことを示している。音声はそもそも同時受電できない前提で作られているのに対し、チャット・タスクは同時対応が前提の設計だ。つまり統合すべきは「システム」である前に「オペレーターの働き方」であり、音声中心のオペレーターにチャットも持たせるなら、同時対応数と負荷を再設計しない限り、統合は数字の上のつじつま合わせで終わる。
当て馬として、「窓口の数を増やす」ことと「履歴を引き継ぐ」ことを分けて考えたい。LINEやチャットボットを新設するのは窓口を増やす投資で、比較的着手しやすい。一方、電話で受けた内容をチャット担当者が引き継ぐには顧客IDの統合が要る。多くのプロジェクトが「窓口を増やす」ところまでは進み、「履歴を引き継ぐ」で止まるのは、ここに難易度の壁があるからだ。
会員先行公開中(9月17日に一般公開)



