日本語

本当に機能するサポートスクリプト(そして対応をこじらせる一言)

返信を送ります。文法はきれいです。技術的な詳細も正確です。ヘルプドキュメントをリンクし、次のステップを含め、適切なブランドボイスで結びました。20分後、CSATが入ってきます。星1つ。

メッセージを読み返します。どこにも間違いが見つかりません。それが問題なのです。

返信は正しかったのです。返信はまた、壁でもありました。あなたがチケット#34に移っている間、顧客が全速力でぶつかった、丁寧な壁です。優れたスクリプトはスクリプトのようには聞こえません。たまたまこの会話を1000回してきた人のように聞こえます。紙の上の言葉は同じです。変わるのは、その言葉の裏で顧客が感じることです。

これはシニアのサポートリードが実際に使うマクロのライブラリです。書き出し、責任を示す一言、「ノー」の伝え方、曖昧さを解く質問、そしてチケットを静かにこじらせるフレーズのカンニングシートです。テンプレートを盗んでください。そのうえで、自分自身の声が埋める継ぎ目を学んでください。

なぜスクリプトは足場であって、松葉杖ではないのか

人々はマクロの問題について2つの立場で議論します。一方は、スクリプトはサポートをロボットのように感じさせると言います。もう一方は、スクリプトがなければ木曜までに燃え尽きると言います。どちらも正しく、互いにすれ違って議論しています。

良いマクロは、会話の予測可能な部分(挨拶、受け止め、次のステップ)を圧縮するので、予測不可能な部分により多くの注意を残せます。実際の問題。顧客の気分。言いかけてやめたこと。そこにこそ、あなたの判断力が宿ります。

悪いマクロは、人間を {{first_name}} という変数に平板化し、テンプレートを避けて書くことを強い、技術的には完全だが感情的には空っぽの返信を顧客に残します。CSATスコアは炭鉱のカナリアです。

経験則:目の前の実際の顧客に合わせるために、マクロから2文を超えて削除したり書き直したりする必要があるなら、そのマクロは硬すぎます。意図的な余白とともに作り直しましょう。

受け止めを先にする書き出し

新人Specialistが犯す最大のミスは、顧客が聞いてもらえたと感じる前に解決策へ飛びつくことです。顧客は段落を書きました。あなたは「アプリを再起動してみてください」と書きました。たとえそれが正しい答えでも、顧客はこう読みます。あなたは私が送ったものを読まなかった、と。

2文です。気持ちを受け止め、それから事実を受け止める。それからトラブルシューティングします。

機能するマクロ:

Mayaさん、これがもどかしいのはよく分かります。明日のレビューに必要だったレポートから締め出されたまま、20分経ってもパスワードリセットのメールがまだ届いていないのですね。すぐに戻れるようにします。

機能しないマクロ:

Mayaさん、サポートチームにお問い合わせいただきありがとうございます。パスワードリセットのメールが届かない問題を経験されているとのことですね。この問題を解決するために、次の手順をお試しください…

どちらの返信も同じ修正へつながります。最初のものは、あなたが顧客の書いたものを読んだことを伝えます。2番目のものは、顧客がチケット番号であることを伝えます。仕事をしているのは「これがもどかしいのはよく分かります」であって、「承知しております」ではありません。後者は長らくあまりに平板に使われてきたため、顧客はそれをつなぎ言葉として読みます。

受け止めを、その顧客の状況に固有の何かへ翻訳しましょう。「明日のレビューに必要だったレポート」は書くのに5秒かかりました。それが、問題を解決する間の20秒の辛抱を買ってくれます。

「私が責任を持って」という当事者意識の一言

謝罪は緊張を和らげません。目に見える当事者意識が和らげます。

不満を抱えた顧客は、たいてい「ご不便をおかけして申し訳ございません」と言ってから自分を別の人へ回した人々の間をたらい回しにされてきました。あなたのところに着く頃には、「すみません」は何も意味しません。意味を持つのは、ここから先これを扱うのはあなただ、と名指しで伝えることです。

機能するマクロ:

私が責任を持って、本日中にこれを解決します。このチケットを一般の対応キューから外し、データが戻るまで私が抱えるようにしました。お客様の時間で午後4時までに、修正か状況のいずれか、早いほうをこちらからご連絡します。

