工務店・ハウスメーカーの商談ステータス 担当者で判定がぶれない定義

担当者による判定のぶれを止めるには、ステータス名を決めるだけでは足りません。「誰が」「どの証拠を見て」「いつ変更し」「次に何をするか」まで定義表にします。本記事では、問い合わせから受注・失注までの全体設計を扱い、最終的に自社で使える「商談ステータス定義表」（ステータスごとに一行）と「案件判定記録」（案件ごとに一件）を作ります。CRM製品の細かな比較、次回行動の詳細、失注理由の分類は隣接する実務として切り分けます。

本記事の状態名と入口・出口条件は、本シリーズの商談ステータスの正本です。項目設計を扱う顧客管理項目の記事は同じ状態名を使い、追客施策の分析区分を扱う追客KPIの記事は本記事の状態と対応づけた別軸の区分を使います。

01.商談ステータスは営業日報ではなく経営判断の共通言語

商談ステータスの役割は、案件の雰囲気を短い言葉で表すことではありません。営業担当者、設計担当者、経営者が同じ案件を見たときに、現在地と次の判断をそろえることです。

たとえば「見込み」という言葉だけでは、資料請求があった状態なのか、初回面談が終わった状態なのか、資金計画まで合意した状態なのかが分かりません。「見込み大」も同様です。担当者が受注できそうだと感じているだけなら、担当者の経験や性格によって判定が変わります。

一方、「初回面談済み」「計画条件確認済み」「提案中」のように、顧客との間で確認できた事実を中心に定義すれば、別の担当者でも同じ記録から近い判定ができます。担当者が休んだ場合にも、案件を引き継ぎやすくなります。

ステータスがそろうと、経営会議で扱う数字の意味も変わります。「商談が20件ある」という集計ではなく、「初回面談前が8件、条件確認中が6件、提案中が4件、契約手続中が2件」と把握できるからです。どこで案件が滞留しているか、誰に支援が必要か、設計部門へどの程度の案件が流れそうかを検討できます。

次の表は、ステータスと混同しやすい情報を分けたものです。

この表から読み取るべき点は、「電話した」「前向きそう」「確度A」という情報だけでは、標準工程上の現在地を決められないことです。ステータスは工程、活動履歴は事実、温度感は観測、確度は予測として分離します。

特に避けたいのが、「追客中」「対応中」「検討中」の乱用です。これらは担当者が動いていることを示しても、顧客との合意がどこまで進んだかを示しません。長期間放置されても同じ表示になりやすく、経営者から見ると案件数だけが膨らみます。

ステータス設計の最初の判断は、顧客の心理を当てることではなく、自社の仕事の区切りを定めることです。担当者の主観を完全に排除する必要はありませんが、主観は補足欄へ置き、ステータス変更そのものは確認可能な条件で行います。

02.先に一案件の単位と開始・終了地点を決める

定義づくりで最初につまずくのは、名称ではなく「何を一案件として数えるか」です。同じ人から土地相談と建替え相談を別々に受けたとき、一つの商談にまとめるのか、二つに分けるのかを決めなければ、担当者ごとに案件数が変わります。

基本単位は、「同じ検討主体が、同じ建築計画について行う一連の相談」とすると扱いやすくなります。検討主体とは名義人だけではなく、計画の意思決定に関わる夫婦や家族を含む管理上のまとまりです。建築地、建築目的、想定時期が大きく異なる場合は、同じ顧客でも案件を分ける余地があります。

たとえば、同じ顧客が自宅の新築と親世帯の所有地に建てる賃貸住宅を同時に相談しているなら、目的も条件も意思決定も異なります。これを一案件にすると、一方が止まったときに全体のステータスが判定できません。反対に、夫婦が別々に問い合わせを送っただけで、同じ土地の同じ新築計画なら、重複案件として統合するほうが実態に合います。

