アンケートの質問例50選:フィードバック収集に使えるサンプル集

質問ではなく、目的から始める

サポートチームでよく見かけるアンケートの失敗は、言葉選びが悪いことではありません。回答からどんな意思決定をするかを決める前に、質問を書き始めてしまうことです。すべてを測ろうとするアンケートは、結局何も測れません。そして、次回のアンケートに必要な顧客の好意まで消費してしまいます。

だから、以下の質問を1つでもコピーする前に、まずこれに答えてください。回答結果を受けて、具体的に何を変えるのか? その行動を言葉にできないなら、その質問は削りましょう。「私たちの対応はどうでしたか?」という質問を投げても、結果を受け取る担当者がいなければ、それは顧客に発生させているただのノイズです。

この考え方は、どの種類のアンケートが必要かも教えてくれます。1回のやり取りを測るのはCSATの仕事です。ブランド全体へのロイヤルティを測るのはNPSです。相手にどれだけ手間をかけさせたかを測るのはCESです。これらは互換性がなく、間違ったものを選ぶと、誰も信用しない数字が出来上がります。3つの主要なサポート指標を比較すると、次のようになります。

回答してもらえるアンケート質問を書くためのルール

言い回しは、使うプラットフォームよりも重要です。洗練されたツールで巧妙な質問をするより、素朴なメールでも明快な質問をするほうが優れています。ほとんどの場合、次の5つのルールでカバーできます。

• 1つの質問につき1つのこと。 「サポートのスピードと対応の丁寧さにどれくらい満足しましたか?」は、実は2つの質問です。無愛想な担当者に速く対応してもらった人は、正直に答えられません。分けましょう。
• 誘導的な形容詞を外す。 「信じられないほど速い私たちのサポートは、どれくらい素晴らしかったですか?」は、読み手に答え方を教えてしまっています。形容詞を取り除けば「私たちのサポートのスピードをどう評価しますか?」になります。
• 尺度のバランスを取る。 ネガティブな選択肢もポジティブな選択肢と同じ数だけ用意し、本当に中立な中間点を設けましょう。「良い、とても良い、最高」のような尺度には、本音が入り込む余地がありません。
• 短く保つ。 質問を追加するたびに、完了率は下がります。チケット対応後のアンケートなら、評価1問と任意コメント1問がちょうどよいバランスです。
• 適切なタイミングで尋ねる。 満足度に関する質問は、解決した直後に尋ねるのと、3日後に尋ねるのとでは、まったく違う印象を与えます。

最初の修正ポイントは、多くの人が見落としがちなので、比較して見ておく価値があります。

目的別アンケート質問サンプル

以下がサンプル集です。合うものを選び、プロダクト名を書き換え、残りは削除してください。以下の各セットは、そのまま送るのではなく、必要なものだけを抜き出して使うことを想定しています。

必要なセットにすぐジャンプするには、こちらをお使いください。

顧客満足度(CSAT)の質問

これらは1回のやり取りに紐づく質問です。最も鉄板のパターンは、評価1つと自由記述欄1つの組み合わせです。

• 本日受けたサポートにどれくらい満足しましたか?(1〜5)
• その評価をつけた主な理由は何ですか?(自由記述)
• 問題は最初の対応で解決しましたか?(はい/いいえ)
• 対応した担当者の知識をどう評価しますか?(1〜5)
• 私たちの対応スピードをどう評価しますか?(1〜5)
• 担当者がもっとうまくできたことはありますか?(自由記述)

Zendesk、Freshdesk、Gorgiasを使っているなら、それぞれにチケットクローズ時に発火させられるネイティブのCSATアンケート機能があるため、別途ツールを用意する必要はほとんどありません。

ネットプロモータースコア(NPS)の質問

NPSは関係性レベルの指標なので、チケットごとではなくスケジュールに沿って送信します。定番は0〜10の単一質問ですが、本当の価値はその後の自由記述の質問に隠れています。

