VOCとは？収集・分析から改善につなげる方法

収集目的と、声を集める対象を決める

何を判断したいかを決めると、必要な経路と見落としやすい声を選び分けられます。

「顧客満足度を上げる」から一歩進め、「予約変更のどこで困るかを調べ、操作・完了表示・案内のどれを直すか決める」と書きます。QualtricsのVOC解説も、複数の経路で声を集め、分析した情報を部門の行動につなぐ考え方を扱っています。

問い合わせは申出のあった案件、調査は回答した人、レビューは投稿者の情報です。経路・期間・対象を残し、異なる経路を足しただけの件数を「顧客全体の不満率」としないでください。質問を作る場合は、顧客満足度調査の設計も参考になります。

この例でそろえる対象と数え方

ここからのサービス、原文、人数、記録、調査結果、改善案はすべて説明用の架空例です。2026年9月1〜28日に予約変更画面を開いた利用者40人へ、10月1〜7日に同じ任意の質問を送り、8人から一人1件の自由記述を得たとします。質問は「直近の予約変更で、困ったことや役立ったことはありましたか。どの場面で、どうしたかを教えてください」です。

分析する単位は「直近の予約変更について回答した人」です。同じ人が補足を送った場合は同じIDへ追記し、人数を増やしません。回答しなかった32人の体験や、画面を開かなかった人の事情は、この8人からは分かりません。

8人の原文を場面と困りごとで分類する

短い要約を付けても原文を残し、どの場面で何が起きたかを同じ基準で読みます。

最初は全回答を読み、今回の判断に関わる「場面」「困りごと・評価」「影響」を付けます。「メール」「画面」といった単語だけで分けると、異なる手段で同じ不安が起きていることを見落とすためです。

「変更結果が不明」は、反映されたか本人が分からなかったという申告に付けます。実際に変更処理が失敗したという分類ではありません。V08は同じ予約一覧を評価しているため、問題のある声だけを残すと見えなくなる手掛かりです。

V04には二つの困りごとがあるので、二分類を付けています。分類の定義と対象IDを残し、別の担当者が原文から同じ判断をできるか確認します。迷う記述は無理に既存分類へ押し込まず、判断理由や未分類の状態を残します。

同じ単位で共通課題と深刻さを読む

分類別の人数に原文の影響を重ね、頻出する課題と少数でも重い問題を分けて捉えます。

分母は自由記述を寄せた8人にそろえます。一人が同じ問題を繰り返し書いても、その分類では一人です。以下は回答した8人の内訳で、40人全体の発生率ではありません。

回答者は8人、回答は8件ですが、分類は延べ4＋1＋2＋1＋1＝9件です。V04を二分類で数えるため、分類ごとの該当人数を8人で割った割合の合計は112.5%になります。声を受けた件数、回答者数、分類別人数を区別して報告します。

この例では結果確認の困りごとが最も多く見えます。一方、V05は一人でも操作を完了できていないため、個別の支援と再現確認を先に進める判断ができます。安全への影響や利用不能の程度は、件数順とは別に確認してください。

原文から分かるのは本人が述べた体験です。「メール未着」は送信障害とは限らず、登録先や受信設定なども確認が必要です。行動ログも補助に使えますが、「一覧を開いた」だけで不安や満足まで確定しません。

根拠を確かめ、改善候補を選ぶ

同じ分類でも原因を確かめ、何を変えると困りごとに届くかを判断します。

架空例の続きとして、担当者が記録と画面を確認したところ、V01〜V04の予約変更は反映済みで、完了画面には「手続きが完了しました」とだけ表示されていたとします。通知の未着理由はまだ未確認です。また、V05の操作は申告された端末で画面停止を再現できたものとします。これらも実在サービスの調査結果ではありません。

この確認を受け、利用不能の調査・修正を優先しながら、複数の声に共通する結果確認の改善案を選びます。全機能を一度に変えず、次のように根拠と判断を対応させます。

選んだ完了画面の案は、「変更後の予約：10月22日18時」「予約一覧で確認する」「当日の持ち物を見る」を表示する設計例です。実際の変更が反映された場合だけ日時を示します。メールを待たずに確認できる経路を用意しつつ、通知の未着調査も続けます。画面を変えるだけで未着の原因が解消したとは扱いません。