開始地点も明確にします。広告の閲覧者全員を商談にする必要はありません。問い合わせ、資料請求、電話、紹介受付、見学会予約など、自社が個別対応できる情報を受け取った時点を「受付」とする方法があります。ただし、匿名のウェブ閲覧まで同じ案件管理に含めると、個別商談と集計単位が混ざります。

終了地点は、受注と失注だけとは限りません。顧客から中止の意思表示があった案件、他社に決定した案件、連絡不能が一定期間続いた案件、計画時期が大きく先送りされた案件をどう扱うかが必要です。「連絡が取れないから失注」と即断すると、担当者の追客頻度によって失注率が変わります。そのため、終了理由と終了条件を別に定めます。

本記事では、説明を具体化するために、次の架空例を一貫して使います。実在する企業、顧客、成果値ではありません。

この表からは、以降の判定例が「土地未確定の注文住宅案件」という同一条件を前提にしていることを読み取ってください。自社がリフォーム、非住宅、分譲住宅を扱う場合は、工程や案件単位を別に設計する必要があります。

案件の開始から終了までの全体像は、次の順序で捉えます。

この模式図で重要なのは、活動回数ではなく、顧客と自社の間で確認された状態が前へ進むことです。括弧内は後述するステータス名です。電話を5回かけても連絡が成立し面談日程に合意していなければ、「接触中」から「面談設定済み」へ進みません。

ここまで決めてからステータス名を考えます。案件単位、開始地点、終了地点が曖昧なままでは、どれほど詳細な名称を用意しても集計は安定しません。

03.ステータス名より先に入口条件と出口条件を書く

ステータス定義で最も重要なのは、入口条件です。「そのステータスに変更してよいのは、何を確認できたときか」を文章にします。名称から意味を推測させてはいけません。

入口条件には、担当者があとから証拠を示せる事実を使います。「興味が高い」ではなく「初回面談の日程について顧客の了承を得た」、「提案が刺さった」ではなく「顧客に提案内容を説明し、質問または検討事項を記録した」と書きます。

出口条件は、現在のステータスから次へ進む条件です。入口条件と対になるように設計すると、工程間の隙間を発見できます。たとえば「条件確認中」の出口条件が「要望を聞いた」だけでは、予算や土地条件が未確認でも提案中へ進んでしまいます。自社が提案作成に必要とする最低情報を列挙すべきです。

さらに、対象外条件も必要です。同じ事実があってもステータスを進めない例を明記します。「来場予約済み」は日程合意までであり、実際の面談完了ではない、「プランをメール送付した」は説明を伴わないため提案説明済みとはしない、といった境界です。

各ステータスの定義は、次の七項目を定義表の一行として記入すると運用しやすくなります。

この表で見るべきなのは、名称が七項目のうち一つにすぎないことです。担当者の判定をそろえるのは、入口条件、証拠、対象外条件の組み合わせです。

証拠は、過度に重くしないことも大切です。面談録音や署名がなければ一切変更できない仕組みにすると、実務が止まります。日付、相手、確認内容、次回行動といった、通常業務で残せる記録を中心にします。

反対に、「担当者が確認したら変更」という定義では証拠になりません。何を確認したかが人によって変わるからです。「建築時期、建築予定地、概算予算、主要要望、意思決定者の五項目のうち、提案着手に必要な項目を記録した」のように、自社の作業開始条件へ落とします。

すべての項目を必須にすると、土地未定客や家族構成が変わる可能性のある顧客を前へ進められないことがあります。その場合は「確定」「顧客希望」「未定」「未確認」を区別して入力します。「未定」と「聞いていない」は異なります。未定でも、未定であることを双方が認識していれば、次の提案に進める場合があります。

04.進行7段階と休止・終了2区分を組み立てる

ステータスは細かいほど精密に見えますが、多すぎると担当者が選べません。活動のたびに状態が増えると、「資料送付済み」「電話済み」「メール済み」「再送済み」のような行動一覧になります。ここでは受注までの進行7段階と、長期保留・失注という休止・終了2区分を分け、経営判断に必要な差だけを残します。

