SVガチャでOJTが辛いのでは?

「コールセンター OJT 辛い」

この言葉で検索している人は、どんな人なのでしょうか?

「OJTが辛い」という検索だけなら、新入社員など教えてもらう側かもしれません。

一方で、OJTを担当している側かもしれません。

実際、「OJT 辛い」という検索結果には、新入社員、OJT担当者、トレーナー、上司、人事など、さまざまな立場の人の悩みが含まれています。

では、

「コールセンター OJT 辛い」

となると、少し見え方が変わるのではないでしょうか?

コールセンターでは、オペレーターが分からないことがあったとき、SVに相談します。

難しい問い合わせがあれば、SVへエスカレーションします。

SVは、質問に答えたり、顧客応対を引き取ったり、対応方法を教えたりします。

つまり、コールセンターにおけるOJTには、SVとの関係がかなり深く関わっています。

もしかすると、

「OJTが辛い」の正体は、SVとの相性なのではないでしょうか?

いわゆる「SVガチャ」です。

ただ、ここで一つ考えてみたいことがあります。

本当に「SVガチャ」は、SVの人柄だけの問題なのでしょうか?

こんなこと、ありませんか?

コールセンターで働いていると、こんな経験はないでしょうか?

「分からないことをSVに聞いたら、すぐに教えてくれた」

「困ったときは、いつも同じSVに相談している」

「SVによって、教えてくれる内容が違う」

「前のSVには大丈夫と言われたのに、別のSVには確認したほうがいいと言われた」

「同じ質問をしたのに、SVによって答えが違う」

「SVに相談するのが怖くて、自分で判断してしまった」

「逆に、何でもSVに聞くようになってしまった」

「なかなか一人で対応できるようにならない」

こうしたことが続けば、

「自分には向いていないのではないか」

「自分の覚えが悪いのではないか」

「OJTが辛い」

と思ってしまうかもしれません。

では、ここで考えてみましょう。

その違いは、本当にオペレーターとSVの「相性」だけなのでしょうか?

「SVガチャ」は、本当にSVの人柄の問題なのでしょうか?

「気分屋のSVは好かれない」。

これは、単なるイメージではありません。

インソースのコールセンターSVに関するアンケートでは、オペレーターがSVに期待するものとして、「エスカレーション時の迅速・的確な回答」に加え、「感情の安定性」が挙げられています。

「いつ話しても笑顔で対応してくれる」「相手によって態度を変えない」「気分屋にならない」といった声も紹介されています。

つまり、オペレーターにとってSVは、単に質問に答えてくれる人ではありません。

困ったときに頼れる人なのです。

だからこそ、SVの態度や応対の仕方が、オペレーターの働きやすさに影響します。

ただし、ここで「気分屋のSVが悪い」と結論づけるのは、少し違うように思います。

なぜならSVも、人だからです。

それぞれに経験があります。

得意な応対があります。

顧客を見るポイントも違います。

質問の仕方も違います。

何を重要だと考えるかも違います。

つまり、

SVによって応対の知識や経験が違うこと自体は、自然なことなのです。

問題は、その違いをそのまま「人による教育」にしてしまってよいのか、ということです。

コールセンターのSVは、何をしているのでしょうか?

コールセンターのSVは、オペレーターの業務を管理するだけではありません。

オペレーターからの相談を受けたり、難しい問い合わせに対応したり、オペレーターを指導したり、教育したりします。

インソースでは、SVの役割として「業務遂行の管理」「指導・育成」「顧客対応」などが挙げられています。

その中でも、オペレーターのフォローや指導、教育は、コールセンターを運営する上で重要な仕事です。

ここで、ある調査結果を見てみます。



このグラフを見て、どのように感じるでしょうか?

SVの仕事には、オペレーターのフォローや指導、教育が大きく含まれています。

これは、コールセンターにとって、とても重要なことです。

困ったときにSVが助けてくれる。

分からないことを教えてくれる。

