サポート担当者へのフィードバックとは何か？
サポート担当者へのフィードバックとは、返信がどう受け取られたか、次に何を変えるべきかを担当者に伝えるあらゆるシグナルです。多くのチームはQAスコアカードを思い浮かべますが、それは5つある情報源のひとつにすぎず、たいてい最も届くのが遅いものです。
| 情報源 | 誰が出すか | 届くまでの速さ | 向いていること |
|---|---|---|---|
| 進行中のチケットへのメモ | シニア担当者またはチームリーダー | 数分から数時間 | 送信前後すぐの返信の修正 |
| QAレビュー | QA担当者またはリーダー（スコアカード使用） | 数日から数週間 | チーム全体の一貫性、パターンの把握 |
| 顧客のCSATコメント | 顧客 | 数時間から数日 | 顧客自身の言葉で見るトーンと結果 |
| 指標 | ヘルプデスクのレポート | 週次 | 傾向：平均処理時間、再オープン率、解決 |
| 自己レビューとピアレビュー | 本人または別の担当者 | 予定したとき | 判断力の育成、うまくいった方法の共有 |
私は毎日eeselのサポートキューを担当していますが、返信の書き方を変えたフィードバックは、スコアから得たものではほとんどありませんでした。答えたばかりのチケットに、なぜそう書いたかをまだ覚えているうちに誰かがメモを残してくれたことが、きっかけでした。
これがこのガイド全体の前提です。それぞれの情報源には役割があり、最も遅いものにすべてを任せるとトラブルが始まります。
なぜサポート担当者へのフィードバックの大半は何も変えないのか？
担当者にフィードバックについて尋ねると、何度も同じ4つの不満を聞きます。「上司の言い方がきつすぎた」というものは1つもありません。
届くのが遅い。 チケットの2、3週間後に書かれたQAレビューは、その後に100件もの会話をこなした担当者に、その1件を思い出すよう求めます。そのころには、その癖は何十回も繰り返されています。
対話のないスコアである。 これが最大の問題です。パーセンテージは、何かが悪かったことは伝えても、次のチケットで何をすべきかは決して伝えません。
"I've gotten the same QA scores for weeks now. I haven't reviewed a single call with my boss yet and I've been graded on 8 or 9 calls. She's sent out a copy of the QA agent rubric sheet for two or three of them - the rest, no detail at all. But with no info on account and no call review or coaching on it, I really can't process the percentage score."
サンプルが少なすぎて公平でない。 レビュアーが担当者1人につき月2件しか読まなければ、悪い1件がすべてを決めてしまいます。ある担当者は、犬が吠えたせいで、それ以外は完璧だった通話でゼロ点をつけられました。「Out of hundreds of calls, they got the one where he barked!」別の担当者は、レビュアーが難しいチケットを避け、誰でも満点を取れる短いものを採点するため、まさに間違った担当者が評価されると指摘しました。
スコアカードが測るものが違う。 担当者は、壁の価値観ポスターではなく、配点から何が本当に重視されているかを学びます。
"I did tech support, only 30% of our score was actually fixing the user's problem. 70% was getting the opening/closing right, bullshit empathy statements, positive responses about being able to fix the problem (even when I couldn't because it was a misroute that I'd have to transfer), offering to send the knowledge article you were using, etc.."
指標をフィードバックとして使うと、同じ失敗がより大きな形で起きます。Hacker Newsでは、元コールセンター担当者が、平均通話時間にこだわるあまり、顧客に上司を求めさせて通話を転送できるようわざと怒らせることが「common practice」だったチームについて書いていました。別の人は、通訳の通話が1時間近くかかり、翌日もらったフィードバックは本人によれば「your handle time is too high.」だけだったと述べています。彼は1週間以内に辞めました。
良い知らせは、担当者が代わりに何を求めているかがはっきりしていることです。r/callcentresの常連は、あらゆるフィードバックを3つの問いで確認します。客観的か、公平か、建設的か。レビュアーが「can't give practical advise」なら、無視されます。これは、ほとんどの研修資料よりも管理職にとって良い基準です。
フィードバックのリズム：日次、週次、月次、四半期
遅くて薄いフィードバックの解決策は、QAを増やすことではありません。それぞれのフィードバックを、本当に向いているタイミングに置くことです。5人から50人のチームなら、私は次のリズムを設定します。
日次：進行中のチケットへのメモ
この層が教育の大部分を担いますが、多くのチームは仕組み化していません。シニアまたはリーダーが毎日数件の返信を読み、チケットに短い社内メモを残します。うまくいった点、または変えるべき1点です。新人には一歩手前で、送信前に返信をレビューします。
Hacker Newsのあるサポートリーダーはまさにこれを書いていました。新人はエキスパートに同行し、リーダーが準備できたと判断したら、"reviewed by a senior before sending"されるチケットに回答します。そのスレッドによれば、そうです。顧客の問題がまだ頭に残っているうちに届くので、これは最も安価なフィードバックです。ヘルプデスクごとのメモ専用の席の設定方法は、私のオンボーディングガイドで解説しています。
どのヘルプデスクでも、すでに支払っているツールでできます。Freshdeskのプライベートスレッド、Help Scoutのメモ、Gorgiasの社内メモ、Frontのコメントは、いずれも@メンションした人に通知します（ツールごとの詳細は下の表にあります）。
週次：実際のチケット3件について15分の1on1
担当者のその週から3件を選びます。うまく対応できたもの、うまくいかなかったもの、本人が選ぶものです。一緒に読み、何か言う前に、自分ならどう変えるかを尋ねます。
3件がちょうどよい数です。1件だと、悪い日1日への判決のように感じられ、10件だと説教になります。顧客の言葉はレビュアーの言葉とは響き方が違うので、CSATコメントも持っていきましょう。
"It sounds like your boss is really letting you down. A big part of their job is to help you perform better. When I worked the floor I'd have a weekly meeting with my boss and we'd go over my surveys then."
比率は正直に保ちましょう。Redditの緊急通報センターのQAリードは、"a lot of positive and supportive feedback as well as coaching feedback."を出していると書いていました。1on1が毎回ミスの一覧だと、担当者は自信のないチケットを持ってこなくなります。言い回しについては、スコアカードの項目ごとの前後比較を載せたQAフィードバックの例の記事をご覧ください。
月次：担当者ではなくレビュアーをキャリブレーションする
3人のレビュアーが同じチケットに3通りのスコアをつけると、担当者は気づき、それ以降のスコアはすべて疑われます。ある担当者は、台本を一語一句読んだのに、3人のレビュアーから「3 different scores」を受け取ったと述べています。
キャリブレーションが解決策です。全員が同じ少数のチケットを別々に採点し、集まって正解を合意します。私が見つけた最も具体的な方法は、元品質チームリーダーのものでした。
"Every month we'd pick a random call, all score separately, then get together and decide the correct score for each quality point. Whatever we all decided on, we had to be within 3% of that score (and certain elements had to be 100% on point)."
Zendesk QAには、比較用の基準レビューを備えたキャリブレーションセッションが組み込まれています。知っておくべき注意点が2つあります。キャリブレーションは通知を送らないので、セッションがあることはリーダーがレビュアーに伝える必要があり、担当者にはその内容が一切表示されません。どちらも妥当な設計ですが、セッションは自分でカレンダーに入れておきましょう。
四半期：チケットではなく傾向
四半期の面談は指標の出番で、それも傾向としてだけです。「3月以降、再オープン率が9%から5%に下がりました」は役に立ちます。「14日は処理時間が長かったです」は役に立ちません。どの数字が信頼できるかは、私のパフォーマンスレビューの例とKPIガイドで解説しています。
特定のフィードバックをどこに置くかを選ぶ早見表が欲しければ、私が固定している版がこちらです。
このフィードバックはどこに置くべきか？
状況を選んでください。チャネル、タイミング、使い回せる一言が表示されます。
- 「ひとつだけ。このお客様は年額プランなので、返金期限は14日ではなく30日です。訂正のフォローアップを送ってもらえますか？」
- ヘルプセンターでもポリシーが不明確なら、同じ作業の中で記事も直します。
- まず尋ねます。「この返信を読んで、お客様はどう感じたと思う？」
- そのうえで、メール全体ではなく、書き直した1文だけを見せます。
- ミスを生み続けているマクロ、ヘルプ記事、AIの指示を更新します。
- 「配送のマクロを更新したので、例外を覚えておく必要はもうないよ。」
- 「再オープン率が6週間で5%から9%に上がっています。再オープンされたチケットを3件出して、共通点を見てみましょう。」
- 悪かった1日だけを指標として持ち出してはいけません。
- 「二重請求チケットへのこの返信が、これからのテンプレートです。明確で短く、次の質問を聞かれる前に答えていました。」
- 公開での称賛は、ほかの全員にとっての研修にもなります。
担当者が実際に使えるフィードバックの伝え方
リズムが「いつ」を決めます。次の5つの習慣が、担当者が何を変えるべきかを理解して帰れるかを決めます。
- すべての指摘を実際のチケットに結びつける。 「もっと共感して」では何も伝わりません。「チケット4182で、お客様は二重請求されたと言っていました。最初の一文が返金手順にいきなり入っていました」なら、担当者は思い描いて直せます。
- 1回につき1点。 問題が5つあるなら、顧客にとって最もコストが大きいものを選びます。残りの4つは1週間待てますし、担当者は1つを確実に覚えられます。
- 伝える前に尋ねる。 「ここはどう変える？」半分は、担当者自身が気づきます。自分でたどり着いたフィードバックは、受け取ったものより定着します。
- 顧客にとってなぜ重要かを伝える。 「注文番号を確認して」はルールです。「先週の再オープンのうち2件が、違う注文に返金していたので、注文番号を確認して」は理由です。
- コーチングと採点を分ける。 「だからあなたは72%なんです」で終わる1on1は、以後のすべての会話を防御的にします。スコアはレビューにとっておき、1on1は次のチケットの話にします。
新人とベテランが混在するチームを管理する人には、もうひとつ。新人を2週目から同じスコアカードで評価しないでください。目標80%で10日後に解雇された新人研修生のグループについて、Redditのチームリーダーは簡潔にこう書きました。「10 days is nothing.」実際にチームが経験する期間は、私の立ち上がり期間ガイドにあります。
担当者に反論させる：異議申し立てと自己レビュー
反論する手段のないフィードバックの仕組みは、採点システムです。担当者はその違いを知っており、r/callcentresの異議申し立ての体験談は、何がうまくいかないかの教訓になります。
ある担当者は95.5%のスコアに異議を申し立て、上司も同意しましたが、レビューは約8件の"new errors found"とともに90.25%で戻ってきた、とその担当者は書いています。別の人は、悪いアンケートへの異議は"almost always ignored for months"で、その後却下されるとコメントで述べています。さらに、異議が認められたあとにスコアが何の連絡もなく静かに変わっていたことに気づいた人もいました。「an acknowledgment of it would be nice.」
うまく機能するプロセスがどう聞こえるかと比べてみてください。
"If there's a problem with one of my scores and I feel I have a reason to dispute we have a process, but I've never even had to use it because the scorer just looks at it and either clarifies in a way that makes sense to me or changes it because they agree with me. They are reasonable, and not retaliatory, even the semi cranky ones. That's how adults behave at work."
違いを生むルールは単純です。担当者による書面での理由、決まった対応期限、どちらの結果でも説明のある判断、解決時の通知です。反対側の立場のレビュアーは、私が気に入っているルールをもうひとつ挙げました。QAが間違えたときは、"we own up to it and award the points back and issue an apology"と、あるQAレビュアーは述べています。
Zendesk QAは、そのほとんどを製品に組み込んでいます。担当者はレビューを開き、異議の受け手を選び、カテゴリごとに新しいスコアを提案でき、その理由をコメントに書かなければなりません。受け手は承認、一部承認、却下のいずれかを選び、双方に通知が届き、1件のレビューに対する異議の回数に上限はありません。Zendesk QAの異議申し立てに関するドキュメントによります。
平均解決日数を示す異議申し立てダッシュボードと、どのレビュアーが最も異議を受けているかの表もあり、キャリブレーションが必要なレビュアーをさりげなく見つける方法になります。MaestroQA（現Rippit）はこれをアピールと呼び、チームリーダーが先にアピールを確認するオプションがあります。Scorebuddyは、担当者のダッシュボードから"request a review"のプロセスを提供しています。
自己レビューは過小評価されている半分です。Zendesk QAでは、ワークスペースごとに自己レビューを有効にでき、担当者は自分の会話を同じスコアカードで採点します。月に1回、レビュアーのスコアと並べて実施すると、2つの数字の差は、どちらか単独の数字よりも良い1on1のテーマになることが多いです。
フィードバックはヘルプデスクのどこにあるか
ここからは実践的な話で、ベンダーのドキュメントで最も驚いた点もここにあります。担当者が自分の品質スコアを見られるヘルプデスクばかりではなく、AI採点のアドオンはスコアの使い方について意図的に慎重です。
| ツール | フィードバックを書く場所 | 担当者に通知？ | 異議申し立ての流れ | 自己 / ピアレビュー | AI採点 | 価格 |
|---|---|---|---|---|---|---|
| Zendesk QA | レビューコメント（ハッシュタグ、@メンション）、コーチングセッション、ピン | はい、メールまたはSlack、即時から月次まで | あり：新スコア、必須コメント、承認 / 一部 / 却下 | 両方、さらにキャリブレーション | AutoQA、システムカテゴリ8つ | $35/エージェント/月のアドオン、年払い |
| Front Smart QA | サイドバーのAIスコアカード、コメント付きの管理者による上書き、社内コメント | @メンションはあり、QA専用の通知は記載なし | 記載なし | 記載なし | 標準15基準、カスタム最大10 | $20/席/月、Enterpriseに含まれる |
| Gorgias Auto QA | チケット内のAIスコア、リーダーが編集、社内メモ | メモはあり、担当者はQAスコアを閲覧不可 | なし | 記載なし | 自動3基準、手動4基準 | AI Agentのサブスクリプションが必要 |
| Freshdesk | @メンション付きのプライベートノートとプライベートスレッド | はい、担当者と参加者にメール | QAモジュールは見つからず | 見つからず | 見つからず | スレッドは全プランで利用可 |
| Help Scout | @メンション付きのメモ | はい、Notification Stationと任意のメール | QAモジュールは見つからず | 見つからず | 見つからず | メモは全プランで利用可 |
| MaestroQA / Rippit | ルーブリック評価、タスク付きのコーチングセッション | 公式には未確認 | あり、リーダーの承認が任意のアピール | ピアレビュープログラム | AutoQA | Rippit Free、$185、$495/月 |
| Scorebuddy | 評価者フィードバック付きスコアカード、コーチングセッション | リアルタイムの担当者ダッシュボード | "Request a review" | ピア採点とキャリブレーション | 月500または1,000件のAIスコア | 見積もりのみ |
この表のいくつかの点は、ツールごとにフィードバックの進め方が変わるので、補足しておきます。
Zendesk QAは、担当者がフィードバックを読んだかを追跡します。 ReviewsダッシュボードはUnseen reviews、つまり担当者がまだ開いていない手動レビューの割合を報告し、Coachingダッシュボードは担当者が受け取ったフィードバックを確認したかを追跡します。未読率が高いなら、フィードバックの問題は言い回しではなく、届け方です。担当者のActivityページには、レビュー、コメント、リアクション、CSATフィードバック、異議申し立てが1か所に集まります。
ZendeskはAIスコアと人間のスコアを分けています。 AutoQAの結果は自動品質スコアに反映され、社内品質スコアは手動レビューのみに基づきます。Zendesk自身のアカウント設定のドキュメントも、AutoQAの評価は"are for guidance only and shouldn't be used for performance decisions."と述べています。別のツールを使っていても参考にできる、賢明な線引きです。QAアドオンは、SupportまたはSuiteのどのプランにも加えて、エージェント1人あたり月$35で、Zendeskの料金に基づきます。
Frontは、担当者に自分のAIスコアを根拠付きで見せます。 Smart QAは、会話のサイドバーに基準ごとの説明文付きスコアカードを置き、担当者は自分の結果しか見られません。管理者はスコアを上書きし、コメントを追加し、確認済みにでき、その時点で「Generated by AI」が管理者の名前に置き換わります。また、FrontはSmart QAが会話を採点していることを顧客に伝えるよう求めており、これはどのツールでも私ならやります。料金はStarterとProfessionalで席あたり月$20、Enterpriseは$105に含まれ、Smart QAのヘルプ記事とFrontの料金に基づきます。
Gorgias Auto QAはマネージャー向けのツールで、担当者へのフィードバックではありません。 解決の完全性、コミュニケーション、言語能力を自動で採点しますが、"only the account owner, admins, and leads can view and change QA scores,"とAuto QAのドキュメントにあります。つまりGorgiasでは、担当者に届くフィードバックはすべて、メモ、1on1、または共有するレポートを通ります。誰かが実際に対話するなら、それで問題ありません。
FreshdeskとHelp Scoutは、ドキュメントや料金ページにネイティブのQAスコアカードがありません。 そこでのフィードバックは、担当者に通知されるメモと@メンション、そしてCSATを通ります。Freshdeskのプライベートスレッドなら、特定の返信にコメントして担当者を巻き込めるので、日次の層に向いています。どちらかでスコアカードが欲しければ、専用のQAツールが必要です。
CSATコメントは、主要なヘルプデスクのすべてが担当者に見せている唯一の情報源です。Zendeskでは評価がチケット上部に表示され、コメントはEventsの下にあります。FreshdeskではチケットのActivitiesに表示され、Gorgiasではすべてのロールが、コメントのハイライト付きの満足度レポートを開けます。ランキングではなく、週次の1on1で使いましょう。
一度で直す：フィードバックが実は足りない答えである場合
ここが、フィードバックについての私の考え方を変えた部分です。異なる担当者に同じ指摘を3回目にしているなら、問題はおそらく担当者ではありません。
繰り返される指摘は、たいていナレッジベースの抜け、古くなったマクロ、あるいはあるシニアの頭の中にしかないポリシーです。担当者を1人ずつコーチングするのは遅く、次の新人も同じ穴に落ちます。情報源を一度直せば全員分が直り、5分の修正で済むことも多いです。
私が見たeeselのトライアルで、それがはっきり見えました。担当者がAIの下書きをそのまま送ったのはおよそ12%だけで、よくあるパターンは「glance and rewrite」、つまり長い下書きを1〜3文の返信に直すことでした。内訳は、およそ65%が長さとトーン、およそ20%がAIがつながっていないデータの必要性、事実としてAIが間違っていたのはわずか約5%でした。担当者全員が、すべてのチケットで同じフィードバックを手作業で行っていたのです。解決策は、担当者やAIをチケットごとにコーチングすることではありませんでした。チーム自身の送信済み返信で学習させ、下書きが最初からチームの口調で出てくるようにすることでした。
同じ理屈は人間のチームにも当てはまります。日次のメモから出た指摘の一覧を、継続して持っておきましょう。3回出てきたものは、ヘルプ記事、マクロ、AIの指示など、情報源で直します。そのうえで1on1で伝え、問題は本人ではなく仕組みにあったと担当者に分かってもらいます。この一手は、どんなフィードバックサンドイッチよりも士気に効きます。
AIコパイロットがチームの返信を下書きしているなら、それもこのループに入れるべきです。新人と同じフィードバックが必要で、うれしいことに、一度行った修正はその後のすべての下書きに適用されます。これについては、AIエージェントのコーチングのガイドでさらに書いています。
サポート担当者へのフィードバックが裏目に出る失敗
- すべてを月次レビューまで取っておく。 届くころには、担当者は何週間もその癖を繰り返しています。日次メモなら40件目ではなく2件目で止められます。
- 誰も話題にしないチケットを採点する。 担当者が一度も話し合わないレビューは、評価であってフィードバックではありません。ツールが報告するなら、未読率を確認しましょう。
- スコアカードの配点を台本に偏らせる。 スコアの70%があいさつと締めなら、担当者はあいさつと締めに最適化します。言い回しより初回接触解決と正確さに重みを置きましょう。
- AIスコアを人事評価に使う。 ベンダー自身もやめるよう言っています。AIは人間がレビューする価値のあるチケットを見つけるために使い、そのうえでレビューしましょう。
- 悪かった1日を指標として持ち出す。 通訳の通話1件で、その日の処理時間が台無しになることがあります。3週間以上の傾向を見ましょう。
- 異議申し立ての流れがない、または遅い。 反論できない担当者は、公平なものも含め、すべてのスコアを信用しなくなります。
- 壊れたプロセスのことで人をコーチングする。 3人の担当者が同じミスをするなら、まずマクロか記事を直しましょう。
サポート担当者へのフィードバックにeeselを
チームが同じ種類のチケットで同じフィードバックを受け続けているなら、最も早い解決策は、送信する前に正しい答えを担当者の目の前に出すことです。eeselのAIヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgias、そのほかのスタックに接続し、ヘルプセンター、マクロ、過去のチケットから学び、各返信を担当者が確認して送信する社内メモとして下書きします。新人は一語も書く前に、返金や障害にチームがどう答えるかを目にするので、多くの事後フィードバックが、事前の素早い修正に変わります。
フィードバックの面で私が最も気に入っている点です。リーダーがチャットで答えを修正すると、eeselがその修正を自身の指示に書き込むので、修正は5回の別々の1on1で繰り返されることなく、以後のすべての下書きに反映されます。Freshdeskを使うある創業者は、G2のレビューでこう述べています。
"When we re-test, it correctly incorporates the coaching... specifically on enabling newer team members to have a 24/7 supervisor that coaches them on how to handle inquiries."
役割をはっきりさせておくと、eeselは人間の担当者向けのQAスコアカードや異議申し立てのツールではないので、それにはZendesk QA、Front Smart QA、または専用のQAプラットフォームを使い続けてください。eeselがするのは、そもそも与えるべき是正フィードバックの量を減らすことです。eeselを無料で試し、100クレジットで自分のチケットの下書きを確認できます。