HubSpotで作る不動産CRMのデータ設計｜物件・顧客・取引をどう持つか

顧客の属性ではなく、それ自体がレコードであるという前提に立つと、設計の選択肢がはっきりします。

ここは正直にお伝えしたい部分です。カスタムオブジェクトは万能ではなく、使わない方がいい場面が確かにあります。

賃貸は「継続関係」をどう持つかが焦点

賃貸で難しいのは、契約が終わりではなく始まりだという点です。入居後も更新・修繕依頼・退去といったイベントが続きます。

入居中の問い合わせをチケットで受け、更新は契約オブジェクトの期限から自動でタスク化する設計が現実的です。

また、入居希望者とオーナーという性質のまったく違う2種類の顧客を、同じコンタクト／会社オブジェクトに混在させることになります。

ライフサイクルステージやラベルで明確に区別しておかないと、入居希望者向けの案内がオーナーに飛ぶといった事故が起きます。

売買と投資用で気をつけたいこと

売買では1件あたりの金額が大きく、検討期間も長くなります。在庫として大量に抱える業態は多くないため、カスタムオブジェクトを作らず取引のプロパティーで持つ判断も十分にあり得ます。

無理に増やさず、スモールスタートで様子を見るのがおすすめです。

投資用でやっかいなのは、同じ人物が買主にも売主にもなり得ることです。コンタクトを「買主」「売主」と固定的に分類すると、この転換を表現できません。

役割は関連付けラベルや取引側の属性で表し、コンタクト自体は「1人1レコード」に保つのが基本です。

取引（Deal）を「1顧客1本」にするか「1提案1本」にするかの判断

データモデルの中で、実務上いちばん揉めるのがここです。取引レコードを顧客ごとに1本立てるのか、提案した物件ごとに立てるのか。どちらにも一長一短があります。

1顧客1本（追客ベース）の考え方

1人の顧客に対して取引を1本だけ作り、そこで追客全体を管理する方法です。レコード数が増えず、反響件数と取引件数が一致するため歩留まりレポートが素直に作れます。

追客が中心で提案物件が入れ替わっていく賃貸仲介では扱いやすい形になります。

欠点は、「どの物件で成約したか」がぼやけることです。提案物件を関連付けで持つことはできますが、金額やクローズ日は1本しか持てないため、物件ごとの成約率は取引レポートだけでは出せません。

1提案1本（物件ベース）の考え方

提案した物件ごとに取引を立てる方法です。物件単位の金額・確度・クローズ日が正確に持てるため、フォーキャストの精度が上がります。

売買や投資用のように1件あたりが重く、並行提案が発生する業態に向いています。

欠点は、レコードが増えることと失注の扱いが複雑になることです。5物件提案して1件成約すれば残り4件は失注になります。

これを「顧客としての失注」と混同すると失注率が実態より高く見えるため、失注理由に「他物件で成約」という区分が必須になります。

判断の基準

折衷案：申込以降だけを取引にする

実務でよく落ち着くのが両者の中間です。

反響から内見までの追客はコンタクト側のステージで管理し、申込が入った時点で初めて取引を作る設計にします。

取引が「ほぼ確度のある案件」だけになり、パイプラインの数字が読みやすくなります。

不動産に合わせたステージの切り方は不動産の追客パイプライン設計で具体的に扱っています。

オーナー・管理会社を会社オブジェクトでどう表現するか

物件と顧客の設計ができたら、次はその周りにいる関係者です。不動産では、オーナー・管理会社・元付業者・金融機関・施工会社など、登場人物が多くなります。

個人オーナーをコンタクトに持つか会社に持つか

会社オブジェクトは法人を想定した項目構成のため、個人名を会社レコードとして登録するのは違和感があります。

法人オーナーの場合は会社レコードを作り、その担当者をコンタクトとして紐づけます。

こうすると、個人でも法人でも「物件から所有者をたどる」という動線が統一されます。

役割はプロパティーではなくラベルで持つ

会社オブジェクトに「区分」というプロパティーを作り、「オーナー」「管理会社」「仲介会社」から選ばせる設計もよく見かけます。ただ、同じ会社がある物件ではオーナー、別の物件では管理会社というケースが普通に発生します。

役割は会社そのものの属性ではなく、会社と物件の関係の属性です。ですから関連付けラベルで持つほうが正確に表現できます。プロパティーで持つと1社1役割に固定され、後から表現しきれなくなります。

なお金融機関や司法書士まで会社オブジェクトに入れるかは業務の必要性次第で、そうでなければ取引のプロパティーで足ります。

データ設計を間違えたときに起きること

設計をやり直すことになった現場では、だいたい同じ症状が出ています。3つに整理します。

重複レコードが増える

物件を文字列で持っていると、表記揺れのぶんだけ実質的な重複が発生します。コンタクト側でも、同じ人が反響のたびに新規レコードとして登録されるケースがあります。

重複が増えると、メールが二重に届く、担当が別々に付くといった、顧客に見える形の事故につながります。CRM上の数字も実態より大きく見えるため、経営判断の材料としても使えなくなります。

集計ができない

いちばん多いのがこれです。入力自体はされているのに、見たい数字が出せません。

「エリア別の反響数」を出したいのに所在地を1つのテキストで持っていた、「物件種別ごとの成約率」を見たいのに種別が自由入力だった、という具合です。

テキストプロパティーは集計軸に使いづらいため、レポートで軸にしたい項目は必ず選択肢（ドロップダウン）で持つというのが鉄則になります。

現場が入力しなくなる

現場が入力をやめる条件は、次の3つです。

• 入力項目が多すぎる
• 同じ情報を2か所に入れさせられる
• 入れても何も返ってこない

