営業へのリード引き継ぎシートに入れる項目と設計手順

結論: 引き継ぎシートは「属性」ではなく「文脈」を渡す

リード引き継ぎシートに入れるべきは、企業属性ではなく行動の文脈です。社名・部署・役職は名刺やCRMから取得できますが、「何を聞き、何に困り、次に何を期待しているか」は接点の場でしか残りません。営業がMQLを使わない原因の多くは、この文脈が欠けたまま名前だけが渡ることにあります。

シートの設計は、項目を増やす作業ではありません。営業が最初の1本の電話までに必要な最小情報を決める作業です。項目が多いシートほど記入されず、記入されないシートは信用されません。

本記事では、必須項目・任意項目の切り分け、記入者と期限の決め方、運用が破綻するパターンを順に整理します。

※本記事は2026年9月時点の情報をもとに作成しています。

リード引き継ぎシートとは

リード引き継ぎシートとは、マーケティング側が獲得・育成したリードを営業へ渡す際に添える、定型フォーマットの情報記録です。ハンドオフシート、パスシート、トスアップシートなどとも呼ばれます。

記録の場所はCRM/MAのレコード内でも、フォーム連携された通知でも構いません。重要なのはフォーマットが固定されていることと、営業が受け取る前に記入が完了していることの2点です。

似た概念に「MQLの定義」がありますが、役割が異なります。MQLの定義は「渡してよいか」を判定する基準、引き継ぎシートは「渡すときに何を添えるか」の設計です。判定基準だけを整えても、添付情報が空なら営業の初動は変わりません。両者はセットで設計します。

混同しやすい3つの文書

必須項目と任意項目の切り分け

項目は「必須」「任意」「自動取得」の3層に分けます。必須は営業の初動判断に直結するもの、任意は会話の厚みを出すもの、自動取得は人が書かないものです。

必須項目は7つ以内に収めます。これを超えると記入率が落ち、結果として空欄だらけのシートが流通します。空欄が常態化したシートは、営業から「見る価値がない」と判断されます。

自動取得できる項目を人が書く欄に置かないことが、記入率を保つ基本です。

自由記述欄の設計が品質を決める

シートの価値は、自由記述欄の書かれ方で決まります。選択肢だけのシートは、営業にとって既知の情報の再掲になりがちです。

自由記述は発言の引用形式を推奨します。「課題: 手作業が多い」ではなく、「『月末の集計に3日かかっていて、担当者が1人しかいない』との発言」と書きます。要約ではなく引用にすることで、営業は相手の言葉をそのまま会話の入り口に使えます。

記述の長さは3〜5行を目安にします。長文は読まれず、1行では判断できません。

自由記述に入れる3要素

• 状況: いま何が起きているか
• きっかけ: なぜ今調べているか
• 期待: 次に何を求めているか

この3要素が揃うと、営業は初回接触の仮説を立てられます。逆にこの3つのどれかが空なら、シートは未完成として差し戻す運用が妥当です。詳細な引き継ぎ基準の合意方法はMQLの営業引き継ぎとSLA設計で整理しています。

記入者・期限・差し戻しのルールとレビュー

シートは項目だけでなく、運用ルールとセットで初めて機能します。決めるべきは、記入者・記入期限・差し戻し条件の3点です。

記入者は接点を持った側にします。ウェビナー後のアンケート回答をインサイドセールスが補完する、Web上の対話ログをそのまま格納する、といった形で、情報の発生源に近い側が書きます。

記入期限は接点発生からの時間で定義します。日をまたぐと記憶が薄れ、記述が抽象化します。ウェビナーや展示会のように接点が集中する場面では、ウェビナー後72時間のフォロー設計のように時間基準で設計すると運用が安定します。

差し戻し条件は事前に文書化します。「必須項目に空欄がある」「自由記述が3要素を満たさない」など、主観を挟まない条件にします。

月次レビューの観点

シートは作って終わりではなく、月次でレビューします。見るのは記入率と、営業からの差し戻し理由です。3か月連続で会話に使われなかった項目は削除候補とし、追加より削除を優先します。良い記述の実例を数本、社内の参照サンプルとして共有すると、記述の粒度が揃いやすくなります。

• 必須項目の記入率は保たれているか
• 差し戻しの理由は特定の項目に偏っていないか
• 営業が実際に会話で使った項目はどれか
• 自動取得に置き換えられる手入力は残っていないか

よくある失敗のパターン

引き継ぎシートの運用は、いくつかの決まった形で崩れます。いずれも項目設計ではなく、運用設計の問題です。

項目を増やし続ける。営業から「これも知りたい」と言われるたびに欄を足すと、記入負荷が上がり空欄が増えます。追加するときは同数を削る前提で議論します。

スコアだけを渡す。スコアは判定の道具であり、会話の材料ではありません。数値のみを渡すと、営業は何を聞けばよいか分からず、結局ゼロから質問します。

マーケの解釈を書いてしまう。「確度が高そう」「前向き」といった主観は、営業の判断を歪めます。書くのは観測された事実と発言です。

差し戻しの行き先がない。不備を指摘しても戻す先が決まっていないと、営業は指摘をやめ、シート自体を見なくなります。差し戻し先は個人名ではなく役割で定義します。

フォーマットが複数存在する。展示会用、ウェビナー用、Web用と分かれると比較ができません。経路は項目の一つとして持ち、フォーマットは1つに統一します。

この進め方が向いていないケース

引き継ぎシートの整備が適さない場面もあります。以下に当てはまる場合は、先に別の課題を解くべきです。

そもそも渡すリードの量が少ない。月数件であれば、口頭やチャットでの共有のほうが速く、フォーマット化の負荷が上回ります。

商談が1回の接触で完結する低単価商材。検討文脈を引き継ぐ必要が薄く、リードタイムの短さが優先されます。

営業組織がMQLの定義に合意していない。渡してよい線引きが未合意のまま添付情報だけ整えても、受け取り拒否は解消しません。先に定義の合意が必要です。

CRMが運用されていない。シートの置き場所がないと、記録は個人のメールやメモに分散します。格納先の整備が前提になります。

インバウンドの母数が伸びていない局面。渡す前段の流入とCVRが課題なら、BtoB LPのCVRが頭打ちになる原因のような入口側の設計を先に見直します。

よくある質問

まとめ

引き継ぎシートの本質は、項目表ではなく文脈の受け渡し設計です。必須項目を絞り、自由記述に状況・きっかけ・期待の3要素を入れ、記入者と期限と差し戻し条件を決める。この4点が揃えば、シートは営業の初動を支える道具になります。

逆に、項目を増やし、スコアだけを渡し、差し戻し先を決めないままでは、フォーマットは形骸化します。月次でレビューし、使われない項目を削る運用を続けることが、軽さを保つ現実的な方法です。

UniAgentは、Webサイト上で登録資料を根拠に説明・ヒアリングを行い、そこで得られた文脈を担当者へ引き継ぐAIです。関連する設計の考え方はナレッジ記事一覧にまとめています。