営業から導入担当へ何を引き継ぐ？

営業から導入への引き継ぎでは、顧客の希望と、提供すると確認した作業を照合しましょう。営業インターンが社員の指示で引き継ぎを準備する場面を想定します。出典付きの説明以外は編集部の提案で、受注例は架空です。

受注の記録と、導入で実行する範囲をつなぐ

営業から導入担当への引き継ぎを手伝うときは、最初に今回の契約・申込・発注の対象と、社内で確認済みの文書を聞いてください。学生が契約成立を判定するのではなく、責任者が確定した条件を、導入担当が参照する場所へ結び付ける案です。

Salesforceの学習資料では、営業からカスタマーサクセスへ引き継ぐ際の問いとして、購入理由、事業上の目標、窓口、商談での障害などを挙げています。

出典：Salesforce「Partner with Customer Success」（How Sales and Customer Success Work Together。公表・更新日：記載なし、確認日：2026-10-16）。

この情報連携を参考に、本記事では「なぜ導入するか」と「何を提供すると確認したか」を分けて渡す方法を提案します。売上を伸ばしたいという顧客の目標を、その数値の達成を約束した条件へ変えないでください。

担当部署の呼び名や分担は勤務先へ確認します。職種そのものを比べたい場合は営業とカスタマーサクセスの違いを入口にし、ここでは一件の受注条件が導入へ引き継がれる場面を扱いましょう。

含む作業・対象外・希望を、別々に置く

提案資料、見積書、注文内容、商談メモを集める際は、今回使う版と確認状態を添えます。資料名だけで優先順位を推測せず、どの文書を合意内容の参照元とするか担当者へ聞いてください。食い違いを見つけたら、学生が一方を正しいと決めて消さないようにします。

Atlassianのプロジェクト範囲の解説は、対象に含める作業に加えて、実施しない作業や成果物、予算・日程・人員などの制約を明示する手順を示しています。

出典：Atlassian「What is Project Scope? How to Define & Write」（4. Establish clear project exclusions／5. Learn and detail the project constraints。公表・更新日：記載なし、確認日：2026-10-16）。

以下はその考え方を営業引き継ぎに使う編集案です。欄を「合意済みとして確認した提供範囲」「対象外と確認した範囲」「顧客の希望」「判断が残る点」に分けましょう。書かれていない作業を、無償で含むとも、対象外とも独断で分類しないでください。

たとえば「データ移行も相談したい」というメモは希望欄へ置きます。「移行対応を受注済み」とするなら、対象データ、作業内容、回数などを責任者が確認した根拠が必要な項目として扱いましょう。回答が出るまでは実施予定に入れず、確認待ちにします。

架空の受注を、導入担当の四つの判断へ渡す

次は架空の予約管理サービスの受注です。社内の担当者が、基本設定一回と管理者向け説明一回を合意済みとして確認した設定です。既存データの移行は見積範囲外、顧客は月末開始を希望しているが開始日は未確定とします。実在の案件や提供条件ではありません。

この表では「月末開始で引き継ぎます」と短縮しないでください。希望日を確定日へ変えてしまうためです。導入担当へは、月末という希望と、何が未確認かを一緒に渡します。

移行の相談も、対象外だから消すのではなく希望として残します。追加の判断をする人が決まるまでは、導入担当へ実行を依頼しない扱いです。見積書の範囲を読む練習は営業の見積書の照合と合わせて確認できます。

開始日には、先に満たす条件を添える

引き継ぎで日付を扱うときは、「顧客の希望」「社内の作業予定」「相手へ確定して伝えた日」を別の欄に置く案です。同じ日でも、何の状態を表すかを添えてください。確定の根拠がない日付は、予定欄から約束の欄へ移さないようにします。

先ほどの仮例で、基本設定に顧客側の管理項目の回答が必要という条件を加えます。回答期限がまだ決まっていないなら、営業側が希望日を受け取っただけで設定完了日を置かず、導入担当へ必要な前提と作業順を聞きましょう。

• 顧客に確認する前提：必要な項目を誰がいつ回答するか
• 提供側で確認する前提：実施担当と作業枠を確保できるか
• 開始の確認：どの設定と説明を終えれば利用へ進めるか
• 遅れた場合：誰が影響を判断し、誰が顧客へ連絡するか

インターンの役割は、未回答を見つけて確認先へつなぐ範囲で決めてください。作業の遅れを埋めるために、対象外の移行を自分で引き受けたり、説明を省略すると約束したりしないようにします。

営業の説明と文書が違うときは、差を見せる

「営業から移行も含むと聞いた」と顧客が話した一方で、確認済みの文書には移行が含まれていない、という追加の架空場面を考えます。この時点で顧客の勘違いと決めず、説明した内容と日時、文書の版、残っている記録を並べて責任者へ渡しましょう。

導入担当の判断だけで約束を追加することも、営業メモを消して文書に合わせることも避ける案です。「文書Aの対象は基本設定、商談メモBには移行の相談あり、顧客は移行を含むと理解している」と、相違を短く書きます。

確認が終わるまでは、どの作業を止め、どの準備は進めてよいかを責任者に決めてもらってください。関係のない作業まで学生の判断で全面停止せず、影響する範囲と期限を添えて相談します。

顧客への返答を任された場合も、「追加料金なしで対応します」と埋めないでください。確認する内容と連絡担当を示す文案を作り、回答できる時期も含めて承認を求めます。契約の解釈や補償の判断は、担当窓口へ戻しましょう。

導入開始の打ち合わせでは、作業を読み合わせる

引き継ぎ資料を送った後は、担当者同士が同じ作業を想定しているか確かめる場を相談しましょう。「資料を読みましたか」だけでなく、「最初に設定する対象は何か」「何がそろうまで開始できないか」を説明してもらう案です。

顧客も参加する場なら、社内向けの評価や価格判断のメモをそのまま見せず、共有を認められた内容へ整理します。質問は、導入目的、今回の提供範囲、顧客側の準備、開始条件の順に置いてください。追加希望が出たら、その場で合意済み欄を書き換えず、確認する要望として受け取ります。

架空例では「基本設定と管理者向け説明が今回の対象です。データ移行は別途確認中です。月末開始については管理項目への回答と作業枠を確認します」という説明案を、責任者へ確認してもらいます。希望を聞いたことと、受け入れたことが混ざらないかを点検してください。

関係者の判断範囲が不明なら、営業での役割確認を参考に、窓口経由で確認する問いを残しましょう。出席者の肩書だけで追加作業の承認者を決めないようにします。

引き継ぎ後の追加要望は、元の条件と差分で扱う

導入中に「説明をもう一回してほしい」と希望が出たら、元の条件、追加したい内容、必要な判断を分けて営業担当へ戻す案です。架空例の説明一回を、いつの間にか回数の制限なしへ変更しないでください。

逆に、元の対象に含まれる作業が漏れている場合は、追加注文と決める前に合意済みの範囲へ戻ります。「元から含むが未実施」「新しい希望」「資料間の相違で未判断」の三つを区別し、どれか不明なら判断待ちとして扱いましょう。

1. 引き継いだ対象と、その根拠となる版を残す
2. 導入担当の受領と、未解決項目の担当を確認する
3. 追加の希望が出たら、元の範囲との差分を記録する
4. 承認された変更だけを作業計画へ反映する
5. 顧客へ伝えた内容と、導入側の計画が一致するか確かめる

今日の練習では、架空例の月末開始とデータ移行について、未確定の理由と確認先を一行ずつ書きましょう。資料の完成をゴールにせず、誰が何を実行でき、何をまだ約束できないかまで説明できる引き継ぎを目指してください。