商談が前の段階へ戻ったら？進み具合と差戻し理由の記録表

青葉商会の設備商談D21は、森製作の検討担当が提案を確認した後、新しい設置条件が出て仕様確認へ戻りました。佐藤は進行履歴を見直します。

一度提案へ進んだ状態を保つと、必要な確認が終わったように見えます。履歴を消して戻すと、なぜ戻ったか分かりません。

段階は現在確認できている条件を表し、前へ戻す際は戻った理由・日付・未確認事項を履歴へ残します。 参照資料「HubSpot: Set up and manage object pipelines」で確認した範囲は、商談段階と条件欄を使って進行状態を表す概念。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「10月1日 提案確認」の入力は、当初の設置条件で説明済みです。ここではその時点の資料Q21を残します。記録の判断欄には「当時の段階として保存」と残します。

「10月8日 仕様確認へ戻す」の入力は、設置高さが変更です。ここでは高さの確認タスクを佐藤へ付けます。記録の判断欄には「現在の段階を更新」と残します。

「10月15日 再確認予定」の入力は、新条件の適合は未確認です。ここでは技術担当中村の結果を待ちます。記録の判断欄には「提案確認への復帰は保留」と残します。

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

田中は段階を上げる条件を、資料送付ではなく対象条件を確認できた状態として定義します。条件が崩れたD21は仕様確認へ戻し、営業の努力量を段階とは別に記録します。

履歴では提案確認の滞在と二回目の仕様確認が分かれます。現在の状態だけなら仕様確認一件ですが、提案に進まなかった案件として過去の経過を消す必要はありません。

現在の段階は条件がそろった位置を表し、努力量や累積の活動数を表しません。10月8日に設置高さが変わった事実を理由として残すと、佐藤の提案が消えず、戻した判断も説明できます。

単なる記入ミスで提案段階を選んだ場合は、顧客条件の変更とは別に訂正理由を残します。実際の差戻しと入力訂正を同じ分析区分にすると停滞の原因が混ざります。

商談を戻すことは失注を意味しません。段階の高低だけで営業担当を評価せず、条件変更の内容と次の確認可能性を合わせて扱います。

田中は差戻し理由を条件変更、訂正理由を誤選択として分けます。条件変更日が不明なら今回の確認日を残し、過去へさかのぼった差戻し日を推定入力しません。

佐藤が設置高さの変更資料をD21へ添え、中村が適合確認を担当します。田中は復帰条件を新しい高さで説明可能と記し、確認前には段階を進めません。

段階の変更前後の日付と理由が残り、10月1日の資料が現行条件として自動で使われないかを確認します。次の会議では現在の未確認事項を先に読みます。

高橋は新しい高さ条件から次の確認を説明できるか試します。誤って提案の履歴を削っていた場合は元の活動と段階変更日を照合し、確認できた経過だけを訂正記録として復元します。

段階ごとの移行条件を明文化し、条件が崩れたら理由と確認日を残して戻します。段階を後退させないために未確認のまま進めません。

現在の状態と過去の経過を別に読みます。二回目の仕様確認を最初から仕様未確定だった案件と同じ履歴にしません。

佐藤は新条件を確認し、田中は戻した理由を点検します。条件が再びそろった時点で提案確認へ進め、前回との違いを残します。