椿工務店の架空例では、「受付」「接触中」「面談設定済み」「条件確認中」「提案中」「契約手続中」「受注」の進行系ステータスを置きます。これとは別に「長期保留」「失注・終了」を終了または休止系として管理します。

この表から読み取れるのは、ステータス名だけでなく、前へ進めない条件もそろえる必要があることです。特に「候補日を送った」と「日程に合意した」、「提案資料を作った」と「提案着手条件を満たした」を分けます。

自社の商流によっては、「敷地調査」「資金計画」「設計申込」などを独立ステータスにしたくなります。ただし、それが全案件に共通する直列工程かを確認してください。土地あり案件と土地なし案件で順番が変わる作業を一本のステータス列へ入れると、逆戻りや飛び越しが頻発します。

全案件に共通しない作業は、チェック項目やサブステータスで管理する方法があります。たとえば「土地探索中」は案件全体の現在地ではなく、土地条件の確認状況として持たせます。「住宅ローン事前確認」も、実施有無、予定日、結果などの個別項目にしたほうが、工程の並びを壊しません。

また、「契約手続中」の入口は各社で差が大きい領域です。申込書の受領、設計申込、見積条件の合意、経営者承認など、自社の実際の手続に合わせてください。本記事では、特定の契約方式や法的な成立時点を一律に定めません。社内の契約書式、業務手順、必要に応じた専門家の確認に沿って定義します。

05.判定は現在地、証拠、次工程の順に行う

現場で迷ったときに、一覧表を上から眺めるだけでは時間がかかります。判定順序を固定すると、短時間で同じ結論へ近づけます。

最初に、直近の活動ではなく、最後に満たした入口条件を探します。次に、その条件を裏づける記録があるかを見ます。最後に、次工程へ進むための出口条件が満たされているかを確認します。条件が一部だけなら、現在のステータスにとどめ、不足項目を次回行動にします。

この模式図からは、ステータス変更が最後ではないことが分かります。更新後に次回行動を設定して初めて、管理が実務につながります。

椿工務店の岸本様邸で考えます。資料請求を受け、営業担当が電話をかけたものの不通だった場合、「接触中」です。電話をかけたこと自体は活動履歴へ記録しますが、双方向の連絡がないので「面談設定済み」にはしません。

その後、顧客からメール返信があり、「10月12日の見学会後に30分相談したい」と双方で合意したなら、「面談設定済み」です。担当者が面談候補日を一方的に送っただけなら、まだ合意ではありません。

10月12日に夫婦が来場し、建築希望時期、土地未定であること、希望エリア、予算に関する現時点の認識、家族の要望を聞き取ったとします。面談日、参加者、相談概要を記録した時点で「条件確認中」へ移します。

ここで顧客が「雰囲気が気に入った」「ぜひ提案を見たい」と発言しても、それだけで「提案中」にはしません。椿工務店が定めた提案着手条件を満たしているかを確認します。土地未定でも、想定エリア、必要面積、予算枠、建築時期の仮定を置いて提案できるという社内基準なら、その仮定を明記したうえで提案中へ進めます。

一方、候補地も資金の考え方も分からず、顧客が「まず資料だけ見たい」と言っているなら、条件確認中にとどめます。次回行動は「提案作成」ではなく、「希望エリアと総予算の考え方を確認する面談の設定」です。

次の判定表は、同じ活動でも結果によってステータスが異なる例です。

この表から分かるのは、活動名だけで自動的にステータスを進めてはいけないということです。面談、提案、電話といった活動の「結果」が入口条件に届いたかを照合します。

判断に迷った場合は、より進んだステータスを選んで数字をよく見せるのではなく、証拠がそろっている最後の段階に置きます。そのうえで、不足している証拠や条件を次回行動として明示します。保守的に置くことが目的ではなく、未確認事項を見える状態にすることが目的です。

06.ステータス変更と同時に残す記録を最小化する