機能しないマクロ:

担当チームがこの件を調査し、できるだけ早くご連絡いたします。このたびのご不便をお詫び申し上げます。

機能する版は、3つの具体的な約束をします。チケットは名前のある1人の人間のもとにある、期限がある、そして期限が滑った場合のバックアップの約束がある(午後4時までに状況の更新)。顧客は、それがどこにあり、誰が持っているかを正確に知ります。

これは、自分で問題を直せないときでも機能します。「私が責任を持って」は、あなたがパッチを書くエンジニアだという意味ではありません。問題がクローズするまで、あなたが顧客の体験の名前のある責任者だという意味です。

怒ったチケットを和らげる:3拍子の構造

チケットが大文字3つの感嘆符付きで届くと、誘惑はそのエネルギーに合わせること(「お怒りはごもっともです」)か、企業的な言い回しに逃げ込むこと(「利用規約に従いますと…」)です。どちらも機能しません。

機能する構造はこれです。受け止める、捉え直す、次のアクション。3拍子、飛ばしなし。

機能するマクロ:

Jamesさん、お怒りになるのも当然です。取締役会の資料が期限を迎える日にエクスポートが3回連続で失敗するのは、受け入れられることではありませんし、私もそうでないふりをするつもりはありません。起きていると私が考えていることはこうです。火曜に私たちが入れた設定変更のせいで、80MBを超えるファイルでエクスポートのジョブがタイムアウトしています。エンジニアリングが恒久的な修正を展開する間、今すぐお客様のアカウントについてその変更を元に戻します。5分後にもう一度エクスポートをお試しください。それでも失敗するなら、このスレッドにご返信いただければ、お電話でご一緒します。

機能しないマクロ:

Jamesさん、エクスポートで問題が起きているとのこと、大変申し訳ございません。取締役会の重要性を考えると、どれほどもどかしいかお察しいたします。あいにく、この問題はいくつかの要因によって起こり得ます。さらに調査できるよう、エラーメッセージのスクリーンショットを送っていただき、ご利用のブラウザをお知らせいただけますでしょうか?

1拍目(受け止める):「お怒りになるのも当然です。」「お気持ちお察しします」ではありません(それは逃げです)。怒りを正当なものと認め、それが正当である具体的な理由を名指しします。

2拍目(捉え直す):実際に何が起きていると考えているかを、平易な言葉で名指しします。チケットを「怒っているし、なぜ壊れているのか分からない」から「壊れているのはこれで、その理由はこうだ」へ動かします。

3拍目(次のアクション):顧客がする1つの具体的なこと、そして代替策。3ステップのトラブルシューティングリストはなし。顧客はリストには怒りすぎています。

原因がまだ分からないときでも、この構造を走らせましょう。「3回目だというのはおっしゃる通りです。まだ答えはありませんが、今このシステムを所有するエンジニアをスレッドに引き入れており、1時間以内に説明をお伝えします。」

答えが「ノー」だと伝える

「ノー」のメールは、ほとんどのSpecialistが4回書き直すものです。謝罪で始め、決定を埋もれさせ、3つの弱い代替案を出し、もう一度謝罪で終わる。顧客は、自分が断られたのかどうかを見極めようとして2回読みます。

謝罪ではなく、決定で始めましょう。3つの弱い代替案ではなく、1つの本物の代替案を。

機能するマクロ:

端的に申しますと、ノーです。単一のアカウントでトライアルを30日を超えて延長することはできません。理由は、トライアルが一度限りの請求記録に紐づいており、延長するとその後にたどるアップグレードの経路が壊れてしまうからです。私にできることはこうです。金曜までにアップグレードいただければ初月に50%の割引を適用でき、これはおおよそトライアルをあと2週間延ばすのと同じ価値になります。お送りしましょうか?

機能しないマクロ:

Priyaさん、トライアルの延長についてお問い合わせいただき、誠にありがとうございます。お待ちいただいたことに本当に感謝しており、プラットフォームをご活用いただけていることがよく分かります。あいにく、私たちの方針では通常、ほとんどの場合トライアルの延長は認められていません。ですが、有料プランへのアップグレードをご検討いただくか、パートナー割引プログラムを調べていただくか、更新日が近づいた頃に改めてご連絡いただくのもよいかもしれません。これらの選択肢のいずれかがご希望に合うか、お知らせください!

