工務店・ハウスメーカーのCRM入力定着 営業の負担を増やさない見直し

本記事に登場する「工務店例018」は、CRM定着の見直し方を説明するための架空の工務店です。実在する企業の運用や成果を示すものではありません。数値も試行条件を比較するための例であり、そのまま自社の目標値にはしません。

この記事で扱うのは、導入済みCRMについて、入力の契機、周辺業務との重複、管理者の使い方、例外時の扱いを見直す順序です。製品の比較、権限、検索、移行、解約時の確認は工務店のCRMの選び方｜入力項目・検索・権限・移行を実務で比較する、初期項目の設計は工務店の顧客管理項目｜最初に必要な記録を絞るで扱います。

また、本記事では案件ステータスや次回行動の設計を独自に作り直しません。案件ステータスはCRMステータスの9区分と移動条件を定めた記事を正本とし、担当・期限・完了証拠を含む次回行動の詳しい作り方は工務店の次回行動管理｜担当・期限・完了証拠をそろえる実務設計へ委ねます。本記事は、それらを営業活動のどの時点で入力し、管理者がどう利用すれば定着しやすいかに絞ります。

01.定着をログイン回数や空欄の少なさで判定しない

CRMの定着とは、営業担当者が毎日画面を開くことではありません。必要な判断の前に、必要な情報が、決めた場所へ、利用できる状態で残っていることです。訪問や問い合わせのない日に入力がなくても、業務上の支障はありません。反対に、毎日ログインしていても、商談結果が自由記述だけで、現在地や次に確認すべきことを読み取れなければ、記録は管理に使えません。

定着を判断するときは、次の四つを確認します。

1. 次の担当者が、営業本人へ聞かずに必要な引き継ぎを受けられるか 2. 店長が、確認すべき案件をCRMから抽出できるか 3. 顧客との約束や社内依頼が、記録の遅れによって止まらないか 4. CRMへの入力によって、日報、表計算、チャット、口頭報告のいずれかを減らせたか

「入力率100％」を単独の目標にすると、空欄を埋めるための仮入力が増えます。次回予定が決まっていないのに便宜的な日付を置く、確認していない予算を推測で入れる、選択肢が分からないため一律に同じ値を選ぶ、といった状態です。空欄が少なくても、内容を信用できなければ、確認作業はむしろ増えます。

最初に、観察した現象と推定原因を分けます。「空欄が多い」「更新が遅い」は現象であり、原因ではありません。同じ空欄でも、まだ確認できない情報、対象外の項目、入力期限が不明な項目、選択肢に該当する答えがない項目では、修正方法が異なります。

修正は一度に一つか二つへ絞ります。更新遅れ、長文入力、状態判定の不一致を同じ週にすべて変えると、何が改善や悪化に影響したか分かりません。まず具体的な案件をたどり、最も頻繁に業務を止めている原因から着手します。

02.CRMが受け持つ範囲と情報の正本を決める

工務店の営業活動では、電話、メール、チャット、カレンダー、紙のヒアリングシート、見積ソフト、図面管理、施工管理システムなどが併用されます。すべてをCRMへ複製すれば、転記と不一致が増えます。一方、どこにも要点を集めなければ、担当者以外は案件の現在地を判断できません。

CRMへ残す候補は、一般に次の情報です。

• 顧客と案件を識別するための情報
• 正本記事の区分に沿った現在の案件ステータス
• 直近の接触で決まったことと保留になったこと
• 次に確認または実行すべき事項への参照
• 見積書、図面、メールなど、別の正本を確認するための保存先
• 連絡停止や希望する連絡方法など、接触判断に必要な情報

CRMが正本でない資料は、全文を転記しません。たとえば、詳細見積の明細を見積ソフトで管理するなら、CRMには提出日、提出した版、判断に必要な総額、見積書の参照先を記録します。明細を両方で編集できる状態にすると、どちらが最新かを確認する作業が生まれます。

メールが正本であっても、添付やリンクだけでは一覧判断に使えない場合があります。「土地売却の結果が出るまで検討を中断し、11月以降の連絡を希望した」という事実が接触時期を変えるなら、その要点はCRMへ残します。ただし、これを独自の案件ステータスとして追加せず、正本の9区分、待機理由、再確認日、連絡条件をそれぞれ所定の項目へ記録します。

