どの段階で商談が長く止まる？段階別の滞在日数を読む方法

青葉商会のD34は9月1日に仕様確認へ入り、9月6日に提案へ進み、9月10日に仕様確認へ戻りました。9月20日の会議で田中は停滞を確認します。

最初の仕様確認日だけから経過を計算すると、現在の待ちと以前の確認期間が混ざります。

現在の段階の滞在と同段階の累積を分け、比較日と暦日・営業日の単位を固定します。 参照資料「HubSpot: Use stage calculated properties」で確認した範囲は、現在の段階の経過時間と再入場を含む累積時間の区別。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「最初の仕様確認」の入力は、9月1日から6日です。ここでは開始を含めず退出時刻との差で測ります。記録の判断欄には「5暦日」と残します。

「提案期間」の入力は、9月6日から10日です。ここでは仕様確認の時間へ足しません。記録の判断欄には「4暦日」と残します。

「再度の仕様確認」の入力は、9月10日から20日です。ここでは累積仕様確認は5＋10＝15日です。記録の判断欄には「現在10暦日」と残します。

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

田中は現在の滞在10日を待ちの確認へ、累積15日を何度戻ったかの分析へ使います。二つの列を分け、比較日9月20日を保存して後日の一覧と混ぜません。

現在10日、累積15日、商談開始から19日という三つの値は別の問いへ答えます。どれも同じ滞在日数という見出しにすると担当者は何を確認するか選べません。

9月1日から20日までは19日という差で計算し、開始日と終了日を両方含めた日数にはしません。段階の現在値、累積値、全体経過の対象区間をそれぞれ書くと引き算を再現できます。

段階の変更日を後から訂正した場合は再計算します。時刻がない古い履歴は日単位の近似と明記し、時刻付きの案件と厳密な時間順位で比べません。

例の閾値や滞在は標準の商談期間ではありません。長期設備計画と短期備品相談を同じ日数で評価せず、商談の種類を合わせます。

田中は変更日の訂正理由と資料を照合します。古い履歴が日付のみなら日単位の差で計算し、時刻を仮に午前0時へ置いて厳密な待ち時間として比較しません。

佐藤は再確認の待ち先を顧客の設置資料待ちと記し、田中は現在滞在の長い案件から待ち先を確認します。長いことだけで失注へ変更しません。

段階へ戻った履歴が保存され、現在10日と累積15日を表から再計算できるか確認します。平均値だけで一件の長期案件が隠れないよう個別一覧も見ます。

高橋は5日と4日と現在10日の区間を図から再計算します。仕様確認の累積15日が現在10日へ上書きされていないか見ます。訂正後は対象区間が変わった指標だけを再計算します。

段階の開始と終了を履歴へ残します。現在の滞在、同じ段階の累積、商談全体の経過を別名で表示します。

数字が長いだけで待ちの原因は決まりません。現在10日には誰の確認を待っているかを並べ、次の行動を担当へ渡します。

田中は区間と計算単位を確認し、高橋は日数を再現します。時刻がない場合の限界を残し、粗さの違う案件を厳密に順位づけません。