見積の前に仕様確認が必要なら？営業タスクの順序と待ちを整理

青葉商会の佐藤は森製作へ設備の見積を準備します。数量は分かっていますが、電源条件を技術担当中村が確認するまで仕様と価格を決められません。

見積作成を先に期限設定すると、担当は動けない作業を抱え、待ちの原因も見えません。

営業の次回行動を前提作業と実行作業に分け、依存する条件・担当・確認日を記録します。 参照資料「HubSpot: Create tasks」で確認した範囲は、担当、期日、対象記録を備えた営業作業の管理。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「T31-A 電源確認」の入力は、中村が顧客資料を照合です。ここでは10月12日に確認結果を佐藤へ渡します。記録の判断欄には「見積の前提」と残します。

「T31-B 仕様選択」の入力は、佐藤が確認結果を使用です。ここでは未確認中は候補だけを準備します。記録の判断欄には「電源確認後に着手」と残します。

「T31-C 見積作成」の入力は、仕様と数量が必要です。ここでは顧客への提出日は確認後に決めます。記録の判断欄には「仕様確定後に着手」と残します。

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

佐藤は作業順を一列に並べ、完了の条件を結果が届いたことにします。確認依頼を出しただけで前提作業を完了にせず、見積作成の待ち先を中村と記します。

三作業へ同じ期限を付けると順序が見えません。前提確認12日、仕様判断13日、見積準備14日という社内案なら依存関係を示せます。ただし顧客回答の予定は合意がない間は未確定です。

12日、13日、14日は社内で置いた作業順の案です。顧客の回答を約束した日として表示しません。前提が遅れた場合は後続の着手可否と見込み期限を一緒に見直します。

中村が追加資料を求めた場合は、T31-Aを顧客資料待ちへ変えます。見積の期限だけを後ろへ動かすのではなく、誰が不足資料を確認するかを佐藤のタスクとして作ります。

順序表は社内準備の予定です。条件が未確認のまま顧客へ確定納期を約束せず、確認結果に応じて作業計画を更新します。

中村は不足した資料を列挙し、佐藤が確認を依頼するタスクを持ちます。依頼済みという状態を資料確認完了へ変えず、届いた資料の内容を中村が確認してから後続へ渡します。

佐藤は中村への確認項目と資料F31をそろえ、田中は待ち作業一覧でT31-B・Cが前提待ちと見えるか確認します。結果が届いたら次のタスクへ進めます。

電源確認を完了にしただけで見積提出が自動完了にならないかを点検します。前提の結果が不適合なら候補を再選択する分岐も残します。

高橋は見積タスクから必要な前提をたどれるか試します。誤って完了にした依頼タスクは資料の到着状態を照合して訂正し、後続の見積が先に確定していないか田中が確認します。

作業ごとの完了条件と依存先を書きます。期限を三つ付ける前に、何が終わると次へ進めるかを定義します。

電源確認、仕様判断、見積準備という順を図へ置きます。外部の回答予定は社内期限と別欄にして不確実な前提を見える形にします。

佐藤は不足資料の確認担当を持ち、中村は前提完了を判定します。田中は後続作業の着手と確定を分けて照合します。