難しい顧客応対では、一緒に考えてくれる。

そうしたSVがいるからこそ、オペレーターは安心して顧客応対を続けることができます。

つまり、

オペレーターが困る。

SVが助ける。

オペレーターが応対を続けられる。

この仕組みは、コールセンターにとって必要なものです。

では、ここで一つ考えてみたいことがあります。

SVがオペレーターに教えたことは、その後どうなっているのでしょうか?

エスカレーションで教えたことは、どこに残っているのでしょうか?

SVがエスカレーションに対応します。

そのときSVは、単に答えを教えているだけではありません。

経験豊富なSVなら、

「まず何を確認するか」

「お客様の話のどこに注目するか」

「この情報が分からないと判断できない」

「この場合はAではなくBを選ぶ」

といったことを、頭の中で判断しています。

ところが、それが言葉として整理されず、その場の会話だけで終わってしまったらどうでしょう。

オペレーターは、その場では問題を解決できます。

顧客応対も続けられます。

SVとしても、困っているオペレーターを助けることができました。

一見すると、何も問題はありません。

しかし、そのSVが考えたことは、そのSVの頭の中に残ったままかもしれません。

そして、次の日には別のオペレーターが、同じようなことで困ります。

またSVに聞きます。

またSVが教えます。

また、その場では解決します。

これが繰り返されます。

すると、

「同じことを何度も教える」

という現象が起きます。

ここには、オペレーターの覚えが悪いというだけでは説明できないものがあります。

教えたことが、次の応対に使える形で残っているのか。

という問題です。

OJTが辛いのは、教える側だけなのでしょうか?

「OJTが辛い」という検索結果を見ると、OJT担当者側の悩みも数多く見つかります。

自分の仕事が止まる。

何度教えても覚えてもらえない。

新人の反応が分からない。

どこまで教えればよいのか分からない。

新人の成長が思ったように進まない。

自分自身も教育について教えてもらっていない。

こうした悩みがあります。

一方で、教えてもらう側にも、

何を聞けばよいのか分からない。

質問しづらい。

先輩によって言うことが違う。

成長できているのか分からない。

いつまで経っても一人でできない。

といった悩みがあります。

つまり、

OJTが辛い。

という状態は、教える側だけの問題でも、教わる側だけの問題でもありません。

両方が辛くなっているのであれば、個人ではなく、仕事の仕組みを見る必要があるのではないでしょうか?

エスカレーション率が高いのは、本当に「人の問題」なのでしょうか?

コールセンターでは、オペレーターがSVへ相談することを「エスカレーション」と呼びます。

そして、オペレーターの評価指標として、エスカレーション率が使われることがあります。

実際、コールセンターのKPIとして、一次完結率やエスカレーション率などを管理するという調査結果もあります。

また、エスカレーションを減らし、オペレーターが自分で対応できる範囲を広げることを、コールセンターの課題として扱っている事例もあります。

そのため、

「エスカレーション率が高い」

という結果だけを見ると、

「まだ一人で対応できていない」

「独り立ちできていない」

「もっと教育が必要」

と考えることがあります。

場合によっては、

「この人は適合していない」

と評価されることもあります。

しかし、本当にそれだけでよいのでしょうか?

エスカレーションそのものが悪いのでしょうか?

エスカレーションすることは、本当に悪いことなのでしょうか?

ここは、少し分けて考える必要があります。

顧客に誤った情報を伝えてしまうより、分からないことをSVに確認するほうが安全です。

判断できないことを勝手に処理するより、必要なタイミングでエスカレーションするほうがよい場合もあります。

つまり、

エスカレーションそのものが悪いわけではありません。

重要なのは、

「なぜエスカレーションしたのか」

「何を確認できていなかったのか」

「SVは何を教えたのか」

「次回は一人で対応できるようになったのか」

ということではないでしょうか?

実際、コンタクトセンターの品質評価においても、エスカレーションしたかどうかだけではなく、適切なタイミングで相談できたか、必要な情報を確認してから相談したか、といった点を見る考え方があります。