情報単位ごとの正本を、次のように決めます。

正本は、製品単位ではなく情報単位で決めます。「CRMがすべての正本」と一括指定すると、図面や見積書まで転記する運用になりがちです。反対に「メールが原本だからCRMには何も書かない」とすると、管理者が案件ごとに受信箱を開かなければなりません。必要なのは、原資料の保存先と、一覧判断に使う要点の役割分担です。

現在の重複を調べるときは、営業担当者へ新しい日報を書かせません。実際の案件を三件程度選び、問い合わせ発生から次の社内処理までに開いた道具、書いた内容、連絡した相手を一緒にたどります。「商談結果をCRMへ入力した後、日報へ要約し、店長へチャットし、会議用表計算へ転記した」という流れが見つかれば、CRM画面の数秒を削るより、周辺の重複を廃止するほうが効果は大きくなります。

03.入力負担を項目数ではなく五つの作業へ分ける

CRM入力の負担は、表示される項目数だけでは決まりません。選択式が十項目あっても、意味が明確で迷わず選べれば短時間で終わります。一つの自由記述欄でも、過去のメールを探し、顧客の発言と担当者の推測を分け、上司向けに文章を整える必要があれば負担は大きくなります。

負担は「探す」「判断する」「書く」「重ねて書く」「後から直す」に分けて観察します。

計測範囲は、CRM画面を開いてから保存するまでに限定しません。入力のために過去メールを探し始めた時点から、必要な依頼や報告が終わるまでを「商談後処理」として見ます。CRM入力が一分短くなっても、別の台帳への転記が三分増えれば、総負担は悪化しています。

厳密な秒数を測る必要はありません。「一分未満」「一～三分」「三分超」の三段階でも、頻度を掛け合わせれば優先順位を判断できます。月一回の不便な操作より、商談のたびに発生する二分の転記のほうが、月間負担を大きくしている場合があります。

工務店例018では、次の判断票を使って修正候補を絞ることにします。

項目を削除する前には、会議、帳票、通知、外部連携、設計への引き継ぎで使われていないかを確かめます。営業本人が見ていない項目でも、設計担当が初回要望を確認している場合があります。利用者がいるなら、その人が必要とする情報を失わない移行方法まで決めます。

04.必須記録は節目ごとに変え、状態名を増やさない

すべての接点で同じ項目を必須にすると、まだ確認できない情報の仮入力が増えます。問い合わせ受付、初回接触、商談、見積提出では、その時点で確定できる内容が異なります。必須条件は顧客カード全体へ一律に設定せず、次工程へ渡す節目ごとに考えます。

ここでの必須記録は、顧客情報を網羅するためではなく、案件を誤った扱いにせず次工程へ渡すための最小限です。次回行動の担当・期限・完了証拠を具体化する方法は、前掲の工務店の次回行動管理｜担当・期限・完了証拠をそろえる実務設計で扱います。本記事では、次回行動そのものを再設計せず、「どの出来事を契機に登録または見直すか」だけを定めます。

正本であるcrm-statusの9区分は、「未対応」「初回対応中」「商談中」「プラン提案中」「見積提出済み」「契約」「長期保留」「失注」「終了」です。本記事では、これらの名称や移動条件を変更しません。「長期保留」は独自状態ではなく正本の案件ステータスなので、正本の移動条件に該当するときは、その名称をそのまま使用します。

一方、元の運用で使っていた「未確認」「顧客回答待ち」「自社確認中」「対象外」「要管理者確認」は、案件ステータスとして新設しません。これらは案件の営業段階ではなく、確認の進み具合、待機の理由、集計上の扱い、管理者への依頼を表そうとした名称だからです。旧運用でも「長期保留」を使っていた場合だけは、別名へ置き換えず、正本区分として扱います。

旧状態名と正本区分、補助項目の対応は次のとおりです。

