これは ビジネスエンジニアリング株式会社（B-EN-G） Advent Calendar 2023 の記事です。
はじめに
リリースされた製品が「愛される製品」に育つかどうかは、カスタマーサポート業務にかかっているのでは、と個人的に考えています。
- カスタマーサポートで顧客満足度が向上する
- 顧客満足度が向上すると使い続けたいと思われる製品「愛される製品」になる
- 「愛される製品」はより多くのご要望やご指摘をいただける
- ご要望やご指摘が製品へフィードバックされると、製品の魅力が向上する
- ...
図にすると次のようなイメージです。
この記事では、このような好循環を促すかもしれない取り組みとして、弊社で利用しているカスタマーサポート業務の「レビュー基準」を紹介します。
カスタマーサポート業務の概要
弊社製品をエンドユーザー様に導入する立場の「ビジネスパートナー（BP）」様がいます。
弊社のカスタマーサポート業務は、主にBP様からの問合せに回答することです。
カスタマーサポート業務は以下のような流れで実施されています。
今回紹介するレビュー基準はレビュー者が利用する目的で作成されていますが、回答者もレビュー依頼前にセルフチェックすべきものですので、その意味で回答者にとっては「心得」とも表現できると思います。
5つのCS指標
弊社ではBP様の満足がエンドユーザー様の満足に繋がると考えています。
BP様の満足度向上のために弊社のカスタマーサポートに対する反応を分析すると、満足度の性質に偏りがありそうでした。
具体的には
- 「回答が迅速である」観点以外の満足コメントが少ない
- 不満コメントの観点は多様にある
という状況でした。
この不満コメントに表れている多様な観点を言語化・指標化したうえで、その指標すべてについてバランスよく満足度の向上を目指すことにしました。
具体的には一般的なカスタマーサポート業務の満足度アンケート項目に共通する部分をまとめ、「満足度」を以下の5つに分類することにしました。
- わかりやすさ：回答文がわかりやすい
- 正確さ：回答内容が正確である
- 不快のなさ：イラッと来るところがなく快い
- 付加価値の高さ：歩み寄ったサービスをしてくれる
- 迅速さ：回答、解決までの時間が短い
これらを5つの「CS（Customer Satisfaction：顧客満足度）指標」と呼称しています。
CS指標をもとにしたレビュー基準
各CS指標を向上させる目的のレビュー基準を設けています。
また、各レビュー基準に「レベル」を設けています。レベルが「必須」「普通」を通常レビューの範囲としており、「発展」ついてはレビュー者の判断に任せることとしています。
「迅速さ」については内容面のレビュー基準はとくに設けていません。
指標１：わかりやすさ
レベル：必須
- 一度読んで理解できる文章か
- 先方の言葉を利用しているか
- 先方への依頼内容は明確か
レベル：普通
- テクニカルライティングの内容に準拠しているか
- 明らかにおかしな言い回しはないか
- 製品ドキュメントの参照箇所を明記しているか
弊社（弊部）で取り組んでいるテクニカルライティング講座の内容
レベル：発展
- 仕様の根拠を説明しているか
- 具体例やモデルを説明しているか
- 次にどうアクションすればいいか示唆しているか
指標２：正確さ
レベル：必須
- 問われていることにすべて回答しているか
- 先方の文章についてこちらが勝手な解釈をしていないか
- 回答者としての立場やTPOから逸脱していないか
- 先方の質問内容は明確になっているか
レベル：普通
- 製品ドキュメントの用語を使用しているか
- 製品動作や製品ドキュメントと整合しているか
- 不具合の場合、あるべき動作を説明しているか
- 過去のやりとりを参考にしているか
レベル：発展
- 関連するドキュメント間の誤謬や不整合を説明しているか
指標３：不快のなさ
レベル：必須
- ビジネス文章としていのマナーがあるか
- イラッとされるような言い回しはないか
レベル：普通
- 文章を省略しすぎていないか
- 常識的な労いや謝辞はあるか
- 相手のミスを責めるような回答になっていないか
- クッション言葉を適切に利用しているか
レベル：発展
- 調査・回答ができない場合、その理由を説明しているか
- あまりにもそっけない回答になっていないか
指標４：付加価値の高さ
レベル：必須
- 不具合の場合、必要なリカバリ手順を説明しているか
レベル：普通
- 自製品に関連しない内容でも、善意の範囲で情報を提供しているか
- 製品やドキュメントの改善要望を積極的に汲み取っているか
- やりとりが長期間にわたりそうな場合、見通しを明示しているか
レベル：発展
- 先方に役立つ情報を善意の範囲で提供しているか
- 可能な範囲で代替案を提示しているか
レビュー基準の補足
指標１：わかりやすさ > 先方への依頼内容は明確か
例：修正済みの不具合の可能性があるので、先方に修正パッチを適用してほしいケース
△回答：修正パッチXXXが適用されているかご確認をお願いします。
この場合「適用されていませんでした」だけ返ってくる可能性が高くなります。
◯回答：修正パッチXXXが適用されているかご確認をお願いします。
適用されていないようでしたら、修正パッチを適用することで
現象が改善されるかご確認をお願いします。
指標２：正確さ > 問われていることにすべて回答しているか
例：「ドキュメントに記載がある場合は、記載箇所を教えてください」という質問がきたケース
△回答：ドキュメントに記載がなかったので、特に何も触れなかった。
※ドキュメントにある場合にのみ触れれば十分と解釈した。
問われていることに触れていない場合、再質問がきて再回答が発生する可能性が高くなります。
◯回答：記載箇所がない場合は「ドキュメントに記載はございません」と回答した。
指標２：正確さ > 先方の文章についてこちらが勝手な解釈をしていないか
質問に不明瞭な点がある場合
不明瞭な点を先方に確認します。
推測や憶測で回答しようとすると、回答作成に時間がかかる上に、先方の意図とあわない回答となり、かえって不満を持たれる結果となる可能性があります。
質問が理解できない場合
※なぜこの質問をするのかわからない、この質問だと回答を書きにくい等
質問の意図、背景、顧客からの要件など、質問の詳細を確認します。
詳細を確認することで、先方が何をやりたいか、何を知りたいかがわかったりします。
実は先方が直接的に知りたいことのほうが回答しやすい内容だったりする可能性があります。
質問が抽象的で回答に困る場合
※様々なケースが考えられ、考えられるケースを全て網羅するのは厳しい等
回答しやすくするために（回答作成の際に考えることを少なくするために）質問内容を具体的にしてもらいます。
例えば、知りたい機能を絞り込んでもらったり、質問の背景や顧客からの要件などを具体的に記載してもらったりします。
指標２：正確さ > 先方の質問内容は明確になっているか
先方で発生している事象の再現をとるために必要な情報がそろっていない場合は、調査をする前に先方に情報提供を依頼します。
- 事象の再現手順
- 画面のスクリーンショット
- 事象の再現性の有無（1回きりか否か）
- 障害発生時のログ
- カスタマイズの有無
- etc...
必要な情報が不足している状態で調査すると、再現確認に時間が掛かる上に、精度も低くなってしまう場合があります。
早期解決（不具合であれば早期発見）のためにも、必要な情報は先方に提供を依頼します。
指標３：不快のなさ > 常識的な労いや謝辞はあるか
- 本来は弊社で発見すべき不具合をご報告いただいている
- イケてない仕様、あるいは改善要望をご連絡いただいている
という感謝の気持ちを忘れないことが重要だと考えています。
「ご報告いただきありがとうございます」等、感謝の言葉を回答に含めるようにします。
指標３：不快のなさ > クッション言葉を適切に利用しているか
質問内容によっては、どうしても先方の意に沿わない回答となってしまう場合があります。
ゼロ回答（標準機能ではできません、対応はいたしません等）となる場合もあります。
また文字でやりとりするため、口頭と比べると表現がきつい印象になりがちです。
クッション言葉を利用することで、少しでも印象がよくなる（あるいは悪くなるのをやわらげられる）可能性があります。
指標４：付加価値の高さ > やりとりが長期間にわたりそうな場合、見通しを明示しているか
回答に時間がかかる場合は、状況をこまめに連絡します。
- 取りかかっているのか、調査に時間がかかっているのか
- 事象は再現しているのか、再現していないのか
- 再現しているが仕様を確認しているのか、不具合で対応方針を確認しているのか
- etc...
おわりに
弊社（弊部）では、多くの製品開発担当者が、新規開発業務や不具合修正業務と並行してカスタマーサポート業務に携わっています。
自分たちが作った製品が売れるにつれて問合せ数も増えていき、限られた時間で今までと同等（あるいはそれ以上）の質の回答を求められるようにもなってきました。
そのような中で整備されたレビュー基準が、少しでも皆様のご参考になれば幸いです。