前任者から引き継いだスプレッドシートを開くと、同じ会社が二重に並び、数年前に移転した住所が残り、よく見ればすでに取引が始まっている企業まで混ざっている。上司からは「リストを見直せ」と言われたものの、何から直せばよいのか分からない。営業リストに関する悩みは、多くの場合こうした「手元にあるリストの状態をどう評価すればよいか分からない」という地点から始まります。
営業リストの作り方を調べると、項目の例・情報の集め方・便利なツールの紹介までは比較的すぐに見つかります。一方で、多くの作成手順の解説は「リストが完成した時点」で話を終えてしまいがちです。そのため、できあがったリストから「この会社には送ってはいけない」という相手をどう外すのか、その判断を誰がいつ行うのかという部分は、自力で設計しなければならない領域として残ります。
しかし実務で本当に怖いのは、リストの項目が足りないことではありません。すでに取引のある企業や、他社(取引先・別チャネル)が接触済みの企業にアプローチしてしまい、社内から問題視されたり、相手の信頼を損なったりすることです。これは「うっかりミス」ではなく、作成の工程に「送信前の確認」が組み込まれていないことから生じる、構造的な事故だと考えたほうが防ぎやすくなります。
そこで本記事では、営業リストの作成を「目的定義・ターゲット定義・情報収集・精査・送信前チェック」の5工程として整理し、最後の送信前チェックを独立した工程として扱います。
本記事では、営業リストの定義と構成項目、4つの入手経路の向き不向き、作成の5工程、送信前に外すべき企業の分類、そして運用が崩れる3つのパターンと予防策までを順に解説します。読み終えた時点で「自社のリストに足りないのはどの工程か」が切り分けられる状態を目指します。
営業リストとは|定義と営業活動での位置づけ