つまり、エスカレーションは、

「できない人が助けを求めた記録」

だけではありません。

教育情報でもあるのです。

エスカレーションの中には、SVの経験と知識が詰まっています

例えば、こんな場面を考えてみます。

オペレーター：

「お客様からこう言われているのですが、どう対応したらいいですか?」

SV：

「その前に、○○について確認した?」

オペレーター：

「確認していません」

SV：

「では、まずそこを確認してみてください」

オペレーター：

「分かりました」

この短いやり取りの中にも、SVの知識があります。

SVは、

「この問い合わせなら、まず○○を確認する」

という経験則を持っています。

さらに、

「この情報が取れたらA」

「取れなければB」

「この条件なら別の部署へ確認する」

といった分岐も持っています。

これは、単なる答えではありません。

顧客応対の進め方そのものです。

ところが、エスカレーションがその場の解決で終わると、この知識はSVの頭の中に残ったままになります。

オペレーターは、そのときは理解したかもしれません。

しかし、次の電話では別の問い合わせが来ます。

すると、さっき教えてもらったことを忘れているかもしれません。

また困ります。

またSVに聞きます。

またSVが教えます。

この繰り返しです。

SVによって教え方が違うと、オペレーターの経験も変わります

さらに問題になるのが、SVによる違いです。

AというSVは、

「まずここを確認してください」

と教える。

BというSVは、

「この場合は、そこまで確認しなくても大丈夫です」

と教える。

CというSVは、

「念のため全部確認してから対応してください」

と教える。

それぞれが間違っているとは限りません。

それぞれの経験や判断基準があるからです。

しかし、オペレーターから見ると、

「結局、何を基準に判断すればよいのか分からない」

という状態になる可能性があります。

これが「SVガチャ」の一つの正体なのではないでしょうか?

SVの人柄だけではありません。

SVが持っている知識や経験が、個人に閉じていること。

それによって、オペレーターが受ける教育に差が生まれているのです。

「できるSV」がいることで、見えなくなるものがあります

優秀なSVがいるコールセンターでは、問題が起きてもすぐに解決します。

オペレーターが困れば、SVが助けてくれます。

難しい顧客応対なら、SVが対応してくれます。

オペレーターが迷えば、SVが判断してくれます。

そのため、コールセンターとしては、

「うまく回っている」

と感じます。

実際、うまく回っています。

しかし、その裏側では、

「なぜSVは、この判断ができたのか?」

が残っていない可能性があります。

SVが経験で判断している。

SVが経験で教えている。

SVが経験で問題を解決している。

その結果、

SVが優秀であるほど、仕事の仕組みの不足などの欠点が見えにくくなる

ことがあります。

これは、SVを責めたいわけではありません。

むしろ逆です。

SVが持っている知識や経験を、コールセンター全体で使えるようにしたいのです。

エスカレーションを減らすには、オペレーターをもっと頑張らせればよいのでしょうか?

ここで、最初の問いに戻ります。

エスカレーション率が高い。

だから、

「もっと覚えてください」

「もっと勉強してください」

「もっと経験を積んでください」

「もっと自分で考えてください」

とオペレーターに求める。

もちろん、それも必要な場面があります。

しかし、それだけでエスカレーションは減るのでしょうか?

もし同じ問い合わせで、複数のオペレーターが同じようにSVへ相談しているのであれば、見るべきなのはオペレーターだけではありません。

その問い合わせに対して、

「何を確認するのか」

「どのように質問するのか」

「どこまで分かれば判断できるのか」

「どの条件で次の対応へ進むのか」

が、仕事の仕組みとして整理されているかを見る必要があります。

つまり、

人の不足だけを見るのではなく、応対を成立させる仕組みを見る。

ということです。

SVが教えていることを、次の人が使えるようにする

では、どうすればよいのでしょうか?

