賃貸管理のCRM設計｜オーナーと入居者を両建てで持つデータモデル

「仲介向けのCRMを入れたが、管理部門ではまったく使われていない」——賃貸管理を手がける会社で、よく聞く話です。原因は現場の意識ではなく、仲介と賃貸管理では、そもそも管理すべき対象が違うことにあります。

仲介は「契約したら終わり」ですが、賃貸管理は契約してからが本番です。しかも顧客が2種類います。物件を預けるオーナーと、そこに住む入居者です。この2者を1つのデータモデルに素直に載せようとすると、必ずどこかで無理が出ます。

賃貸管理のCRM設計とは、オーナー・物件・部屋・入居者という4つの登場人物を、それぞれどのオブジェクトのレコードとして持ち、どの関係でつなぐかを決める作業です。オブジェクトの名前を並べる作業に見えますが、実際には「誰の情報を、誰が見られる状態にするか」を決める業務設計そのものです。

この記事では、HubSpotを例に賃貸管理のCRMをどう設計するかを整理します。管理戸数を増やしたい賃貸管理会社の方、仲介と管理を両方手がけていて情報が分断している方に向けた内容です。次の4点がわかります。

• オーナー・物件・部屋・入居者の持ち方 ── 4つの登場人物をどのオブジェクトに割り当てるかの判断基準を示します
• 役割を関連付けラベルで表現する方法 ── 同じ会社が別の役割で登場する状況を、プロパティーではなく関連付けで解く考え方です
• 管理受託と入退去でパイプラインを分ける理由 ── 営業の案件と、日々の入退去業務を同じボードに載せない設計です
• 管理ソフトとの棲み分け ── CRMに持たせないほうがよいものを先に決める順序を説明します

読み終える頃には、自社の賃貸管理業務をどのオブジェクトで表現するかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

賃貸管理は「顧客が2種類いる」ビジネスです

まず、仲介向けのCRM設計をそのまま持ち込むと何が起きるかを整理します。

契約後が本番なので、パイプラインだけでは足りない

仲介のCRMは、反響から契約までを追うパイプラインが中心です。契約したらクローズし、レコードは過去のものになります。

賃貸管理では、管理受託契約を結んだ時点から数年単位の関係が始まります。入居者の入れ替わり、更新、修繕、解約。どれもクローズ後に発生する業務です。「クローズしたら見なくなる」構造のままだと、管理部門にとってCRMは記録場所にすらなりません。

オーナーと入居者は、求めるものが正反対の場面がある

オーナーは空室を埋めたい、家賃を上げたい、修繕費は抑えたい。入居者は早く直してほしい、家賃は上げないでほしい。利害が対立する2者を同じ会社が同時に相手にするのが賃貸管理の構造です。

このため、オーナー向けの情報と入居者向けの情報は、見える範囲を分けて設計する必要があります。全員が全部見える状態にしておくと、うっかり片方の情報がもう片方に流れる事故が起きます。

管理戸数が増えるほど、記録の欠落が効いてくる

賃貸住宅管理業法では、自己所有物件の管理を除く管理戸数が200戸以上の事業者に登録が義務づけられており、登録の有効期間は5年です（賃貸住宅管理業登録の方法、国土交通省）。200戸を超える規模になると、担当者の記憶で回すのは現実的ではなくなります。

戸数が増えるほど、「誰がいつオーナーに何を報告したか」が追えないことのリスクが上がります。データモデルの設計は、この規模になる前に手を入れておくと後の移行が軽くなります。

オーナー・物件・部屋・入居者をどう持つか

賃貸管理には4種類の登場人物がいます。それぞれをどのオブジェクトに割り当てるかが設計の中心です。

これは特定の企業の実装ではなく、賃貸管理でよく出てくる構造を一般化した設計例です。

4つの登場人物を整理する

物件をカスタムオブジェクトで持つ設計の詳細は、HubSpotで不動産の物件情報を管理する方法で扱っています。カスタムオブジェクトの作成には、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hub のいずれかの Enterprise が必要です（カスタムオブジェクトを作成する）。プランが届かない場合の代替案も後述します。

オーナーは会社に持つか、コンタクトに持つか

判断の起点は、そのオーナーが「組織」として動くかどうかです。

