コールセンターDXの進め方|現状把握から定着までの5ステップ
「コールセンターのDXを進めるように」と言われても、何から手をつければよいのか迷う方は多いのではないでしょうか。新しいシステムを入れれば変わるのか、AIを使えばよいのか、在宅勤務に対応すればよいのか。選択肢が多いほど、目的を見失いやすくなります。
コールセンターDXで大切なのは、ツールを導入することそのものではなく、お客様の体験と、オペレーターや管理者の働き方を、デジタルの力で良い方向に変えることです。そのためには、今の窓口で何が起きているかを把握し、解決すべき課題に優先順位をつけ、課題に合ったツールを選び、小さく試してから広げ、使われ続ける状態をつくる、という順序を踏むことが欠かせません。
この記事では、コールセンターDXを五つのステップに分けて、それぞれで何をすればよいか、どこでつまずきやすいかを解説します。各ステップで使える表やチェックリストも紹介しますので、自社の取り組みに当てはめながら読み進めてください。
コールセンターDXとは
DXは「道具の入れ替え」ではない
DX(デジタルトランスフォーメーション)という言葉は、使う人によって意味が少しずつ違います。この記事では、コールセンターDXを「デジタルの仕組みを使って、窓口の仕事の進め方と、お客様の体験を変えること」と考えます。
たとえば、古い電話の設備を新しいクラウドのシステムに置き換えるだけでは、仕事の進め方は変わらないかもしれません。同じメニュー、同じ手順、同じ管理の仕方のまま設備だけが新しくなれば、それは「道具の入れ替え」です。一方、新しい仕組みを使って、オペレーターが通話の後の記録にかけていた時間を減らす、管理者がリアルタイムで状況を見て配置を変えられるようにする、お客様が電話以外の窓口でも同じ履歴で対応を受けられるようにする、といった変化が起きれば、それはDXと呼べる変化です。
コールセンターDXで変わりうること
コールセンターDXで変えられる領域を、大きく四つに分けて整理します。
| 領域 | 変わりうること | 関わる仕組みの例 |
|---|---|---|
| つながり方 | お客様が用件に合った窓口に早くつながる | IVR、着信のルーティング、キュー、折り返しの依頼 |
| 対応の仕方 | オペレーターが必要な情報をすぐに見られる、記録の手間が減る | 顧客の履歴、ナレッジ、通話の要約 |
| 管理の仕方 | 管理者が状況を見て、配置や教育を改善できる | レポート、リアルタイムの状況表示、品質管理、要員管理 |
| 働き方 | 場所に縛られずに働ける | ブラウザの電話、クラウドのシステム |
どの領域から取り組むかは、会社によって違います。お客様がつながりにくいことに悩む窓口もあれば、オペレーターの定着に悩む窓口もあります。だからこそ、最初のステップで現状を把握することが大切になります。
DXがうまくいかない典型的なパターン
本題に入る前に、コールセンターDXがうまくいかない典型的なパターンを押さえておきましょう。
- ツールが先に決まっている:「AIを入れる」「このシステムに変える」と先に決めてしまい、何の課題を解くのかがあいまいなまま進む
- 現場が置き去りになる:管理者や情報システムの担当だけで進め、実際に使うオペレーターの意見を聞かない
- 一度にすべてを変える:設備、手順、管理の仕方を一斉に変え、現場が混乱する
- 導入して終わる:導入した後の使われ方を確認しず、気づいたら以前の手順に戻っている
- 効果を測れない:導入の前の状態を記録しておらず、変わったのかどうかがわからない
これから紹介する五つのステップは、こうしたパターンを避けるための順序でもあります。