機能する版は、率直であることで顧客に親切をしています。顧客は質問をしました。答えを得ました。30秒以内にイエスかノーを言える本物の代替案を1つ得ました。機能しない版は、解決するためにさらにチケットを必要とする3つの中途半端な選択肢を顧客に残します。

「理由は」が重要です。理由のないノーは、恣意的に感じられます。理由のあるノーは、たとえ顧客が気に入らない理由でも、決定として感じられます。決定には反論できます。恣意的な拒否は、ただ恨みを残すだけです。

曖昧さを解く質問

解決までの時間を3倍にする最速の方法は、間違った問題を解き始めることです。顧客は「レポートが壊れている」と言います。それが意味し得ることは6つあります。間違って推測すれば、それが分かるまでに10分を浪費しています。

直し方は尋ねることです。コツは、顧客に尋問されていると感じさせずに尋ねることです。

機能するマクロ:

取りかかる前に手早く確認させてください。「レポートが壊れている」とおっしゃるのは、(a) レポートがまったく生成されない、(b) 生成されるが数字がおかしく見える、(c) 生成されるがエクスポートや共有ができない、のどれでしょうか?いずれも修正可能ですので、正しいものに取り組んでいることを確かめたいだけです。

機能しないマクロ:

問題についてもう少し情報をいただけますか?具体的に何が壊れていますか?どんなエラーが表示されていますか?何をしようとしていましたか?どのブラウザをお使いですか?スクリーンショットがあれば助かります。

機能する版は3つのことをします。自由回答の尋問ではなく具体的な選択肢を提示し、どの答えでもよいと示し(「いずれも修正可能です」)、なぜ尋ねているかを顧客に伝えます。人は、質問が何のためのものか分かると、より進んで質問に答えます。

このマクロをライブラリに組み込めば、初回タッチでの解決が目に見えて上がります。3往復のやり取りのほとんどは、問題が複雑だったからではありません。最初の返信が、間違った版の問題を解いただけなのです。これを明確なチケットのトリアージのシステムと組み合わせ、そもそも正しい問題が正しいSpecialistに届くようにしましょう。

敵対的なスレッドのトーンのリセット

時には、スレッドが悪化していることがあります。顧客は敵対的です。前のSpecialistは身構えました。双方が塹壕にこもり、返信のたびに事態は悪くなります。降参せずに引き戻す必要があります。

機能するマクロ:

Marcusさん、ここで入って、いったんリセットさせてください。返信する前にこのスレッドを最初から最後まで読みました。火曜にお客様が本物の問題を提起され、水曜の私の同僚の返信はそれに十分に答えておらず、それ以来行き詰まっています。それはお客様ではなく、私たちの責任です。私が事実だと分かっていること、分かっていないこと、そして次に私がすることをお伝えします。

これが機能するのは、実際に事実である部分を譲るからです。スレッドは確かに悪化しました。前の返信は良くありませんでした。そうでないふりをすることは顧客を侮辱し、サポート側の誰も注意を払っていないという顧客の疑いを裏付けます。

この書き出しの後、事実だと分かっていることを2〜3個、分かっていないことを2〜3個、そして期限付きで次にすることを1つ挙げましょう。この構造は、謝罪を強いることなく正直さを強います。状況が本当にチケットを上に上げることを求めているなら、それを明示的に行いましょう。「私が持ち込めない目が必要なので、エンジニアリングのリードを引き入れます。」静かに姿を消さないこと。

言ってはいけないこと:カンニングシート