• 友人や同僚に[製品]を勧める可能性はどれくらいありますか?(0〜10)
• その評価をつけた主な理由は何ですか?(自由記述)
• あなたの体験を改善するために私たちができる、たった1つのことは何ですか?(自由記述)
• もし削除されたら一番困る機能はどれですか?(自由記述)
• 顧客になるのをためらわせそうになった点は何ですか?(自由記述)

ゼロから作りたくない場合、Freshdeskをはじめとするヘルプデスクツールには、スケジュール送信できるネイティブのNPSアンケート機能が付属しています。

カスタマーエフォートスコア(CES)の質問

多くのサポートの場面で、CESは満足度よりもロイヤルティを正確に予測します。なぜなら人は問題そのものよりも、それを解決するのに苦労したことのほうを許しにくいからです。

• 本日、問題を解決するのはどれくらい簡単でしたか?(1=非常に難しい、7=非常に簡単)
• [製品]のおかげで、問題に簡単に対処できた。(まったくそう思わない〜非常にそう思う)
• サポートを受けるために、自分自身でどれくらい労力をかけましたか?(1〜5)
• 本来より大変だと感じさせた要因は何ですか?(自由記述)

プロダクト・機能フィードバックの質問

これらは、ランダムにではなく、実際にその機能を使った後に尋ねましょう。

• [機能]はあなたのニーズをどれくらい満たしていますか?(1〜5)
• [機能]を使ったとき、何を達成しようとしていましたか?(自由記述)
• もし[機能]がもう使えなくなったら、どう感じますか?(非常に残念/やや残念/特に残念ではない)
• あってほしいと思う機能を1つ挙げるとしたら?(自由記述)
• 初めて使ったとき、[機能]はどれくらい理解しやすかったですか?(1〜5)

この「もう使えなくなったらどう感じるか」という質問は、ショーン・エリスによるプロダクトマーケットフィットのテストであり、このリストの中でも特に鋭い質問の1つです。

オンボーディング・アクティベーションの質問

新規顧客は「どこが分かりにくいか」を知る最良の情報源です。まだすべてが新鮮な状態だからです。

• [製品]を使い始めるのはどれくらい簡単でしたか?(1〜5)
• あると思っていたのに見つからなかったものはありますか?(自由記述)
• セットアップ中に諦めそうになった要因は何ですか?(自由記述)
• 1〜5の尺度で、今[製品]を使うことにどれくらい自信がありますか?

ウェブサイト・ページ内マイクロアンケート

ページ上にポップアップする1問だけのアンケートは、訪問者にほとんど負担をかけないため、高い回答率が得られます。

• このページはあなたの疑問に答えられましたか?(はい/いいえ)
• 探していたのに見つからなかったものは何ですか?(自由記述)
• 今すぐ登録するのをためらわせている要因は何ですか?(自由記述)

ナレッジベースやヘルプセンターにこうしたアンケートを多く設置しているなら、ギャップを測るだけでなく、実際に問い合わせを減らせるセルフサービスと組み合わせる価値があります。

解約・キャンセルの質問

読むのはつらいですが、最も価値のある回答です。すでに相手の忍耐を使い果たしているので、質問は2〜3個に絞りましょう。

• 本日解約する主な理由は何ですか?(単一選択、「その他」の自由記述欄あり)
• あなたに残ってもらうために、私たちにできたことは何ですか?(自由記述)
• 代わりにどこを利用する予定ですか?(自由記述)
• また利用を検討する可能性はありますか?(はい/いいえ/たぶん)

解約理由は、もっと早い段階で察知できるシグナルでもあります。顧客が解約ボタンを押す前にサポートの会話から解約リスクを見つけられれば、退会アンケートは最初の警告ではなく、最後の砦になります。

残しておく価値のある自由記述の質問

評価質問からは数字が得られ、自由記述の質問からは理由が得られます。安定して良い回答を引き出す質問をいくつか紹介します。

• もし魔法の杖があったら、[製品]について変えたいことは何ですか?
• 購入・更新をためらわせそうになった要因は何ですか?
• 同僚に私たちのことを説明するとき、どう伝えますか?
• 現在の業務フローで最もストレスを感じる部分はどこですか?

気づかないうちにデータを台無しにするミス