ステップ1:現状把握
なぜ現状把握から始めるのか
現状把握は、地味で時間のかかる作業に見えるかもしれません。しかし、ここを省くと、課題の優先順位を決められず、ツールを選ぶ基準も持てず、導入の効果も測れません。現状把握は、DXのすべてのステップの土台です。
把握する四つの視点
現状は、次の四つの視点で把握します。
1. お客様の視点
- どんな用件で電話をかけてくるか(用件の種類と、その割合の傾向)
- つながるまでにどれくらい待っているか、どこで電話を切っているか
- 一度で用件が解決しているか、何度もかけ直していないか
- お客様からどんな声が寄せられているか
2. オペレーターの視点
- 一件の電話の中で、何に時間がかかっているか(聞き取り、検索、記録、確認など)
- どんな場面で困っているか、先輩や管理者に聞いているか
- 使っているシステムや道具はいくつあり、どれくらい行き来しているか
- 通話の後の記録や連絡に、どれくらいの手間がかかっているか
3. 管理者の視点
- 窓口の状況を、どのように、どれくらいの遅れで把握しているか
- シフトや配置をどのように決めているか
- 応対の品質をどのように確かめ、オペレーターに伝えているか
- 報告のための集計に、どれくらいの手間がかかっているか
4. 仕組みの視点
- 電話の設備、顧客の情報、ナレッジ、記録の仕組みは、それぞれ何を使っているか
- 仕組み同士はつながっているか、手作業で写していないか
- 契約の更新時期や、保守の終了時期はいつか
現状把握の方法
四つの視点で現状を把握するには、次のような方法を組み合わせます。
| 方法 | わかること | 進め方のポイント |
|---|---|---|
| 電話の記録を集計する | 用件の傾向、待ち時間、放棄、時間帯ごとの量 | 使っている仕組みで取れるデータを確認し、数か月分を見る |
| オペレーターの作業を観察する | 一件の中で時間がかかっている作業 | 隣に座って数件の電話を観察し、作業の流れを書き出す |
| オペレーターに聞き取る | 困っていること、工夫していること | 管理者以外の人が聞くと、本音を聞きやすい |
| 管理者に聞き取る | 管理の手間、判断に困る場面 | 集計や報告にかかる時間も具体的に聞く |
| お客様の声を読む | 不満や要望 | アンケート、問い合わせ、口コミなどを集める |
| 仕組みを棚卸しする | 使っている仕組み、つながり、契約 | 一覧表にして、更新の時期も書き込む |
作業の流れを書き出す
オペレーターの一件の電話を、作業の単位に分けて書き出してみると、改善の余地が見えてきます。
| 段階 | 作業 | 使う仕組み | 困りごとの例 |
|---|---|---|---|
| 着信 | 電話に出る | 電話の設備 | 誰からの電話かわからない |
| 本人確認 | 名前や番号を聞いて確かめる | 顧客の情報 | 別の画面で検索が必要 |
| 用件の聞き取り | 用件を聞く | — | 前回の対応の内容がわからない |
| 回答 | 答えを調べて伝える | ナレッジ、社内の資料 | 資料がばらばらで探しにくい |
| 記録 | 対応の内容を書く | 対応の記録 | 通話の後に書く時間がかかる |
| 連絡 | 担当部署に引き継ぐ | メール、社内のチャット | 同じ内容を何度も書き写す |
「困りごとの例」の欄に書かれたことが、DXで解決できるかもしれない課題の候補です。書き出すときは、一つの段階に何秒、何分かかっているかの目安も添えておくと、どの段階に時間が集まっているかがわかります。観察した数件だけで判断せず、用件の種類が違う電話も含めて、何人かのオペレーターについて書き出すと、偏りを減らせます。
数字で残しておくこと
現状把握の段階で、あとで比べられる数字を残しておくことが大切です。導入の後に効果を確認するとき、この数字が比べる基準になります。どの数字を残すかは、ステップ2で決める課題によって変わりますが、少なくとも次のような基本の数字は記録しておきましょう。
- 時間帯ごと、曜日ごとの電話の量
- つながるまでの待ち時間の傾向
- 待っている間に切られた電話の割合
- 一件あたりの通話の時間と、通話の後の作業の時間
- 転送の割合
指標の意味や計算の仕方は、コールセンターのKPI一覧で詳しく整理しています。
現状把握のつまずき
- データだけで判断する:数字は「どこで」問題が起きているかを教えてくれますが、「なぜ」は教えてくれません。観察と聞き取りを必ず組み合わせます。
- 管理者の思い込みで決める:管理者が考える課題と、現場が感じている課題が違うことはよくあります。
- 時間をかけすぎる:完璧な現状把握を目指すと、いつまでも次に進めません。数週間など期限を決めて行います。
ステップ2:課題の優先順位
課題を一覧にする
現状把握で見つかった課題を、一つの表に書き出します。このとき、課題は「ツールがない」ではなく、「何が起きていて、誰が困っているか」の形で書くのがポイントです。
| 課題 | 困っている人 | 起きていること |
|---|---|---|
| 月曜朝につながりにくい | お客様 | 待っている間に切られる電話が多い |
| 通話の後の記録に時間がかかる | オペレーター | 次の電話に出るまでに時間がかかる |
| 回答を探すのに時間がかかる | オペレーター、お客様 | 保留が長くなる、回答がばらつく |
| 状況がリアルタイムでわからない | 管理者 | 混雑に気づくのが遅れる |
| 集計に手間がかかる | 管理者 | 毎月の報告に多くの時間を使う |
| 電話とメールの履歴が分かれている | オペレーター、お客様 | 同じ説明を繰り返してもらう |
「ツールがない」という書き方をすると、解決策が一つに決まってしまいます。「何が起きていて、誰が困っているか」で書けば、ツール以外の解決策(手順の見直し、教育など)も検討できます。
優先順位をつける二つの軸
課題の優先順位は、「影響の大きさ」と「取り組みやすさ」の二つの軸で考えます。
- 影響の大きさ:お客様の体験、オペレーターの負担、会社の目標に、どれくらい影響するか
- 取り組みやすさ:費用、期間、関わる部署の数、今の仕組みとの関係などから見て、どれくらい取り組みやすいか
| 取り組みやすい | 取り組みにくい | |
|---|---|---|
| 影響が大きい | 最初に取り組む | 計画を立てて段階的に取り組む |
| 影響が小さい | 余力があれば取り組む | 後回しにする |
最初に取り組むのは、影響が大きく、取り組みやすい課題です。早い段階で成果が見えると、社内の協力を得やすくなり、次の課題にも取り組みやすくなります。影響は大きいが取り組みにくい課題は、すぐには手をつけられなくても、計画に入れておきます。たとえば、古い設備の契約の更新時期に合わせて仕組みを入れ替える、といった長期の計画です。目の前の取り組みやすい課題と、長期の大きな課題を並行して見ておくことで、場当たり的な取り組みになるのを防げます。
目標を決める
優先する課題が決まったら、その課題が解決した状態を、具体的な目標として書きます。
- 「月曜朝の待っている間の放棄を、現状より減らす」
- 「通話の後の作業の時間を短くし、その分を次の電話に使えるようにする」
- 「混雑に気づいてから配置を変えるまでの時間を短くする」
目標には、現状把握で残した数字と比べられる指標を含めます。どれくらい改善を目指すかは、現状の数字と、取り組みの規模を踏まえて、社内で話し合って決めましょう。
関わる人を決める
課題ごとに、誰が責任を持ち、誰が関わるかを決めます。現場のオペレーターの代表、管理者、情報システムの担当、必要に応じて経営層や関係部署が加わります。特に、実際に使うオペレーターの代表を最初から加えておくと、ツールを選ぶときにも、試験導入のときにも、現場の視点を取り入れられます。
ステップ3:ツールの選び方
課題からツールの種類を決める
優先する課題が決まったら、その課題を解くのに必要な機能を考えます。ツールの名前から入るのではなく、課題から機能、機能からツールの順に考えるのがポイントです。
| 課題 | 必要な機能の例 |
|---|---|
| つながりにくい、待たせてしまう | 着信の振り分け、キュー、折り返しの依頼、待ち時間の案内 |
| 用件に合った担当につながらない | IVRのメニュー、スキルに応じた振り分け |
| 通話の後の記録に時間がかかる | 通話の要約、記録のテンプレート |
| 回答を探すのに時間がかかる | ナレッジの検索、よくある質問の整理 |
| 状況がリアルタイムでわからない | リアルタイムの状況表示、レポート |
| 品質の確認に手間がかかる | 通話の録音と評価、評価シートの管理 |
| シフトの作成に手間がかかる | 入電の予測、シフトの作成と実績の管理 |
| 窓口ごとに履歴が分かれている | 複数の窓口をまとめる受信箱、顧客の履歴 |
| 在宅でも働けるようにしたい | ブラウザで使える電話、クラウドのシステム |
着信の振り分けの考え方はACD(着信呼自動分配)とはで解説します。
クラウドかオンプレミスか
コールセンターのシステムには、インターネットを通じて使うクラウド型と、自社で設備を持つオンプレミス型があります。導入までの期間、拡張のしやすさ、保守の負担、在宅勤務との相性などが違います。比べ方は、クラウド型コールセンターとオンプレミスの違いで詳しく解説します。
比べるときの観点
ツールを比べるときは、機能の多さだけでなく、次の観点も確かめます。
現場で使えるか
- オペレーターが迷わずに使える画面か
- 管理者が、自分たちで設定を変えられるか(メニュー、営業時間、振り分けのルールなど)
- 使い方の説明や、問い合わせの窓口は整っているか
今の仕組みとつながるか
- 顧客の情報、対応の記録、社内の連絡の仕組みとつなげられるか
- つなぐための仕組み(APIなど)が用意されているか
- データを書き出して、ほかの仕組みに移せるか
段階的に広げられるか
- 一部の窓口や一部の機能から始められるか
- 人数や窓口が増えたときに、広げやすいか
情報の扱いは十分か
- 通話の録音や顧客の情報が、どこに、どのように保存されるか
- 誰がどの情報を見られるかを、細かく設定できるか
- 社内の情報管理のルールに合っているか
費用の構造はわかりやすいか
- 月額の費用、利用量に応じた費用、初期の費用など、何に費用がかかるか
- 人数や電話の量が変わったとき、費用はどう変わるか
具体的な料金や条件は、各サービスの公式の案内で確認してください。
比較表を作る
候補のツールを、同じ観点で比べるための表を作ります。
| 観点 | 重み | ツールA | ツールB | ツールC |
|---|---|---|---|---|
| 優先課題の機能 | 高 | |||
| 現場の使いやすさ | 高 | |||
| 管理者による設定の変更 | 中 | |||
| 今の仕組みとのつながり | 中 | |||
| 段階的な導入 | 中 | |||
| 情報の扱い | 高 | |||
| 費用の構造 | 中 |
「重み」は、自社にとっての大切さです。すべての観点を同じ重みで比べると、優先課題に関係の薄い機能の多さで評価が決まってしまうことがあります。
デモや試用で確認する
資料だけで判断せず、デモや試用で実際に操作してみます。このとき、管理者や情報システムの担当だけでなく、オペレーターの代表にも触ってもらいましょう。試すときは、自社でよくある電話の場面を用意し、その場面を最初から最後までツールで進めてみると、使いやすさの違いがわかります。たとえば、「住所の変更を希望するお客様からの電話を受け、本人を確認し、変更の内容を記録し、担当部署に引き継ぐ」という場面を、候補のツールそれぞれで試します。管理者の立場でも、「混雑している時間帯に、どのキューに何件待っているかを確認し、オペレーターの配置を変える」といった場面を試しておくと、管理の画面の使いやすさも比べられます。
ツール選びのつまずき
- 機能の多さで選ぶ:使わない機能が多いと、画面が複雑になり、設定も難しくなります。
- 今の手順をそのまま再現しようとする:新しいツールの考え方に合わせて、手順を見直すことも検討します。
- つながりを後回しにする:導入してから、ほかの仕組みとつながらないことに気づくと、手作業の写し替えが残ります。
ステップ4:試験導入
小さく試す理由
ツールが決まったら、いきなり全体に導入するのではなく、範囲を絞って試験的に導入します。小さく試すことで、次のような利点があります。
- 実際の電話で使ってみて、資料やデモではわからなかった問題を見つけられる
- 問題が見つかっても、影響を小さく抑えられる
- 試験の結果を数字で示せるため、全体への展開の判断がしやすくなる
- 試験に参加したオペレーターが、全体に広げるときの教え手になれる
試験の範囲を決める
試験の範囲は、次のような単位で絞ります。
- 窓口:一つの窓口や、一つの用件のキューだけで試す
- チーム:一つのチームのオペレーターだけで試す
- 機能:通話の要約だけ、ナレッジの検索だけ、など一つの機能だけで試す
- 時間帯:営業時間外の電話だけ、など時間帯を絞って試す
範囲を選ぶときは、ステップ2で優先した課題がはっきり表れる範囲を選びます。課題が表れにくい範囲で試すと、効果を確認できません。
試験の計画を書く
試験を始める前に、次の内容を一枚にまとめておきます。
| 項目 | 記入例 |
|---|---|
| 目的 | 通話の後の作業の時間を短くできるかを確認する |
| 範囲 | サポート窓口のAチーム、通話の要約の機能のみ |
| 期間 | 〇週間 |
| 比べる指標 | 通話の後の作業の時間、記録の質(管理者の確認) |
| 比べる相手 | 同じ期間のBチーム、またはAチームの試験前の数字 |
| 成功の判断 | 作業の時間が短くなり、記録の質が下がっていないこと |
| 問題が起きたときの戻し方 | 以前の記録の手順に戻す |
| 担当 | 試験の責任者、現場の代表、情報システムの担当 |
「問題が起きたときの戻し方」を事前に決めておくと、試験中に問題が起きても慌てずに済みます。
試験中に集めること
試験中は、数字と声の両方を集めます。
- 数字:計画で決めた指標を、試験の前と同じ方法で集めます。
- オペレーターの声:使いにくい点、助かった点、困った場面を、短い時間で定期的に聞きます。毎日の終わりに数分だけ聞く、週に一度まとめて聞く、など負担の少ない方法を選びます。
- お客様への影響:つながりやすさ、待ち時間、お客様からの声に変化がないかを確認します。
- 想定外のこと:計画にはなかった問題や、思わぬ効果を記録します。
試験の振り返り
試験の期間が終わったら、関わった人で振り返ります。
- 目的に対して、指標はどう変わったか
- オペレーターとお客様への影響はどうだったか
- 想定外の問題と、その対処
- 全体に広げる場合に、変えるべき点(設定、手順、教育)
- 全体に広げるか、範囲を変えて試験を続けるか、やめるか
試験の結果が思わしくない場合でも、それは失敗ではありません。全体に導入する前に、合わないことがわかったという成果です。結果が思わしくなかった理由が、ツールそのものにあるのか、設定や手順にあるのか、慣れの問題なのかを分けて考えると、次の打ち手を決めやすくなります。原因を確認し、設定や手順を変えて再び試すか、別の方法を検討します。
試験導入のつまずき
- 試験の範囲が広すぎる:試験が全体導入と変わらなくなり、問題の影響が大きくなります。
- 比べる基準がない:試験の前の数字を記録しておかないと、効果を確認できません。
- オペレーターへの説明が足りない:なぜ試すのか、何を確認したいのかを伝えておかないと、協力を得にくくなります。
- 期間が短すぎる:慣れるまでは作業が遅くなることもあります。慣れた後の様子を見られる期間を確保します。
ステップ5:定着と改善
導入はゴールではない
全体への導入が終わると、プロジェクトが完了したような気持ちになります。しかし、DXの本当の成果が出るのは、新しい仕組みが日々の仕事に溶け込み、使われ続けるようになってからです。導入の後に何もしなければ、使いにくい部分は避けられ、いつの間にか以前の手順に戻ってしまうことがあります。
定着のための三つの仕掛け
1. 教育と手引き
- 導入のときに、操作だけでなく、なぜ手順が変わったのかを説明します。
- よくある操作や、困ったときの対処をまとめた短い手引きを用意します。
- 試験に参加したオペレーターに、ほかのオペレーターの相談役になってもらいます。
- 新しく入ったオペレーター向けの教育の内容も、新しい仕組みに合わせて更新します。
- 手引きは、操作の画面を順に説明するより、「こんなときはこうする」という場面ごとの形で書くと、忙しいときにも探しやすくなります。
2. 使われ方の確認
- 新しい機能がどれくらい使われているかを、定期的に確かめます。
- 使われていない機能があれば、その理由をオペレーターに聞きます。使いにくい、知らない、必要ない、など理由によって対処が変わります。
3. 声を集めて直す仕組み
- オペレーターが、使いにくい点や改善の案を気軽に伝えられる場所を用意します。
- 集まった声を定期的に確かめ、設定や手順を直します。直したことは、声を寄せたオペレーターにも伝えます。
効果を確認する
全体に導入した後も、ステップ1で残した数字と比べて、効果を確認し続けます。
| 確かめる時期 | 確かめること |
|---|---|
| 導入の直後 | 大きな問題が起きていないか、お客様への影響はないか |
| 数週間後 | 慣れてきた段階で、指標が改善しているか |
| 数か月後 | 効果が続いているか、以前の手順に戻っていないか |
| その後は定期的に | 月に一度などの振り返りで、指標と声を確認する |
効果が見えたら、関わった人と経営層に伝えます。成果が共有されると、次の課題に取り組むときの協力が得やすくなります。
次の課題へ進む
一つの課題が落ち着いたら、ステップ2の課題の一覧に戻り、次に取り組む課題を選びます。DXは一度のプロジェクトで終わるものではなく、この五つのステップを繰り返していく取り組みです。一巡目で導入した仕組みが、二巡目以降の取り組みの土台になることもあります。たとえば、一巡目でクラウドの電話の仕組みを入れておけば、二巡目では、その仕組みのデータを使った要員の配置の見直しや、品質管理の改善に取り組みやすくなります。

