賃貸管理会社の家賃滞納・督促対応｜対応履歴の分散が二重連絡と報告漏れを生む

「督促の電話をかけたのは誰だっけ」「保証会社への連絡、もう済んでいたはず」――家賃滞納が発生するたびに、担当者の記憶とExcelのメモを頼りに対応履歴を追いかけていませんか。管理戸数が増えるほど、滞納対応は「たまに起きる例外処理」から「毎月一定数発生する定常業務」に変わります。それなのに、対応履歴の管理は属人的なままという管理会社は少なくありません。

先に、要点をまとめます。

• 家賃滞納の対応は保証会社・オーナー・入居者の三者が絡み、対応履歴が分散すると同じ入居者に二重で連絡する等のミスが起きやすい
• 督促は「いつまでに・誰が・何をしたか」の時系列記録が、法的手続きに進んだ際の証跡としても重要になる
• 対応履歴を一元管理できれば、担当者不在時の引き継ぎや、複数物件を抱えるオーナーへの状況説明もスムーズになる
• どこまで自社の仕組みで対応し、どこから弁護士や保証会社に委ねるかの線引きを明確にしておくことが、トラブル拡大を防ぐ

本記事では、賃貸管理会社における家賃滞納・督促対応の実務を整理したうえで、対応履歴をどう一元管理し、仕組みとして回していくかを具体的に書き下ろします。ただし、督促の具体的な法的手段（内容証明、支払督促、明渡訴訟等）に関する個別判断は弁護士等の専門家の領域であり、本記事はあくまで「社内の記録・情報共有の仕組み」という業務設計の観点に絞って解説します。なお、Excelでの管理から専用の仕組みへ移行すべきタイミングの見極め方については、後半で具体的な目安を説明します。

家賃滞納が起きたとき、管理会社は何をするのか

家賃滞納が発生すると、管理会社はまず入居者への連絡・保証会社への報告・オーナーへの状況共有という3方向の初動対応を行います。この初動の速さと正確さが、その後の解決までの期間を左右します。

賃貸借契約の多くは家賃保証会社の利用が前提になっており、滞納が起きた際の役割分担は契約形態によって異なります。入居者がオーナーや管理会社へ直接家賃を払う「代位弁済型」の契約では、滞納が起きた際にまず管理会社が状況を確認して保証会社へ報告し、保証会社が未払分を立て替えたうえで入居者へ請求・回収する流れになります。一方、家賃の集金自体を保証会社に任せる「収納代行型」では、入居者が保証会社の口座へ直接振り込むため、保証会社が集金窓口として滞納を即座に検知でき、督促の初動も保証会社が担います。管理会社は状況の把握とオーナーへの報告が主な役割になります（出典: 賃貸知識BANK「収納代行・代位弁済とは？保証会社が家賃を立替える仕組みの違いについて」、https://chintaichishiki-bank.com/knowledge/20230424-2/ ）。

保証会社の初動は比較的早く、初月の滞納であればSMS（ショートメッセージサービス）での連絡が基本の初期対応とされ、高齢者や生活保護受給者、外国人など連絡が取りづらい入居者については1か月目でも訪問による対応が行われることがあります（出典: 全国賃貸住宅新聞「家賃債務保証会社に聞いた、家賃集金・滞納対応業務の実態」、https://www.zenchin.com/news/post-8129.php ）。ここで管理会社に求められるのは、保証会社の対応状況をリアルタイムで把握し、オーナーからの問い合わせに即座に答えられる体制です。「保証会社に確認します、少々お待ちください」を繰り返すたびに、オーナーの管理会社に対する信頼は目減りしていきます。

督促の記録が重要になるのは、対応が長期化した場合です。督促を重ねても支払いがなく、契約解除や明渡請求といった法的手続きに進む可能性が出てきた段階では、「いつ・誰が・どのような方法で督促したか」という時系列の記録が、その後の手続きにおいて事実関係を整理する材料になります。督促の記録が担当者の記憶や個人のメモ帳に依存していると、担当者が異動・退職した際に経緯が追えなくなるリスクがあります。

なぜ滞納対応の履歴は分散しがちなのか

滞納対応の履歴が分散する最大の理由は、電話・メール・保証会社のポータル・社内のExcelという複数の経路に情報が発生し、それを1か所にまとめる仕組みがないためです。