「顧客回答待ち」は、案件全体の営業段階を示す名称ではありません。同じ営業段階でも、顧客が家族と相談している場合、金融機関の回答を待つ場合、営業側の説明不足を補う必要がある場合では扱いが異なります。案件ステータスを正本の区分から選んだうえで、待機理由と自社が再確認する日を記録します。顧客が一定期間の連絡停止や検討中断を明示し、正本の移動条件に該当した場合は「長期保留」へ移動します。

「要管理者確認」も恒久的な案件ステータスにはしません。移動条件を担当者が判断できないときの処理として、現在のステータスを勝手に変更せず、管理者への判定依頼を作り、回答期限を置きます。回答後は、正本の区分へ確定し、何に迷ったかを定義改善へ戻します。

「対象外」は、案件ステータスではなく集計範囲を表す場合があります。たとえば、新築追客の一覧からOB改修相談を外す必要があっても、その案件自体には正本の9区分のいずれかを設定し、別途「新築追客集計の対象外」と記録します。集計除外を理由に案件の現在地を消してはいけません。

自由記述は、完成された議事録を求めません。「決まったこと」「未決事項」「原資料の参照先」を短く分ければ、通常の引き継ぎに使えます。ただし、「検討中」「いい感じ」「見込みあり」のように、観察した事実が分からない表現は避けます。

05.入力を通知で思い出させず、業務の終了条件へ組み込む

CRM入力を独立した事務作業にすると、忙しい日に後回しになります。「時間があるときに入力する」「毎日17時にまとめて入力する」という運用は、訪問件数、直帰、急な顧客対応によって崩れます。入力の契機は時刻ではなく、問い合わせ返信、商談終了、見積送付、社内依頼、担当変更などの出来事へ結び付けます。

商談対応の終了条件は、「商談が終わったこと」ではなく、次の業務へ渡せる記録が残ったことまで含めます。ただし、次回行動の詳細な管理方法を本記事で重ねて定義せず、必要な記録先への接続を確認します。

設計担当へ先に口頭依頼し、CRM入力を後回しにすると、依頼内容と案件記録が分離します。先に要点を残してその情報を参照しながら依頼するか、依頼番号やCRMの案件番号を相互に記載します。システム連携がなくても、同じ案件識別子を使えば後から照合できます。

外出先で詳細入力が難しい場合は、二段階入力を認めても構いません。ただし、第一段階だけで次の顧客対応を誤らない情報が残ること、第二段階の完成担当と期限が決まることが条件です。「自分宛てメールを送ったから完了」とはしません。

通知は、すべての空欄へ送らず、案件停止や誤連絡につながる不足へ絞ります。たとえば、記録期限を過ぎた接触、担当未設定、判定依頼の回答期限超過などです。どの通知も、受信者が自分で処理できるか、処理後に消えるかを確認します。処理権限のない警告を毎日送り続けると、重要な通知まで見られなくなります。

予定が決まらない場合に、架空の日付を入力させてはいけません。顧客が回答する予定日と、自社が状況を再確認する日は別です。日付欄が一つしかない製品では、その欄がどちらを表すのかを固定します。両方が必要なら、項目追加だけでなく、既存の次回行動管理との重複を確かめます。

06.店長と管理者はCRMを質問の起点にする

営業担当者に入力を求めながら、店長が会議で一から口頭説明を求めると、CRMは報告作業を増やす道具になります。入力すれば会議説明や個別報告が短くなるという利益を、営業担当者が実感できる運用へ変える必要があります。

週次会議では、全案件を担当者順に読み上げません。新規受付後に動きがない案件、記録期限を過ぎた案件、ステータスが変わった案件、管理者の判定を待つ案件、連絡条件に注意が必要な案件など、確認理由のあるものを抽出します。期限超過した次回行動の処理方法は、次回行動管理の記事の定義へ従います。

管理者の質問も、広い質問から不足を特定する質問へ変えます。

入力内容で判断できなかったときは、文章量を一律に増やしません。「顧客の発言が不明」「ステータス移動の根拠が不明」「原資料の参照先が不明」「次回行動の登録要否が不明」のように不足を分類します。最も多い不足が、項目説明、入力時点、管理者の確認方法のどこに起因するかを調べます。