• 資産管理法人や不動産所有会社であれば、会社オブジェクトに持ち、担当者をコンタクトとして紐づけます
• 個人オーナー1人であれば、コンタクトだけで足りる場面が多くなります
• ただし、個人オーナーでも相続や共有名義で複数人が関与する場合は、会社オブジェクトを「オーナー世帯」として使う設計が扱いやすくなります

3つの持ち方を比較すると、次のようになります。

会社に統一するか、混在を許すかは事前に決めてください。混在させる場合、「オーナー一覧」を1つのビューで出せなくなるため、どちらのオブジェクトにも共通の識別プロパティーを持たせておく必要があります。

部屋・区画を分けるかどうかの判断

部屋を独立レコードにすべきかは、部屋ごとに状態を持つ必要があるかで決まります。

分けるべきなのは、部屋ごとに賃料・入居状況・契約期間が違い、それを一覧で見たい場合です。分けなくてよいのは、1棟貸しや戸建て中心で、1物件＝1契約が基本の場合です。

戸数が数千を超える場合、部屋を全部レコードにすると運用負荷とレコード数が跳ね上がります。全部屋を持つのではなく、契約が発生した部屋だけを持つという中間案も現実的です。

入居者をコンタクトで持つときの注意

入居者はコンタクトで持ちますが、過去の入居者を消さない設計にしてください。退去したら削除する運用にすると、原状回復費の請求や、再入居時の履歴が追えなくなります。

入居中か退去済みかは、コンタクトのプロパティーではなく賃貸借契約側の状態で判断できるようにしておくと、同じ人が別の部屋に移った場合も破綻しません。

役割は「プロパティー」ではなく関連付けラベルで持つ

賃貸管理では、同じ会社が複数の役割で登場します。ここをプロパティーで解こうとすると必ず詰まります。

同じ会社が別の役割で登場します

たとえば、ある不動産会社が「A物件のオーナー」でありながら「B物件の仲介元付」であり、「C物件の工事協力会社」でもある、という状況は普通に起こります。

会社レコードに「区分」というプロパティーを1つ作り、そこに役割を入れる設計にすると、1社につき1つの役割しか持てません。実態と合わないため、担当者は分身のような重複レコードを作り始めます。ここから重複が増えていくのが典型的な崩れ方です。

関連付けラベルで解く

HubSpotには、レコード同士の関連付けに意味を持たせる「関連付けラベル」があります。「この会社は、この物件のオーナー」「この会社は、この物件の工事協力会社」というように、関係ごとに役割を持てるのが利点です。

関連付けラベルの作成には、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM のいずれかの Professional 以上が必要で、1つのオブジェクトペアにつき最大50個のラベルを作成できます（関連付けラベルを作成して使用する）。50という上限は実務上ほぼ問題になりませんが、ラベルを増やしすぎると入力時に選べなくなるため、10前後に収める設計が扱いやすいです。

ラベル設計でやりがちな失敗

ラベルに「重要」「優良」といった評価を入れてしまうケースがあります。これは役割ではなく属性なので、プロパティーで持つべきものです。

ラベルは「関係の種類」だけに使う。この線引きを守ると、後から見返したときに意味が壊れません。

パイプラインは「管理受託」と「入退去」で分ける

賃貸管理には性質の違う2種類の案件があります。同じパイプラインに載せないことが設計の要点です。

管理受託のパイプライン

オーナーから管理を預かるまでの営業プロセスです。相談受付、物件調査、提案、条件調整、契約、管理開始といった流れになります。担当は営業部門で、扱う金額は管理受託の想定年間収入です。

このパイプラインは件数が少なく、期間が長いのが特徴です。1件あたりの重みが大きいため、停滞の検知が効きます。

入退去・更新のパイプライン

退去予告、解約手続き、原状回復、募集、申込、審査、契約、入居という日常業務の流れです。担当は管理部門で、件数が多く、期間が短いという逆の性質を持ちます。

この2つを1本にすると、ボードが日常業務のカードで埋まり、管理受託の案件が視界から消えます。数の多いほうが少ないほうを押し流すため、分けるのが基本です。パイプラインは Starter 以上のサブスクリプションで追加作成できます（パイプラインを設定・カスタマイズする）。

修繕・クレームはチケットで持つ