一つの方法は、エスカレーションでSVが教えていることを、コールセンターのナレッジとして残すことです。

ただし、ここでいうナレッジは、

「質問されたら、この答えを返す」

というFAQだけではありません。

重要なのは、

「何を確認するのか」

「なぜ確認するのか」

「どの順番で聞くのか」

「どの情報が取れたら次に進むのか」

「どの条件なら別の対応を選ぶのか」

といった、会話の進め方です。

SVがエスカレーションで教えていることには、こうした情報が含まれています。

だからこそ、

エスカレーションを、ナレッジ更新の入り口にする

という考え方ができます。

顧客応対。

エスカレーション。

SVの知見。

ナレッジ更新。

次の顧客応対。

この循環です。

推進チームが、SVの知識をコールセンターのナレッジに変える

ここで重要になるのが、推進チームの役割です。

SV一人ひとりに、

「あなたの知識を全部マニュアルに書いてください」

とお願いするだけでは、うまくいきません。

SVには日々の業務があります。

エスカレーションへの対応もあります。

オペレーターのフォローもあります。

教育もあります。

そのため、SV自身にナレッジ化まで任せると、どうしても負担になります。

そこで、

「SVが教えていることを観察する」

「どのような問い合わせでエスカレーションが起きているかを見る」

「SVが何を確認しているのかを見る」

「どのような分岐で判断しているのかを見る」

「それをコールセンター全体で使える形に整理する」

という役割を、推進チームが担います。

ここで初めて、

SVの個人知

から

コールセンターの組織知

へ変えることができます。

トークスクリプトは「同じセリフ」を話すためのものではありません

ここで、トークスクリプトの意味も変わってきます。

トークスクリプトというと、

「この質問には、この答えを読む」

というイメージがあるかもしれません。

しかし、本当に再現したいのは、同じセリフではありません。

様々な問題を抱えて電話してくる顧客に対して、

「何を確認するのか」

「なぜ確認するのか」

「次に何を聞くのか」

「どの情報を得たら、どの対応を選ぶのか」

という、応対の進め方です。

つまり、

SVがエスカレーションの中で行っていることを、誰でも使える仕事の仕掛けに変える。

ということです。

これができれば、SVによる教育の差も変わってきます。

SVの個性をなくす必要はありません。

SVを同じ人間にする必要もありません。

必要なのは、

SVが持っている知識を、SVだけのものにしないこと

です。

AIコーチングエンジンは、SVの代わりをするものではありません

こうした考え方を、顧客応対の中で実現するために、当社ではAIコーチングエンジンを開発しています。

AIコーチングエンジンは、AIがオペレーターに代わって顧客応対をするものではありません。

また、AIがすべてを判断するものでもありません。

基本にあるのは、

判断はヒト・意思決定はヒト

という考え方です。

AIが支援するのは、

「次に何を確認するのか」

「どの質問をするのか」

「どの情報が不足しているのか」

「どの分岐に進むのか」

といった、顧客応対の会話運びです。

SVがエスカレーションで教えていることを、あらかじめ整理しておけば、オペレーターが顧客応対をしている途中で、その知識を使えるようになります。

つまり、

顧客応対。

必要なときに確認。

AIによるナビゲーション。

オペレーターが判断。

顧客応対を継続。

という形です。

SVガチャをなくすのではなく、SVガチャを減らす

ここまで考えると、「SVガチャ」という言葉の意味も少し変わってきます。

SVを選べるようにする。

SVを教育する。

SVの人柄を変える。

という話ではありません。

SVによって、

「教えてくれる内容が違う」

「判断基準が違う」

「確認するポイントが違う」

という状態を、そのままオペレーターの経験差にしないことです。

SVが違っても、

「コールセンターとして必要な確認ポイント」

「顧客応対の進め方」

「判断するための情報」

が、組織として共有されていれば、オペレーターは必要な知識を使うことができます。

つまり、

SVの個性は残したまま、SVによる教育差を減らす。

