オペレーションを進化させる
現場のWEBマガジンpowered by Bewith

日常は、業務指示にあふれている 意味ある指示と、意味のない指示

  • #コールセンター
  • #コンタクトセンター
  • #業務指示

HUMAN

古川真澄

2022.07.22

コンタクトセンターというところは、とにかくルールが多い。
最前線でお客様に提供しているサービスについて対応をするわけだから、サービス内容に基づいた応対ルールがあることはもちろん、企業のポリシーや文化というものも、ルールにしてオペレーション全体に落とし込んでいくことになる。

また、コンタクトセンターでは多くの人が業務に従事するため、大勢が統一した動きが取れ、かつ、不公平が無いように、業務の内容だけではなく、コンタクトセンターの中での所作についてもルールが存在する。

そのため、出勤したらまずあれをしろ、小休憩を取る時はこれをしろ、このお問合せがきたらどうしろ、あの商品のこの色だったらこうしろなど、コンタクトセンターには大小さまざま多数のルールが存在することになる。

ちなみに、これらのルールを過不足なく設定することが業務設計における重要ポイントの一つであるし、ここを見誤ったがために運営で苦しんだ話は、この業界の人間であれば一つやふたつ、身に覚えがあると思う。

だから、コンタクトセンターではルールを守り切るために、多くの業務指示が繰り出される。だが、その指示が指示として有効でない場面が多く見られるのも事実だ。

コンタクトセンターにおける業務指示とはどうあるべきか、一度まじめに考えてみたい。

「~しないでください」

コンタクトセンターにはテッパンのルールがいくつかある。
「オペレーターは何かわからないことがあった時に、隣のオペレーターにエスカレーション(質問)をしてはならない」もその中の一つだ。

このルールが設定されている理由は大きく2つある。

・正確性が担保できないから
 ➡隣のオペレーターが必ずしも正解を持っているとは限らないので正確性が担保できない。かつ、万が一隣のオペレーターが誤った回答をしてしまった場合に、お客様にご迷惑をおかけした責任の所在が曖昧になる
・生産性が低下する恐れがあるから
 ➡隣のオペレーターが、自身の対応業務以外に時間を取られることで、生産性が低下する

よって、オペレーターは分からないことがあったなら、スーパーバイザーにエスカレーションをするのが正解だ。
では、このルールをオペレーターに守ってもらいたいときに、指示としてどう伝えるべきだろうか。

やりがちなのは、「分からないことがあっても、隣のオペレーターさんには質問しないでくださいね」というものだ。禁止事項としてルールを伝えている。でもこの指示は100点ではない。

なぜならば、この指示を聞いたオペレーターがスーパーバイザーに質問してくれるとは限らないからだ。この指示を聞いたオペレーターが、「隣がダメなら向かいの人かな?」などと向かい合わせに座るオペレーターにエスカレーションをする可能性だって残される。もちろんオペレーターには悪気などない。

私たちは、正解を知っているから禁止事項を言い渡された時に即座に正しい回答が思い浮かぶが、オペレーターはそうではない。コンタクトセンターの常識など、一般の人は持ち合わせていないのだ。

だから、正しくは次のように指示をしなければならない。
「わからないことがあったら、手を上げてスーパーバイザーを呼んでください。スーパーバイザーが回答します。隣のオペレーターさんには質問しないでくださいね。」

相手に正しいことをしてほしいなら、禁止事項を伝えて道をふさぐだけではだめだ。正しきルートを伝えることが重要だ。あなたの指示は、相手がそれを聞いたら余計な想像を巡らせず、即座に実行できるものになっているだろうか。

「確認してください」

近くにあるマニュアルを今すぐに確認してほしい。
安易に「確認してください」というフレーズを使っている箇所はないだろうか。

例1)「正しい処理ができているか、最後にきちんと確認してください」
例2)「スクリプトを確認してください」。
よく見るフレーズだ。

実は「確認する」とは曖昧な言葉だ。容易に「チラッと見る」に置き換えられる。
特に、何を確認するかが明確に定義されていない時に、「チラッと見る」に変換される率が高い。

初心者に運転を教える時に、「右折をする時は周りをよーく確認してくださいね」などと言ってももはや無意味だ。間違いなく、後方からくる歩行者と接触事故を起こす。
車で右折をする際は、

・対向車がきていないこと
・前方 / 後方から自転車やバイクが来ていないこと
・前方 / 後方から歩行者が来ていないこと

を確実に視認する必要があることを教えなければならない。