入居者からの修繕依頼やクレームは、取引ではなくチケットで持つほうが実態に合います。金額を追うものではなく、受付から完了までの対応を追うものだからです。

チケットにすると、対応の滞留や再発を集計できるようになります。オーナーへの月次報告で「今月の対応件数」を出したいなら、この形が扱いやすいです。

更新・解約を期限から逆算して回す

賃貸管理の業務の多くは、期日に紐づいています。ここを人の記憶に任せると必ず漏れます。

契約満了日を持たないと、更新業務は属人化する

賃貸借契約のレコードに満了日を日付プロパティーとして持たせ、そこから逆算して通知やタスクを自動生成する。これが更新業務を仕組みにする最小構成です。

HubSpotのワークフローは日付プロパティーを基準にした実行に対応しています（ワークフローのアクションを選択する）。「満了3か月前に更新案内のタスクを作る」といった設計が可能です。

解約予告から原状回復までを1本の線にする

解約予告を受けた時点で、原状回復の見積、精算、募集開始までが動き出します。これらを別々の場所で管理すると、空室期間が伸びます。1つのレコードの中で、予告日・退去予定日・原状回復完了予定日・募集開始日を並べて持つと、どこで詰まっているかが見えます。

期日プロパティーは「予定」と「実績」を分ける

退去予定日と実際の退去日は違います。両方を持たせておくと、後から「予定からどれだけずれたか」を集計できます。片方しか持たない設計にすると、改善の材料が残りません。

賃貸管理で見るべき数字

設計が正しいかどうかは、機能が揃っているかではなく、必要な数字が取れるかで判定できます。オーナーへの報告と、自社の経営判断の両方で使う指標を先に決めておくと、どの項目を持つべきかが自動的に決まります。

賃貸管理で継続的に見たい指標と、それを取るために必要なデータ構造は次のとおりです。

このうち平均空室期間とオーナーへの接触頻度は、設計を後から変えると過去分が取れません。最初の設計時点で持たせておく価値が高い項目です。

なお、これらの指標をすべて最初から追う必要はありません。まずは管理戸数と稼働率の2つが自動で出る状態を作り、報告のたびに手作業で集計している項目を1つずつ移していく。この進め方のほうが、現場の負担を増やさずに定着します。指標を増やすことより、1つの指標が確実に更新され続けることのほうが価値が高いためです。

オーナーへの報告を仕組みにする

賃貸管理の解約は、多くの場合「対応が悪かったから」ではなく「何をしてくれているのか分からないから」起こります。報告の設計は、管理戸数の維持に直結します。

報告に必要な情報が散っていると、作成が属人化する

月次報告の資料を作るために、管理ソフトから入出金を出し、メールから対応履歴を探し、担当者の記憶で補う。この状態だと、報告は担当者ごとに品質がばらつき、忙しい月は省略されます。

CRM側でオーナーに紐づく活動（対応・修繕・募集の動き）が自動で積み上がっている状態を作れば、報告の作成は集計作業に変わります。属人性が減り、担当者が変わっても続きます。

報告のタイミングをレコードで管理する

オーナーごとに報告の頻度（毎月・四半期・年1回）をプロパティーで持ち、次回報告予定日から逆算してタスクを作る。更新業務と同じ考え方です。

報告を「気づいた人がやる」運用にしない。これだけで、報告の抜けは大きく減ります。

接触が途切れているオーナーを検知する

最も危険なのは、何のトラブルもなく、静かに接触が途切れているオーナーです。「直近90日で活動が記録されていないオーナー」をビューで出せるようにしておくと、解約の予兆を早く拾えます。

この検知を機能させるには、オーナーとの接触が必ずCRMに記録されていることが前提になります。記録が電話のメモ帳に留まっていると、検知は成立しません。報告の仕組み化と接触の記録は、セットで設計する必要があります。

管理ソフトとの棲み分けを先に決める

賃貸管理会社の多くは、既に賃貸管理ソフトを使っています。CRMを入れるときに最初に決めるべきは、どちらを「正」にするかです。

CRMに持たせないほうがよいもの

家賃の入出金明細、送金計算、原状回復費の精算内訳といった会計に近いデータは、管理ソフト側に残すのが基本です。CRMに二重で持つと、必ずどこかでずれます。

CRMが持つべきなのは、人と関係と経緯です。誰がオーナーで、いつ何を話し、次に何をするか。管理ソフトが持ちにくいのはこちらです。