要望をすべて仕様にする必要はありません。声の多さ、影響、代替手段、工数を合わせて採用・保留・不採用を決め、別の担当者にも理由が分かるように残します。HubSpotのVOC活用記事も、知見を顧客対応部門に閉じず、製品や営業などの関係部門へ渡す視点を示しています。

個別回答と再発防止を分けて動かす

目の前の顧客を支援する仕事と、同じ問題を減らす仕事は、完了条件を分けます。

V01へ予約の反映を伝えれば、本人の不安は解消するかもしれません。しかし、それだけで次の利用者にも分かる画面へ変わったわけではありません。「個別回答済み」と「共通の改善を確認済み」を別々に追います。

XM Instituteの運用ガイドは、誰に応答するか、担当、対応量、引継ぎなどを設計項目にしています。担当欄を「関係部署」だけで終えず、判断する人、作業する人、顧客へ連絡する人を決めます。

回答期限は対応容量と合わせます。説明用の試算で週20件へ各15分必要なら300分、確保できる240分との差は60分です。担当の追加や分担、回答日程を調整してから約束します。安全に関わる案件や現在利用できない案件は、通常の改善会議を待たせない運用を設けます。

保留・不採用にも理由と対応を残す

未確定の原因や提供予定を約束せず、今できることと次に連絡する時点を伝えます。

V01へ調査中の状況を伝える文面例です。実際に確認した内容と守れる時刻へ置き換えます。

予約変更は反映されていることを確認しました。確認メールが届かなかった理由は現在調べています。次の確認結果は10月9日15時までにお知らせします。調査が続く場合も、その時点の状況をご連絡します。

V07の日曜電話窓口は、用件や必要な体制を確認するまで保留としています。現在は日曜に電話対応せず、フォームを常時受け付け、月曜9時から回答する運用だと仮定すれば、次のように伝えられます。

日曜の電話対応のご要望を受け取りました。現時点では開始をお約束できませんが、日曜に確認したかった内容を差し支えない範囲でお聞かせください。お問い合わせフォームは日曜も受け付け、回答は月曜9時以降となります。

窓口や案内先が実在し、伝えた条件で使えることを確認してください。保留は再検討する条件と日、不採用は理由を記録します。匿名の声は個別返信できないため、公開案内や全体の改善へ反映する方法を検討します。

改善後を確かめ、次の判断を記録する

選んだ変更に合う確認方法を決め、同じ条件で声と行動を見直します。

完了画面の案について、以下のように実施前の計画を残します。操作できたかと、利用者が理解できたかの両方を確認します。

次の調査で「変更結果が不明」という声が減っても、回答した人や利用者数が違えば、画面変更の効果とは断定できません。問い合わせの件数も、利用減や受付の見つけにくさで減ることがあります。対象・分母・観測期間・他の変更を残し、原文と実際の操作を合わせて判断します。

原文から改善判断までを残す記入表

担当や期限は、分析で選んだ仕事を進めるために記入します。原文を多数の表へ複製せず、管理するIDから参照できるようにします。

満足度や継続も追う場合は、改善対象とのつながりを確かめてから追加します。調査対象、尺度、期間、利用状況をそろえ、同じ時期に上がっただけでVOC施策の成果としないようにします。長期の行動を確認する際は、顧客維持率の考え方が補助になります。

まとめ

VOCは、複数の声を同じ基準で読み、確認できた困りごとから改善を選び、変更後を確かめるために使います。

• ✓収集目的と対象を決め、原文を場面・困りごと・影響で分類します。
• ✓回答者数と分類別人数を分け、非回答者や別経路の顧客へ結果を広げすぎません。
• ✓頻度だけでなく深刻さと実行条件を見て、改善候補の選択理由を残します。
• ✓個別回答と再発防止を分け、同じ条件の声・行動で次の判断をします。

まず一つの判断したい体験を選び、期間と対象をそろえた複数の原文を読み比べてください。共通する困りごとと、少数でも先に確認すべき問題を書き出すところから始めます。