営業へ渡したリードの結果を戻すには？引受・保留・決着の返却表

春野ラボでは加藤が問い合わせを営業の佐々木へ渡しています。森工場のI70は受領後に条件確認へ進み、橋工場のI71は来年の予算待ち、北工場のI72は相談が決着しました。加藤の台帳には三件とも引渡し済みしか残っていません。

引渡し済みだけでは、営業が受け取ったか、対応を引き受けたか、どんな理由で保留したかが分かりません。受注だけを返すと、対象条件を改善する手掛かりになる保留や対象外の記録も失われます。

営業への結果共有は受領、引受、保留、決着を分け、問い合わせIDと確認時刻で返します。保留の再確認条件と決着理由を残すと、マーケティングが元の対象条件を見直せます。 参照資料「HubSpot: Contact and company lifecycle stages」で確認した範囲は、マーケティング判定MQL、営業判定SQL、商談という状態の区別。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「森工場I70」の入力は、受領10時、引受11時、条件確認中です。ここでは受領だけで引受済みとは書きません。記録の判断欄には「営業対応中として返却」と残します。

「橋工場I71」の入力は、対象用途は合うが予算は来年です。ここでは予算確認月を再確認条件にします。記録の判断欄には「時期保留として返却」と残します。

「北工場I72」の入力は、相談は他方式を選び決着です。ここでは対象外、時期保留、価格理由へ勝手に置き換えません。記録の判断欄には「選定理由と決着日を返却」と残します。

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

加藤と佐々木は返却票の状態名をそろえ、受付ID、人物・会社、営業担当、状態を確認した時刻、理由、次の確認条件を必須にします。商談を作らなかった問い合わせにも結果欄を置きます。元の流入や受付の履歴は、営業の判断で上書きしません。

三件の引渡しに対して、受領は3件、現在の営業対応は1件、保留は1件、決着は1件です。これらを引受3件や受注1件と読み替えません。返却の状態をそろえることで、どこまで営業が確認したかを件数と具体的な理由で追えます。

返却票の件数は現在状態として対応中、保留、決着の三つへ分けます。受領三件という節目の数と足して六件の問い合わせにしません。引受したかは各受付IDの確認結果から判断します。

返却期限に未回答のI70があれば、加藤は結果不明とし、佐々木へ確認する社内タスクを置きます。空欄を保留と推定して配信候補へ戻しません。複数の営業が関わる問い合わせでも、返却の責任者は一人に決めます。

返却理由は営業が確認できた範囲の記録です。相手の心理や真の失注原因を断定せず、確認した言葉と営業側の解釈を分けます。架空の三件は成果実績ではなく、連携を検証するための記入例です。

加藤は結果不明の行を佐々木へ確認するタスクにします。返却がない状態を案内へ戻す条件にせず、担当と期限を置きます。営業が二人でも返却の責任者は一人にそろえます。

佐々木はI70〜I72を返却票へ記入し、加藤は時期保留I71の再確認条件だけを育成候補の検討へ渡します。吉田は決着理由が元の問い合わせ内容と矛盾しないかを見ます。配信状態や商談化とは別に結果共有を完了させます。

三件の受付IDが返却票にも存在し、状態の確認時刻と返却責任者が埋まっていることを確認します。I71には再確認条件、I72には決着理由と日付があり、I70は確認中であると読めれば、今回の結果共有は完了です。

吉田は返却理由を問い合わせの原記録へ戻して確認します。他方式の選定を価格理由へ変えていた場合は確認した説明と営業の推測を分離して訂正し、時期保留の再確認条件も点検します。

受付IDをそろえ、状態と確認時刻を営業から返します。商談にならなかった問い合わせも理由と次の条件を残します。

受領と引受を分けると、連携のどこまで進んだかが分かります。保留と決着は異なる次の行動へつなぎます。

佐々木が結果を記入し、加藤が再確認条件を受け取ります。吉田が理由の根拠を点検し、元の流入記録を上書きせず共有を完了させます。