滞納対応でやり取りされる情報は多岐にわたります。入居者への電話連絡の日時と内容、保証会社のポータルサイトでの手続き状況、オーナーへの報告メールの送信履歴、契約書や重要事項説明書に記載された保証内容の確認結果。これらは発生する場所も形式もバラバラで、担当者が個人の判断で「とりあえずExcelにメモしておく」「案件ごとにメールのフォルダを分けておく」といった自己流の管理に落ち着きがちです。

この状態には3つの弱点があります。1つめは、担当者不在時に他のメンバーが状況を把握できないこと。オーナーから「あの物件、どうなっている」と電話が来ても、担当者の机の周りを探すか、本人への連絡を待つしかありません。2つめは、同じ入居者に複数の担当者が重複して連絡してしまうリスクです。督促の連絡が重なると、入居者側の心証を悪化させ、かえって対応がこじれることがあります。3つめは、複数物件・複数オーナーを抱える管理会社ほど、案件数が増えて記憶での管理が破綻しやすいことです。管理戸数が一定規模を超えると、「今月、滞納中の案件が何件あって、それぞれどの段階か」を即答できる担当者は少なくなります。

物件管理システムと保証会社のシステムが連携し、申込や結果確認をポータル上で完結できる仕組みも増えてきていますが（出典: 全国賃貸住宅新聞「家賃債務保証会社に聞いた、家賃集金・滞納対応業務の実態」、https://www.zenchin.com/news/post-8129.php ）、保証会社とのやり取りが仕組み化されても、社内の「誰が・いつ・オーナーに何を報告したか」という記録が別管理のままでは、結局は同じ属人化の問題が残ります。滞納対応の仕組み化は、保証会社との連携だけでなく、社内の情報共有までを一体で設計する必要があります。

滞納発生から督促・保証会社連携・オーナー報告までの一連の流れを示すフロー図。入居者・保証会社・オーナーの3者と管理会社の間で発生する情報が、対応履歴として一元的に記録される仕組みを表している。

督促対応でやってはいけない対応とは

督促は「支払いを求める正当な行為」である一方、伝え方や頻度を誤ると入居者との関係が悪化し、かえって解決が遠のきます。感情的な言葉や過度な頻度の連絡は避け、事実と期限を淡々と伝えることが基本です。

督促の実務でしばしば指摘される注意点として、21時から翌8時までの時間帯に連絡すること、同日に何度も電話やメッセージを送るなど執拗な連絡を繰り返すこと、家族や勤務先といった第三者に滞納の事実を伝えることなどが挙げられます（出典: いえらぶパートナーズ「家賃滞納者への督促方法」、https://ielove-partners.co.jp/media/1572/ ）。これらは入居者の生活の平穏を害する行為やプライバシー侵害として問題視されやすく、管理会社としてのレピュテーションにも関わります。

現場でこうした「やってはいけない対応」が起きる背景には、担当者が「前回いつ、どう連絡したか」を把握できていないまま、焦って連絡を重ねてしまうという事情があります。対応履歴が一元管理されていれば、「前回の連絡から何日経っているか」「どのような約束を取り付けたか」を確認したうえで、次の一手を落ち着いて判断できます。逆に履歴が分からない状態では、督促の“やりすぎ”も“抜け漏れ”も起きやすくなります。

Excel管理と専用システム、何が違うのか

Excelでの滞納管理も一元管理の一種ですが、「同時に開けない」「検索性が低い」「通知の仕組みがない」という3点で、案件数が増えるほど限界が来ます。専用の仕組みは、この3点を解消することに価値があります。

多くの管理会社が最初に取る対応は、滞納案件を1枚のExcelシートで管理することです。案件数が少ないうちはこれで十分機能します。しかし管理戸数が増え、同時進行の滞納案件が二桁に乗ってくると、次のような限界が表面化します。

Excel管理そのものが悪いわけではなく、「案件数が少ない立ち上げ期の暫定手段」としては合理的です。問題は、案件数や担当者数が増えても同じ運用を続けてしまい、属人化が固定化することです。どのタイミングで専用の仕組みに移行するかは、「担当者が変わったときに、前任者に確認しないと状況が分からない案件が増えてきたか」を目安にすると判断しやすくなります。

記録を怠るとどうなるか｜よくある失敗例

記録の徹底を怠ると、二重連絡・報告漏れ・引き継ぎ不能という3つの失敗が典型的に起きます。いずれも「起きてから対処する」より「起きない仕組みを先に作る」方がコストは小さく済みます。