営業リストとは、アプローチの対象となる企業や担当者の情報を、営業活動に使う目的で整理したデータのことです。商号・所在地・業種・従業員規模・問い合わせフォームの URL・担当部署といった項目を一定の形式でそろえ、誰が見ても同じ基準で扱える状態にしたものを指します。
営業プロセスの中では、営業リストは最も上流に位置します。テレアポ・メール・フォーム営業・DM といったアプローチ手段は、すべて「誰に向けて行うか」が決まってはじめて実行できます。つまり営業リストは実行の前提条件であり、ここが曖昧なまま後工程の改善(トークスクリプトの見直し、送信文面の改善など)に手をつけても、効果は見えにくくなります。
本記事が置く前提は1つです。営業リストの価値は、載っている企業の件数ではなく、「この会社には送ってよい」と判断し切れている企業の数で決まります。1万件のうち判断できているのが500件なら、そのリストの実質的な規模は500件です。この見方を最初に採ることで、以降の工程の優先順位が決まります。
営業リスト・ターゲットリスト・アタックリストの呼び分けと「リスト営業」
現場では似た言葉が併用されており、引き継ぎのときに混乱の原因になります。明確な業界標準があるわけではありませんが、実務では次のように使い分けられることが多いです。
呼称 | 実務上の意味 | 粒度 |
|---|---|---|
営業リスト | アプローチ対象の企業・担当者情報を営業目的で整理したデータの総称 | 最も広い |
ターゲットリスト | 業種・規模・エリアなどの条件で「狙う層」として絞り込んだリスト | 営業リストの部分集合 |
アタックリスト | 今期・今月など、実際にアプローチする対象として確定させたリスト | 最も具体的 |
重要なのは呼び方をそろえることではなく、「どの段階のリストなのか」をチーム内で区別できることです。母集団としての営業リストと、今週送信するアタックリストが同じファイルで管理されていると、送信済みと未送信が混ざり、二重アプローチが起きやすくなります。
また「リスト営業」という言い方もよく使われます。リスト営業とは、作成した営業リストをもとに、電話・メール・フォームなどでアプローチしていく営業手法のことです。営業リストが「データ」を指す言葉であるのに対し、リスト営業は「そのデータを使う活動」を指します。本記事で扱うのは主に前者のデータ側ですが、後述するように、データの整え方はリスト営業の運用設計と切り離せません。
営業リストの構成項目|最低限そろえる項目と後から補完する項目
営業リストの項目は、最初からすべてをそろえる必要はありません。「これがないとアプローチが実行できない項目」と「精度を上げるために後から足す項目」を分けて考えると、整備の順番がはっきりします。
最低限そろえる項目は、アプローチの実行に直結するものです。
- 商号(正式名称。法人格の表記も統一する)
- コーポレートサイトの URL
- 問い合わせフォームの URL、または連絡先(フォーム営業を行う場合)
- 所在地(都道府県レベルでもエリア判断に使えます)
- 業種
後から補完する項目は、ターゲットの絞り込みや文面の出し分けに使うものです。
- 従業員規模・資本金
- 事業内容の要約、主力サービス
- 担当部署・役職(個人名まで必要かは手法によります)
- 自社との接点履歴(過去の商談・問い合わせ・イベント接触など)
- 送信可否のステータスと、その判断日
最後の2項目は、競合記事の項目例では省かれることがありますが、本記事の文脈では重要です。接点履歴と送信可否ステータスは、後述する送信前チェックで参照するデータそのものだからです。項目として持っていなければ、チェックは担当者の記憶に依存することになります。
件数ではなく「送ってよい相手の数」で評価する
営業リストの評価指標を件数に置くと、作業の方向は「増やす」に向かいます。しかし増えたリストの中に、取引先・接触済み企業・情報が古い企業が混ざっていれば、増えた分だけ事故の確率も上がります。
評価軸を「送ってよいと判断できた企業の数」に置き換えると、同じ工数の使い道が変わります。新規に100件集めるのと、既存の500件の送信可否を判定するのでは、後者のほうが短期の成果と安全性の両方に効くことがあります。特に、リストを引き継いだばかりで状態が分からない段階では、集める前に「今あるものを判定する」ほうが先に手をつけやすい作業です。
この評価軸は、以降のセクションを通じた判断基準になります。入手経路を選ぶときも、工程の優先順位を決めるときも、「判断できる相手が増えるか」を基準にします。
営業リストの種類と入手方法|4つの経路と向き不向き

