メモ
- 脊髄反射で細々と対応していくと結果としてユーザーに不利益な状態に陥りがち
- 問い合わせの数や内容、ユーザーシナリオとの整合性、優先度の整理が重要
- そもそもサポート側で対応しきれない内容なのか？も掘り下げ必須
詳細
「お客さまからこんな問い合わせがあったから改修をお願いします！」サービスを運営しているこういった事例に遭遇することが多々ある。もちろん、ユーザーの声に真摯に対応することは大事なことだし、スピード感をもって改修すれば利便性が上がってサービス価値が向上してくチャンスでもある。
これぞ、カスタマーサクセスだと思われがちだけど、往々にしてよくあるのが問い合わせの内容（お客さまが言うままの内容）をそのまま要件にして改修してリリースしてしまうことだったりする。いわゆる脊髄反射で「お客さまが言ってるんだから！」「サポートからの要望です！」と、慌てて対応してしまうやつ。
具体的には、対象のページに説明文を追加したり注記を追加したりデザインや機能をいじったり…などなど。みんなユーザーが言ってるんだからよかれと思ってやってるんだけど、このやり方だと結果的にはユーザーにとって不利益な状態になってしまうことに気づかないことが多々あります。ほんと要注意。
先日も、A社の案件で同様のことがあって。あるページでサブスクの料金周りでお客さまから問い合わせがあったと。それもややクレームっぽい内容だったと。なのでサブスク案内ページに説明や注記を追加してください。それもプラン選択のボタンと、アクションボタンのところに。といったような依頼でした。
結果から先に言うと、個人的には不本意な対応になってしまった…。なので、自戒としてメモ。
問い合わせ対応のケースでは、何も考えずに脊髄反射で対応してしまうのではなく、一度立ち止まって（いや踏ん張ってでも）以下のことについて検討しなければならない。
- まず問い合わせ数はどれくらいなのか？1件？それとも10件以上？
- その問い合わせ内容はユーザー視点で問題のあるものか？
- 問い合わせの内容はユーザーシナリオを阻害するものか？
- その要件は対象となるページのゴールの障害にならないか？
- 今対応しなければならない優先度のものなのか？
- そもそもカスタマーサポート側で対処しきれない質量のものか？
少なくともこれらについて部署内、チーム内で検討し、対応が必要かどうかの可否を判断したい。そのうえで対応するならデザインおよび開発要件の検討。他案件との優先度の整理。ここまですり合わせたしたうえで改修に進めたいところです。
なぜそこまでするのかといえば、問い合わせをしてくる（クレームならなおさら）ユーザーは自分にとって都合の良いように主張しがちだからです。強い言葉を使ってくることも多い。なのでユーザーを頭から信じ切ってはいけないし、本質を見極めるべく腰を据えてユーザーと向かい合う必要があります。もちろん、こちらが見落としていた観点やバグを教えてくれるケースも多々あるので慎重な対応が求められます。
そして同時に自社のサポートチームの状況も把握しておく必要ありです。サポートチームの人数や体制、運用次第で問い合わせの取扱、エスカレーションが変わってくるので。ともすれば、サポートチームも自分たちの仕事が楽になるように、問い合わせが少しでもあればすぐ対応依頼を投げてくるケースがよくある。これほんとあるある。いや、気持ちはわかるけどそうじゃないぞと。
実際、今回のケースだと急ぎ対応をと依頼してきた割には、問い合わせ数は1件だけ。さらには、対象ページから決済完了までの導線上のページで、問い合わせの内容についての説明や注記はしっかりと案内されている状態だ。こうなると、ユーザーの見落としは明確だし、そもそもたった1件のために実装してまで改修するんですか？って話になる。
さらに言えば、ビジネス的に最重要であるプラン選択やアクションボタン周りに要素を追加しちゃうんですかと。CVRやKPIに影響でる可能性ありますよと。なので、UX/UI観点からも今回は対応不要だと主張しました。そもそもサポートがしっかり説明すれば十分なレベルだったので。必要な情報は提供したうえでしっかり仕事してもらいましょう、と。
まあ結果としては、サポートチームの現状と関係性を考慮して、簡潔な説明を追加することになったわけで…。うーん、間を取ったみたいな着地だけど、正直こういった対応が積み重なるとチリツモで分かりづらく使いづらくなってくんだよなーと。もったいないなー。と残念かつ無念な気持ちに…。
まあ自分の力不足でもあるんだけど。次また同じ事例があればしっかりと踏ん張りたい。