現場でよく見られる失敗の1つが、担当者交代のタイミングで起きる二重連絡です。前任者が既に督促を行い、支払いの約束を取り付けていたにもかかわらず、引き継ぎメモが不十分だったために後任者が同じ内容の督促を重ねて送ってしまう。入居者からすれば「話がついたはずなのに、また同じ連絡が来た」という不信感につながります。

もう1つは、オーナーへの報告漏れです。滞納が発生した時点では報告したものの、その後の進展（保証会社による代位弁済の実行や、支払い再開など）を報告し忘れ、オーナーが別の経路（保証会社からの通知等）で先に状況を知ってしまうケースです。管理会社としての情報提供の速さは、管理委託契約の継続可否にも関わる信頼の問題です。

3つめは、担当者の急な休職・退職による引き継ぎ不能です。記録が担当者個人のメモ帳やローカルのExcelに閉じていると、その担当者が抜けた瞬間に、進行中の案件の経緯が誰にも分からなくなります。これは滞納対応に限らず属人化業務全般に共通するリスクですが、法的手続きの期限が絡む滞納対応では、遅れが直接的な不利益に直結しやすい点で特に重大です。

これらの失敗は、いずれも「記録を残す文化がなかった」ことが根本原因ではなく、「記録を残す先が決まっていなかった」ことが原因であるケースがほとんどです。担当者個人の裁量に任せず、記録する場所と項目をあらかじめ仕組みとして用意しておくことが、失敗の予防線になります。

私たちなら滞納対応の記録基盤をこう設計する

ここからは、実際によりどころべーすで賃貸管理会社の滞納対応の仕組みを受託するとしたら、という前提で、具体的な設計の考え方を書き下ろします。

データ設計: 中心に据えるのは「滞納案件」という単位です。物件マスタ・入居者マスタ・オーナーマスタを、それぞれの物件IDでひもづけたうえで、滞納が発生した時点で1つの滞納案件レコードを起票します。滞納案件には、滞納開始月・滞納額・保証会社の契約種別（代位弁済型／収納代行型）・保証会社での手続き状況・オーナーへの報告履歴という項目を持たせます。督促のやり取り（電話・メール・書面）は、この滞納案件に紐づく時系列の対応ログとして1件ずつ記録します。担当者・日時・連絡手段・話した内容の要約・次のアクション予定日をログの必須項目にすることで、「前回いつ何を伝えたか」を誰でも即座に追える状態にします。

情報の流れ: 滞納の第一報は、多くの場合、入金確認の担当者が家賃の未入金に気づいた時点で発生します。この担当者が滞納案件を起票すると、案件担当（多くは管理担当者）に通知が飛び、担当者は入居者への連絡と並行して保証会社への報告状況を記録します。督促を重ねても改善が見られない案件は、一定の滞納月数や金額を超えた時点でダッシュボード上に「要エスカレーション」として表示され、管理責任者が法的手続きの要否を判断する材料にします。オーナーへは、滞納案件が発生した時点と、状況に進展があった時点の2つのタイミングで、自動生成した状況報告のドラフトを担当者が確認のうえ送付する流れにします。

AIの回答設計: 社内向けのナレッジbotに「A棟101号室の滞納対応、今どこまで進んでいる？」と尋ねると、滞納案件レコードと対応ログを参照し、「滞納2か月目、保証会社（収納代行型）が督促中。前回の入居者連絡は8月20日、次回確認予定は9月10日です」のように、現在のステータスと直近の対応履歴を要約して即答します。根拠データは、滞納案件レコードの現在ステータスと、紐づく対応ログの最新1〜2件です。管理責任者が複数物件を横断して状況を把握したいときに、担当者に電話をかけて聞き回る手間を省けます。

*デモ画面のイメージ:*

よりどころべーすのデモ画面(サンプルデータ)。不動産管理業向けダッシュボードで、物件・入居者・オーナー情報を一元管理する画面イメージ。実際の滞納案件・対応ログの管理はこの基盤の上に構築するイメージです。

権限・運用ルール: 対応ログの記録・閲覧は管理担当者全員に開放しつつ、法的手続きの要否判断や督促内容の最終確認は管理責任者のみが行える権限設計にします。督促の内容（電話で伝えた文言、送付した書面の控え）を全担当者が記録する運用を徹底しないと基盤が形骸化するため、対応ログの入力を「その日のうちに1行でも残す」というルールとして明文化し、未入力の案件は翌朝の朝礼で確認する運用フローとセットで設計します。

