問い合わせを半分にしたあと、次に何を設計するか

問い合わせ対応を半分にした。それは大きな一歩です。問い合わせ対応を半分にする方法で触れたように、繰り返しの質問を案内やFAQで受け止める形にすると、対応工数は確かに減ります。

でも、その先で止まっている現場を、tugiloではよく見ます。

「半分にしたのはいいが、同じ質問がまだ来る」「誰が何を更新しているか分からない」「少しずつ問い合わせが増え始めた」。削減はできた。定着と、さらに減らす設計が、できていない——そういう声です。この「半分にしたあと」の壁を、現場で見てきたパターンから整理します。

問い合わせが生まれる構造

問い合わせは、必ずしも「情報が足りない」から生まれるわけではありません。tugiloでは、問い合わせは情報の問題ではなく、構造の問題として見ることが多いです。

情報はある。でもどこにあるか分からない。探すより聞いたほうが早い。そうなると、問い合わせになる——という構造です。

• 情報はある（FAQにもマニュアルにも書いてある）
• どこに何があるかが共有されていない
• 探すより人に聞いたほうが合理的に感じる
• 問い合わせとして発生する

問い合わせが生まれる要因を、次のように整理できます。（1）情報がない。（2）情報はあるが見つからない——どこにあるか、何を探せばよいかが分からない。（3）情報が古い——更新されておらず正しいか分からない。（4）情報が分散している——FAQ・マニュアル・チャット・個人メモに散らばり、入口が決まっていない。tugiloでは、半分にしたあとにも問い合わせが残る現場の多くは（2）（3）（4）——情報の量ではなく構造の問題として扱うことが多い。

「探すより聞く」が合理的になってしまう情報の入口設計ができていないと、問い合わせは減りません。半分にしたあと、同じ質問がまだ来るのは、答えが「書いてある」だけで、探しにいく動線が設計されていないことが多いからです。ナレッジの置き場所を決めたら、次は「その場所にどうたどり着くか」「何を探せばよいか」を設計する。そこが欠けると、問い合わせが発生する構造は残ったままになります。

相談の場でよく出る例です。「FAQに書いたのに、同じ質問が来る」。聞くと、どの質問がどの項目か分からないという。一覧が長い、検索できない、担当者に聞いたほうが早い——そうなると問い合わせは減りません。情報はある。でも入口が設計されていない。この差を埋めることが、半分にしたあとの設計の焦点です。

半分にしたあとに起きがちなこと

問い合わせを減らすとき、多くの場合は FAQ・案内ページ・テンプレ返信 を整えます。そこまではうまくいっても、相談に来る会社では、次のような状態になっていることが多いです。

• FAQや案内の更新が誰の仕事か決まっておらず、古い情報のままになる
• 「この質問はどこに書いてあるか」が現場で共有されておらず、また問い合わせで答えてしまう
• 減らした結果、どこに何があるか分からなくなり、結局「人に聞く」が増える

いずれも、情報の置き場所はあるが、更新ルールや情報の入口が設計されていないために起きています。つまり、削減の「仕組み」は作ったが、「運用と更新の設計」が追いついていない状態です。問い合わせの中身を分解すると、「答えの置き場所」はできているのに、「誰がいつ更新するか」「どこに何があるか」が現場に共有されていない——そういうケースがほとんどです。探すより聞くが合理的になる構造を変えないと、問い合わせはまた増えていきます。

次に設計するべきは「更新の担当と頻度」

削減を定着させるには、「誰がいつ、何を更新するか」を決めます。更新ルールがないと、誰も更新しないか、誰かが抱え込むかになり、古い情報が残ります。

• FAQ・案内の更新担当を一人ないしチームで決める（兼務でも可）
• 更新のトリガーを決める：問い合わせが来たとき、一定期間ごと、など
• 「この質問はもうFAQにある」と現場が分かるように、一覧や検索の入口を整える

「全部自分で分かっている」の次にやること。属人化解除のステップでも触れたように、「誰が困るか」と「どこから書き出すか」が決まると、情報のたまりどころがはっきりします。tugiloでは、問い合わせ削減の次の一手をナレッジの「置き場所」と「更新ルール」の設計と整理しています。誰がいつ更新するか、が決まらないままFAQを増やしても、古い情報が残り、結局「人に聞く」が戻ってきます。

ナレッジの構造設計

FAQ、マニュアル、チャットの履歴、個人のメモ——情報が分散していると、問い合わせは減りません。「どこに書いてあったか」が人によって違う。探すより聞いたほうが早い、がまた合理的になってしまう。

tugiloでは、こう整理しています。重要なのは「情報を書くこと」ではなく、「情報が集まる場所を設計すること」。書くことだけ増やしても、置き場所がバラバラだと、入口が分からず問い合わせがなくならない。情報の入口設計——「この種の質問はここを見る」「更新はここに集約する」——を決め、ナレッジの置き場所を一つにまとめるか、少なくとも「何を探すときはどこを見るか」を共有する。更新ルール（誰がいつ更新するか、何をトリガーに更新するか）とあわせて、情報が集まる構造を設計すると、問い合わせ削減は定着しやすくなります。現場では「とにかく書こう」となりがちですが、まずどこに集めるかを決める。そのうえで更新ルールを決める。この順で設計すると、運用が続きやすくなります。

「さらに減らす」ために見るポイント

半分にしたあと、さらに減らすには まだ問い合わせになっているものの傾向 を見ます。

• 同じような内容が繰り返し来ていないか：来ていれば、案内の見つけやすさや文言を見直す
• 「人に聞いたほうが早い」と思わせている要因はないか：探しにくい・分かりにくいを潰す。入口が分からない、検索しづらい、文言が難しすぎる、など
• 問い合わせ内容を軽く記録し、月単位で「何が多かったか」を振り返る

問い合わせ削減は一度で終わりにはしません。運用しながら「まだ来る問い合わせ」を減らすループを回す設計にすると、長く効く——私たちが現場で提案しているのは、その考え方です。

問い合わせは情報不足ではなく、情報が見つからない構造で生まれる。その構造——ナレッジの置き場所、更新ルール、情報の入口設計——を設計し直すことが、半分にしたあとの次の一手になります。まずは「どこに集めるか」「誰がいつ更新するか」「どう探すか」の三つから、一つずつ決めていくと、現場でも進めやすいです。

問い合わせ削減は情報を増やすことではなく構造を設計することである——tugiloでは、そう整理しています。書くことやFAQを増やしても、置き場所・更新ルール・入口が設計されていなければ減らない。どこに集めるか・誰がいつ更新するか・どう探すかを決めると、定着しやすくなる。次の一手は、情報ではなく構造の設計にある。

置き場所・更新ルール・情報の入口。三つを一つずつ決めていけば定着し、さらに減らすループに乗せていける。まずは「一つの置き場所」か「一つの更新担当」から、設計を見直してみてほしい。