店長が担当者に代わって毎回修正すると、画面上の数字は整っても入力は定着しません。顧客への誤連絡を防ぐ必要がある場合など、業務上急ぐ修正は管理者が行い、変更者と理由を履歴へ残します。緊急性がなければ、不足が生じた工程へ戻し、担当者が修正できるようにします。

試行中の未入力件数を、直ちに個人評価へ結び付けないことも重要です。運用を試している段階で件数を評価に使うと、原因の報告より見かけの穴埋めが優先されます。評価へ使うかどうかは、ルールが安定した後に、対象、期間、例外、確認方法を別途決めます。

07.例外を分類し、個人情報に関わる事故時の順序を決める

CRM運用は、標準的な商談だけを想定すると崩れます。担当者の休暇、営業と設計の複数担当、長期検討、紹介案件、同一世帯の重複登録、連絡停止の希望などでは、通常と異なる判断が必要です。

例外を新しい案件ステータスとして増やす前に、「次の行動」「閲覧範囲」「集計方法」のいずれかが変わるかを確認します。変わらなければ通常項目の補足で扱い、変わる場合だけ、担当ルール、除外条件、管理者への判定手順を設けます。

顧客情報の取得、利用、閲覧、外部サービスでの保存、委託先との連携、第三者への提供に該当し得る場面は、事実関係によって必要な対応が変わります。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」は、利用目的、安全管理措置、従業者や委託先の監督、漏えい等への対応などを確認する際の一次資料です。個別の保存方法や共有が適法かどうかを本記事だけで判定せず、最新版の資料、自社の取扱状況、契約条件をそろえて責任者へ確認します。

誤送信、不正な閲覧、アカウントの不正利用、意図しない自動配信などが疑われる場合は、通常の入力改善より被害拡大の防止を優先します。現場が実行する順序を、あらかじめ次のように定めます。

1. 自動配信、共有リンク、該当アカウントなど、被害を広げ得る処理を可能な範囲で停止する 2. 独断で履歴を削除せず、発生日時、対象、操作、送信先、画面表示など確認できる事実を保全する 3. 個人情報管理責任者、情報システム担当、経営責任者など、自社で定めた連絡先へ速やかに報告する 4. CRM提供者や委託先の窓口へ、契約と社内手順に沿って連絡し、影響範囲と封じ込め方法を確認する 5. 本人への通知や個人情報保護委員会への報告が必要かを、最新の法令・ガイドラインと事実関係に基づいて責任者が判断する 6. 通常運用へ戻す前に、アクセス権、連携、自動処理、認証情報、対象データを再確認する

緊急時の現場担当者へ、法的判断まで求めません。まず拡大防止と証拠保全を行い、報告先へつなぐ手順を画面付近や社内連絡網に置きます。

08.工務店例018で四週間の試行範囲を固定する

工務店例018は、営業担当者四人と営業店長一人で、新築と大規模改修の問い合わせを扱う架空の工務店です。すでにCRMを利用していますが、商談記録を日報へ転記し、週次会議用の表計算も別に作っています。店長は会議前にCRMを手直しし、担当者へ口頭で状況を確認しています。

試行対象は、開始日以降に初回接触する新規案件と、試行中に商談または見積提出を行う進行案件の合計二十件までとします。既存の全顧客台帳、CRM製品、正本記事の9区分は変更しません。過去案件への一斉遡及入力も行いません。

試す変更は次の三つです。

• 商談後の記録を、決定事項、未決事項、ステータス変更の有無、原資料または次回行動の参照先へ絞る
• 同じ案件経過を日報へ転記する運用を停止する
• 週次会議をCRMから抽出した例外案件の確認から始める

次回行動の項目構成やステータスの9区分を同じ試行で改変すると、入力契機の改善と定義変更の影響を切り分けられません。既存定義に問題が見つかった場合は、事実を記録し、各正本記事の手順で別に見直します。

第1週は「CRMの不満」を広く募集するだけでなく、直近の一件を担当者とたどります。商談終了後に何を開き、誰へ連絡し、どこへ同じ内容を書いたかを確認します。「入力が面倒」という感想を、検索、判断、記述、転記、手戻りへ分解するためです。