定義が正しくても、入力負担が大きければ運用されません。ステータス変更のたびに長文の日報を要求すると、更新が翌日以降に回り、一覧の現在地が古くなります。

最低限必要なのは、変更日時、変更者、変更前後の状態、根拠となる活動または確認事項、次回行動、次回期限です。顧客が述べた内容と担当者の推測は、同じ文章に混ぜないほうが安全です。

「顧客はA社より当社を気に入っているようだ」という記録では、顧客の発言なのか担当者の印象なのか分かりません。「顧客発言：木の内装は当社事例が希望に近い」「担当者所見：デザイン面の評価は得られているが、価格比較は未確認」のように分けます。

入力フォームでは、自由記述だけに頼らず、選択項目と短文を組み合わせます。選択項目は集計しやすく、短文は事情を残せます。ただし、選択肢を増やしすぎると担当者が近いものを適当に選びます。

この表から読み取るべきなのは、ステータスだけを更新しても案件は動かないことです。「未確認事項」と「次回行動」を一緒に残すことで、現在地から仕事へ接続できます。

次回行動の詳細な期限管理は、工務店の次回行動管理｜期限と担当を漏らさない仕組みで扱う領域です。本記事では、少なくともステータス変更時に担当、期限、行動を空欄にしないことまでを定義します。

顧客情報を記録する際は、必要な情報だからといって無制限に集めてよいわけではありません。取得・利用の法的な考え方は個人情報保護委員会の個人情報保護法ガイドライン（通則編）で確認し、利用目的、閲覧範囲、保存と共有の具体的な運用は顧客情報の扱いの記事に沿って決めます。

本記事が提案する「顧客発言と担当者所見を分ける」「未確認事項を残す」という形式は、商談判断をそろえるための社内運用案です。個別案件でどの個人情報を入力してよいか、誰が閲覧してよいかを一律に保証するものではありません。CRMの権限、保存期間、社外共有、委託先の取扱いは、自社の実態に応じて別途確認してください。

CRMをこれから選ぶ場合も、製品機能からステータスを決めるのではなく、定義表と必須入力欄を先に作ります。そのうえで、履歴保存、入力制御、権限設定、集計などを工務店のCRM選び｜入力項目と運用から比較するに沿って比較すると、導入後の作り直しを減らせます。

07.戻り、飛び越し、保留を例外ではなく規則にする

住宅の商談は、常に一方向へ進むわけではありません。土地が決まりかけて提案へ進んだ後に候補地が変わる、家族の要望が増えて条件整理へ戻る、数か月後に計画が再開する、といった動きがあります。

前のステータスへ戻ることを失敗扱いすると、担当者は実態が変わっても更新しなくなります。すると「提案中」の件数は多いのに、実際には再提案の前提条件すら定まっていない案件が残ります。戻りは異常ではなく、入口条件を満たさなくなったときの正常な処理として定義します。

たとえば、提案中だった岸本様邸で建築候補地が決まり、敷地条件が当初の仮定と大きく異なったとします。自社の提案着手条件が無効になったなら、「条件確認中」へ戻し、敷地条件を再整理します。ただし、過去の提案履歴を削除してはいけません。変更理由と変更日を残し、再提案に必要な条件を次回行動へ設定します。

工程の飛び越しも起こります。紹介客がすでに土地、予算、要望を整理して来社し、初回面談で提案着手条件まで満たす場合です。このとき、架空の中間日付を入れて順番どおりに見せる必要はありません。実際の面談記録を根拠に、満たした条件まで進めます。

ただし、「社長からの紹介だから提案中」「以前から知っている顧客だから契約手続中」という飛び越しは認めません。紹介経路や人間関係は、工程条件の代わりにならないからです。

長期保留は、失注を避けるための倉庫にしないことが重要です。保留には、理由、再確認日、再開条件を必須にします。「子どもの進学先が決まる翌年3月に再検討」「所有地の相続手続完了後に再開」など、止まっている事情が分かる記録を残します。