これが、私たちが考える「SVガチャを減らす」という意味です。

エスカレーションを「なくす」のではなく、次の成長につなげる

エスカレーションは、なくせばよいものではありません。

分からないことを確認する。

難しい問い合わせを安全に処理する。

顧客に誤った案内をしない。

そのために、エスカレーションは必要です。

だから、

「エスカレーション率をゼロにする」

ことを目標にするのではなく、

必要なエスカレーションを残しながら、同じことを次から自分で対応できるようにする。

という考え方が重要なのではないでしょうか?

そして、そのためには、

エスカレーション。

SVの知識。

ナレッジ更新。

次の顧客応対。

という循環をつくる必要があります。

OJTを「人を育てる時間」だけで終わらせない

OJTは、人を育てるために必要です。

SVが教えることも必要です。

エスカレーションで助けることも必要です。

しかし、それだけで終わってしまうと、同じことが何度も繰り返されます。

OJTで起きたこと。

エスカレーションで起きたこと。

SVが教えたこと。

オペレーターが迷ったこと。

これらはすべて、コールセンターの仕事を改善するための情報でもあります。

だからこそ、

OJTが辛い。

という声があったとき、

「もっと頑張ってください」

「慣れれば大丈夫です」

だけで終わらせるのではなく、

「なぜ辛いのか?」

「どこで迷うのか?」

「何をSVに聞いているのか?」

「SVは何を教えているのか?」

「それは次の人が使えるようになっているのか?」

まで見てみる。

そうすると、OJTの見え方が変わってきます。

「人ができないこと」と「仕事の仕掛けが整っていないこと」は、本当に同じなのでしょうか?

新人が一人で対応できない。

エスカレーションが多い。

着台判定に合格できない。

OJTが長引く。

こうした結果が出たとき、私たちはつい「人」の側を見ます。

知識が足りない。

経験が足りない。

判断力が足りない。

コミュニケーション力が足りない。

もちろん、人の成長は必要です。

しかし、

人ができないことと、応対を成立させる仕組みが整っていないことは、本当に同じなのでしょうか?

ここを分けて考えることが重要です。

人に「もっと頑張ってください」と求めるだけではなく、

「その人が自然に感じ取ったことを、次の応対に使える形にできないか?」

「SVが教えたことを、組織のナレッジにできないか?」

「同じことを何度も教えなくても済む仕組みにできないか?」

と考える。

その積み重ねが、

人が違っても顧客応対を成立させられるコールセンター

につながっていくのではないでしょうか?

顧客期待に応えるために、OJTを考える

コールセンターの目的は、人を評価することではありません。

OJTを効率化することでもありません。

エスカレーション率を下げることでもありません。

最終的に考えたいのは、

会社として顧客期待に応えること

です。

そのために、顧客応対があります。

顧客応対を支えるために、業務があります。

業務を支えるために、人や教育があります。

そして、人や教育を支えるために、ナレッジやシステムがあります。

OJTで起きていることも、エスカレーションで起きていることも、単なる教育上の出来事ではありません。

そこには、

「顧客に応えるために、何が必要なのか」

を考えるための情報があります。

だからこそ、

顧客応対。

エスカレーション。

SVの知識。

ナレッジ更新。

次の顧客応対。

この循環をつくることが大切なのです。

「コールセンター OJT 辛い」

という検索の裏側には、

「自分の何が悪いのだろう?」

「SVが悪いのだろうか?」

という問いがあるのかもしれません。

しかし、もう一つ、

「人が頑張らなくても顧客応対を成立させられる仕事の仕掛けになっているだろうか?」

という問いも、あってよいのではないでしょうか。

OJTの辛さを、人の問題だけで終わらせない。

エスカレーションを、人の未熟さだけで終わらせない。

SVの経験を、SVだけのものにしない。

そうして、個人の経験を組織のナレッジへ変えていく。

それが、顧客期待に応えるコールセンターをつくるための、一つの方法だと考えています。