Webフォーム、電話、SNS、紹介など受付経路が増えると、問い合わせ情報が担当者のメールやメモに分かれます。問題はツールの数ではありません。「誰が対応中か」「次に何をするか」「いつまでに動くか」を同じ基準で確認できず、対応品質が個人の記憶や経験に依存することです。
問い合わせ管理を整えるときは、新しいCRMやAIを先に選ぶのではなく、受付から商談・見積後フォローまでの流れと完了条件を決めることから始めます。
結論：問い合わせ管理は「一つの台帳」と「次回行動日」から整える
最初に行うのは、複数の受付経路から入った案件を一つの案件台帳で確認できる状態にすることです。そのうえで、各案件に担当者・案件状態・次回行動日を設定します。
自動化するなら、受信確認、案件台帳への反映、未対応通知、定型フォロー、KPI集計などから始めます。ただし、すべてを一度に変えず、取りこぼしが起きやすい対象フロー1本に絞ります。
これは単なる営業ツール導入ではなく、問い合わせ対応を「担当者が覚えている仕事」から「組織で確認・改善できる仕組み」へ変える取り組みです。
最初に可視化する業務
現在の問い合わせを一件ずつ追い、受付から受注・失注までに使っている情報を洗い出します。最低限、次の項目を同じ場所で確認できるようにします。
| 管理項目 | 確認する内容 |
|---|---|
| 受付日時 | 問い合わせを受け付けた日時 |
| 流入元 | Webフォーム、電話、SNS、紹介など実際の受付経路 |
| 顧客情報 | 対応に必要な氏名・連絡先等 |
| 相談内容 | 何について相談しているか |
| 希望時期 | 顧客が伝えた検討・導入時期 |
| 担当者 | 現在の対応責任者 |
| 案件状態 | 受付、ヒアリング、提案中、見積提出済みなど現在地 |
| 次回行動日 | 次に連絡・確認する予定日 |
| 最終接触日 | 最後に顧客と連絡した日 |
| 失注理由 | 失注が確定した場合に確認できた理由 |
案件状態の名称は実際の営業工程に合わせます。重要なのは名称の細かさではなく、担当者が変わっても同じ意味で使えることです。「対応中」のように次の行動が分からない状態は避け、次回行動日とセットで管理します。
問い合わせ前の導線そのものに課題がある場合は、営業し続けなくても売れる仕組みもあわせて確認してください。
実装手順
1. 対象フローと開始・終了地点を決める
「新規問い合わせを受け付けてから、初回提案後のフォローを完了するまで」のように一本で定義します。開始地点と終了地点が曖昧だと、どの案件を管理・集計するかが担当者ごとに変わります。
2. 受信確認と担当者の初回対応を分ける
自動返信は「問い合わせを受け付けた事実」を伝える工程です。担当者が内容を確認して返信・連絡する工程とは分けます。自動返信が送られただけで対応完了にしないルールが必要です。
3. 初回対応前に必要な情報を決める
相談内容、希望時期、予算感、連絡しやすい方法など、初回対応に必要な情報を整理します。必要項目は事業によって異なります。不要な個人情報まで集めず、取得目的と保存先を確認して決めます。
4. 案件台帳へ反映し、完了条件をそろえる
各工程について「誰が」「何を入力したら」「次の状態へ進めるか」を決めます。特定のCRMやSaaSを前提にせず、現在利用している環境で管理可能かを先に確認します。道具を変える場合も、業務ルールを固めてから選びます。
5. 未対応通知の条件を決める
会社ごとに定めた基準時間を超えても担当者・案件状態・次回行動日のいずれかが未設定の案件を見つけます。通知先、営業時間外の扱い、通知を止める条件まで設計します。
6. フォローの型を作る
提案や見積の提出後に、いつ・何を確認するかを決めます。回数を固定すること自体が目的ではありません。顧客の検討状況に応じた連絡タイミング、文面、手段、停止条件を定義し、返答があった場合は担当者の個別対応へ切り替えます。
価格、契約条件、専門判断に関わる文章は自動確定せず、人が確認できる工程を残します。
KPIは「誰を評価するか」ではなく「どこで止まるか」を見る
数値は成果を保証するものではなく、対応フローのボトルネックを見つけるための判断材料です。集計期間と対象案件の定義を固定し、同じ条件で比較します。
| KPI | 定義 |
|---|---|
| 初回対応時間 | 問い合わせ受付から担当者の最初の対応まで |
| 未対応数 | 定めた完了条件を満たさず基準時間を超えた案件数 |
| 次回行動日設定率 | 対象案件のうち次回行動日が設定されている割合 |
| フォロー実施率 | フォロー対象案件のうち設計した対応を実施した割合 |
| 商談化率 | 問い合わせのうち商談の定義を満たした割合 |
率だけで良否を決めず、分母となる案件数と、止まっている案件の中身まで確認します。
自動化しない判断
次のような判断は、担当者または責任者が内容を確認する前提にします。
- 価格、値引き、支払条件の確定
- 契約内容や保証範囲の説明
- クレーム、事故、緊急性がある相談への対応
- 個人情報を外部サービスへ渡す判断
- 顧客の意向が不明な状態での継続連絡
- 業界固有の専門判断や法的判断
自動化は人の判断をなくすことが目的ではありません。定型作業と確認漏れを仕組みに任せ、人が判断すべき案件を明確にするために使います。
向いている会社・先に別課題へ取り組む会社
問い合わせ管理の整備が効きやすいのは、受付経路が複数あり、案件の担当者や次回行動を一覧で確認できない会社です。提案後の連絡方法が担当者任せになっている場合や、失注理由を振り返れない場合も対象になります。
一方、問い合わせ自体がほとんどない場合は、管理システムを作り込む前に集客・営業導線を見直します。営業し続けなくても売れる仕組みを参考に、見込み客との接点から相談までの流れを確認してください。
また、対応責任者を決められない状態では、通知を増やしても処理先がありません。先に役割と承認者を決めてから実装へ進みます。
まとめ
- 問い合わせは一つの案件台帳に集め、担当者・案件状態・次回行動日を管理する
- 自動返信と担当者の初回対応を分け、対応完了の条件を決める
- 最も取りこぼしが起きやすいフロー1本から仕組み化する
- KPIは担当者を監視するためではなく、業務が止まる場所を見つけるために使う
- 価格・契約・クレーム・個人情報など、人が判断すべき境界を残す
問い合わせ管理だけを切り離して考えるのではなく、集客から商談、受注、振り返りまでを一つの流れとして設計することが重要です。
シクミベースでは、特定のツール導入ありきではなく、現在の集客・営業・業務の流れを確認し、どこから仕組みにすると効果が大きいかを整理します。 支援内容の一覧はこちらをご覧ください。仕組み化について相談するから、現状の課題を共有してください。