コンタクトセンターでのオペレーションも同様に、確認をするならば、何がどのような状態であることが正しいかを、明確に定めて伝えるべきだ。

よって例1は、「一度入力が完了したら、〇〇が□□の状態になっていることを確認してください」「〇〇に□□が入力されていることを確認してください」「空欄が一つもないことを確認してください」など、正解の状態を合わせ伝えてほしいのだ。

次に例2はどうだろうか。さきほど、「確認する」は「チラッと見る」に容易に置き換えられると書いたが、「確認する」は「ただ見る」に置き換えられることも多い。
「お鍋を見ておいてね」と言われた人が、鍋が吹きこぼれているのにただそれを見続けたという例のやつだ。

例2の場合、本来は「〇〇の場合はスクリプトを確認し、記載されているフロー通りにお伝えしてください」と、スクリプトを見た後に何をしてもらうのかを伝えなければならない。「確認する」ことよりも、「確認した後に何をするか」「確認して何がどういう状態だったらどうするのか」の方が、ルールを守り切るという意味においては重要なはずなのだ。

「~ができていません」

オペレーターや、時には同僚のスーパーバイザーにフィードバックするのが心苦しいという話はよく耳にする。
確かにフィードバックとは、相手ができていないことの指摘が起点になるため、気が重くなるのも少しは理解する。

だが、気が重くなるのはフィードバックの方法や内容が不十分だからという点も、見過ごしてはならない。

「〇〇さん、△△ができていませんでしたよ」
「〇〇さん、そういうことをされると困ります」
「〇〇さん、今のような話し方はお客様がご不快になりますよ」

こんな伝え方をしてはいないだろうか。実際にコンタクトセンターでは、これらにトゲが生えたようなフレーズを聞くことがあると言えばある。

きっと、このような伝え方をする背景には、相手を責める気持ちが存在する。そしてこれらの伝え方は、指示でも指導でもなんでもなく、ただのネガティブ感情の吐露だ。

フィードバックをするためには相手の不足点を伝えることは必要だ。だが、仕事としてはそれだけでは足りない。やはりフィードバックをする際も、どうすることが正しいのか、どうしてほしいのかを伝えなければならない。

「〇〇さん、△△ができていなかったので、次からは□□するようにしましょう」
「〇〇さん、△△をすると後工程が遅れることがあるので、□□でやってもらうことはできますか」
「〇〇さん、今のような話し方はお客様がご不快になりますので、□□のように話してみましょう」

どんな感情を抱いていようが、相手にどうしてほしいのかまで伝えること。きっとこれが仕事ということなのだと思う。
このフィードバックを受け取る側も、「〇〇しましょう」とポップに言ってもらえた方が、気持ち良くその気になるというものだ。

伝えるべきは、あなたの気持ちではない

「~しないでください」も、「確認してください」も、「~ができていません」も、これらは実は感情だ。
業務指示とは業務を正しく遂行するためにするものなのだから、相手にどうしてほしいかを端的に分かりやすく伝える必要がある。正直、あなたがどう思っているかは、仕事の指示においてはさほど重要ではない(誤解を恐れずに言うならば、だが)。

無数に存在するルールを正しく守り、コンタクトセンターを安全に運営するためには、スーパーバイザーが出す指示が、具体的でそのままオペレーターが取るべき行動になっていることが理想だ。

コンタクトセンターにおける「普通」や指示を出す人にとっての「当たり前」を前提に指示を出してはいけないし、自分の感情を伝えればオペレーターがあなたの意を汲んで正しい行動を取ってくれるなどということも期待してはならない。

「何度も伝えているのに全然ルールを守ってくれない」「相手が思ったように動いてくれない」。そんなことがあったら、まずは、自分の指示が「そのままオペレーターが取るべき行動」になっているかを確認してみてほしい。

ビーウィズでは、コールセンター教育を効率化し、オペレーターの成長サイクルを高める教育プラットフォーム『Qua-cle(クオクル)』をご提供しております。

コンタクトセンターにおける応対品質の課題を解決するために必要な、「学び」・「トレーニング」・「フィードバック」の一連のサイクルを実現する、コールセンター向け品質改善プラットフォームで、eラーニングから学ぶだけではなく、フィードバックのサイクルまでを組み込んだことが最大の特徴です。

また、モニタリング自動評価機能を搭載し、日常の自分の成果を確認することができ、オペレーターの成長機会に繋がります。


詳しい資料は、以下からご覧いただけます。
https://www.bewith.net/gemba-driven/download/entry-130.html


関連記事