第2週は、入力時間だけで合否を決めません。CRM入力が一分増えても、日報転記と店長への個別連絡が合計五分減れば、商談後処理全体では改善です。反対に、入力が短くなっても、必要な社内依頼へ接続できず案件が止まるなら採用しません。

第3週の会議前に、店長が全案件を手直ししてはいけません。記録されたまま一覧を使い、判断できなかった箇所を残します。質問を「接触結果が不明」「区分の根拠が不明」「参照先が不明」「次回行動の登録要否が不明」などに分け、翌週は最も多かった原因だけを直します。

第4週には、次回日程が決まらない案件、営業と設計が関わる案件、顧客が連絡時期を指定した案件も含めます。標準項目へ例外をすべて取り込まず、発生頻度、誤った場合の影響、通常案件の負担を比較します。

試行後の選択肢は「採用」か「中止」だけではありません。「全員へ展開する」「説明を修正して再試行する」「特定の案件種別だけ採用する」「変更を撤回する」から選びます。慣れた担当者が使えたことだけを理由に全社展開せず、他の担当者や案件種別でも同じ終了条件を使えるかを確認します。

09.定着指標は入力率ではなく停止と総負担を測る

評価には、記録の適時性、管理者の聞き直し、CRM外の転記、商談後処理の総時間を使います。次回行動の品質や実行状況を評価する場合は、次回行動管理の記事にある担当・期限・完了証拠の定義を使い、本記事独自の「次回行動設定率」は設けません。

分母を固定しない数値は比較できません。「未入力が五件」ではなく、「対象期間中に記録期限を迎えた商談四十件のうち五件」のように示します。休止案件や試行対象外案件を除くなら、除外条件を測定前に決めます。

期限内記録率を使う場合は、期限を具体化します。「当日中」だけでは、次の社内依頼が商談直後に発生する業務に間に合いません。工務店例018では、「商談後に設計依頼を出す案件は依頼前」「それ以外は当日中」のように、記録が利用される時点から逆算します。

平均時間だけで判断すると、特定の案件種別で発生する大きな負担が隠れます。平均三分でも、大規模改修だけ十五分かかるなら、通常の入力様式が合っていない可能性があります。一方、担当者一人の所要時間が長い場合も、本人の姿勢と決めつけず、権限、端末、通信環境、担当案件の複雑さを確認します。

目標値は、外部の平均をそのまま採用せず、自社の基準値と業務上許容できる状態から決めます。見直し前と試行中を比較する場合は、初回接触後、商談後、見積提出後など同じ節目に分けます。案件数や業務内容が大きく違う二週間を、単純に比較しません。

数値を良くするために、後から例外を分母から外し続けてはいけません。除外は、試行対象外、全社的なシステム停止、事前に定めた休業日などに限定します。「忙しかった」「特殊な案件だった」は、そのまま除外理由にせず、再発する運用条件かを確認します。

一つの数値だけで項目を増減しないことも重要です。期限内記録率が上がっても、仮記録が残り、会議での聞き直しが増えていれば、問題を後工程へ移しただけかもしれません。適時性、利用可能性、総負担を組み合わせて判断します。

10.全社展開後も変更窓口と撤回条件を持つ

試行した運用を全社へ広げるときは、操作説明だけで終えません。対象案件、開始日、入力の契機、最小記録、正本、例外時の相談先、旧運用の終了日を一枚にまとめます。

旧日報への案件経過の転記を廃止するなら、「当面はCRMと日報を併用」と無期限にしません。確認期間と終了日を決めます。終了できない場合は、日報を使っている人、判断、帳票を特定し、CRMから代替できるかを検討します。

全社展開時に過去データを一斉補完すると、現場負担が急増します。遡及入力は、現在進行中で引き継ぎが必要な案件、連絡条件の確認が必要な案件、管理者が判断に使う案件などへ限定します。完了済みの古い案件まで新ルールへ合わせる必要があるかは、利用目的、保存方針、既存の取扱ルールを踏まえて別に判断します。

運用ルールには、理想的な長文例より、誤りやすい境界を載せます。

