リードステータスだけで成約まで追う設計｜商談を使わない判断と実データで見直したチェックリスト

リードステータスとは、見込み客（リード）への対応がどこまで進んだかを示す、CRMの選択項目のことです。見込み客とは、問い合わせや資料請求などで接点ができたものの、まだ取引に至っていない相手を指します。多くのCRMは、見込み客を有望と判断したら「商談」に変換し、そこから先は商談のステージで成約まで追う設計になっています。

ところが、問い合わせの件数が多くない会社では、この変換の一手間が運用を止める原因になることがあります。この記事では、建築設計事務所（特定用途の施設設計に特化）のCRMの設計を見直した事例をもとに、「商談を使わず、見込み客だけで成約まで管理する」と決めた理由と、そのときのステータスの持ち方を解説します。設定はお客様の確認を経て進めている段階のため、運用の成果ではなく、設計の判断と、実データを読んで分かったことを書きます。

運用を決める前に、CRMの実データを読んだら何が分かったのですか？

運用の方針は、定例の打ち合わせで先に合意していました。「見込み客が作成されたら社内に通知し、当日中に有効か無効かを判定する」「進捗は週1回の定例で更新する」「ステータスは細かく分けすぎない」の3つです。方針自体は妥当です。

そのうえで、本番のCRMのデータを読み取り（設定は変えずに）、方針が今の設定で動くかを確かめました。2026年10月1日時点で分かったのは次のことです。

見たところ	状態	何が問題か
見込み客のステータス	千件を超える見込み客のすべてが空欄	フォームから作成されても「未対応」が入らない。「未対応の件数でアラートを出す」前提が成り立たない
ステータスの選択肢	「無効」と「対象外」が重複。英語の初期値が残っている	どちらを選ぶかで人によって判断が割れる
見込み客の流入元を入れる標準項目	ほぼ全件が空欄	流入は別に用意した流入情報の項目で持つため、この項目は使わないと判断
商談	0件	変換の運用がそもそも始まっていない
作成時の通知	お客様あてのお礼メールのコピーが社内にも届くだけ	「判定してください」という依頼がない。資料ダウンロードは差し込み項目がなく、誰がダウンロードしたか分からない
ステータスの変更日	記録されていない	「眠っている案件を見えるようにする」ができない

打ち合わせで決めた運用は、どれも「ステータスに値が入っている」ことを前提にしています。ところが実際は1件も入っていませんでした。会議で決めたことと、CRMの中身を突き合わせる工程を挟まなければ、気づかないまま運用を始めていたはずです。

もう1つ見つかったのが、編集時に動くお礼メールの設定です。見込み客の種類を示すタグが付け直されると、同じお礼メールがお客様に再送される可能性がありました。残す理由がなければ止めます。

リードと商談はどう違い、なぜ商談を使わないと決めたのですか？

CRMでのリードと商談の違いは、記録の単位です。リードは「接点ができた相手」1人（1社）につき1件、商談は「1つの案件」につき1件で、金額や完了予定日を持ちます。当初（2026年9月）の運用案は、一般的な形でした。見込み客のステータスで有効・無効を判定し、話が進んだら「商談に変換」して、商談の件数を数える。ところが実データを見ると、商談は0件で、変換の操作は一度も行われていませんでした。

打ち合わせで改めて話し合い、次の理由から、商談は使わず見込み客のレコードで最後まで追うと決めました。

1. 操作が増える：変換すると見込み客が取引先・連絡先・商談に分かれ、どこを見ればよいかが増える。週1回の定例で更新する運用には重い
2. 定例の合意と合う：打ち合わせで「見込み客のステータスを増やし、定例で更新する」と既に合意していた
3. 今は必要がない：案件ごとの金額や完了予定日の集計も、1社で複数案件を並行して追う場面も、今はない

逆に言えば、この3つ目が変わったら見直します。金額・完了予定日を管理したくなったとき、または1社と複数の案件を並行するようになったときが、商談を使い始める合図です。判断の条件を書き残しておくと、半年後に「なぜ商談を使っていないのか」で迷いません。

失注の扱いの考え方は失注分析の始め方で、項目を増やさない考え方は入力最小主義のCRM項目設計で詳しく解説しています。

リードステータスは、どう持つことにしたのですか？

見込み客のステータスに「商談中」「見積もり提示中」「成約」を足し、次の8つで始めることにしました。

順	ステータス	意味	誰が・いつ
0	未対応	作成直後。判定待ち	自動（作成時）
1	対応予定（有効）	有効と判定。連絡する	判定する人（作成された当日中）
2	対応中	初回連絡済み	担当者
3	商談中	初回の打ち合わせ後、相談が続いている	担当者（週1回の定例で更新）
4	見積もり提示中	見積もりを出し、返事待ち	担当者（同上）
5	成約	契約	担当者
5	失注	見送り	担当者
—	対象外	営業・求人・取材・いたずら・重複など	判定する人

あわせて、次の整理をします。

• 「無効」は「対象外」に統合する（お客様の確認後）
• 使われていない英語の初期値は、画面に出さない
• 選択肢を変えるときは、システム内部の値を変えず、表示名だけを変える（過去のデータや自動処理が内部の値を参照しているため）
• 案件の全体像は、ステータスを列にしたカンバン（ボードのように列で並べる画面）で見る

