失注理由を記録して振り返る｜推測と顧客の回答を分ける

失注と連絡待ちを分ける

返信がない案件を一律に失注にすると、忙しいだけの顧客と明確に他社を選んだ顧客が混ざります。明確な見送り、他社決定、時期延期、連絡待ち、判定不能を分けます。どの状態で営業活動を止めるかは社内の基準として決め、顧客が言っていない理由を補って記録しないようにします。

回答と解釈を別の欄にする

案件ID、対象の提案版、結果を確認した日、顧客が伝えた理由、担当者の見立て、根拠、次に確認したいことを残します。顧客の言葉は必要な範囲で短くまとめ、断定し過ぎないようにします。「予算が合わない」と「価値に対して高い」は違う可能性があるため、同じ価格分類でも詳細を残します。

分類を増やしすぎない

最初は価格、仕様、時期、体制、既存取引、その他、不明など、振り返りに使う少数の分類にします。選択肢が多過ぎると担当者によって入力がぶれます。一つだけ選ばせる場合も主な理由と補足を分けます。分類は顧客の評価を採点するためではなく、自分たちが変えられる提案や受付条件を考えるために使います。

件数と提案条件を一緒に見る

月ごとの失注数だけでなく、提案した件数、対象商品、規模、見積もりの版、顧客層を合わせて見ます。小さな件数の比率から一律値下げを決めないようにします。価格が理由でも納期や対象範囲が背景にあるかもしれません。集計前に空欄と不明を区別し、理由が取れた案件だけを全体の代表として扱わないことが重要です。

改善案を一つ決めて追う

振り返りでは提案書の説明追加、受付条件の明確化、納期案内の改善など、一つの変更を決めます。誰がいつ変え、次のどの案件で確認するかを残します。過去の理由を新しい分類へ変える場合は、元の記録を保存して対応を決めます。AIで要約する場合も、顧客の回答と担当者の推測を混ぜていないか人が確認します。

不明を残せる運用にする

明確な見送り、理由なし、延期、複数理由、後日再開の例を確認します。理由を必須にしても「不明」を選べるようにし、入力を埋めるための推測を増やさないようにします。後日再開した案件は古い失注結果を消さず、新しい商談との関係を残します。振り返りでは顧客情報の公開範囲も絞ります。

見送りと延期を集計で分ける

確認用に、他社を選んだ案件3件、来期へ延期した案件2件、返信がない案件4件を並べます。9件すべてを価格による失注へ分類すると、根拠のない値下げ判断につながります。顧客が理由を答えた件数と、判断できない件数を別に示します。来期へ延期した顧客へは、連絡の希望があれば確認日を置きます。返信がない顧客へ同じアンケートを繰り返して数字を埋めることはしません。次のレビューでは分類の変化だけでなく、どの提案条件を変えたかを照合します。改善の効果と記録方法の変更を区別するためです。

振り返りの場では、顧客の発言を要約した人が不在でも根拠を確認できるようにします。ただし全員へ元メールの閲覧権限を広げる必要はありません。集計を使う人には必要な分類と状況を示し、詳細の確認は権限のある担当が行います。理由が取れた案件に偏りがあるなら、その偏りも説明します。大口の一件が結果を大きく変える場合は、件数と金額規模を別に見ます。失注理由を全部なくすという目標ではなく、提案の説明不足や対象条件のずれを一つずつ直す運用にします。改善しなかった場合も元の記録を修正して成功に見せないようにします。

道具と費用を増やす前に確認する

少数の案件なら、月一回の共有表レビューで始められます。道具を増やす前に分類と記録の基準を揃えます。自動集計やAI要約を追加する場合は、入力の確認時間、対象件数、閲覧権限も含めて費用を見ます。件数を増やすために顧客へ不要なアンケートを送り続けず、既存のやりとりから分かる範囲を使います。

• Airtableで問い合わせ管理表を作る｜受付・担当・対応状況の設計
• Tallyでサービス利用後のアンケートを作る｜評価と改善依頼を分ける
• Airtableのビューで未対応案件を確認する｜フィルター・並び順・共有の注意点