既存環境との連携・移行: 多くの管理会社では、保証会社ごとに専用のポータルサイトで手続きを進めているのが実態です。この基盤は保証会社のポータルを置き換えるものではなく、「保証会社での手続き状況を社内側に転記・記録する受け皿」として位置づけます。移行時は、現在進行中の滞納案件から優先的に基盤へ登録し、解決済みの過去案件は必要に応じて後追いで移行する段階移行が現実的です。

定着の仕掛け: 対応ログの入力負担を最小化するため、よくある連絡内容（「本人と電話で話し、○日までの支払いを約束」等）は定型文を選ぶだけで記録できるようにし、自由記述は補足のみで済むようにします。次回確認予定日を過ぎても未対応の案件は、担当者と管理責任者の両方に通知が届く設計にすることで、「対応したつもりで忘れていた」という抜け漏れを構造的に防ぎます。

こうした仕組みは、既製の賃貸管理SaaSでも入居者管理や契約管理の機能は用意されていますが、「滞納案件ごとの対応ログを時系列で記録し、社内向けAIが横断的に要約して答える」というところまで一体で作り込んでいる例は多くありません。パッケージ×スクラッチという構成であれば、既存の入居者管理・オーナー管理の機能はそのまま活かしつつ、滞納対応の記録という自社の運用に合わせた部分だけを個別に追加開発できます。要件定義もエンジニアが直接ヒアリングするため、「督促のログをどの粒度で残せば法的手続きの証跡として使えるか」「オーナー報告のタイミングをどこで区切るか」といった細部まで仕様に落とし込めます。

もちろん、ここに書いた設計はあくまで一般化した叩き台です。実際にはオーナーとの契約形態、利用している保証会社の種類、社内の承認フローによって最適な設計は変わります。まずは現状の滞納対応がどこで属人化しているかを整理するところから、一緒に要件を詰めていくのがよいステップです。

まとめ｜滞納対応の記録を仕組みにする

この記事を読んで持ち帰れることは、次の3点です。

• 滞納対応は入居者・保証会社・オーナーの3方向のやり取りが発生し、記録が分散すると対応の重複や遅れが起きやすいこと
• 対応履歴を時系列で一元管理することが、担当者不在時の引き継ぎや法的手続きに進んだ際の証跡整理に直結すること
• 仕組み化は保証会社との連携だけでなく、社内の情報共有まで含めて設計する必要があること

まずは今月発生している滞納案件を1つ取り上げて、「いつ・誰が・何をしたか」をどれだけすぐに答えられるか、社内で確認してみてください。もし即答できる人が1人しかいないなら、それは記録の仕組み化を検討するタイミングのサインです。

自社の滞納対応フローや保証会社との契約形態を踏まえた具体的な仕組みづくりについては、お気軽にご相談ください。

よくある質問

Q. 家賃滞納の督促は管理会社が直接行ってよいのですか？

A. 保証会社の契約形態によります。収納代行型では保証会社が集金窓口となり督促も主体的に行うため、管理会社は状況把握とオーナー報告が中心です。代位弁済型では管理会社が滞納を確認して保証会社へ報告する役割を担い、入居者への連絡も管理会社が行うケースがあります。いずれも督促の伝え方には配慮が必要で、内容証明や法的手続きが必要な段階になれば弁護士等の専門家に相談するのが基本です。

Q. 滞納対応の記録は具体的に何を残せばよいですか？

A. 最低限、滞納が発生した日、連絡した日時・手段・相手・内容の要約、次回確認予定日を時系列で記録します。これにより担当者が変わっても経緯を追え、法的手続きに進んだ際にも事実関係を整理しやすくなります。

Q. 保証会社のポータルと社内の記録は別々に管理してよいのですか？

A. 保証会社のポータルは保証会社側の手続き状況を確認する場として使い続けつつ、社内側では「その状況を社内の誰が把握し、オーナーにどう報告したか」を別途記録するのが現実的です。二重入力を避けるため、ポータルで確認した内容を社内の対応ログに要約転記する運用にすると負担を抑えられます。

Q. 導入にはどのくらいの期間がかかりますか？

A. よりどころべーすは最短1.5ヶ月での公開が目安です。既存の物件・入居者・オーナー管理機能をベースに、滞納案件の記録機能を追加する範囲であれば、大きな独自機能の追加がない限り比較的短期間で運用開始できます。