テーマ別の進め方の例
コールセンターDXでよく取り上げられるテーマについて、五つのステップをどう当てはめるかの例を紹介します。
テーマ1:通話の後の記録を減らす
- 現状把握:オペレーターが通話の後の記録にかけている時間と、記録の内容を確認します。記録が後で誰に、何のために読まれているかも確かめます。
- 優先順位:記録の時間が長く、次の電話に出るまでの時間に影響しているなら、優先度が高い課題です。
- ツール:通話の要約、記録のテンプレート、顧客の情報との自動のつながりなどを検討します。要約には誤りが起こりうるため、オペレーターが確かめて直す手順を前提にします。
- 試験導入:一つのチームで、要約を使った記録を試し、記録の時間と、記録の質を管理者が確かめます。
- 定着:要約を確認するときの観点(名前、日付、約束したことなど)を手引きにまとめます。
通話の要約の使い方は、AI通話要約の使い方で詳しく紹介しています。
テーマ2:窓口ごとに分かれた履歴をまとめる
- 現状把握:電話、メール、チャットなど、お客様がどの窓口からどれくらい問い合わせているか、窓口ごとの履歴がどこに残っているかを確認します。
- 優先順位:お客様が窓口を変えるたびに同じ説明を繰り返している、担当者が別の窓口の履歴を探すのに時間がかかっている、といった課題があれば優先度が高くなります。
- ツール:複数の窓口をまとめる受信箱と、顧客ごとの履歴を検討します。
- 試験導入:電話とメールなど、二つの窓口から始めます。
- 定着:担当の決め方、対応の状態の管理など、運用のルールを決めます。
テーマ3:在宅でも働ける窓口にする
- 現状把握:在宅で働きたいオペレーターの希望、在宅で扱える業務の範囲、情報の管理のルールを確認します。
- 優先順位:採用や定着の課題、災害時の事業継続の課題とあわせて判断します。
- ツール:ブラウザで使える電話、クラウドのシステム、リアルタイムの状況表示などを検討します。
- 試験導入:一部のオペレーターが、一部の時間帯で在宅勤務を試します。
- 定着:情報管理のルール、チームの連絡の方法、困ったときの相談の方法を整えます。
テーマ4:品質の確認と教育の手間を減らす
- 現状把握:管理者が通話を聞いて評価するのに、どれくらいの時間を使っているか、評価の結果がオペレーターにどう伝わっているかを確認します。
- 優先順位:評価できる通話が少なく、教育が経験の浅いオペレーターに行き届いていないなら、優先度が高い課題です。
- ツール:通話の録音と評価シートの管理、通話の要約や文字起こしを使った評価の補助などを検討します。
- 試験導入:一つのチームで、新しい評価の流れを試し、評価にかかる時間と、フィードバックの回数を確認します。
- 定着:評価の観点と、フィードバックの進め方を、管理者の間でそろえます。
ステップごとのチェックリスト
各ステップを終えるときに、次の点を確認しましょう。
ステップ1:現状把握
- [ ] お客様、オペレーター、管理者、仕組みの四つの視点で確認した
- [ ] 数字だけでなく、観察と聞き取りも行った
- [ ] 後で比べるための数字を記録した
ステップ2:課題の優先順位
- [ ] 課題を「何が起きていて、誰が困っているか」で書いた
- [ ] 影響の大きさと取り組みやすさで優先順位をつけた
- [ ] 優先する課題の目標と、確かめる指標を決めた
- [ ] 現場の代表を含む、関わる人を決めた
ステップ3:ツールの選び方
- [ ] 課題から必要な機能を考えた
- [ ] 重みをつけた比較表で比べた
- [ ] オペレーターの代表もデモや試用に参加した
- [ ] 今の仕組みとのつながりと、情報の扱いを確認した
ステップ4:試験導入
- [ ] 範囲、期間、指標、成功の判断、戻し方を計画に書いた
- [ ] 試験の前の数字を記録した
- [ ] 数字とオペレーターの声の両方を集めた
- [ ] 関わった人で振り返り、広げるかを判断した
ステップ5:定着と改善
- [ ] 手引きと教育の内容を整えた
- [ ] 使われ方を定期的に確かめている
- [ ] 声を集めて直す仕組みがある
- [ ] 効果を確認し、関係者に伝えた
進め方の例
ある窓口でのDXの進め方を、架空の例で紹介します。
状況:オペレーター十数名のサポート窓口。週明けの朝につながりにくく、オペレーターは通話の後の記録に追われている。管理者は、混雑に気づくのが遅れがちで、毎月の報告の集計にも時間がかかっている。
ステップ1:電話の記録を数か月分集計し、オペレーターの作業を観察した。週明けの朝に待っている間の放棄が多いこと、通話の後の記録に多くの時間を使っていることを数字で確認した。
ステップ2:課題を一覧にし、「週明けの朝のつながりにくさ」と「通話の後の記録の手間」を優先した。前者は折り返しの依頼の案内と配置の見直しで取り組みやすく、後者は影響が大きいと判断した。
ステップ3:課題に必要な機能(キュー、折り返しの依頼、リアルタイムの状況表示、通話の要約)から候補を絞り、オペレーターの代表も加わって試用した。
ステップ4:一つのチームで数週間試し、放棄の割合と、通話の後の作業の時間を、試験の前と比べた。要約の確認の手順に慣れるまで時間がかかったため、確認の観点を手引きにまとめた。
ステップ5:全体に広げた後も、月に一度、指標とオペレーターの声を確認している。次の課題として、品質管理の手間の削減を選んだ。
切り替えの計画
全体に導入するときは、古い仕組みから新しい仕組みへの切り替えの計画を立てます。電話の窓口は止められないため、切り替えの日に問題が起きないよう、次の点を決めておきます。
| 項目 | 決めておくこと |
|---|---|
| 切り替えの日時 | 電話の少ない曜日や時間帯を選ぶ |
| 切り替えの順番 | チームごと、窓口ごとに順番に切り替えるか、一斉に切り替えるか |
| 並行の期間 | 古い仕組みをいつまで残しておくか |
| 当日の体制 | 情報システムの担当、管理者、提供元の窓口に、すぐ連絡がとれる体制 |
| 確かめること | すべてのメニュー、振り分け、録音、記録が正しく動くか |
| 戻し方 | 大きな問題が起きたとき、古い仕組みに戻す手順と判断する人 |
| お客様への影響 | 電話番号や案内が変わる場合の告知 |
切り替えの直後は、オペレーターから操作の質問が集中します。相談役のオペレーターや管理者が、すぐに答えられるように近くにいる体制をつくっておきましょう。
オペレーターの声の集め方
DXのどのステップでも、オペレーターの声は大切な手がかりです。ただし、忙しい窓口では、声を集めること自体が負担になりがちです。負担を少なくしながら声を集める方法を紹介します。
- 短い質問を決めておく:「今日、新しい仕組みで困ったことは」「助かったことは」の二つだけを、終業前に聞く。
- 書き込める場所を用意する:社内のチャットや共有の表に、気づいたときに一行で書き込めるようにする。
- 代表を通じて集める:チームごとに代表を決め、代表がまとめて伝える。
- 直したことを伝える:寄せられた声で何を直したかを共有すると、声を寄せる人が増えます。
声を集めても何も変わらなければ、次第に声は寄せられなくなります。すぐに直せないことでも、「検討中です」「次の段階で取り組みます」と返すことが大切です。
見落としがちなこと
コールセンターDXを進めるとき、窓口の中のことに目が向くあまり、次のような点が見落とされがちです。
引き継ぎ先の部署
コールセンターで受けた用件は、技術、営業、経理、配送など、ほかの部署に引き継がれることがあります。窓口の仕組みや手順を変えると、引き継ぎの形も変わることがあります。引き継ぎ先の部署にも早めに説明し、引き継ぎの内容や方法が変わる場合は、一緒に手順を決めておきましょう。
お客様への案内
電話番号、IVRのメニュー、受付時間、問い合わせの窓口が変わる場合は、お客様への案内が必要です。ホームページ、案内の資料、メールの署名など、電話番号や窓口が書かれている場所を洗い出し、切り替えの日に合わせて更新します。
録音や記録の扱い
新しい仕組みでは、通話の録音や要約、顧客の情報の保存先や保存期間が変わることがあります。社内の情報管理のルールに合っているかを、情報システムや情報管理の担当と確かめておきます。誰がどの記録を見られるかも、導入の前に決めておきましょう。
古い仕組みのデータ
古い仕組みに残っている対応の履歴や録音を、新しい仕組みに移すのか、古い仕組みで保管するのか、決められた時期に削除するのかを決めます。移す場合は、移したデータが正しく見られるかを確認します。
管理者の仕事の変化
新しい仕組みで、管理者が見られる情報や、できることが増えることがあります。リアルタイムの状況表示を見て配置を変える、レポートを読んで改善の案を考える、といった新しい仕事に、管理者が時間を使えるよう、ほかの仕事の分担も見直しましょう。
五つのステップを進める体制
プロジェクトの役割
コールセンターDXを進めるには、次のような役割が必要です。小さな窓口では一人が複数の役割を兼ねても構いませんが、役割があいまいなまま進めると、判断が遅れたり、作業が漏れたりします。
| 役割 | 主な仕事 |
|---|---|
| 責任者 | 目的と優先順位を決め、必要な予算や人を確保する |
| 現場の代表 | オペレーターの視点で課題を伝え、試験や定着を支える |
| 管理者 | 指標を集め、運用の手順を決め、教育を行う |
| 情報システムの担当 | ツールの比較、設定、ほかの仕組みとのつながりを担当する |
| 関係部署の窓口 | 引き継ぎ先の部署など、窓口の外で影響を受ける部署との調整を行う |
経営層への説明
DXには費用と時間がかかるため、経営層の理解が欠かせません。経営層に説明するときは、ツールの機能ではなく、課題と目標、効果の確認方法を中心に伝えます。
- 課題:現状把握でわかった、お客様とオペレーターが困っていること
- 目標:課題が解決した状態と、確かめる指標
- 進め方:試験導入から始め、効果を確認してから広げること
- 費用と期間:試験と全体導入、それぞれにかかる費用と期間の見込み
- 判断の時期:試験の結果を見て、全体に広げるかを判断する時期
最初から大きな投資を求めるより、試験導入の結果をもとに判断してもらうほうが、合意を得やすくなります。
現場への説明
オペレーターにとって、新しい仕組みの導入は、慣れた手順が変わる負担でもあります。なぜ変えるのか、何が楽になるのか、慣れるまでの間はどう支えるのかを、導入の前に丁寧に説明しましょう。試験に参加したオペレーターの感想を共有すると、ほかのオペレーターも安心して取り組みやすくなります。
AI-SNS.IO Callでできること
AI-SNS.IO Callは、IVRと着信のルーティング、営業時間に合わせた切り替え、キュー、キューごとのボイスメール、IVRのメニューからの折り返しの依頼、名前で担当者を呼び出すディレクトリ、ブラウザのソフトフォン、AIによる通話の要約、設定した窓口をまとめる受信箱、REST API、レポートと分析、品質管理や要員管理の機能などを備えています。日本の電話番号の提供は準備中です。現在はデモで着信をシミュレーションして体験できます。小さく試してから広げる進め方にも合わせやすい構成です。現在利用できる機能の詳細は機能一覧を、設定の手順は使い方ガイドをご覧ください。
よくある質問
コールセンターDXは、何から始めればよいですか?
現状把握から始めます。お客様、オペレーター、管理者、仕組みの四つの視点で、今の窓口で何が起きているかを確かめ、比べるための数字を残します。ツールを選ぶのは、課題の優先順位を決めた後です。
AIを導入すれば、DXになりますか?
AIは手段の一つです。AIを導入しても、解く課題がはっきりしていなければ、効果を確かめられず、使われなくなることもあります。課題から必要な機能を考え、その中でAIが役立つ場面があれば取り入れる、という順序がおすすめです。
小さなコールセンターでもDXは必要ですか?
規模にかかわらず、お客様の体験とオペレーターの働き方を良くする取り組みは役立ちます。小さな窓口ほど、一人ひとりの負担が大きく、仕組みで減らせる作業の効果が実感しやすいこともあります。範囲を絞って小さく始めれば、規模に合った取り組みにできます。
どれくらいの期間がかかりますか?
課題の大きさ、関わる部署の数、ツールの種類によって大きく変わります。一つの課題について、現状把握から試験導入の振り返りまでを数か月ほどで一巡させ、その後に全体へ広げる、という進め方が一つの目安になります。
現場の反対があります。どうすればよいですか?
まず、反対の理由を聞きます。手順が変わる負担、使いにくさへの不安、評価への影響への心配など、理由によって対処が変わります。現場の代表を最初から計画に加える、試験に参加してもらう、慣れるまでの支えを用意する、といった方法で、現場と一緒に進める形をつくりましょう。
効果をどう測ればよいですか?
ステップ1で残した数字と、導入の後の数字を、同じ方法、同じ長さの期間で比べます。狙った指標だけでなく、関連する指標やお客様への影響もあわせて確かめます。数字に加えて、オペレーターの声も効果の大切な手がかりです。
今のシステムの契約が残っています。
契約の更新時期や、保守の終了時期を確かめ、その時期に合わせて計画を立てます。契約が残っている間に、現状把握、課題の整理、ツールの比較、試験導入を進めておけば、更新の時期に落ち着いて判断できます。
在宅勤務への対応もDXに含まれますか?
含まれます。ブラウザで使える電話や、クラウドのシステムを使えば、場所に縛られずに働ける環境をつくれます。ただし、情報の管理や、チームのコミュニケーションの方法も合わせて見直す必要があります。
一度にいくつもの課題に取り組んでもよいですか?
人と予算に余裕があれば可能ですが、現場の負担が一度に増えることに注意が必要です。最初は一つか二つの課題に絞り、成果を確かめてから次に進むほうが、結果として早く進むことが多いでしょう。
ツールの比較で、何を最も重視すべきですか?
優先する課題を解く機能と、現場の使いやすさです。そのうえで、今の仕組みとのつながり、情報の扱い、段階的に広げられるかを確かめます。機能の多さより、自社の課題に合っているかを重視しましょう。
DXが終わったと言えるのは、いつですか?
DXに明確な終わりはありません。一つの課題が解決したら、次の課題に取り組む、という繰り返しです。五つのステップを繰り返しながら、お客様の体験とオペレーターの働き方を少しずつ良くしていくことが、コールセンターDXの姿です。
まとめ
コールセンターDXは、ツールを入れることではなく、仕事の進め方とお客様の体験を変えることです。
- ステップ1:お客様、オペレーター、管理者、仕組みの四つの視点で現状を把握し、比べる数字を残す
- ステップ2:課題を「何が起きていて、誰が困っているか」で書き、影響の大きさと取り組みやすさで優先順位をつける
- ステップ3:課題から必要な機能を考え、現場の使いやすさ、つながり、段階的な導入、情報の扱いで比べる
- ステップ4:範囲を絞って試験導入し、数字と声で効果を確認する
- ステップ5:教育、使われ方の確認、声を集めて直す仕組みで定着させ、次の課題へ進む
まずは、オペレーターの一件の電話を作業の単位に分けて書き出すところから始めてみてください。キューや着信のルーティング、AIによる通話の要約は、AI-SNS.IO Callで試せます。アカウント登録から始めてみましょう。



