第1話で作った業務地図では、問い合わせが仕事の入口でした。次は、その入口に届く内容を見える化します。ここで整える一覧は、第3話のFAQ、第5話の営業確認表、第10話の改善候補の材料になります。
返信文ではなく問い合わせの事実を集める
メール、フォーム、電話メモから、最近20件程度を匿名化して集めます。氏名や連絡先を消し、問い合わせ日、経路、要点、対応結果だけを残します。一件ごとに完璧な要約を書く必要はありません。
AIには「内容を、価格、内容確認、予約・日程、利用条件、トラブル、その他に仮分類し、迷うものは保留にしてください」と頼みます。分類名は会社の言葉へ直して構いません。重要なのは、AIが決めることではなく、担当者が一覧を見て直せることです。
件数と対応の詰まりを分けて見る
最も多い種類だけが改善対象とは限りません。件数は少なくても、毎回調べ直す問い合わせや、担当者によって答えが違う問い合わせは負担になります。一覧に「すぐ返せた」「確認が必要だった」「失注につながった」を追加すると、次に整えるべきものが分かります。
第3話では、この分類表から繰り返し出る質問を選び、確認済みの回答だけでFAQの土台を作ります。
実践
まず10件を表にし、AIの仮分類を人が見直してください。同じ意味の分類を統合し、保留の理由を残します。完成した一覧は、月ごとに足せる共有ファイルへ保存します。
例：分類名は会社の行動につなげる
「料金について」という分類だけでは、次の対応が決まりません。見積もり前の概算確認、追加費用への不安、支払い方法の確認のように、対応方法が変わる単位へ分けます。飲食店なら「予約変更」「アレルギー確認」「席の希望」、制作会社なら「納期相談」「修正依頼」「見積もり比較」のように、自社の現場で使う言葉に直します。
一件に複数の内容がある場合は、主な用件を一つ決め、補助の用件は別列に残します。分類が曖昧なものを無理に入れると、件数はきれいでも改善に使えない表になります。保留は失敗ではなく、分類の定義を直す材料です。
一覧を運用する小さな決まり
問い合わせを受けた人が、対応後に30秒で追加できる項目数に絞ります。たとえば経路、種類、対応結果、確認が必要だった理由の四つです。月末にAIへ「分類ごとの件数、回答に時間がかかった理由、追加すべき分類候補」を出させ、人が元記録を見て確認します。
電話だけ記録が残らない会社では、通話直後に短い入力欄へ残す担当を決めます。記録の量より、抜けなく同じ場所へ入ることを優先します。
