回答: 事業ごとに案件管理の画面を分けたくなったときは、分ける前に「何が共通で、何が違うのか」を項目の粒度まで分解するのが先です。顧客との結びつけ方と集計の単位を共通にでき、主な違いが種別ごとの固有項目とフェーズ（進捗の段階）の並びに収まる場合は、商談を1つのテーブルに「種別」を持たせてまとめる設計が候補になります。顧客の持ち方が事業ごとに違う場合や、権限・データの分離の要件が事業ごとに異なる場合は、別に管理することも検討します。売買仲介に賃貸・管理・工事などを足していった会社に当てはまります。単一事業しかやっていない会社には、この判断自体が発生しません。
この記事でわかること
- 事業ごとに案件管理を分けると、あとで何が起きるか
- 1本にまとめるか分けるかを決める、3つの判断材料
- 共通で持つ項目と、種別ごとに逃がす項目の線引き
- フェーズが事業ごとに違う問題を、画面を分けずに解く方法
- 1本にしないほうがよいケース
事業ごとに分けると、あとで何が起きるか
答え: 事業固有の項目に絞ると、入力しやすくなる場合があります。一方、共通の顧客IDや横断集計の仕組みがない場合は、事業をまたいで数える・たどる作業が増えます。
兼業の会社でよくある流れはこうです。まず売買仲介の案件管理を作る。賃貸を始めたので賃貸用のシートを足す。リフォームの受注が増えてきたので、リフォーム用の管理表をまた別に作る。それぞれの事業の担当者にとっては、自分の事業に必要な項目だけが並んだ画面になるので、使い勝手はむしろ良くなります。
問題が出るのは、その先の3か所です。
| 困る場面 | 何が起きるか |
|---|---|
| 会社全体の数字を出す | 事業ごとに集計して、手作業で足す。定義が揃っていないと足せない |
| 一人の顧客の経緯をたどる | 「この人は去年リフォームもやっている」が、別の管理表を開かないと分からない |
| 担当者の実績を見る | 売買とリフォームを兼務している人の数字が、2か所に分かれる |
さらに、項目を1つ足すたびに「どの事業の管理表に足すか」「他の事業にも足すか」を毎回決めることになります。運用が長くなるほど、同じ意味の項目が事業ごとに微妙に違う名前で増えていきます。この「選択肢と項目が増え続ける」問題そのものは、CRMを何年も運用すると起きることで別に整理しています。
1本にまとめるか、分けるかの判断材料は3つ
答え: 「顧客の持ち方」「数えたい単位」「フェーズの違いの大きさ」の3つを順に見ます。
1. 顧客を1本で持てるか
同じ人が、売買の問い合わせをし、数年後にリフォームを頼み、賃貸の相談もする。この動きを同じ顧客レコードの上に積みたいなら、商談も1本にしておくほうが素直です。顧客が1本で商談が事業ごとにバラバラだと、顧客から案件をたどるときに事業の数だけ参照先を持つことになります。
顧客を1本で持つ話は売買とリフォームの顧客を1つの台帳で持つに、顧客と商談を分ける理由そのものは顧客と商談を分けて管理する理由に書いています。
2. 事業をまたいで数えたいか
「今月の全社のパイプライン」「この担当者の受注金額」「反響媒体ごとの成約率」を、事業をまたいで1枚で見たいなら、1本が有利です。商談が1つのテーブルにあれば、横断の集計を組みやすくなります。ただし、同じテーブルに入れるだけで比べられるわけではありません。金額の基準（売買代金なのか仲介手数料なのか工事の受注額なのか）、成約率の分母と対象期間、事業ごとのフェーズを全社の指標にどう対応させるかを、別にそろえる必要があります。
逆に、事業ごとに完全に別の会社のように運営していて、全社で横に並べる必要がない場合は、分けても実害は出にくくなります。
3. フェーズの違いが、項目の違いなのか、流れの違いなのか
ここが一番判断しにくいところです。目安はこうです。
- 項目が違うだけ（建築なら構造や工法、リフォームなら対象部位、太陽光なら設置する屋根の条件）→ 1本にできる。違いは子テーブルに逃がす
- 流れそのものが違う（段階の数も、順番も、意味も違う）→ 1本でもよいが、フェーズを種別ごとに出し分ける仕組みが要る
- 扱う対象が人ではない（たとえば仕入の案件が「土地そのもの」を追っていて、顧客がいない期間が長い）→ 分けるか、種別として持ちつつ画面を別に作るかを検討する
共通で持つ項目と、種別ごとに逃がす項目
答え: 全事業に共通して「ある」項目だけを商談本体に置き、その種別にしか存在しない項目は子テーブルへ逃がします。
以下は、複数事業の商談管理を共通化する場合の設計例です。商談を1つのテーブルにまとめ、商談種別（購入／売却／借主／管理受託／仕入／建築／リフォーム／太陽光・蓄電池／エスクローの9種別）で分岐させます。契約も同様に1本にして、契約種別（売買契約／賃貸借契約／管理受託契約／建築請負契約／リフォーム請負契約／太陽光設置契約／エスクロー受託契約）で分けます。種別の数と呼び名は、その会社が実際に扱う事業によって変わります。
共通で持つ項目と、逃がす項目の例は次のとおりです。
| 置き場所 | 項目の例 |
|---|---|
| 商談本体（全種別共通） | 顧客／種別／フェーズ／担当／店舗／反響媒体／問合せ日／受注確度／想定粗利／失注理由 |
| 子テーブル（購入） | 希望エリア・沿線・駅／希望物件種別／価格帯／間取り・面積・築年数／自己資金・年収・借入希望額 |
| 子テーブル（建築） | 建築種別／土地の有無／延床／構造／工法／着工希望／総予算／競合ハウスメーカー |
| 子テーブル（リフォーム） | 工事種別／対象部位／居住中か空室か／工事希望時期／概算予算／補助金 |
| 子テーブル（エスクロー） | 依頼種別／対象取引／決済予定日／関与士業／預託予定額／手数料体系 |
線引きの基準は「その項目が、他の種別では常に空欄になるかどうか」です。常に空欄になるなら本体に置かず、子テーブルに移します。本体に空欄だらけの項目が並ぶと、入力する人は「自分に関係ない項目」を毎回読み飛ばすことになり、必要な項目まで読まれなくなります。
逆に、全種別で埋まる項目を子テーブルに逃がすのは避けます。集計や一覧の絞り込みのたびに、関連テーブルを参照する必要が出てくるためです。配置は入力と集計のしやすさを基準に決め、速度については実際のデータ量と検索条件で確認してください。
フェーズが事業ごとに違う問題は、マスタで解く
答え: 商談種別ごとにフェーズの選択肢を出し分けるマスタを1つ持ち、表示用のフェーズの追加・無効化をマスタの更新で行えるようにします。
売買仲介の購入は「未対応 → 初期連絡 → 希望条件・予算確認 → 物件案内 → 資金計画確定 → 購入申込 → 売買契約 → 住宅ローン本審査 → 決済・引渡 → 取引完了／失注」という流れです。売却は「未対応 → 初期連絡 → 査定依頼受付 → 査定書提示 → 媒介契約 → 販促活動 → 購入申込受領 → 売買契約 → 決済・引渡 → 取引完了／失注」で、段階の数も意味も違います。
これを1つの選択肢リストに全部並べると、どの事業の担当者にとっても関係のない段階が大量に見えることになります。なお、ここで困るのは選択肢の出し方であって、画面の分け方ではありません。商談テーブルは共通にしたまま、種別ごとに画面や表示項目を分けることはできます。
間を取る形が、商談種別 × フェーズ × 表示順をマスタとして持つやり方です。マスタに持たせる項目は、商談種別／フェーズ名／表示順／使用するかどうか／最終フェーズかどうか／失注扱いかどうか、といったものになります。この形にしておくと、事業ごとのフェーズの増減は、マスタの行の追加と「使用しない」への切り替えで扱えます。ただし、フェーズに通知や承認などの処理が結びついている場合は、その処理が新しいフェーズに対応しているかを画面・ワークフロー側でも確認する必要があります。
導入時に決めておくとよいのは次の3点です。
- 「最終フェーズ」と「失注」をフラグで持つ。これがないと、成約率を出すたびにフェーズ名を文字列で比較することになります
- 表示順を数値で持つ。あとから途中に段階を差し込めるよう、10・20・30のように間隔を空けておきます
- 使わなくなったフェーズは消さずに「使用しない」にする。過去の商談がそのフェーズを指しているため、消すと履歴が読めなくなります
1本にしないほうがよいケース
答え: 次のような場合は、無理に1本にまとめないほうが素直です。
- 顧客が存在しない期間が長い案件を主に扱う（たとえば仕入で、売主が決まる前から土地を追い続ける）。この場合でも種別として持つことは可能ですが、入力の動線は別に作ることになります
- 同じ人を、事業ごとに別人格として扱う必要がある（請求先・契約主体・個人情報の取扱い同意の範囲が事業ごとに分かれている）
- その事業が、専用ソフトで完結していて移す理由がない（建築の実行予算や原価管理のように、専用ソフトの計算が業務の中心にある領域）
3つめについては、受注までを共通の商談で持ち、着工後の工程・原価は専用ソフトに任せる、という分担もあります。見積の共通化をどこまでやるかは建築・リフォーム・太陽光の見積を1組にまとめる設計で別に整理しています。
よくある質問
いま事業ごとに分かれています。1本にまとめ直すべきですか
いま困っていないなら、急いで統合する必要はありません。判断の目安は「事業をまたいだ数字を出すために、毎月手作業で足し算しているか」「一人の顧客の経緯を追うのに複数の管理表を開いているか」の2点です。どちらも起きていないなら、当面はそのままでも回ります。
種別はあとから増やせますか
設計としては増やせます。ただし、種別を増やすときに必要なのは種別の選択肢を足すことだけではなく、その種別のフェーズをマスタに足すこと、固有項目があれば子テーブルを用意すること、契約・売上の種別との対応を決めることの3点です。必要な作業量は、いまの設計や実装のやり方によって変わります。
商談と契約は、同じ考え方で1本にできますか
同じ考え方で設計できます。ただし、商談種別と契約種別は1対1とは限りません。たとえば、管理受託のあとの入居者募集まで同じ商談に関連づける運用にするなら、1つの管理受託の商談に管理受託契約と複数の賃貸借契約がぶら下がる形になります。募集を別の商談として立てる運用なら、そうはなりません。商談と契約の対応は、自社の業務に合わせて決めます。1対1で揃うことを前提に設計すると、あとで無理が出ます。
項目数が多くなりすぎないか心配です
商談本体の項目数を抑えるために子テーブルに逃がす、というのがこの設計の目的です。本体に、その種別では使わない項目が増えてきたと感じたら、「この項目は全種別で埋まるか」をもう一度見てください。1つの種別でしか使わない項目が混ざっていることが多いです。
まとめ
事業が増えるたびに案件管理を分けていくと、入力はしやすくなる場合がありますが、共通の顧客IDや横断集計の仕組みがなければ、数えることと、たどることに手間がかかります。
判断の順番は次のとおりです。
- 顧客を1本で持ちたいかを決める。持ちたいなら商談も1本が素直
- 事業をまたいで数えたいかを確認する。数えたいなら1本が有利
- 違いが項目だけなら子テーブルに逃がす。流れが違うなら、商談種別×フェーズのマスタで出し分ける
- 顧客の持ち方そのものが違う事業、専用ソフトで完結している領域は、無理に入れない
この判断は、道具を決める前に紙の上でできます。先に「共通で持つ項目」を書き出してから、どのツールで実装するかを考えるほうが、あとで作り直す量が減ります。
売買・賃貸・管理・工事を、1つの顧客台帳で持つ
BizBlock の不動産パッケージは、売買仲介・賃貸仲介・賃貸管理・建築・リフォーム・太陽光・分譲・エスクローを扱い、顧客は全事業で1本、事業間の紹介（送客）も記録できる構成です。自社の事業構成で商談をどこまで共通にできるかは、現状をお聞きしたうえでご相談いただけます。
—
この記事を書いた会社
7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。
詳しくはこちら → https://7plus.jp/