• 顧客からの回答を待つ間も、案件ステータスは正本の移動条件で判定する
• 「長期保留」は独自状態へ置き換えず、正本の移動条件に該当するときに同じ名称で使用する
• 日程未定を架空の日付で埋めず、自社の再確認日と区別する
• 複数担当でも案件の主担当を一人にし、個別業務の実行者と分ける
• 区分を判断できないときは、独自状態を作らず管理者へ判定を依頼する
• 「対象外」は対象となる集計や業務を明記し、案件ステータスと分ける
• 重複候補を担当者判断で削除せず、履歴と関係を確認する
• 連絡停止の希望は、CRMだけでなく配信や自動化の対象からも外れたか確認する
• 緊急時は通常入力より拡大防止、証拠保全、責任者への報告を優先する

質問窓口は一人へ集中させません。画面操作、営業ルール、案件ステータス、次回行動、個人情報の取扱いでは、判断者が異なる場合があります。

項目追加には入口を設けます。「あると便利」という要望だけで増やさず、利用者、判断場面、入力の契機、更新責任者、既存項目では代替できない理由を確認します。一度だけ作る帳票のための項目や、誰も更新責任を持たない項目は、時間がたつほど信用できなくなります。

項目削除にも確認が必要です。画面から隠す前に、一覧、通知、帳票、外部連携、過去集計で使われていないかを調べます。過去値を保持して新規入力だけ止めるのか、別項目へ移すのか、保存方針に沿って削除するのかを決めます。担当者個人の判断で顧客情報を消去しません。

月次の見直しでは、入力率の報告だけを行わず、長期未更新、仮記録の残存、重複候補、判定依頼の滞留、使われていない項目、CRM外で復活した台帳を確認します。新しい表計算が作られた場合は、作成者を責めるのではなく、CRMでできなかった判断や出力を聞きます。そこに改善すべき要件が現れます。

運用変更は、変更日、対象者、理由、期待する効果、確認指標、判定日、撤回条件を記録します。判定日になったら、採用、修正、限定適用、撤回のいずれかを選びます。効果を確認しないまま項目や通知を積み重ねると、CRMは再び入力負担の大きい道具になります。

最終的に目指すのは、営業担当者が努力してすべての欄を埋める状態ではありません。業務の節目で必要な記録が残り、案件ステータスは正本の9区分でそろい、必要な次回行動は所定の管理方法へ接続され、店長はCRMを読んで不足だけを確認できる状態です。

CRM定着の見直しは、判断場面、情報の正本、入力の契機、業務の終了条件、管理者の利用方法、例外時の処理という順で進めます。記録を減らすこと自体を目的にせず、案件を止めない情報を残し、二重入力と聞き直しを終了することが、営業の負担を増やさずCRMを定着させる基本です。

本文では、入力の契機と管理者の使い方を見直す順番を扱いました。それでも会議で「CRMの受注件数と月次の業績表が合わない」と言われると、営業は結局両方を作り直し、CRMへの入力は再び後回しになります。この追記では、顧客データと業績データの定義をそろえる手順と、CRMの記録が実際の判断に使われる場面を一つ決める方法を扱います。工務店例018と数値はすべて架空です。案件ステータスは本文と同じく正本の9区分を使い、新しい区分は作りません。

CRMと業績表の数字がずれる原因を、指標ごとに分ける

数字が合わないとき、多くの場合どちらかが間違っているわけではありません。同じ言葉で別のものを数えています。まず指標ごとに、CRMと業績表がそれぞれ何を数えているかを並べます。

指標	CRMで起きやすい数え方	業績表で起きやすい数え方	ずれ方	そろえ方の例
受注件数	案件を「契約」へ移した日	契約の締結日、または着手金の入金日	月末の契約が翌月に回る	締結日を正本にし、CRMにも締結日の欄を置く
受注金額	見積提出時の総額のまま	契約金額に変更契約を加算	値引きや変更分だけ差が出る	契約金額を入力し、変更契約は別の記録で加算する
問い合わせ件数	フォームの送信回数	世帯または案件の数	同じ家族の再送で多く見える	世帯単位で数え、送信回数は別に集計する
事業の区分	新築・改修・点検が混在	事業別に計上	合計は合っても内訳が合わない	案件種別を入力の必須条件にする