営業リストの入手方法は多岐にわたりますが、実務上は4つの経路に整理できます。経路ごとに、集まる情報の鮮度・項目の細かさ・利用条件が異なります。そして本記事の文脈で最も重要な違いは、「自社との接点履歴が含まれているかどうか」です。
4つの入手方法の違い|公開情報・自社保有データ・外部データベース・ツール収集
経路 | 具体例 | 得意なこと | 注意点 |
|---|---|---|---|
公開情報 | 企業サイト、業界団体の会員名簿、公的機関の公開データ、展示会の出展社一覧 | 一次情報に近く、事業内容を自社の言葉で確認できる | 収集に工数がかかる。更新のタイミングが情報源ごとに異なる |
自社保有データ | 名刺、過去の問い合わせ、商談履歴、セミナー申込、CRM / SFA の既存データ | 接点履歴を持つため、送信可否の判断材料になる | 部署ごとに分散し、表記が統一されていないことが多い |
外部の企業データベース | 企業情報データベースサービス、リスト販売サービス | 条件での絞り込みが速く、項目がそろっている | 接点履歴は含まれない。利用条件・再利用範囲の確認が必要 |
ツールによる収集 | Web 上の企業情報を収集・構造化するツール、フォーム URL を自動で発見する機能 | 対象の広さと更新頻度を担保しやすい | 取得項目の粒度がツールの設計に依存する |
4つの中で性質が大きく異なるのが、自社保有データと外部取得データです。自社保有データには「いつ誰がどう接触したか」が残っていますが、外部データベースやツール収集で得たデータには、当然ながら自社との関係性は含まれません。
この非対称性が、後述する送信前チェックの必要性に直結します。外部から取得した1万件は、そのままでは「自社と関係があるかどうか不明な1万件」です。判断できる状態にするには、自社保有データと突き合わせる工程が必要になります。
企業データベースの比較や購入判断については、営業リスト向け企業データベース比較で詳しく整理しています。取得したデータベースを実際のアプローチに組み込む流れは企業データベース営業リスト活用をご覧ください。
なお、無料で営業リストを集める方法を探している段階の方も多いと思いますが、本記事では費用面の比較ではなく、どの経路を選んでも共通して必要になる「判断の順番」に焦点を置きます。
入手経路を選ぶ判断軸|更新頻度・項目の粒度・利用条件
経路選びで迷ったときは、次の3点を確認すると判断しやすくなります。
1. 更新頻度:その情報は、いつの時点のものか。移転・社名変更・事業終了が反映されるまでにどれくらいかかるか。鮮度が落ちやすい項目(住所・担当者名・フォーム URL)を多く使う手法ほど、更新頻度の重要度が上がります。
2. 項目の粒度:自社のターゲット条件を表現できる項目がそろっているか。たとえば「従業員30〜100名の受託開発企業」を狙うなら、業種の分類が大まかすぎるデータでは絞り込めません。欲しい粒度を先に決めてから経路を選ぶほうが、後戻りが少なくなります。
3. 利用条件:取得したデータを、どの範囲で・どの期間使えるのか。外部サービスから取得する場合は、利用規約で認められた用途の範囲を確認しておきます。社内でリストを共有・再利用する前に確認しておくべき点です。
3点のうち、立ち上げ期に見落とされやすいのは項目の粒度です。件数と価格で比較してしまい、導入後に「狙いたい層を絞り込めない」と気づくケースがあります。ターゲット条件の立て方そのものは営業リストのターゲティング設計で扱っています。
経路をまたぐときに起きること|名寄せと重複が発生する箇所
複数の経路からデータを集めると、重複と表記の不一致が必ず発生します。どこで発生するかを把握しておくと、精査工程の設計が具体的になります。
発生しやすい箇所は、たとえば次のようなケースです。
- 商号の表記ゆれ:「株式会社○○」と「○○株式会社」、「(株)○○」と「株式会社○○」が別の行として残る。外部データベースは正式名称、名刺データは名刺に印刷された表記、Web 収集データはサイト上の表記を拾うため、同じ企業が3通りの表記で並ぶことがあります。
- 拠点単位と法人単位の混在:外部データベースは本社と支店を別レコードとして持つ一方、名刺データは訪問した支店だけが入っている。同じ法人に対して、複数の拠点から並行してアプローチしてしまう原因になります。
- ドメイン単位での突合漏れ:グループ会社が別ドメインを持っている、あるいは複数の事業ブランドで別サイトを運営している場合、サイト URL を鍵に突合すると同一グループを検知できません。
名寄せの軸として比較的安定するのは、法人番号やコーポレートサイトのドメインです。名刺データを含む自社保有データの統合手順については名刺管理ツールと営業リストの連携で具体的に扱っています。
ここで押さえておきたいのは、重複排除が「見た目をきれいにする作業」ではないという点です。重複が残ったリストでは、接点履歴のある1行と、履歴のない1行が別企業として扱われます。結果として、送信前チェックをすり抜けてしまいます。
営業リストの作成工程|準備から送信前までの5工程
営業リストの作成は、次の5工程に整理できます。1〜4は多くの解説で扱われる範囲ですが、本記事では5番目の「送信前チェック」を独立した工程として置きます。
5工程の全体像と各工程の成果物
工程 | やること | この工程の成果物 |
|---|---|---|
1. 目的定義 | 誰に何を提案し、どの反応を次のステップとするかを決める | 目的と、アプローチ後に期待する反応の定義 |
2. ターゲット定義 | 業種・規模・エリア・課題仮説などの条件を具体化する | 絞り込み条件のセット(ターゲットリストの定義) |
3. 情報収集 | 定めた条件に合う企業情報を、4つの経路から集める | 条件に合致した企業の一覧(項目付き) |
4. 精査 | 重複排除・表記統一・失効データの整理を行う | 1企業1行に整理され、項目がそろったリスト |
5. 送信前チェック | 送信対象から外すべき企業を特定し、除外する | 送信可否が判定済みのアタックリスト |
工程を分けておく利点は、「どこで止まっているか」が分かることです。反応が悪いとき、原因が条件設定(工程2)にあるのか、データの鮮度(工程3・4)にあるのか、そもそも送ってはいけない相手に当たっている(工程5)のかで、打つ手はまったく違います。
工程1の目的定義は省略されやすい工程ですが、ここが曖昧だと工程2の条件が決まりません。「商談を作る」のか「資料請求を得る」のかで、狙う企業の規模も担当部署も変わります。
工程2のターゲット定義の具体的な組み立て方は営業リストのターゲティング設計、工程3で使う作成手段の比較は営業リスト作成ツール比較、工程4の具体的な手順は営業リストのデータクレンジングでそれぞれ扱っています。本記事では工程の位置づけの説明に留めます。
質の高い営業リストの条件|精度を測る3つの見方
「質の高い営業リスト」は抽象的な言葉ですが、測る軸を3つに分けると自己診断ができます。
1. 項目の充足率:アプローチの実行に必要な項目が、何割の行で埋まっているか。フォーム営業であれば、フォーム URL が埋まっていない行は実行できません。全件の平均ではなく「実行できる行が何件あるか」で数えます。
2. 情報の鮮度:各行の情報が、いつ時点で確認されたものか。確認日の列を持つかどうかで、この指標は測れるようになります。確認日がないリストは、古さを評価する手段を持たないリストです。
3. 送信可否の判定済み率:全体のうち、「送ってよい」または「送らない」と判断できている行が何割あるか。判定していない行は、実質的に送信対象にできません。
3つのうち、多くのリストで最も低くなるのが3番目です。そして3番目は、新しい企業情報を集めても改善しません。改善するのは、自社の接点データとの突合と、除外基準の整備だけです。この点が、本記事で送信前チェックを独立した工程として扱う理由です。
工程を回す頻度と担当の決め方
5工程は一度通せば終わりではありません。ただし、すべてを同じ頻度で回す必要もありません。工程ごとに頻度と担当を分けておくと、運用が続きやすくなります。
工程 | 見直しの頻度の目安 | 担当の置き方 |
|---|---|---|
1. 目的定義 | 四半期ごと、または提案内容の変更時 | 営業責任者 |
2. ターゲット定義 | 四半期ごと、または反応率の変化時 | 営業責任者 |
3. 情報収集 | 継続的(補充) | 担当者またはツール |
4. 精査 | 月次、または経路をまたぐデータを追加したとき | 担当者(手順を文書化) |
5. 送信前チェック | 送信のたび | 担当者 + 判断基準の管理者 |
ポイントは、工程5だけが「送信のたび」である点です。他の工程は定期的な見直しで足りますが、送信前チェックは送信という行為と一体です。チェックの頻度を月次に落とすと、月の途中で発生した接点が反映されません。
送信前に営業リストで確認する観点|フォーム営業で外すべき企業