この模式図から読み取るべき点は、「進まない案件」をすべて同じ扱いにしないことです。条件が不足した案件、再開時期が決まった案件、終了した案件では、次に取る行動が異なります。

再開時には、新規案件を作るか、過去案件を開き直すかを決めます。同じ建築計画が短期間の保留から戻るなら、同じ案件の履歴を継続するほうが分かりやすいでしょう。建築地、目的、検討主体が変わり、以前とは別計画になった場合は、新規案件として関連づける方法があります。

重複案件の統合規則も必要です。夫と妻が別々の経路から問い合わせた場合、担当者が異なるまま進むと、二重連絡や異なる提案が起きます。氏名だけで自動統合すると同姓同名を誤認するため、連絡先、建築予定地、相談内容などを照合し、人が確認して統合します。

失注後の再相談も、単純に失注を受注へ書き換えないほうが分析しやすくなります。元の終了判断を履歴として残し、同一計画の再開なのか、新しい計画なのかを判定します。これにより、過去の失注件数を後から消さず、再相談が生じた経緯も追えます。

08.滞留日数は受注確率ではなく確認のきっかけに使う

ステータスの滞留日数は、放置案件を見つけるのに役立ちます。ただし、「30日経過したら自動的に失注」のように、日数だけで顧客の意思を決めるべきではありません。住宅計画は、土地探索、家族調整、資金準備などで止まることがあります。

滞留期限は、顧客を切る期限ではなく、責任者が案件を再確認する期限として置きます。期限を超えたら、現状維持、前工程へ戻す、長期保留へ移す、終了候補として確認する、のいずれかを判断します。

椿工務店では、仮に次のような「見直し目安」を設定できます。ここで示す日数は架空の運用例であり、業界標準や成果を保証する基準ではありません。

この表は、各日数をそのまま導入するためのものではありません。ステータスごとに「いつから数えるか」と「超過したら何を確認するか」をセットにする必要があることを示しています。

営業日と暦日を混ぜると集計がずれるため、単位を明記します。たとえば受付対応は営業日、顧客検討は暦日というように、自社の管理目的に合わせます。システムがどちらで計算するかも確認します。

月次会議では平均滞留日数だけを見ないほうがよいでしょう。一部の長期案件に引っ張られ、通常案件の姿が見えにくくなるからです。件数、期限超過件数、最長滞留案件を併記すると、行動につなげやすくなります。

期限超過率を使う場合は、分母を明記します。たとえば「9月末時点の進行中案件40件のうち、社内の見直し目安を超えた案件が8件」であれば、期限超過率は「8件÷40件×100＝20％」です。受注確率20％という意味ではなく、再確認が必要な案件の割合です。

ステータス別の転換率にも分母が必要です。「提案から契約へ50％」だけでは、どの期間に提案中へ入った案件を追ったのか、月末時点の在庫を分母にしたのかが分かりません。運用開始直後は、高度な指標を増やすより、ステータスの誤判定と未更新を減らすことを優先します。

09.会議では案件の感想ではなく定義との差分を確認する

ステータス定義は、文書を配布しただけでは定着しません。実際の案件を使って、異なる担当者が同じ判定をするかを定期的に確認します。

会議で全案件を一件ずつ長く説明すると、営業報告で時間を使い切ります。対象を「期限超過」「前回から変更なし」「戻りが発生」「証拠不足」「次回行動なし」に絞ると、定義の修正と案件支援に集中できます。

判定会議では、担当者に「この案件はどうですか」と聞くのではなく、次の順に確認します。

1. 現在のステータスの入口条件は何か。 2. その条件を満たした記録はどこにあるか。 3. 対象外条件に該当していないか。 4. 次の出口条件で足りない項目は何か。 5. 誰がいつまでに何を確認するか。

この問い方なら、担当者の営業力や人柄を評価する場になりにくくなります。「感触はよいが条件が未確認」「顧客の意向は不明だが、面談日程は合意済み」と、事実を分けて話せます。

