こんにちは。タカヤマタクマです。
トークスクリプトを作成しないコールセンターはないと思いますが、効果的に作成し運用しているコールセンターもまた少ないと感じています。
今回は当たり前だけどうまく機能しているケースも少ないこの問題について述べていきたいと思います。
 |
 |
トークスクリプト（コールスクリプト）のメリット
トークスクリプトとは電話応対をする上での台本みたいなものです。
こういう質問を受けたらこう答えるというような、シナリオのようなものだと思っていただければ良いでしょう。
会社や人によってはコールスクリプトと呼ぶ人もいますしセンターによって呼び名は異なるかもしれませんが、どのコールセンタでも必ずそういうものがあります。
なぜトークスクリプトが必要か、以下にメリットを挙げたいと思います。
1.電話応対の品質が一定になりやすくなる
2.間違えた回答をするのを防ぐ
3.新人が業務に慣れやすくなる
人によっていうことや対応方法が違うと、電話をかけてきた人が混乱しますし、コールセンターとしてどうなのかという根本的な姿勢が問われてしまいます。
必要か必要でないかと言ったら確実に必要なものです。
ただその作成時に注意をしないと、本末転倒になったり、うまく機能しない場合があります。
これから作成時の注意点に詳しく触れたいと思います。
作成時にオペレーターも参加させる
トークスクリプトは管理層だけでつくらないことが重要です。
たとえSVを入れても、現場のオペレーターを入れて検討する必要があります。
なぜ現場のオペレーターを入れなければいけないのか。
それは電話応対の現場が分からない人が作成したスクリプトは、間違いなく機能しないからです。
電話対応では実際にやっていないと分からないことがあまりにも多いので、それが分からない人だけで勝手に決めてはいいものができないということです。
私はこれまで勤務してきたコールセンターでも上意下達のような形でトークスクリプトを指示されたことがありました。
ただ現場のことに無知な人が作成したトークスクリプトがいきなり決定事項として降りてきた時の衝撃は、なかなかすごいものがあります。
上はこんなにも分かっていないのだと現場では怒りや悲しみの感情が渦巻くことがあります。
もちろんそんな環境でオペレーターが最高のパフォーマンスを発揮できるはずがありません。
現場では機能しないスクリプトを管理層だけで作成して、上意下達のような形で現場に伝えると「これ本当に使うんですか」というリアクションが必ずあるものだと思っていただきたいと思います。
実際に私は何度もそういう場面を目撃していますが、まずそのクレームの窓口となるのはSVです。
しかしSVとしても上からの指示であるため、使ってくださいと言うしかありません。
ただそのまま使うと現場が混乱します。
そして私が見聞きした範囲で申し上げると、そういう場合次第にスクリプトは形骸化します。
問題のあるスクリプトを現場が改変して使うようになります。
そうすると先ほどトークスクリプトを作成する理由として挙げた、電話応対の品質を一定にすると言う効果が失われます。
ただこれは明らかに管理層がに非がある事例です。
現場のことを知らない管理層が、なぜ日々現場で対応しているオペレーターに、このように対応すればうまくいくと指示をしてうまく機能すると思えるのか、既にその考え方自体がおかしいともいえます。
作成にあたっては、管理層、 SV、 オペレーターを入れたチームを編成するのが理想的です。
作成したトークスクリプトは最終決定の前に一度現場に伝えて、意見を受けて修正するプロセスがあってもいいでしょう。
自分たちが決定に関わったトークスクリプトは、現場にとって自分たちのトークスクリプトです。
押し付けられたものではありません。 そのためトークスクリプトが遵守される可能性が高くなります。
トークスクリプトが機能するには、面倒でも意見を吸い上げ、一度現場の意見を受け入れて訂正するという、命を吹き込むプロセスが必要です。
常に見直しや改善をしていく（PCDA）
一度作成したトークスクリプトは、業務内容や環境の変化によって随時変更するといいと思います。
これもトークスクリプトが形骸化しないため必要なメンテナンスです。
ただしオープニングやクロージングなど、トークスクリプトの根幹に関わるような骨組みの部分は、あまり変更しない方がいいと思います。
なぜなら特にオープニングの文言は口癖のようになっているオペレーターも多いですし、またよく電話をかけてくる客にとっても、窓口を間違えたのではないかなどと混乱することがあるからです。
オープニング 、クロージングは基本的によほどの理由がない限り変えてはいけません。
ただしそれ以外のところは、随時見直しをしていく必要があります。
先ほどトークスクリプト帰るのは、業務内容や環境の変化など外部の変化によって変更するのがいいと書きました。
その種の変更は基本的に変更せざるを得ないと言うものです。
しかし私はそうした外部環境の変化だけではなく、対応品質向上を目的として積極的に見直しをしてくべきだと考えます。
特に私がご提案したいのは、トークスクリプトを実際に運用してみて、客から受けた質問を再度予め織り込んでおく変更です。
攻めのトークスクリプト変更といえるかもしれません。
例えば以下のようなケースを想定していただければと思います。
変更前
「このサービスはオプションをつけると1年間延長になります」
ここで一旦区切るトークスクリプトがあるとします。
このスクリプトを用いると質問が返ってきくるかもしれません。
「オプションって何だ」「料金はかかるのか」「オプションを付けるにはどうしたらいいのか」などです。
上記の例では、すぐに次の説明に移行する流れになっていますが、実際の電話応対の現場では「オプション」という言葉に反応した客から様々な質問が投げかけられます。
そこで次のように変更したとします。
変更後
「このサービスはオプションを付けると1年間延長になります。オプションの名前は自動延長オプションというもので、税込で月額108円の料金です。もしよろしければ、お申込みはいかがでしょうか」
この例の通り、トークスクリプトを実施した結果、客から出てくることが多い質問は、予めトークスクリプトに織り込んでおくと良いでしょう。
ただ何でもかんでも織り込んでおく必要はありません。実際に運用して質問が多かったものだけを織り込むようにします。
この場合は特に営業関連のトークなので、ここまで一気に言ってしまった方がいいと思います。ここでひっかからなかったら、切り替えてすぐに次に進めます。
この変更によって得られるメリットは二つです。
1.現場でより機能するトークスクリプトになったため、遵守率が上がる
2.新人が業務に入る時に仕事に慣れやすいというメリットが損なわれない
もちろん見直しする時は、作成時と同じく現場のオペレーターをメンバーに入れて改善していくと良いでしょう。
アンケートなどで予め変更点を洗い出しておくのも一つの手です。
会社側の都合だけで作らない
管理層とオペレーターでトークスクリプトを作成したとしても、肝心の客にうまく届いていない場合があります。
それは会社側の都合だけで作られたトークスクリプトだからです。
オペレーターはより現場に近いといっても基本的に会社側の人間です。どうしても会社側の視点に立った説明になりやすいのは避けられません。
ではどうしたらいいでしょうか。ここからはその窓口の性質によって対応方法が異なります。
テクニカルサポートのような技術的なサポート窓口の場合、その電話応対で解決したかどうか、ある程度は再入電があるかどうかによって判断できます。
もちろん違う件で再入電となる場合もあるので、確実な確認方法ではありません。しかし解決したら再入電は少なくなるものです。
再入電があるかどうかはデータとして確認することができます。ここからは管理層の出番です。
再入電の多い問い合わせ内容は何か、なぜ再入電となったのか、分析する必要があります。
そして分析した結果に共通点があれば、トークスクリプト変更のヒントが見つかる可能性があります。
また営業職に強い窓口の場合、最終的にもっと商品の申し込みの率が低い製品やサービス、そのトークスクリプトの見直しから始めましょう。
そのトークスクリプトに客から見たメリットがきちんと説明されていれば、購入率が上がるはずです。
言葉や言い回し、どこかテコ入れできるところがないか検討する必要があります。
どちらの場合でも会社側の立場からしか説明していない場合、会社側の人間がいくら考えても解決方法が見えてこない場合があります。
そこで客からのリアクションをデータから拾い上げて推測するといいでしょう。
トーク例と箇条書きを分けて作成するメリット
コールセンターによってはトークスクリプトを大変厳格に運用しているところがあります。
厳格に運用するのは、冒頭で述べたようなトークスクリプトのメリットをより確実に得たいと思っているからです。
しかし私はそうすることに反対です。
そこには同じ説明をすれば客は同じように受け取るという、ある意味でとても楽観的な考えがあるからです。
こちら側がどんなに厳格に運用したとしても、必ず客側での受け取り方の差異があります。
もし厳格に運用するならば、相手の受け取り方や理解力などの違いにも配慮しなければいけません。
こちらがどんなに完璧だと思うトークスクリプト作成して説明したとしても、それでは理解できない、もしくは違う意味で理解する人がいるものです。
現場のオペレーターは、その辺りを柔軟に判断して電話対応しています。
つまり客によって説明の仕方、説明にかける時間、話の持っていき方などを変えるものです。そしてそれは多くの場合、良い方向に作用します。
トークスクリプトを厳格に運用することは、その柔軟性を発揮できなくするということです。そこで私から一つ提案があります。
トークスクリプトは、あくまでトーク例として作成します。
変更前 →トークスクリプトのみ
変更後 →トーク例 + 要点の箇条書き
こういう風にします。
新人はトーク例を使って説明します。しかしベテランはトーク例を使わずに、箇条書きの方を見て説明します。
箇条書きとするのは、その時に説明をすべきことが抜けていないか、チェックリストとして使ってもらうためです。
ベテランは自己流で説明してもいいけど、この内容は確実に入れておかないとNGという目的で作成しておきます。
箇条書きはあまり多くしすぎない方がいいでしょう。
多くなりすぎる場合は、トークスクリプトを適切に分割して、その段階で説明すべきことの分量を減らします。
また細かいことですが、箇条書きの順番は 前後に因果関係のある場合はその順番、因果関係がない場合は重要度が高いものから記載します。
トークスクリプトは作成すること自体が目的ではありません。
現場で機能するようにしなければいけません。そのためにこういう工夫の方法もあります。
最後にお伝えしたいこと
冒頭でトークスクリプトは必ず必要だと申し上げました。
ただアリバイづくりでとりあえず作成しておこうという発想は厳禁です。面倒でもより実戦で機能するトークスクリプトを作成しなければいけません。
その面倒な作業をした結果得られる二次的な効果を申し上げておきます。
上が決めたトークスクリプト現場に与えるという方式だと、現場で機能しないとうスクリプトであるため、現場では変えて使うことが多いと申し上げました。
つまりなし崩し的に変更をされてしまうということになります。
それに対して上はなし崩し的に追認をするということが多いように見受けられます。それでは組織全体として正式な判断ではなくなります。
そのトークスクリプトをオペレーターが自己流に変えた結果、問題が起きた時のことを考えてみてください。
トークスクリプトのままきちんと言ったのにクレームを言われたら、オペレーターに責任はありません。
しかし自己流に変えた場合はオペレーターの責任になることがあります。 その時に現場のオペレーターを矢面に立たせてはいけません。
オペレーターとしては上から指示された使えないトークスクリプトを良かれと思って変更しただけかもしれません。
元はといえばトークスクリプトの信頼性が低いことが根本の原因です。
トークスクリプトをきちんと機能させることは、オペレーターを守る為、そしてそれによって組織を守る為だと思っていただく必要あります。
またトークスクリプトと言っても、それは組織としての守るべきルールです。
トークスクリプトを守らないということは他のルールを守らないということにも繋がりかねません。
トークスクリプトを変えて使うことが当たり前になってしまうと、他のルールも守ることに対しての意識が下がります。
例えばトークスクリプトの少々の変更はまだしも、会社側にとって絶対に言ってはいけないこともあります。
先ほど箇条書きなどをご提案したのはそのためです。
会社としてはこれだけを伝えたらトーク例の改変は許容するけれど、ここからは許容できないという一線をきちんと引いておくべきだと思います。
組織としての秩序維持するため、トークスクリプトをきちんと作成し、メンテナンスすると問題が発生しにくくなります。
最後までお読みいただき、ありがとうございました。