ここからが本記事の中心です。送信対象から外すべき企業は一種類ではありません。外す理由が違えば、判断に使うデータも、判断する人も変わります。まずは4種類に分けて整理します。
外す理由が異なる4種類の企業と、判断に使うデータ
外す対象 | 外す理由 | 判断に使うデータ | 判断する人 |
|---|---|---|---|
すでに取引のある企業 | 新規提案が既存の関係と矛盾する。担当者の信頼を損なう | 自社の取引先台帳、CRM / SFA の顧客レコード、請求データ | 営業責任者(基準を定義)、担当者(突合) |
他社(取引先・別チャネル)が接触済みの企業 | アプローチが重複し、相手に混乱を与える。取引先との関係にも影響する | パートナー側から共有される接触済み企業の情報、別チャネルの送信履歴 | 営業責任者(共有ルールの合意)、担当者(突合) |
営業目的での利用を断っている相手 | 受信側が明示している意思に反する | フォーム上の注記(営業目的での利用を断る記載)、過去の送信停止依頼 | 担当者(送信前に確認)、責任者(記録の管理) |
情報が古く送信先として成立しない企業 | 届かない、あるいは誤った宛先に届く | 情報の確認日、サイトの到達性、フォームの稼働状況 | 担当者(精査工程で検出) |
この表で確認したいのは、1行目と2行目のデータが「リストの中」にはないという点です。取引先台帳は経理や既存営業が持ち、他社の接触済み情報はパートナー側が持っています。つまり送信前チェックは、営業リスト単体を眺めても完了しません。外部のデータと突き合わせる工程として設計する必要があります。
3行目の「営業目的での利用を断っている相手」は、見落とされやすい一方で、事故の影響が大きい分類です。フォーム上に営業目的での利用を断る記載がある場合、それは受信側の明示的な意思表示です。送信前に確認する項目として、リストの中に「注記の有無」を持たせておくと判断が属人化しません。
なお、完全な自動送信ができないフォーム(CAPTCHA が設置されているフォームなど)は、この4分類とは別の論点です。送信対象から外すかどうかではなく、どの方式で送るかという実行方式の話になるため、次の小見出しで扱います。
除外対象のカテゴリ分類と、除外リストそのものの更新運用についてはフォーム営業の送信除外リストで詳しく扱っています。本記事では、どの工程でどのデータを見るかという枠組みに留めます。
フォーム営業リストでの扱い|CAPTCHA を突破しない前提とセミオートの線引き
フォーム営業を前提に営業リストを運用する場合、送信の実行方式について1つの線引きを決めておく必要があります。CAPTCHA(画像認証やチェックボックス認証)が設置されているフォームをどう扱うか、という論点です。
秋霜堂株式会社が提供する Form Pilot では、CAPTCHA を「機械的な送信を受けたくない」という受信側の意思表示と捉え、これを技術的に突破しない設計としています。CAPTCHA を迂回して送信することは、受信企業の意思に反する行為を、送信元である自社の名前で行うことになるという考え方です。
そのうえで、CAPTCHA などで完全な自動送信ができないフォームでは、Chrome 拡張機能が入力までを自動化し、送信ボタンは人が押します。入力の手間は仕組みで減らしつつ、送信という最終判断は人が担うセミオートの線引きです。送信対象から外すのではなく、送信方式を分けて扱う点が、前述の4分類との違いになります。
営業リストの設計上、この線引きは項目に反映されます。フォームごとに「完全自動で送信できるか / 入力自動化までで人の操作が必要か / 送信対象にしないか」を区別できる状態にしておくと、送信作業の計画が立てられます。逆にこの区別がないリストでは、送信のたびに個別に判断することになり、担当者による判断のばらつきが生じます。
判断できない相手は送らないという考え方
4分類のチェックを設計しても、実務では「判断がつかない企業」が必ず残ります。取引先台帳の表記と一致しないが同一企業かもしれない、グループ会社のどこかが接触しているかもしれない、といったケースです。
このときの扱い方は2つしかありません。「判断がつかないなら送る」か、「判断がつかないなら送らない」かです。本記事が推奨するのは後者で、安全側に倒す考え方(fail-closed)を基本とする設計です。
後者を基本とする理由は、誤りのコストが非対称であることです。送ってよい相手に送らなかった場合の損失は、その1件の機会損失にとどまります。一方、送ってはいけない相手に送った場合は、取引先との関係、社内での信頼、相手企業との今後の可能性に影響が及びます。回復に必要な工数も、前者とは比較になりません。
Form Pilot も、他社(取引先・別チャネル)がすでに接触済みの企業ドメイン一覧を外部 API から取得して送信リストと突合し、該当する企業への送信を自動で回避する仕組みを備えています。判断できない場合には安全側に倒すことを基本とする設計です。
ただし、仕組みの有無にかかわらず、運用として先に決めておくべきことがあります。「判断がつかない」と分類された行を、誰がいつ再判定するのかです。保留のまま放置すれば、その行は永久に使えません。保留分を定期的に棚卸しする担当と頻度を決めておくと、安全側に倒しても機会が目減りしません。
営業リストの管理・運用で崩れやすい3つの点