本文02章のとおり、正本は情報単位で決めます。受注の日付と金額は契約書と会計の記録が正本で、CRMは案件の現在地と経緯の正本です。CRMを業績表の代わりにする必要はありません。必要なのは、案件番号・契約締結日・契約金額という照合の鍵を両方にそろえ、差が出たときに一件ずつ突き合わせられることです。

架空の計算例として、工務店例018の9月を見ます。CRMで「契約」へ移した案件は4件、業績表の9月受注は3件でした。照合すると、差の1件は9月30日に契約を締結し、着手金が10月2日に入金された案件でした。受注日の定義を「契約締結日」にそろえると、両方とも4件になります。

指標の定義表を一枚作り、埋まらない欄は使わない

定義表は営業責任者と経理担当が一緒に作ります。空欄の雛形には、左から「指標名」「数える対象（分子）」「割る対象（分母、率の場合）」「期間と締め日」「正本」「CRMの項目名」「照合する担当」の七列を置きます。

最初に指標名だけを並べ、残りの欄を埋めていきます。会議で毎月話しているのに「正本」や「照合する担当」が埋まらない指標は、誰も責任を持っていない数字です。いったん会議資料から外し、必要なら定義を決めてから戻します。

工務店例018の記入例は次のとおりです。

指標名	数える対象	期間と締め日	正本	CRMの項目名	照合する担当
新築受注件数	契約を締結した新築案件	毎月末日、締結日基準	契約書台帳	契約締結日	経理担当
新築受注金額	当初の契約金額（税込）	同上	契約書台帳	契約金額	経理担当
新規相談件数	初めて相談した世帯	毎月末日、受付日基準	CRM	受付日・世帯番号	営業店長

記録が判断に使われる場面を一つ決め、入力の理由を見せる

定義をそろえても、入力した情報が何にも使われなければ定着しません。そこで「この会議では、この項目を見て、これを決める」という場面を一つ決めます。

判断の場面	使うCRMの項目	入力の締切	判断する人	結果を戻す先
月1回の着工見込み会議	「見積提出済み」の案件の提出版総額、顧客の希望着工時期	会議の前営業日の正午	工務責任者	工務の予定表
週次の案件確認	案件ステータス、自社が再確認する日	会議の前日	営業店長	次回行動の管理先
OB点検の案内作成	引渡し日、連絡の可否と方法	案内の作成前	アフター担当	点検台帳

工務店例018では、最初に一行目の着工見込み会議から試すと仮定します。営業が見積提出時に顧客の希望時期を入力すると、会議で工務の仮押さえが決まり、営業は顧客へ工期の見通しを返せます。入力の結果が自分の商談に戻ってくることが見えると、入力を求める理由を説明しやすくなります。会議の進め方は営業パイプライン管理、区分の判定は商談ステータスの定義、次に誰が何をするかは次回行動管理に従います。

図は、この追記の四つの手順を順に並べたものです。一つ目の表で「なぜ合わないか」を分け、二つ目の表で定義と責任者を決め、三つ目の表で入力が使われる場面を決めます。記事末尾の追客部の案内から相談する場合は、定義表、照合した月の差異の一覧、判断場面の表の三つを手元にそろえておくと、どの会議から試すかを具体的に話せます。

よくある質問

CRMを業績の正本にしてはいけませんか。 契約書や会計の記録と照合できる仕組みがあれば可能です。ただし一つの情報に正本は一つにします。両方で金額を編集できる状態は避けます。

営業と経理で締め日が違う場合はどうしますか。 締め日をそろえるのが基本です。そろえられない場合は、差が出る案件を毎月一覧にし、理由とともに会議資料へ添えます。

OB顧客の名簿が多すぎて手を付けられません。 点検案内など判断の場面がある範囲から始めます。OBからの相談を点検・修理・改修に分けて受ける窓口と採算の考え方はアフターメンテナンス事業の記事で扱っています。連絡の可否と利用目的の確認は顧客情報の閲覧・共有・保管の運用設計に沿って行います。

参考資料

この追記では新たな外部資料を使っていません。個人情報の取扱いに関する一次資料は、本文07章の参照先をご確認ください。社名と数値はすべて架空例です。