「カスタマーサービスのフィードバック」には2つの異なる意味があり、ほとんどの記事はそのどちらか一方しか扱っていない。一つは担当者に与えるフィードバック(好意的および建設的なコーチング)、もう一つは顧客があなたに与えるフィードバック(レビュー、アンケートスコア、返信)だ。この投稿では、その両方についてそのまま使える例と、返信のためのテンプレートを紹介する。
そのすべてを貫くたった一つのルールがある。具体的なフィードバックは行動を変え、曖昧なフィードバックは無視される。「今日はよくやった」は担当者に何一つ繰り返せる情報を与えない。「ポリシーを引用するのではなく遅延を認めることで、怒っている解約チケットを鎮めたね」はそれを与える。毎回、状況・行動・影響を明示しよう。
私はeeselのサポートキューを担当しているので、以下の例は実際に自分が使っているものばかりだ。対応が追いつかないほどフィードバックに埋もれているなら、最後のセクションで、あらゆるチケットの感情とテーマを自動でタグ付けする方法や、サポートコパイロットがフィードバックの元になった正確なチケットをどう呼び出せるかを解説している。まだそこまで進んでおらず、ツール選びをしている段階なら、私がまとめた最良のカスタマーサービスAIのリストの方が良い出発点になるはずだ。
カスタマーサービスのフィードバックには2種類ある
例を見る前に、自分が書いているのがどちらなのかをはっきりさせておく価値がある。この2つの方向性には、「フィードバック」という言葉以外、共通点がほとんどないからだ。
- 担当者へのフィードバックは社内向けだ。チームリーダーやQA担当者、同僚が、担当者に何がうまくいって何を変えるべきかを伝える。対象は一人の人間で、目的は行動の変化であり、そこで通貨となるのは信頼だ。
- 顧客からのフィードバックは社外向けだ。レビュー、CSATスコア、NPSコメント、チケットへの返信、あるいはライブチャットやチャットボットを通じて届く。対象はあなた自身で、目的はパターンを見つけて修正することであり、そこで通貨となるのは正直さだ。
どちらも、具体的であり、その結果何かが実際に起こったときにのみ役立つ。返信しない星5つのレビューも、誰も行動に移さないコーチングメモも、無駄になったシグナルという点では同じだ。これをきちんとやることは、優れたカスタマーサービスマネジメントの中心にあり、それは一度きりのことではなく習慣だ。
定着するフィードバックと無視されるフィードバックを分けるもの
両方向において私が最もよく目にする間違いは、行動に移すには曖昧すぎるフィードバックだ。「もっと共感的に」も「素晴らしい対応でした!」も、形式上はフィードバックだが、どちらも役に立たない。受け取った側は、何を変えればいいのか、何を続ければいいのか分からない。
その解決策は、サポートチームがコーチングから借りてきた構造、**状況・行動・影響(Situation, Behavior, Impact)**だ。具体的な瞬間を挙げ、観察した実際の行動を描写し、それがもたらした効果を明示する。これによって、ふわっとした印象が、読み手が思い描いて繰り返せる具体的なものに変わる。
同じ称賛の言葉にこれを適用するとどうなるか見てみよう。「よくやってるね」には何の情報もない。これをSBIに通すと、こうなる。「火曜日の請求エスカレーション*(状況)で、返金手順を分かりやすい言葉で書き直し(行動)、顧客は『ありがとう、よく分かりました』と返信して一度のやり取りでチケットをクローズした(影響)*。」これで担当者は、次に何をすればいいか正確に分かる。
同じ規律はネガティブなフィードバックにも当てはまり、むしろそこでこそ重要になる。曖昧な批判は個人攻撃として受け取られるが、具体的な批判は助けとして受け取られるからだ。これが、カスタマーサービスマインドセットを育てるフィードバックと、人を防御的にさせるだけのフィードバックの違いだ。
カスタマーサービス担当者向けの好意的なフィードバック例
好意的なフィードバックは形式的なものではない。それは担当者に、自分のどの直感を信じればいいかを教えてくれるものであり、サポートマネージャーが持つ最も安上がりな定着施策で、どんなコスト削減プログラムよりも安く済む。相手がそのまま引用し返せるくらい具体的にしておこう。以下は、そのまま応用できる例だ。
- 「今朝の配送遅延チケットで、顧客に聞かれる前に追跡リンクを自主的に提示してくれたね。おかげでクレームが感謝の言葉に変わったよ。」
- 「顧客がすでに2回メールしていたことに気づいて、繰り返し説明させるのではなく、待たせたことへの謝罪から始めてくれたね。再連絡に対してまさに求めている対応だよ。」
- 「APIキーのチケットへの返信は3文で、それで完全に解決していたね。過剰に説明したくなる気持ちを抑えたことで、やり取りの往復がゼロになったよ。」
- 「チケットをただクローズするのではなく、請求のバグをエンジニアリングチームに報告してくれたね。今週は他に5人の顧客が同じ問題に当たっていたから、大量のチケットを未然に防げたよ。」
- 「顧客が興奮していたにもかかわらず、返金依頼を温かいトーンで対応してくれたね。冷たく聞こえることなく、ポリシーはしっかり守っていたよ。」
- 「聞かれてもいないのに顧客の名前を使い、以前の注文にも触れていたね。台本通りではなく、本当にパーソナルな対応に感じられたよ。」
どの例も、実際のチケットと実際の行動を具体的に挙げていることに気づくはずだ。これこそが、称賛を消えてなくならせずにきちんと届かせる要因であり、「チーム、みんなよくやってる!」のような一般的なメッセージが何も動かさない理由でもある。評価を数字と結びつけたいなら、カスタマーサービスKPIに紐づけて、その行動が初回問い合わせ解決率やCSATにどうつながったかを担当者に見せるといい。
カスタマーサービス担当者向けの建設的なフィードバック例
建設的なフィードバックこそ、構造がその価値を発揮する場面だ。目的はプライドを傷つけずに行動を変えることなので、その人にレッテルを貼るのではなく、何が起きたかを描写し、次に試す一つのことについて合意する。以下の例はその形を示している。
- 「解約チケットで、フラストレーションを認める前にいきなりポリシーのリンクに飛んでしまったね。次回は、相手がなぜイライラしているか理解していることを示す一文から始めて、それからポリシーの話をしよう。一緒にどう読めるか見てみる?」
- 「答えは正しかったけど4段落もあって、顧客は『つまりイエスってこと?』と返信してきたね。答えを最初の一文に置いて、詳細をその下に書く練習をしてみよう。」
- 「チケットを解決済みとしてクローズしたけど、顧客の2つ目の質問には答えられていなかったね。クローズする前に『聞かれたことすべてに答えたか』をさっと確認していれば気づけたはずだよ。」
- 「料金について反論されたとき、少し防御的なトーンになっていたね。方針を守るのは問題ないけど、説明の前に『これはもどかしいことだと理解しています』と一言添えると、温かみが保てるよ。」
- 「これを私にエスカレーションしてくれたけど、実は返品ドキュメントに書いてあったんだ。まずどこを見ればいいか分かるようにしておけば、こういうものはもっと自分で対応できるようになるよ。」
これらがうまく機能するのには2つの理由がある。まず、一般的な性格特性ではなく特定のチケットについて述べているので、人格を判定されているとは誰も感じない。次に、それぞれが具体的な次のステップか、一緒に見てみようという誘いで終わっている。これは判決ではなくコーチングだ。これを繰り返せる習慣として組み込むことは、優れたチームが同じ問題を何度も火消しするのではなくカスタマーサービスの問題解決を行う上で大きな部分を占めている。
自分たちのキューで学んだことの一つがある。話しながら実際のチケットを表示できると、建設的なフィードバックははるかにうまく伝わる。記憶を頼りにしたフィードバックは、「なんとなく最近君は…」という曖昧なものになりがちだ。実際の会話と提案された返信を並べて表示してくれるサポートコパイロットがあれば、コーチングを実際に起きたことに基づいたものにできる。
今直面している状況に合った例をすばやく選ぶ方法を紹介しよう。
顧客からのフィードバック例と、それぞれへの返信方法
次はもう一方の方向、つまり顧客があなたに与えるフィードバックについてだ。どの返信も公開される可能性がある(たとえ非公開の返信であっても、関係のトーンを決めるものだ)ので、テンプレートは重要になる。ここではよくあるタイプと、応用できる返信例を紹介する。
好意的なレビューやコメント。 顧客がこう書いたとする。「セットアップの間、特に統合機能の設定において、サポートチームは素晴らしかったです。」ただ「ありがとう」と言うだけではいけない。具体的なことを挙げ、その称賛を然るべき人に届けよう。
"Thank you, this means a lot. I've shared it with the team who worked on your integration setup. If you hit anything else as you roll out, you know where to find us."
否定的なレビュー。 顧客がこう書いたとする。「返信を3日待たされた上に、定型文の回答が返ってきた。」ここで防御的な返信をすると、元のレビューよりもさらにダメージが大きくなる。責任を認め、具体的に、変化を約束しよう。
"You're right, three days is too long and a canned reply made it worse. We've since changed how we route setup questions so they don't sit in the queue. I'd like to make your specific issue right, can I follow up directly?"
CSATの生の声(低スコア)。 「実際には問題を解決してくれなかった」というコメント付きの星1つのCSAT。これはクローズされたアンケートではなく、再オープンされたチケットとして扱おう。
"I saw your rating and you're right that we marked this solved before it was. I've reopened it and I'm on it personally now."
NPSの批判者。 顧客が3点をつけ、「動作はするけれど、本来あるべきよりも使いにくい」と書いたとする。これはサポートへのフィードバックではなくプロダクトへのフィードバックであり、取るべき対応は、それを認めて社内に共有し、何かがリリースされた段階でループを閉じることだ。
この4つすべてに共通するパターンは、具体的な事柄を認め、言い訳を避け、何を変えるかを述べ、フォローアップすることだ。人間が返信するかAIが返信するかにかかわらず、その形は変わらない。実際にあったひどいカスタマーサービスの話をいくつか読んでみると、防御的な返信が外からどう見えるかをすぐに学べる。そして、フィードバックが絶賛であれ痛烈であれ、その返信はカスタマーサービスの基準を強化し、一度きりの返信を繰り返す価値のあるエンゲージメントの例に変えるチャンスだ。
アンケートフィードバックの例:CSAT、NPS、CES
顧客からのフィードバックの多くはアンケートによって引き出されるが、主要な3つのタイプは、それぞれ異なる質問をするため、まったく異なる例を生み出す。どれがどれかを理解しておけば、些細な不満を満足度の危機であるかのように扱ってしまうことを防げる。
| フィードバックの種類 | 測定するもの | 質問例 | 実際に見られる回答例 |
|---|---|---|---|
| CSAT | 1回のやり取りに対する満足度 | 「今回のやり取りにどのくらい満足しましたか?」 | 「迅速で親切、1回の返信で解決した。」/「丁寧だったが解決しなかった。」 |
| NPS | 全体的な推奨意向 | 「私たちを勧める可能性はどのくらいですか、0~10で。」 | 「9、サポートがあるから使い続けている。」/「4、プロダクト自体は問題ないが、人間の担当者になかなかつながらない。」 |
| CES | 顧客が費やした労力 | 「問題を解決するのはどのくらい簡単でしたか?」 | 「とても簡単、1通のメッセージで済んだ。」/「大変だった、3回説明しないといけなかった。」 |
最後の列にある例は金脈だ。なぜなら、本当のシグナルは数字ではなく自由記述コメントに宿っているからだ。「丁寧だったが解決しなかった」というコメント付きのCSAT3/5は、トーンは問題ないが解決プロセスが壊れていることを教えてくれる。これは「時間がかかりすぎた」という3/5とは違う修正が必要になる。これらすべてをどう追跡するか組み立てているなら、AIカスタマーサービス指標のガイドで、どの意思決定にどのスコアを頼るべきか、そしてそれがサポートROIの測定にどうつながるかを詳しく説明している。
フィードバックを大規模に行動へとつなげる
フィードバック例を集めるのは簡単な部分だ。難しいのは、忙しいチームは誰も読み切れないほどのフィードバックを受け取るため、そのほとんどが実際の変化につながらないことだ。担当者一人でも週に20件のCSATコメントを受け取ることがあり、15人のチームなら数百件に加えてレビューやNPSのテキストも生まれる。1件ずつ読んでいては規模に対応できず、パターンは山の中に埋もれてしまう。
実際に機能するループはこうだ。あらゆるチャネルからフィードバックを集め、感情とテーマで分類し、そのパターンに対して行動し(担当者をコーチングする、ドキュメントを修正する、プロダクトの問題を報告する)、そして何が変わったかを顧客に伝えることでループを閉じる。チームが省略しがちなステップは分類で、手作業でやるのはあまりにも過酷だからだ。ここでこそAIが真価を発揮する。あらゆるチケットやアンケートコメントに感情とトピックのタグを自動で付けられるので、フィードバックを読む代わりに、実際に何がその原因になっているかをランキング化したリストを読むことになる。AIサポートタグ付けを支え、チケットをルーティングするのと同じチケットタグ付けの手法は、フィードバックの分類にも使え、デフレクションの測定で追跡すべき数値にもつながる。
見落とされがちな、このループのもう半分がある。フィードバックは自動化にも学習させるべきだということだ。顧客が定型文の回答が間違っていたと言うとき、それは担当者だけでなく、AIサポートワークフローやナレッジベースにも修正が必要だというシグナルだ。これはカスタマーサービスにおけるAIの、あまり目立たない恩恵の一つだ。かつてはマネージャーにしか届かなかったフィードバックが、今では次のチケットに答えるカスタマーサービスGPTを改善してくれる。私がこの仕組みで気に入っている点の一つは、AIがまるでチームメイトをコーチングするように、平易な言葉でコーチングできることだ。あるお客様が公開レビューでこう的確に表現してくれた。
"Finally, a coachable AI agent for supporting customer experience accessible to small businesses. It reads and memorizes our procedures, products, and policies, and when we re-test, it correctly incorporates the coaching. We're looking forward to a 24/7 supervisor that coaches newer team members on how to handle inquiries."
a small-business support founder, reviewing eesel on G2
これこそがフィードバックの本質だ。何かを変えるべきだというシグナルなのだ。変わるのが担当者であれ、ドキュメントであれ、AIであれ、上記の例はそのループを閉じてこそ、書く価値がある。
実際に行動につなげられるフィードバックのために、eeselを試してみよう
ボトルネックがフィードバックの収集ではなく、その山をどう処理するかにあるなら、それはまさにeeselが解決するために作られた問題だ。eeselは既存のヘルプデスク(Zendesk、Freshdesk、Gorgias、Help Scoutなど)と連携し、あらゆるチケットやアンケートコメントに感情とテーマのタグを自動で付け、担当者がレビューするだけの返信案を作成する。これにより、誰も千件ものコメントを手作業で読むことなくフィードバックループが閉じる。
この投稿に最もふさわしい部分がこれだ。eeselは平易な言葉でコーチングを受け付ける。フィードバックによってAIが何かを間違った形で答えたことが分かったら、一文で修正し、実際の過去のチケットに対して再テストすれば、それが定着する。人間の担当者に対して行うのと同じコーチングループだ。無料で試せるので、実際の顧客に触れる前に、過去のチケットに当てはめてどう対応していたかを確認できる。