判定の一致度を見る簡単な方法は、同じ架空案件または匿名化した社内事例を複数人に判定してもらうことです。たとえば営業3人と責任者1人の計4人が10事例を判定すると、判定数は「4人×10事例＝40判定」です。

正解率だけで競わせるのではなく、意見が割れた事例を集めます。定義文に不足があるのか、証拠欄が分かりにくいのか、実際の工程が直列ではないのかを確認します。

この表から読み取るべきなのは、担当者を注意するだけでは再発を止めにくいことです。ずれを、定義、入力画面、工程、評価方法のどこに原因があるかまで分けます。

定義を変更するときは、変更日と変更理由を残します。過去の集計と意味が変わるためです。「提案中」の入口を、提案着手時から提案説明時へ変更すれば、変更前後で件数が大きく変わります。改善自体は問題ありませんが、同じ指標として単純比較しないよう注記します。

また、例外事例を見つけるたびにステータスを増やさないことも大切です。一件だけの特殊事情なら、例外欄や補足項目で扱えます。同じ迷いが複数案件で繰り返され、経営判断にも影響する場合に限って、定義や項目を改めます。

10.失注・終了は進行ステータスと理由を分けて残す

失注は、工程の最後であると同時に、分析の入口です。しかし「他決」「予算」「時期」「連絡不通」が、同じ階層のステータスとして並んでいるCRMは少なくありません。

「失注・終了」は案件の状態です。「他社決定」「計画中止」「予算差」「対応範囲外」「連絡不能」は終了理由です。状態と理由を分けないと、進行中案件数を数えるための列で原因分析まで行うことになり、選択肢が増え続けます。

さらに、終了理由では「顧客が述べた事実」と「担当者の推測」を分けます。顧客が「A社と契約した」と伝えたなら、他社決定は顧客回答です。一方、返信がなくなった案件を「価格で負けた」とするのは推測です。

終了判断の例は次のように整理できます。

この表から分かるのは、同じ「終了」でも確定の強さが異なることです。顧客回答、自社判断、担当者推測を分ければ、後から「価格失注が多い」と誤って断定することを防げます。

連絡不能の終了条件は、自社で決めます。「何回連絡したら」という回数だけでなく、どの期間に、どの連絡手段で、最後に何を案内したかを定めます。頻繁な連絡が顧客の希望に反する場合もあるため、最初に確認した連絡希望や配信停止の意思を尊重できる運用が必要です。

失注理由の詳しい記録方法は、工務店の失注理由の記録｜推測と顧客の回答を区別するの担当範囲です。商談ステータス側では、終了条件、終了承認者、理由入力の必須化、根拠区分までを接続します。

終了承認をすべて経営者だけに集中させると、失注候補が滞留します。反対に、担当者だけで自由に終了できると、追客が難しい案件を早く閉じる可能性があります。通常終了は営業責任者、契約手続中からの終了や重要案件は経営者、といった承認範囲を決めます。

受注も同様です。「契約しそう」ではなく、自社で定めた成立確認を終えた状態にします。受注後の設計・工事管理へ引き継ぐ際は、商談ステータスを工事進捗の代わりに使い続けません。営業案件の終了と、受注後業務の開始を接続しつつ、別の管理目的として扱います。

11.30日で試行し、既存案件を一斉に整える

商談ステータスの再設計は、最初から完璧なCRM改修を目指すと止まりやすくなります。先に紙や表計算でも使える定義表を作り、実案件で判定した後にシステムへ反映します。

最初の30日間は、設計、試行、移行、定着の四段階に分けます。期間は運用例であり、組織規模や案件数に応じて調整してください。

この表から読み取れるのは、システム設定より前に判定演習を置くことです。定義が曖昧なまま選択肢を実装すると、後から大量の案件を修正することになります。

