CRM一元管理で、営業の次の一手を見えるように

答えは、段階ごとの件数に加えて、最終接触日、次の行動、期限、担当者を同じレコードに持たせることである。

CRMは顧客情報、接点、商談履歴を一つに置く仕組みで、一元管理はその入力元と項目の定義を揃えることを指す。フォームからCRM、CRMから会議資料へと転記する運用では、同じ相手の重複、古い提出内容、更新漏れを人が毎回確かめる。集計の定義も担当者ごとにずれる。件数だけの画面では「商談中が何件」までしか分からない。

表の下二段が、次の一手を決める情報である。上二段だけの画面は状況の報告には使えるが、会議で「では誰が動くか」を決める材料にならない。

段階に入る条件も先に文章で決める。「商談中」が初回面談の後を指すのか、提案書を送った後を指すのかが担当者ごとに違うと、件数は比べられない。条件を文章で揃えてから画面を作る順序を守ると、画面の数字を疑う時間が減る。

答えは、共通の識別キーで入力元を統合し、採用しなかった行の根拠を残すことである。

複数の入力元には、同じ相手が別の内容で提出した行、識別キーが空の行、内部のテスト行が混ざる。どれを採用するかの判定を先に決めないと、画面の数字は取込のたびに揺れる。判定を決めれば、書き込む件数と書き込まない件数の両方に根拠が残る。

当社が支援した例を一つ挙げる。イベント運営会社（企業名非公開）のスタートアップ支援プログラムで、応募フォーム3種を連携した表計算3件、計472行（ヘッダ除く）を扱った。

判定を先に決めていたため、書き込みは84件で済み、書かなかった30件も根拠つきで残った。同じ成果物を手作業で作る場合の想定は17〜23時間（推定）、実所要は1〜2時間（概算）で、削減率は約90%と推定している。この比較は対照実験ではなく、数字単独では効果量の証明にならない。件数や難しさが違う仕事に同じ削減率を当てはめることもできない。

応募者の氏名、企業名、連絡先は集計値以外いっさい扱っていない。一元管理の目的は個人情報を集めることではなく、判断に要る項目を揃えることである。

答えは、各案件に「到達済みの段階」を複数選択で全部持たせ、到達以上の累計で棒グラフを並べることである。

CRMの標準の棒グラフは「今その段階にいる件数」しか数えられない。段階を「書類審査」から「面談」に動かすと、書類審査の棒からその案件は消える。これでは「書類審査まで到達した件数」が出ず、移行率が計算できない。

到達タグを使うと、面談に進んだ案件は「書類審査」と「面談」の両方のタグを持つ。棒グラフは到達件数の階段になり、隣り合う棒の比が移行率になる。営業なら「初回面談」「提案」「見積」「受注」を到達タグにすれば、どの工程で落ちているかが同じ画面で読める。

このパターンには二重管理の弱点がある。担当者が段階を動かしたとき、到達タグが追随しないとずれる。対策は、全行を再計算して再タグ付けする処理を用意し、更新のたびに走らせることである。人が一件ずつタグを付け直す運用にすると、ずれは戻ってくる。

除外（辞退、お断り、空）は漏斗の外に出す。漏斗の中に残すと到達件数の分母が膨らみ、移行率が実態より低く見える。

答えは、会議の議題を「通常より長く止まっている案件」に絞り、担当者が次の連絡日をその場で決めることである。

画面ができても、会議が状況の読み上げで終わると次の一手は出ない。見る順番を固定する。

1. 滞留期間が長い順に案件を並べ、上から止まっている理由を確認する。
2. 理由が相手側にあるなら次の連絡日を、自社側にあるなら担当者と期限を決める。
3. 決めた行動と期限をレコードに書き、次回の会議で「やったか」から始める。

画面には最終更新時点も出す。入力時に反映するのか、定期的に同期するのかで、見ている数字がいつの情報かが変わる。更新が「成功した」という応答だけを信じず、保存先の件数と主要な項目を突き合わせてから会議に出す。画面の目的は報告ではなく、次の連絡日を決めることである。

明日からやることは3つで足りる。「商談中」など各段階に入る条件を文章で書く。案件ごとに最終接触日、次の行動、期限、担当者の4項目があるか確かめる。次の会議を、滞留期間が長い案件から始める。転記と確認の工程の分け方はAI導入を業務に定着させる方法、代表が営業から離れられる体制は少人数で回る営業体制のつくり方で扱っている。