顧客ごとに要望が違うときは、どう考える？
目次
「通知を増やしてほしい」という顧客と、「通知が多すぎる」という顧客がいる。両方の要望を聞くと、どちらに合わせればよいか迷います。こうした場面では、先に多数決や優先順位を決めるより、誰が、いつ、何のために使っているかを並べてみます。
同じ機能への反対の要望でも、利用する場面が違えば両立できるかもしれません。この記事では、顧客ごとの違いを整理し、共通で解決すること、分けて考えること、まだ判断できないことを見つける手順を紹介します。
- 反対に見える要望は、利用者・場面・目的を並べて確かめる
- 共通の困りごとと、両立しない利用条件を分ける
- 設定追加を急がず、選択肢と残る負担を比較する
要望の言葉だけで、対立していると決めない
「もっと詳しく表示してほしい」と「画面をすっきりさせてほしい」は、同じ画面についての要望です。しかし、前者が月末に全体を確認する管理者で、後者が毎朝自分の担当分だけを見る現場担当者なら、見たい情報や作業が異なります。
まず、要望の原文を残したまま、その人が達成したいことを書き添えます。「表示項目を増やす」という案から、「担当者別の遅れを見つけたい」という目的へ戻すと、別の解決方法も検討できます。
英国政府のユーザーニーズに関するガイドも、想定した解決策ではなく、利用者の問題に焦点を当て、調査の根拠に基づいてニーズを書くよう説明しています。要望を言い換えた部分が担当者の推測なら、確認済みの事実とは分けてください。
要望を出した人と実際に使う人が違う場合もあります。営業担当が聞いた「全員が困っている」を、そのまま全利用者の意見に広げず、誰のどの作業を指しているか確かめます。
同じ項目で、双方の利用場面を書く
情報をそろえるために、次の五つを一組で記録します。顧客の業種や会社規模だけで分類せず、違いが生じる条件まで書くのがポイントです。
- 使う人：購入担当者、管理者、日々操作する担当者のうち誰か。
- 使う場面：いつ、どこで、どの作業の途中に使うか。
- 達成したいこと：操作が終わったあと、何ができればよいか。
- 今の支障：何が起き、本人や周囲の作業にどう影響するか。
- 外せない条件：権限、担当範囲、期限など、変更しにくい条件は何か。
同じ顧客の中でも、役割や時期によって答えは変わります。「大企業は詳細表示、小規模企業は簡単表示」といった分類を先に決めると、同じ企業の中にある違いを見落とします。分類は説明しやすさのために使い、本人の事情に代わる根拠にはしません。
聞き直すときは「通知を増やすべきですか」より、「最後に通知が足りず困ったのは、どんなときでしたか」と具体的な出来事を尋ねます。質問の進め方はユーザーインタビューで背景を確かめる方法を参照できます。
架空の通知要望で、違いを整理する
ここからは、架空の申請管理サービスの例です。登場する顧客、発言、検討案は説明用で、アーコレ！の機能や実際の顧客事例ではありません。
顧客Aの承認担当者は、「通知をもっと送ってほしい」と要望しています。普段はサービスを開かず、自分の承認が必要になったときだけ使います。通知を見逃すと、申請者の作業が止まることを心配しています。
顧客Bの受付担当者は、「通知を減らしてほしい」と話しています。勤務中は申請一覧を開き、届いたものを順番に処理しています。自分に関係のない更新まで通知されるため、対応が必要な知らせを探しにくくなっています。
二つの要望には、「自分が対応すべきことを見逃したくない」という共通の目的があります。違うのは、一覧を開いているか、通知を入口にするか、どの更新が本人の作業につながるかです。
この時点で「通知の回数を中間にする」と決めても、両者の困りごとを解消できるとは限りません。比較する単位を、通知全体の多い・少ないから、「誰のどの対応を知らせるか」へ変えます。
共通対応、条件別の対応、対象外を比べる
違いが分かったら、次の順で選択肢を出します。これは本記事で提案する整理順であり、必ず設定機能を増やすための手順ではありません。
まず、共通で直せる部分を探す
架空例なら、関係のない更新と対応が必要な通知を区別する案があります。双方が何を必要とするかを確認し、不要な通知を減らしても重要な知らせが届くかを検討します。
ただし、「自分に関係がある」の定義は未確認です。代理承認や担当者の不在があるなら、本人に直接割り当てられた申請だけでは足りないかもしれません。共通化できそうな部分にも、例外条件を残します。
共通化が難しい部分は、条件を分ける
役割によって必要な通知が明確に違うなら、役割別に扱う案が考えられます。個人設定を用意する案もありますが、利用者が設定項目を理解し、管理者が運用を支えられるかまで確認します。
設定を増やせば、初期値、変更できる人、設定を引き継ぐ場面なども決める必要があります。「選べるから解決」とせず、設定しない人にも適切な動作になるかを検討してください。実装や問い合わせ対応の負担も開発・サポート担当と確認します。
自社の対象範囲に合わない条件も残す
特定の業務だけで必要な対応が、自社の目指す利用場面から外れる場合は、今は扱わない判断もあります。その際は「少数だから」だけで片づけず、対象とする利用者、代わりの手順、今後見直す条件を記録します。
契約や個別の約束が関係する場合は、製品方針だけで決めず、社内の担当者に確認します。困っている人の存在を認めることと、その解決を製品の標準機能として引き受けることは、分けて検討できます。
判断前に、足りない情報を一つずつ埋める
整理した記録に未確認の項目が残ったら、すぐに多数の顧客へ同じアンケートを送る必要はありません。「一覧を開いていない人は、何を合図に作業を始めるか」など、選択肢の判断を変える問いから確かめます。
次の確認用メモを作ると、会議を同じ意見の繰り返しにしにくくなります。
- 確認できた共通点：双方が、自分に必要な対応を見逃したくない。
- 違いが出る条件：一覧を常時開くか、通知から作業を始めるか。
- まだ不明な点：代理担当者への知らせが、どの場面で必要か。
- 次の確認：双方の実際の担当範囲と、直近の見逃し場面を聞く。
顧客名や連絡先などは、確認に必要な範囲で扱います。社内共有用のメモには役割や利用条件を中心に記し、原文の参照先は閲覧権限に注意してください。
両立できる案が見つかったら、そこで初めて他の改善候補との開発優先順位を比較する段階へ進みます。最終判断する人が曖昧なら、受付・判断・回答の役割分担も先に確認しておきます。
よくある質問
要望が多い側に合わせればよいですか？
件数は判断材料になりますが、同じ利用条件の人が繰り返し発言している可能性もあります。何社・何人のどの場面の声かを確かめ、少数側で業務が成立しなくなる条件がないかも見ます。
どちらも満たせない場合はどうしますか？
両立しない条件と、それぞれで残る負担を明示します。製品が対象にする利用場面や約束を確認したうえで判断し、対応しない側にも理由と可能な代替手順を説明できるようにします。
まとめ
顧客ごとに要望が違うときは、原文と一緒に利用者・場面・目的を並べます。共通で直せる部分、条件別に扱う部分、対象外とする部分を整理してから、優先順位を検討してください。
数件なら管理表でも始められます。ただ、同じ機能への声がメールや会議メモに散らばると、反対意見の背景を探し直す手間が増えます。アーコレ！では、集めた要望を整理する仕組みを紹介しています。異なる声を検討の材料としてまとめておきたい方は、サービス紹介をご覧ください。