これらのフレーズは丁寧に聞こえます。それらはエスカレーションの加速剤です。どれも、顧客がまずく反応する何かを伝えています。

  • 「方針により」 = 私はルールの陰に隠れている。 言い換え:「これがこのように機能する理由はこうです。」
  • 「申し上げたとおり」 = あなたは私の前の返信を読まなかった。 言い換え:「埋もれてしまった場合に備えて、先にお伝えした内容を改めて。」
  • 「正直に言うと」 は、残りのあなたの返信が正直でなかったことをほのめかします。最初から正直でいましょう。
  • 「実は…」 は、顧客を小さく感じさせる形で訂正します。前置きを落としましょう。
  • 「あいにく」 は、悪い知らせを先読みさせる口癖です。知らせを直接切り出しましょう。
  • 「できるだけ早く」 は、約束のように聞こえながら何も約束しません。たとえ「木曜の終わりまでに」でも、本物の時間枠を使いましょう。
  • 「承知しております」 は、使いすぎで空っぽです。具体的に何を理解しているかに言い換え:「月曜からお待ちいただいているのが分かります。」
  • 「そのようにお感じになられて申し訳ございません」 は、原因ではなく気持ちに謝っています。「このようなことが起きて申し訳ございません」に言い換えましょう。
  • 「システム上は…」 は、ツールの陰に隠れています。見えているものをそのまま言いましょう。
  • 「これでお役に立てば幸いです」 は、自信がないことを発信します。言い換え:「これで解決しなければ、次のステップはこちらです。」
  • 「こちらでは動いています」 = 問題はあなたのせいだ。 言い換え:「私がテストしている環境からは問題が見えていません。手順を一緒に追っていただけますか?」
  • 「お待ちいただきありがとうございます」 は、顧客が感じていないかもしれない辛抱を前提とします。言い換え:「本来より長くかかってしまっているのは承知しています。」

直近の50件の返信を検索してみましょう。その数は、ほぼ必ずSpecialistの予想より多いものです。

テンプレートと戦うのをやめる

マクロがおかしくなった最大のサインは、自分がそれを書き直していると気づくときです。定型的に聞こえるからと挨拶を削除し、状況に合わせて中身を書き直し、結びを切り詰める。そのマクロはあなたの時間を節約していません。継ぎはぎだらけの返信を生み出しています。

意図的な空白とともにマクロを作り直しましょう。良いものは、完全な返信というより骨組みに見えます。

{{first_name}}さん、[トピックだけでなく、相手が具体的に言ったことを受け止める一文]。[起きていると私が考えていること、または知る必要があることを述べる一文]。[次の具体的なアクションと時間枠を伴う一文]。よろしくお願いいたします、Camellia

Specialistは3つの文を埋めます。実際に人間が書いたので、結果は人間が書いたように読めますが、構造は、だらだら書くこと、期限を忘れること、顧客が聞いてもらえたと感じる前にトラブルシューティングへ飛びつくことを止めます。この骨組みは、Zendesk、Front、Intercom、あるいはサポートツールと技術スタックにあるその他何から送る場合でも生き残ります。

スクリプトが機能しているかをどう見極めるか

数週間以内に分かります。見るべき3つのシグナルです。

マクロを使ったチケットでCSATが上向きになる。 新しい受け止めの書き出し、「私が責任を持って」の一言、曖昧さを解く質問を使ったチケットにタグを付けましょう。古いテンプレートを使った前月のチケットと比較します。その差は2週間以内に見えるはずです。

初回タッチでの解決が上がる。 曖昧さを解く質問だけでも、この数字は動くはずです。最初の返信が正しい問題を解いたため、2回目の確認を必要とするチケットが減ります。

エスカレーション率が下がる。 怒ったチケットの3拍子の構造は、シニアへ回されるチケットを減らすはずです。そうならないなら、たいていSpecialistは「捉え直す」拍を飛ばしています。それがないと、顧客は次のアクションの約束が本物だと信じません。

これが上手くなるSpecialistは、意識してマクロを使うのをやめます。構造が体に染みつきます。謝罪で始めるか決定で始めるかを決める必要がなくなります。「あいにく」と言わなくなります。テンプレートと戦うのをやめます。自分に逆らうのではなく、自分とともに戦うものを築いたからです。

それが目標です。会話に溶け込んで消えるスクリプト。顧客は、その返信がテンプレートだったかどうかなど一切考えません。ただ、自分の書いたものを読み、当事者意識を持ち、いつ終わるかを明確に伝えてくれた人に対応してもらえた、と感じるのです。

役割の残りをまだマッピングしているなら、よくある落とし穴のプレイブックが次に読むべきものです。

壁は星1つのCSATをもたらします。橋は、6か月後にサポートへメールして同じSpecialistを指名してほしいと頼む常連の顧客をもたらします。橋を架けましょう。