「有効」の判定の目安は、①相手の組織が特定できる、②具体的な検討事項がある、③連絡先が本物である、の3つが揃うことです。運用案の段階では、最も大事な数字を「当月に有効と判定した件数」とし、判定した日で数えることにしていました。問い合わせの総数ではなく、本物の相談の数を追うためです。

ステータスは、見込み客がどこまで進んだかを表します。これとは別に、見込み客を確度で分けて配信の文面を変えるやり方は、リードスコアリングを点数でなくS/A/B/Cの4段階でで紹介しています。

止まっている案件は、どう見つけるのですか？

見込み客に「ステータス更新日」という日付の項目を足し、ステータスが変わったときに自動で当日を入れます。人に入力してもらう項目ではありません。

ダッシュボードのアラートは、次の2つだけにしました（商談が止まる構造そのものは既存顧客の引き合い管理がCRMから漏れる理由で扱っています）。

1. 「未対応」のまま3営業日を超えたもの
2. ステータス更新日から14日以上たったもの

「次のアクションの期限」のように、人が入力して初めて意味を持つ項目は、アラートの条件に使わないことにしました。入力が抜けた案件ほど止まりやすいのに、期限が空欄だとアラートにも引っかからないからです。自動で入る日付だけを条件にすれば、入力の抜けがあっても止まった案件は見つかります。

社内の通知と「対象外」は、どう扱うのですか？

社内に届いていたのは、お客様あてのお礼メールのコピーでした。お問い合わせなら内容は読めますが、「判定してください」という依頼ではなく、CRMへのリンクもありません。資料ダウンロードや電話の問い合わせは、そもそも分かりませんでした。

そこで、判定を依頼する社内通知を別に作ります。問い合わせへの初動を速くする考え方はSpeed to Leadとはで詳しく解説しています。

• 宛先：判定する人と、その代理
• 内容：問い合わせの種類（フォームか資料ダウンロードか電話か）、会社名と氏名、最初に来た経路、CRMのレコードへのリンク
• 対象：お問い合わせだけでなく、資料ダウンロードと電話の分も

お礼メールの社内コピーは、判定依頼の通知ができた後に、外すか残すかを決めます。

「対象外」は、理由を選択式で残します（営業・売り込み／求人・採用応募／取材・学生／いたずら・スパム／重複／その他）。対象外は流入の分析から外しますが、件数は数えます。営業の売り込みが混ざったまま「どこから問い合わせが来たか」を見ると、どのページや媒体が本当に効いているのかが分からなくなるためです。

見込み客だけで管理する前のチェックリスト

最後に、同じ判断をするときに確かめる項目をまとめます。

1. 1社につき、並行して進む案件はほぼ1つか
2. 案件ごとの金額や完了予定日を、今すぐ集計する必要はないか
3. 商談への変換は、実際に使われているか（使われていない件数を数えたか）
4. 見込み客の作成時に、ステータスの初期値が自動で入るか（空欄の件数を数えたか）
5. ステータスの選択肢に、意味が重なるものや使われていないものが残っていないか
6. 選択肢を整理するとき、内部の値を変えずに済むか
7. ステータスが変わった日が自動で記録されるか
8. アラートの条件が、人の入力に頼らない項目だけでできているか
9. 判定を依頼する社内通知があり、フォーム以外（資料ダウンロード・電話）の分も届くか
10. 編集時に、お客様あてのメールが再送される設定が残っていないか
11. 対象外の理由を選んで残し、流入の分析から外せるか
12. 商談を使い始める条件（金額の管理、案件の並行）を書き残したか

1〜3は「商談を使わない」と決めてよいかの確認、4以降は見込み客だけで回すための準備です。運用の方針は打ち合わせで決まりますが、それが動くかどうかはCRMの中身を読まないと分かりません。方針を決めたら、一度実データと突き合わせることをおすすめします。

ステータス設計の見直しを一緒に進める支援は、受注プロセス管理で行っています。

よくある質問

見込み客だけで管理すると、どんなときに困りますか？

主に2つです。1つは、案件ごとの金額や完了予定日を集計したくなったとき。もう1つは、同じお客様と複数の案件を並行して進めるようになったときです。見込み客のレコードは1人（1社）に1つなので、案件を分けて持てません。どちらかが必要になった時点で、商談の利用を改めて検討します。最初からそこまで見越して作り込むより、必要になってから足す方が運用は続きます。

過去に溜まった見込み客のステータスは、全部埋め直すべきですか？

最初から全件を埋め直す必要はありません。今回の設計でも、まず今後作成される見込み客に「未対応」が自動で入るようにし、過去分の扱いはお客様と相談して決める順番にしました。過去分には名簿の取り込みなど、問い合わせとは性質の違うものが混ざっていることがあります。一括で同じ値を入れると、かえって数字が意味を失います。

「有効」かどうかは、どう判定すればよいですか？

判定の目安を、誰が見ても同じ結論になる程度まで言葉にしておきます。今回の運用案では、①相手の組織が特定できる、②具体的な検討事項がある、③連絡先が本物である、の3つが揃えば有効としていました。判定は見込み客が作成された当日中とし、判定する人と代理を決めておきます。未対応のまま3営業日を超えたものは、アラートで拾います。

リードステータスは何個くらいがよいですか？

今回は、未対応・対応予定（有効）・対応中・商談中・見積もり提示中・成約・失注・対象外の8つで始めました。細かく分けすぎず、運用しながら足すことを前提にしています。使われていない選択肢や、意味が重なる選択肢は、残しておくと入力の迷いになるので整理します。