既存案件の移行では、現在のラベルを機械的に新ラベルへ置き換えないでください。旧「見込みA」が新「提案中」と一致する保証はありません。案件ごとに、直近の記録から最後に満たした入口条件を確認します。

全件を同じ深さで調べるのが難しい場合は、進行度が高い案件、直近30日以内に活動がある案件、次回行動が設定されている案件を先に確認します。ただし、残りを放置せず、「移行未判定」という一時フラグを付け、完了期限と担当者を決めます。この一時フラグを恒久的なステータスにしないことが重要です。

移行日に更新日が一斉に上書きされると、実際の滞留日数が分からなくなります。可能なら、現在の入口条件を満たした実日付を「ステータス起算日」として別に保持します。実日付が確認できない場合は、推定日を事実のように入力せず、「起算日不明」または移行日を使ったことを識別できる印を残します。

教育では、定義表を読み上げるだけでなく、迷いやすい事例を使います。「候補日を送ったが返信なし」「提案書を作成したが未説明」「他社決定らしいが顧客確認なし」「一年後に再開すると顧客と合意」といった事例です。

責任者は答えを伝えるだけでなく、どの入口条件と証拠を使ったかを説明します。担当者が暗記するのはステータス名ではなく、判定の手順です。新しい例外が出ても、同じ手順で考えられます。

運用開始後は、変更を急ぎすぎないことも必要です。毎週名称を変えると、担当者が古い意味と新しい意味を混同します。明らかな不具合は直しつつ、迷い事例を一定期間ため、月次など決めたタイミングで改定します。

12.完成成果物は定義表と案件ごとの判定記録

最終的に必要なのは、分厚いマニュアルではありません。全体を一覧する「商談ステータス定義表」と、変更理由を案件ごとに残す「案件判定記録」の二つです。

定義表には、ステータスの並び、入口条件、証拠、出口条件、対象外条件、戻し条件、具体例、変更権限、滞留時の扱いを載せます。案件判定記録には、判定日時、使った証拠、変更前後の状態と判断者を残します。CRMの画面上から参照できる場所に置き、定義表には版番号と改定日を明記します。

そのまま社内で埋められる最小ひな型は次のとおりです。

このひな型から読み取るべきなのは、ステータス定義が「名称と説明」の資料ではないことです。入口から例外、次回行動、権限までつながって初めて、現場で判定できます。

さらに、案件ごとの判定は次の形式で残せます。

案件名：
判定日時：
現在のステータス：
満たした入口条件：
根拠となる記録：
未確認事項：
対象外条件への該当：なし／あり
次回行動：
担当者：
期限：
次のステータスへ進む条件：

この案件判定記録では、「現在のステータス」と「次へ進む条件」を同時に書きます。会議で説明を求められた担当者が、長い活動履歴を最初から読み直さなくても、判定根拠を示せます。

運用開始前には、少なくとも次の状態になっていることを確認します。

• 一案件の単位が決まっている
• 受付から受注・終了までの標準工程が描けている
• ステータスごとに入口条件と証拠がある
• 顧客の温度感、確度、活動履歴を別項目にしている
• 進めてはいけない例が書かれている
• 戻り、飛び越し、保留、再開の規則がある
• 滞留期限の起算日と確認者が決まっている
• 受注・失注の成立条件と承認者が決まっている
• 顧客発言と担当者推測を分けている
• ステータス変更時に次回行動と期限を残せる
• 定義の版番号、施行日、改定責任者が決まっている

担当者で判定がぶれない状態とは、全員が同じ印象を持つことではありません。同じ記録を見て、同じ入口条件に照らし、違う判断になったときに差の理由を説明できる状態です。

最初から例外をゼロにする必要もありません。判定不能な案件が出たら、担当者の勘で埋めず、迷い事例として残します。同じ迷いが繰り返されるなら定義を改め、一件だけなら例外欄で扱います。この更新を続けることで、商談ステータスは単なるCRMの選択肢ではなく、営業、設計、経営をつなぐ共通言語になります。