提案済みなら商談を進めてよい？次の段階へ移す確認条件

青葉商会の佐藤は森製作へ設備提案Q22を送付しました。顧客が読んだか、設置条件が合っているかはまだ確認できず、商談D22は仕様確認にあります。

メールを送っただけで提案合意へ進めると、後続の見込み集計に確認不足の案件が混ざります。

段階を変える入力規則へ確認項目を定め、送付した事実と条件の確認結果を別に記録します。 参照資料「HubSpot: Set up and manage object pipelines」で確認した範囲は、商談段階と条件欄を使って進行状態を表す概念。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「資料の送付」の入力は、Q22を10月3日に送付です。ここでは送付だけでは合意欄を埋めません。記録の判断欄には「活動記録を追加」と残します。

「設置条件」の入力は、電源条件が未確認です。ここでは中村へ確認タスクを残します。記録の判断欄には「移行条件を満たさない」と残します。

「顧客の次回確認」の入力は、10月12日に条件を確認予定です。ここでは実施結果が出た後に移行を判断します。記録の判断欄には「予定として記録」と残します。

比較表は横に動かして全ての列を確認できます。

田中は提案確認への移行条件を、対象製品・設置条件・次の確認担当がそろうこととします。自社の社内規則として欄を定義し、顧客の購入意思を資料送付から推定しません。

必須欄が日付だけなら架空の日付を入れて進められます。確認結果と根拠資料が必要なら、未確認と確認済みの違いを残せます。システムの保存制約だけでなく確認内容が必要です。

入力規則は空欄を埋める命令ではなく、段階を進められる確認結果の定義です。確認済みには結果と根拠、未確認には担当と期限、対象外にはその製品で不要な理由を対応させます。

電源条件が対象外の製品は未確認ではなく対象外とします。全案件で同じ欄を要求して営業が意味のない値を入れる事態を避け、対象外にできる条件を規則に記します。

確認項目はこの商談の社内規則です。資料を読んだという返答があっても購入合意にはならず、受注判定は注文など別の根拠で行います。

田中は対象外にできる製品の条件を決め、佐藤が勝手に対象外を選んで進めないよう例を残します。電源条件が必要か不明なら確認待ちとし、保存のために適当な電圧を入れません。

佐藤が送付活動を残し、中村が電源条件を確認します。田中は対象あり・対象外・不足の三例で移行規則を試し、記入例を営業へ共有します。

不足例で段階が進まず、対象外の理由がある例は確認済み範囲で扱えるかを確認します。段階変更日と資料送付日が別の日でも正しく残ることを点検します。

高橋は送付日だけの入力、必要条件が未確認の入力、対象外理由が正しい入力の三件を試します。段階変更の結果だけでなく、どの不足を誰へ戻したかを確認し、誤った対象外は理由付きで訂正します。

提案確認へ進む条件を製品、設置条件、次の確認担当に分けて定義します。入力欄の数を減らす定着策より、今回は段階の判定を実行できる規則に集中します。

日付があっても必要な条件を確認できたとは言えません。確認結果と根拠を持つ入力例を作り、未確認でも受付は残して移行だけを保留します。

三つの入力で判定を試し、田中が不足と対象外を区別できるか確認します。規則の例外に新製品を追加したら同じ試験を行います。