「正」の向きを項目ごとに決める

物件情報や契約情報は、両方に存在します。この場合、項目ごとに「どちらを見て判断するか」を決め、片方向の同期にするのが安全です。双方向にすると、上書きの衝突が起きたときに原因を追えなくなります。

不動産CRM全体のデータ設計の考え方は不動産CRMのデータ設計、業界全体の設計観点は不動産業界のHubSpot活用ガイドをあわせてご覧ください。募集側の反響管理は不動産の追客管理をCRMで設計する、ポータルからの反響をCRMへ取り込む方式は不動産ポータルの反響をCRMに取り込むで扱っています。

よくある質問

賃貸管理のCRM設計について、ご相談の場でよくいただく質問をまとめました。

Q1. カスタムオブジェクトが使えないプランでも、賃貸管理の設計はできますか。

できます。物件を会社オブジェクトで代用し、オーナーをコンタクトとして紐づける構成が現実的です。会社に「物件」と「オーナー法人」が混在するため、区分プロパティーとビューで切り分けます。制約は、部屋単位の管理が難しくなることです。1棟貸しや戸建て中心であれば、この構成でも十分に回ります。

Q2. オーナーと入居者の情報が混ざらないようにするには、どうすればよいですか。

レコードへのアクセス権で担当者やチーム単位に絞る方法があります。チーム単位の権限設定には Professional または Enterprise が必要です（レコードへのアクセス権を割り当てる）。ただし、権限だけに頼るより、オーナー向けの記録と入居者向けの記録を別のオブジェクトに置く設計のほうが事故が起きにくくなります。

Q3. 管理戸数が数千あります。部屋を全部レコードにすべきですか。

いきなり全部は入れないことをおすすめします。まず物件（棟）単位で入れ、部屋は「契約が発生したもの」から順に作る進め方が現実的です。全部屋を入れる価値が出るのは、空室の一覧をCRM側で持ちたい場合です。管理ソフトで空室一覧が十分に見えているなら、CRM側に持つ必要はありません。

Q4. 仲介部門と管理部門で、同じCRMを使うべきですか。

同じアカウントで使い、パイプラインとビューで分けるのが基本です。分けたアカウントにすると、オーナーが仲介の顧客でもある場合に情報が繋がりません。ただし、見える範囲は分けてください。仲介担当が全オーナーの管理情報を見られる必要はありません。

Q5. 既に管理ソフトがあるのに、CRMを入れる意味はありますか。

管理ソフトは「契約と入出金の記録」に強く、「まだ契約していない相手との経緯」には弱いのが一般的です。管理受託の営業、オーナーとの継続的な関係づくり、退去理由の蓄積といった領域は、CRM側が担うほうが自然です。逆に、入出金や送金計算をCRMへ持ってくることはおすすめしません。役割を重ねないことが、両方を活かす条件です。

まとめ

賃貸管理のCRM設計は、仲介の設計の延長では組めません。要点を整理します。

• 顧客が2種類いる前提で設計する。オーナーと入居者は利害が対立する場面があり、見える範囲を分ける必要があります
• オーナー・物件・部屋・入居者の4つを、規模と粒度で割り当てる。部屋を分けるかどうかは「部屋ごとに状態を持つ必要があるか」で判断します
• 役割はプロパティーではなく関連付けラベルで持つ。1社が複数の役割で登場する実態は、プロパティーでは表現できません
• 管理受託と入退去はパイプラインを分ける。件数の多い日常業務が、件数の少ない営業案件を押し流すためです
• 管理ソフトとは項目ごとに「正」を決める。入出金はCRMに持たず、人と関係と経緯をCRMが持つ切り分けが安定します

最初の一歩としておすすめしたいのは、「直近1年で解約になった管理物件を5件挙げ、解約の予兆がいつ・どこに現れていたかを書き出す」ことです。予兆が記録に残っていなかったなら、それが今のデータモデルに足りていないものです。全体像を描く前に、この5件から必要な項目が見えてきます。

そのうえで、まずはオーナーと物件の関係だけを正しく持つ。部屋と入居者を足すのはその後で構いません。

自社の賃貸管理業務に合わせたデータモデルを具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の業務をうかがったうえで、設計の方向性をご提案します。