この3つが揃うと現場は入力をやめます。入力が止まったCRMは、データが中途半端に入っているぶんExcel時代より状況が悪くなります。

後から直すコストは想像より高い

「とりあえず作って後で直せばいい」と考えたくなりますが、直すコストは決して小さくありません。主な制約を整理します。

やり直しが不可能なわけではありません。ただ、レコードが数千件を超えたあたりから「直すより我慢する」という判断になりがちです。

だからこそ、最初に決めるべきものだけは時間をかけて決める価値があります。

設計を進める順序

最後に、どの順番で決めていくかを整理します。順序を間違えると手戻りが発生するため、ここは型に沿って進めることをおすすめします。

全体の流れ

レポート要件から逆算する

「毎月の営業会議で何を見るのか」を先に決めておくと、必要なプロパティーと不要なプロパティーの線引きが一気に明確になります。

逆に項目から考え始めると必ず増えます。「あったほうがいいかもしれない」で作られた項目は、ほぼ使われません。

一度に全部やらず、入力の入口も同時に決める

不動産のデータモデルは、突き詰めるといくらでも複雑にできます。物件・区画・契約・オーナー・管理受託・修繕履歴と広げていくと、初期構築だけで数か月かかります。

現実的には、まず反響〜成約までの1本の線を通してから、管理業務や周辺の関係者を足していく進め方が続きます。

同じくらい重要なのが「そのレコードは誰がどこで作るのか」です。

• 物件 ── ポータルサイトからの取り込みなのか手入力なのか
• 反響 ── フォーム経由なのかメール転送なのか

ここが決まっていないと、きれいな設計図があっても中身が入りません。

反響を担当者に振り分ける部分まで含めて考えると初動の速さが変わります。振り分けの自動化はリードの傾斜配布を自動化するで解説しています。

よくある質問

不動産CRMのデータ設計について、ご相談の場でよくいただく質問をまとめました。

Q1. 物件をカスタムオブジェクトにしないと、不動産でCRMは使えませんか。

そんなことはありません。扱う物件数が少なく、1顧客あたりの提案が重ならない業態であれば、取引のプロパティーに物件情報を持たせる形で十分に運用できます。オブジェクトを増やすと入力と関連付けの手間も増えるため、必要性が明確になってから足すほうが定着します。判断の起点は「同じ物件を複数の顧客に同時提案するか」「物件側から引き合いを見たいか」の2点です。

Q2. 既に物件管理システムを使っています。CRMにも物件を入れるべきですか。

二重管理になるため、原則としておすすめしません。物件マスターは既存システムに置いたまま、CRM側は物件番号などの参照キーだけを持つ設計が現実的です。ただし反響数を物件別に見たい場合は、必要最小限の項目（物件番号・物件名・エリア・種別・ステータス）だけを連携する判断もあります。どちらを正とするかを先に決めることが重要です。

Q3. 個人オーナーは会社オブジェクトとコンタクトのどちらに入れるべきですか。

コンタクトとして持ち、物件との関連付けにラベルを付けて「オーナー」であることを表現する方法をおすすめします。会社オブジェクトは法人を前提とした項目構成のためです。同じ会社が物件によってオーナーだったり管理会社だったりするため、役割はプロパティーではなく関連付けラベルで持つのが重要なポイントになります。

Q4. カスタムオブジェクトはどのプランで使えますか。

HubSpotのナレッジベースでは、Marketing Hub / Sales Hub / Service Hub / Data Hub / Content Hub の各Enterprise、および Smart CRM Enterprise・Revenue Hub Enterprise で利用できると案内されています（出典 2026年8月1日確認）。同ページには契約内容による上限がある旨も記載されていますが、具体的な数値は明示されておらず、製品・サービスカタログの確認が必要とされています。契約前にHubSpotまたはパートナーへ確認することをおすすめします。

Q5. 設計をやり直したくなったら、どのくらい大変ですか。

内容によります。プロパティーを1つ足すだけなら数分ですが、テキスト項目を選択肢型に変える、物件をオブジェクトに移す、取引の粒度を変えるといった変更は、既存レコード全件の再処理が必要になります。特にプロパティーのフィールドタイプ変更には制約があり、スコア・計算タイプへの変更やそこからの変更はできません。集計軸に使う項目の型だけは最初に決めておくことをおすすめします。

まとめ

不動産CRMの設計は、機能比較ではなくデータ構造から始めるのが要点になります。要点を整理します。

• 最初に決めるのは「物件をどこに持つか」。プロパティーか、取引か、カスタムオブジェクトか。この選択で後から見えるレポートが変わります
• 標準オブジェクトだけで足りる会社もあります。扱う物件が少ない、提案が重ならない、基幹システムが既にある場合は、無理にオブジェクトを増やさないほうが定着します
• 賃貸・売買・投資用でデータモデルは変わります。契約の継続性とオーナーの位置づけが違うため、他社の設計をそのまま持ってきても合いません
• 取引の粒度は「1顧客1本」か「1提案1本」か。並行提案の有無と1件あたりの重さで決まります。申込以降だけを取引にする折衷案も現実的です
• 後から直すコストは高い。プロパティーの型変更には制約があり、関連付けの張り替えは全レコードの再処理になります

最初の一歩としておすすめしたいのは、「毎月の会議で見たい数字を5つ書き出す」ことです。空室率なのか、エリア別の反響数なのか、物件種別ごとの成約率なのか。

その5つが出せるデータ構造になっているかを逆算すると、必要なオブジェクトとプロパティーが自然に決まります。ツールの検討はその後で構いません。

そのうえで、まずは物件・コンタクト・取引の3つで1本の線を通し、動き始めてから区画・契約・オーナー管理を足していく。この段階的な進め方が、結局いちばん現場に残ります。

自社の物件や顧客の持ち方をどう設計するか具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。