除外基準を一度決めても、運用が崩れれば誤送信は再発します。整備したリストが半年後に使えなくなる典型的なパターンは3つあり、それぞれ原因が異なります。
更新が止まる|営業リストの更新サイクルを階層化して分ける
更新が止まる最大の原因は、更新作業が「リスト全体を見直す大仕事」として設計されていることです。全件を一度に見直す設計では、着手のハードルが高く、忙しい月に飛ばされ、そのまま戻らなくなります。
対策は、更新の対象を項目の性質で階層化することです。
階層 | 対象項目 | 更新の契機 |
|---|---|---|
送信のたび | 送信可否ステータス、送信履歴 | アプローチの実行時 |
月次 | フォーム URL の到達性、担当部署、接点履歴の反映 | 定例作業として固定 |
四半期 | 従業員規模、事業内容、ターゲット条件との適合 | ターゲット定義の見直しと同時 |
階層化すると、毎回の作業量が小さくなり、飛ばしても次の周期で回復できます。また、どの層が止まっているかを特定できるため、原因の切り分けもしやすくなります。
スプレッドシートで管理している場合、更新の手間が増えるにつれて限界が見えてきます。どの時点で管理方法の変更を検討すべきかは営業リストのスプレッドシート管理で整理しています。
担当者に依存する|判断基準をリストの外に出す
2つ目の崩れ方は、判断が人の頭の中にある状態です。「この会社は社長が知り合いだから送らない」「ここは前に断られた」といった情報が担当者の記憶にしかない場合、担当者が替わった瞬間に判断が失われます。
対策は、判断の結果ではなく判断の基準を、リストとは別のドキュメントとして持つことです。リストには「送らない」というステータスと、その理由コード(取引先 / 接触済み / 送信停止依頼 / 情報不足など)だけを入れ、理由コードの定義と判断手順は別途管理します。
この分離には2つの効果があります。1つは、担当者が替わっても同じ基準で判定できること。もう1つは、基準を変更したときに、過去の判定を再評価する対象を特定できることです。理由コードが入っていれば、「接触済みで外した行」だけを抽出して見直せます。
属人化の解消を具体的にどう設計するかは営業リスト属人化対策で扱っています。
セグメントが曖昧になる|送信可否をステータスで持つ
3つ目は、リストの中で「今どういう状態の行なのか」が分からなくなることです。送信済み・未送信・保留・除外が同じシートに混在し、行の色やコメントで区別されている状態がこれに当たります。
対策は、送信可否を自由記述やセルの色ではなく、選択肢の決まったステータス列として持つことです。たとえば次のような粒度です。
- 未判定(送信可否を判断していない)
- 送信可(判定済み・未送信)
- 送信済み(日付と文面のバージョンを併記)
- 保留(判断がつかない。再判定の対象)
- 除外(理由コードを併記)
ステータスで持つことの利点は、抽出条件として使えることです。「送信可かつ未送信」を抽出すれば、そのまま今週のアタックリストになります。色やコメントでは、この抽出ができません。
ステータス設計とセグメントの切り方は営業リストのセグメント管理で詳しく扱っています。
営業リストの論点別ガイド|次に読む記事
営業リストの課題は、「作る」「整える」「送る前に外す」のどの段階にあるかで対処が変わります。自社の状況に近い悩みから、該当する記事をご覧ください。
営業リストを作る段階の論点
まだ使えるリストが手元にない、あるいは条件の絞り込みから見直したい段階です。
自社の悩み | 参照先 |
|---|---|
狙う層の条件が決められない・反応率が条件設定のせいかを確かめたい | |
手作業での収集が追いつかず、作成手段を比較したい | |
外部の企業データベースを使うべきか、どう選ぶかを判断したい | |
データベースから取ったリストを実際のアプローチに組み込みたい | |
社内に溜まった名刺データをリストに統合したい |
営業リストを整える段階の論点
リストはあるが、重複・古さ・属人化で使い切れていない段階です。
自社の悩み | 参照先 |
|---|---|
重複と表記ゆれ、古いデータの整理手順を知りたい | |
送信可否や進捗のステータス設計を決めたい | |
スプレッドシート管理の限界と、移行の判断時期を知りたい | |
担当者交代でリストが使えなくなる状態を解消したい |
送信前に外す段階の論点
リストは整ったが、送信先の判断基準が決まっていない段階です。
自社の悩み | 参照先 |
|---|---|
送信除外のカテゴリ分類と、除外リストの更新運用を設計したい |
まとめ|営業リストで次に着手する1手
本記事で扱った内容を1行でまとめます。営業リストの改善は「増やす」ことから始めるのではなく、「送ってよい相手を判断し切れる状態にする」ことから始めると、成果と信頼の両方を守りやすくなります。
手元のリストに送信可否のステータスがない場合は、そこを足すことが次の1手になります。ステータス列を1つ追加し、既存の行を「未判定」で埋めるだけでも、何件が判断済みで何件が未判断なのかが数えられる状態になります。そこから先は、判断に必要なデータ(取引先台帳・他チャネルの接触履歴・フォーム上の注記)をどこから引くかを決め、送信のたびに参照する運用へつなげていくことになります。
関連情報
送信先の選定と除外運用を仕組みとして整えたうえでフォーム営業を進めたい方は、Form Pilot のサービスページをご覧ください。CAPTCHA を突破しないセミオート送信と、他社が接触済みの企業を送信前に除外する設計について記載しています。
営業リストの整備や、送信可否の判断基準づくりの進め方からご相談されたい場合は、お問い合わせフォーム よりご連絡ください。
よくある質問
- 引き継いだ営業リストは、まず何を測れば状態が分かりますか?
実行できる行の数、各行の情報の確認日、送信可否を判定済みの行の割合の3点を数えてください。件数よりも、判定済みの行がどれだけあるかが、そのリストの実質的な規模を表します。
- 取引先台帳や他社の接触履歴は、どう突き合わせれば送ってよいと言えますか?
自社の取引先台帳、CRM / SFA の顧客レコード、別チャネルの送信履歴、パートナーから共有された接触済み企業の4つを確認します。商号は表記ゆれがあるため、法人番号かドメインを鍵に突合するのが安定します。
- 同じ企業かどうか判断がつかない行は、送ってもよいですか?
送らずに「保留」とするのが基本です。誤送信は取引先や社内の信頼に響く一方、見送った損失は1件の機会損失で済みます。ただし保留分を再判定する担当者と頻度を決めておかないと、その行は使えないまま残ります。
- 送信前チェックは、月次の見直しにまとめてもよいですか?
まとめず、送信のたびに行ってください。月次にすると月の途中で生じた商談や接触が反映されず、除外すべき企業に送る恐れがあります。目的やターゲットの定義は、四半期や月次の見直しで足ります。
- フォームに営業お断りの記載があるときは、リストでどう扱えばよいですか?
受信側の明示的な意思表示なので、送信対象から外して理由コードを付けて記録します。リストに「注記の有無」の項目を持たせておくと、担当者が替わっても同じ基準で判断でき、判断が属人化することを防げます。