優れたアンケートプログラムでも、いくつかの常習犯のせいで使い物にならないデータしか得られていないのを何度も見てきました。送信ボタンを押す前に、このリストにざっと目を通してください。

• 一問二答式の質問。 「私たちのチームは親切で知識豊富でしたか?」という質問には、1つの答えで両方をカバーできません。
• 誘導質問。 「〜はどれくらい素晴らしかったですか」のように答えをこっそり忍び込ませる質問は、スコアを水増しし、問題を隠してしまいます。
• 絶対表現。 「あなたはいつも迅速な対応を受けていますか?」に対して「いつも」や「一度もない」と正直に答えられる人はいません。結局、当てずっぽうで答えることになります。
• 専門用語や社内呼称。 社内で「統合解決ハブ」と呼んでいても、顧客にとっては「あのチャットの機能」です。顧客の言葉を使いましょう。
• 必須項目が多すぎる。 必須の質問1つ1つが、離脱の理由になります。中心となる評価以外はすべて任意にしましょう。
• 対応する計画のないまま尋ねる。 フィードバックを集めておきながら、何もしていないことが目に見えてしまうのが、今後の回答率を下げる一番の近道です。

回答を集めるのは簡単。難しいのは読み解くこと

ほとんどのアンケートガイドが省略している部分がここです。質問を書くのは半日もあれば終わります。しかし、週に何百件も届く自由記述の回答を読み解くのは終わりのない仕事であり、フィードバックプログラムがひそかに機能停止していく場所でもあります。スコアはダッシュボードに記録され、コメントは一度ざっと目を通されるだけで、40人の顧客がそれぞれ違う言葉で語っている本当のシグナル、つまり繰り返し現れるテーマは、決して数えられることがありません。

これが、サポート側で私が重視しているループです。アンケートを送る、回答を集める、テーマを見つける、問題を直す、そしてまた繰り返す。

1段階目と2段階目はすでに解決済みです。AIが真価を発揮するのは3段階目です。すべての自由記述回答を読み込み、テーマごとにまとめて、「請求書が見つからない」が今月60回出てきた一方で「チェックアウトのバグ」は2回しか出てこなかった、といったことを教えてくれます。これが、勘に頼るのと優先順位付けされたバックログを持つことの違いです。フィードバックを大規模に読み解くのは、大規模にサポートチケットを分析するのと同じ筋力であり、優れた顧客フィードバックツールはまさにこの点を中心に作られるようになってきています。

もう1つ、やっておく価値のある工夫があります。アンケートだけがフィードバックの情報源ではありません。すべてのサポートチケット、チャット、メールにはすでに同じシグナルが含まれており、たいていはアンケート回答よりも多くの情報を含んでいます。アンケート結果とチケット履歴全体を合わせて読み込めるツールを使えば、わざわざフォームに記入してくれるごく一部の顧客よりも、はるかに大きなサンプルを得られます。

eeselを試す

フィードバックを集め始めると、ボトルネックは「尋ねること」から「行動すること」に移ります。そこで登場するのがeesel AIです。既存のヘルプデスクに接続し、過去のすべてのチケットとアンケートの自由記述回答を読み込んで、繰り返し出てくるテーマに自動でタグ付けします。コメントを手作業で仕分ける代わりに、実際に何が問題になっているかを優先順位付けした形で把握できます。レポート機能では、手作業で読める程度のわずかなアンケート回答だけでなく、何千もの会話全体のパターンを可視化します。

また、チケットそのものについてもループを閉じるレイヤーになります。担当者向けに返信の下書きを作成し、CSATのコメントで繰り返し指摘されるような定型的な質問を自動で処理できます。実際、Gridwiseというチームは、導入から最初の1か月でeeselにtier-1リクエストの73%を解決させることに成功しました。あるZendesk管理者はこう述べています。「eesel AIは私たちのワークフローを効率化し、生産性を高め、より高いレベルのサービスの一貫性を保証してくれます」(Melissa Ryan, Discuss.io)。何かを決める前に、無料で試して、自社の過去のチケットに実際に当ててみることができます。