経営を脅かすリスクを再点検!! 経営リスクを無力化できる対策を公開。是非お役立てください
「コールセンターを立ち上げることになった。さて、何から始めればいいのだろう?」
そんな状況になったら、まず何を調べますか?
電話を受けるためのシステムが必要。
オペレーターも必要。
管理者も必要。
業務フローやマニュアルも必要。
教育や研修も必要。
もちろん、予算や導入スケジュールも考えなければなりません。
実際に「コールセンター 立ち上げ」と検索すると、立ち上げの手順、必要なもの、システム、人員、費用、業務設計など、さまざまな情報が見つかります。
どれも、コールセンターを立ち上げるためには必要な情報です。
でも、ここで一つ疑問が出てきます。
「必要なものは分かった。でも、何を基準に選べばいいのだろう?」
システムにも複数の選択肢があります。
人材の採用方法にも選択肢があります。
外部サービスを利用する方法もあります。
教育方法にも、設備やツールにも、それぞれ選択肢があります。
つまり、コールセンターの立ち上げで難しいのは、必要なものを知ることだけではありません。
何を選び、何を優先するのか。
その基準を決めることも、立ち上げの重要な仕事です。
そこでこの記事では、コールセンターの立ち上げを「必要なものを揃える作業」としてではなく、顧客期待に応えるサービスをどう実現するのかという視点から整理してみます。
コールセンターの立ち上げに必要なものとは?
まず、一般的にコールセンターの立ち上げで必要になるものを考えてみます。
例えば、
- コールセンターを運営する人
- 管理者
- 電話や通信の仕組み
- PBXやCRMなどのシステム
- 業務フロー
- マニュアル
- トークスクリプト
- 教育・研修
- 品質管理
- 運用ルール
- セキュリティ
- 予算
- 導入スケジュール
などがあります。
どれも重要です。
ただし、ここで一つ考えておきたいことがあります。
「なぜ、それが必要なのか?」
例えば、CRMを導入するとします。
「コールセンターだからCRMが必要」というだけでは、どの製品を選べばよいのか判断できません。
必要な機能も分かりません。
どこまでシステム化すればよいのかも分かりません。
オペレーターに何をしてもらうのかも決まりません。
一方、
「顧客から問い合わせを受けたとき、過去の情報を確認しながら、顧客の状況に応じた顧客応対を行う必要がある」
と分かれば、そのために必要な情報、業務、システム機能が見えてきます。
つまり、
必要なものを先に決めるのではなく、必要な理由を先に考える。
ここが、コールセンターの立ち上げを考える上で重要になります。
コールセンターの立ち上げで、何を基準に選ぶのか?
必要なものが分かったとして、それを何を基準に選べばよいのでしょうか。
例えば、複数のシステム会社から提案を受けたとします。
A社は価格が安い。
B社は機能が多い。
C社は導入実績が多い。
D社はカスタマイズに強い。
どれを選ぶのでしょうか。
採用する人材についても同じです。
経験者を採用するのか。
未経験者を採用して育成するのか。
教育期間を長くするのか、短くするのか。
外部の専門会社に支援してもらうのか。
選択肢はいくらでもあります。
判断基準が曖昧だと、価格や知名度、機能数など、目につきやすい条件に引っ張られてしまいます。
だから、立ち上げ時には、
「何を選ぶか」より先に「何を実現したいのか」を決めておく。
これが重要になります。
例えば、コールセンターの目的が「電話を効率よく処理すること」だけなら、生産性を中心に選択することも考えられます。
しかし、
「顧客が困ったときに、適切に問題を解決できるサービスを提供する」
ことが目的なら、選ぶ基準は変わってきます。
では、そもそも、
コールセンターは何を実現するために作るのでしょうか?
顧客期待から逆算すると、コールセンターの作り方が変わる
顧客がコールセンターに電話をするのは、電話をすること自体が目的だからではありません。
知りたいことがある。
困っていることがある。
商品やサービスについて確認したい。
問題を解決したい。
納得したい。
あるいは、自分が経験したことを会社に伝えたい。
その先に、顧客が期待している状態があります。
そこで、まず、
「顧客は何を期待しているのか?」
を起点にします。
そして、その期待に応えるために、
- どんなサービスを提供する必要があるのか
- そのサービスを提供するために、どんな業務が必要なのか
- その業務を行うために、どんなシステムが必要なのか
- そのシステムを成立させるために、どんなインフラやプロダクトが必要なのか
という順番で考えます。
サービス実現モデル
ここで、当社がコールセンターなどのサービスを構築するときに使っている「サービス実現モデル」をご紹介します。
顧客期待
↓
提供サービス
↓
提供サービスを支える業務
↓
業務で使うシステム
↓
インフラやプロダクト
このモデルで大切なのは、下から積み上げないことです。
「このシステムがあるから、この業務にしよう」
ではありません。
「このサービスを実現するために、この業務が必要だから、このシステムが必要になる」
という順番です。
そうすると、立ち上げ時の「選ぶ」という行為も変わります。
システムを選ぶ。
人を選ぶ。
支援会社を選ぶ。
教育方法を選ぶ。
それぞれを別々に考えるのではなく、
「顧客期待を実現するために必要なのは何か?」
という一つの基準から考えられるようになります。
顧客期待をサービスに変えるために、何を要件定義するのか?
では、この考え方を、実際の立ち上げにどう落とし込めばよいのでしょうか。
ここで必要になるのが、要件定義です。
サービス実現モデルは、「何を実現するのか」を考えるための概念的な地図です。
そこから、
「では、具体的に何を決めればいいのか?」
へ落としていきます。
当社では、コールセンターなどのサービスを構築するときに、次のような要件定義書のもくじ案を使っています。
これは、システムの機能を決めるためだけのものではありません。
顧客期待に応えるサービスを実現するために、何を決めておく必要があるのかを整理したものです。
1. 目的・目標
まず、
- 顧客向け商品・サービスの目的
- 顧客期待と提供価値
- 目指す顧客満足度
- 事業として達成したい目標
を整理します。
つまり、
「何のために作るのか?」
を確認します。
2. 現状と課題
次に、
- 現在のサービスや業務
- 顧客から見た課題
- 組織・業務上の課題
- 人材・教育上の課題
- システム・インフラ上の課題
- 既存の仕組みが抱える課題
を整理します。
3. 改善・変革の要件
そして、
「何を変える必要があるのか?」
を整理します。
ここまでが、
目的 → 現状 → 変えること
です。
その上で、具体的なサービスや業務へ進みます。
4. サービス要件
- 必要なサービス
- 顧客との接点
- 顧客に提供する価値
- 顧客から期待される顧客応対
- サービス実現に必要な機能
を決めます。
ここで、顧客期待が具体的なサービスへ変わります。
5. 業務要件
次に、そのサービスを実現するために必要な業務を決めます。
必要な業務だけではありません。
- 組織間連携
- 各部門の業務
- 管理者業務
- 業務担当者の業務
- 人材育成
- 保守・運用
- 業務上必要な判断・確認・対応
まで考えます。
サービスを実現するには、人が実際に何をしなければならないのか。
そこまで定義します。
6. 人・組織要件
ここで、
- 必要な組織体制
- 必要な役割・責任
- 必要な人材
- 必要なスキル
- 教育・訓練
- 人材育成・定着
を整理します。
ここまで決まって初めて、
「どんな人を採用し、どう育てるのか?」
という話が具体的になります。
7. システム・インフラ要件
その上で、
- システム化する業務
- 管理者機能
- 業務担当者機能
- データ
- セキュリティ
- インフラ
- 既存システムとの連携
などを決めます。
つまり、
システムを先に決めるのではなく、サービスと業務を実現するために必要なシステムを決める。
という順番です。
8. 実現・移行要件
どう導入するのか。
どう移行するのか。
どう運用するのか。
実現するための方法を整理します。
9. 検証・評価要件
そして、
- 顧客満足度
- 業務上の評価
- 導入効果
- 改善効果
などを確認します。
10. 経費・資源要件
必要な財源、資源、期間、投資などを整理します。
11. 要件の優先順位
何を必須とするのか。
何を優先するのか。
何を将来対応とするのか。
を決めます。
12. 要件のトレーサビリティ
最後に、
- 顧客期待と要件
- サービスと要件
- 業務と要件
- 人・組織と要件
- システムと要件
- 要件と評価指標
それぞれの関係を追えるようにします。
つまり、
「なぜ、この要件が必要なのか?」
を、顧客期待まで戻って確認できるようにするわけです。
要件定義とは、「システムに何を作ってもらうか」を決める作業だけではありません。
顧客期待に応えるために、会社として何を実現する必要があるのかを明らかにする作業
とも言えるのではないでしょうか。
サービスを実現する業務と、人・組織をどう設計するのか?
ここまで来ると、コールセンターで働く人の仕事も変わってきます。
単純に、
「電話を受けて、マニュアル通りに答える」
という仕事を設計するのではありません。
顧客の状況を把握する。
必要なことを確認する。
顧客が何を求めているのかを理解する。
必要な情報を伝える。
問題を解決する。
必要に応じて会社の他部署につなぐ。
そして、そこで得られた情報を次の改善につなげる。
こうした仕事を成立させるために、
- どんな人材が必要なのか
- どんなスキルが必要なのか
- どんな教育が必要なのか
- どんなナレッジが必要なのか
を考えます。
教育とOJTをどう考えるか
教室で知識を教え、マニュアルを読んでもらい、ロールプレイをする。
それだけでは、実際の顧客応対で起きるすべての分岐を経験することはできません。
実際のOJTでは、ベテランが、
「そこをもう少し確認した方がいい」
「この場合は、先にこちらを聞こう」
「このお客様が本当に困っているのは、別のところかもしれない」
と補足します。
つまり、ベテランは単に答えを知っているのではありません。
どこで何を確認し、どのように会話を進め、どの選択肢を取るのか
を知っています。
この仕事をどう設計するのかという問題が、次の「AIをどう使うのか」という話につながってきます。
コールセンターの業務を支えるシステムとAIをどう考えるのか?
AIというと、
「AIに顧客応対をさせる」
「AIに判断させる」
「AIで問い合わせを自動化する」
という発想になりがちです。
しかし、今回考えているサービス実現モデルでは、少し順番が違います。
まず、
顧客期待に応えるために、どんな仕事が必要なのか?
を考える。
その仕事を、
人が行う部分と、システムが支援する部分に分ける。
そして、
AIに何を支援させると、人が適切に仕事をできるのか?
を考えます。
例えば、顧客との会話の中で、
「次に何を確認すればよいのか分からない」
「必要な情報をどこから探せばよいのか分からない」
「このケースでは、どの対応を選択すればよいのか迷う」
ということが起きるなら、そこをAIで支援するという考え方があります。
ここで重要なのは、
AIが判断するのではなく、人が判断できるようにする。
ということです。
顧客期待に応えるコールセンターで、AIは何を支援するのか?
当社が特許を取得し開発しているAIコーチングエンジンは、ここから生まれました。
AIコーチングエンジンは、FAQを表示するだけの仕組みではありません。
ベテランが顧客応対の中で行っている、
- 質問
- 確認
- 会話の運び
- 分岐
- 選択
などを構造化し、応対中のオペレーターを支援します。
例えば、顧客から一つの質問を受けたとします。
その質問にそのまま答えるだけで、本当に問題が解決するのでしょうか。
場合によっては、答える前に確認すべきことがあります。
その確認によって、顧客が本当に困っていることが分かるかもしれません。
そして、その情報をもとに対応を選択する。
この一連の流れを支援するのが、AIコーチングエンジンです。
あくまで、
判断はヒト。意思決定はヒト。
AIは、人が顧客期待に応える仕事を適切に行うための支援役です。
顧客の声を改善につなげると、コールセンターの役割が変わる
ここまでの話は、コールセンターの中で顧客に適切な顧客応対をするという話です。
しかし、顧客期待に応えるためには、コールセンターだけでは解決できない問題もあります。
そこで重要になるのが、顧客の声を会社の改善につなげることです。
実際の実証実験では、問い合わせを「呼種」という単位で分類し、パレート分析を行いました。
すると、さまざまな顧客から寄せられる問い合わせの中に、同じような問い合わせが集中していることが見えてきます。
例えば、
「マニュアルのこの表記は何を指しているのか分からない」
「記入すると書いてあるけれど、具体的に何を書けばよいのか分からない」
「蓋が開けづらい」
「蓋のしまりが悪い」
といった問い合わせです。
ここで重要なのは、「問い合わせが多い」という事実を確認して終わらないことです。
呼種別にパレート分析をすると、
どの問い合わせを優先して改善すればよいのか
を選びやすくなります。
その原因をコールセンターの中だけに求めるのではなく、
- 商品なのか
- サービスなのか
- マニュアルなのか
- 業務なのか
- 案内方法なのか
会社側の原因に戻して考えます。
つまり、
顧客から問い合わせを受ける
→ 問い合わせを分類する
→ 集中している呼種を見つける
→ 改善対象を選ぶ
→ 原因側を改善する
→ 同じ問い合わせを減らす
という循環です。
こうなると、コールセンターは単に電話を処理する場所ではありません。
顧客期待と、会社が提供しているサービスとの間にあるズレを見つけ、改善につなげる場所
にもなります。
立ち上げたコールセンターを、どう検証し改善し続けるのか?
コールセンターは、立ち上げた瞬間に完成するものではありません。
実際に顧客と接することで、初めて分かることがあります。
想定していなかった問い合わせ。
分かりにくい説明。
業務上の無理。
教育では教えきれなかったケース。
システムでは想定していなかった使い方。
こうした情報を、
使う → 気づく → 共有する → 改善する
という循環につなげていく必要があります。
だからこそ、立ち上げ時の要件定義にも、
「実現後の改善方法」
や、
「改善効果の確認方法」
を入れておきます。
そして、要件のトレーサビリティによって、
「この改善は、そもそもどの顧客期待から生まれたものなのか?」
まで戻れるようにしておく。
これができれば、立ち上げ時に決めたことを固定化するのではなく、顧客との接点から学びながらサービスを更新できます。
会社として顧客期待に応える
ここまで、コールセンターの立ち上げについて考えてきました。
最初は、
「何が必要なのか?」
という問いでした。
そこから、
「何を基準に選ぶのか?」
という問いになりました。
そして、
「そもそも何を実現するために作るのか?」
と考えると、顧客期待が出てきます。
顧客期待から提供サービスを考える。
そのサービスを実現する業務を考える。
業務を担う人と組織を考える。
それを支えるシステムやインフラを考える。
必要に応じてAIで人の仕事を支援する。
実際に顧客と接して、顧客の声からサービスを改善する。
この循環を回していく。
そう考えると、コールセンターの立ち上げは、単に電話を受ける部署を作ることではありません。
顧客期待に応えるためのサービスを、会社として実現すること。
そのために、何が必要なのかを逆算して決めていく。
だから、コールセンターを立ち上げるとき、
「何を揃えるか」から始めるのではなく、
「顧客期待に応えるために、何を実現する必要があるのか」から始める。
ことが重要だと考えています。
そして、その先にあるのは、コールセンターの成功だけではありません。
会社として顧客期待に応えること。
そこまでを見据えて、コールセンターを設計する。
コールセンターの立ち上げについて、疑問があればお問い合わせください
ここまで読んで、
「考え方は分かったけれど、自社の場合はどう考えればいいのだろう?」
「どこまでを自社で決めればいいのだろう?」
「要件定義は何から始めればいいのだろう?」
といった疑問があれば、お気軽にお問い合わせください。
一般的なご質問であれば、できる限り回答します。
また、自社の状況を整理しながら、必要なサービス、業務、人・組織、システムなどを具体的に検討したい場合には、個別のご相談として対応することもできます。
コールセンターを立ち上げることが目的なのではなく、
会社として顧客期待に応えるために、何が必要なのか。
そこから一緒に整理していきましょう。
