媒介契約書、重要事項説明の書面、契約書、そして更新のたびに増える覚書。支店ごとのキャビネットに年度別で積まれ、どの案件がどのファイルに綴じられているかは担当者しか知りません。担当者が異動・退職した案件でトラブルが起きると、対応の初動が「まず書庫を探す」から始まります。
賃貸借の更新は、期限のかなり前に貸主・借主それぞれへ話を通さないと条件の見直しが間に合いません。ところが管理の実体は担当者個人のカレンダーと、家賃管理用のExcelの色付けです。繁忙期に一件抜けると、そのまま次の期間まで条件を動かせなくなります。
物件情報サイト経由の問い合わせ、看板を見ての電話、既存入居者からの紹介。入口はばらばらで、追客の履歴は個人のメモアプリと通話履歴の中です。「あの物件、誰がいつまで追っていたのか」を社内で再現できないため、同じ客付けを二人で追うことも、そのまま放置されることも起きます。
敷金、礼金、仲介手数料、保証会社の保証料、火災保険、鍵交換。項目の並びも書き方も担当者のExcel任せなので、契約直前に「その費用は聞いていない」となって申込がひっくり返ります。誰がいつどの条件で提示したかも残らないため、言った・言わないの決着がつきません。
仲介手数料は請求先が分かれ、元付・客付で分ける取引も入ります。決済が終わったあとに「そちらで請求しましたか」と相手方の担当者に確認する電話が発生し、控えの保管場所も担当者ごとにばらばらです。
各段階で使うアプリは、名前を押すと詳細を見られます。
初期費用は項目を固定した見積として出し、誰がいつどの条件で提示したかを案件に残します。締結後は、媒介契約書、重要事項説明の書面、契約書、特約の付いた覚書までを一つの案件にまとめ、有資格者の記名がある版がどれかを版数で区別します。差し替えが起きたときに古い版が現場に出回らないことが、この業種では最優先です。
契約ごとに保存期限と更新期限を持たせ、期限が近い契約を日付順の一覧にします。取引の種類や書面の性質によって求められる保存年限は異なるため、一律の年数ではなく案件単位で期限を設定できることが実務上は重要です。毎朝のブリーフィングに「今日から通知の準備に入る契約」を担当者別で出せば、更新の取りこぼしは個人の記憶ではなく仕組みで止まります。
設備の故障や退去後の原状回復は、見積を取ってオーナーの承認を得るまで着手できません。見積の取得、社内での確認、オーナー承認、施工の依頼という流れを決裁として残すと、負担区分でもめやすい修繕費の経緯を後から追えます。オーナーごとの連絡窓口と所有物件は名簿側に持たせ、担当が替わっても対応履歴ごと引き継げる状態にします。
保存年限は取引の種類や書面の性質によって異なるため、製品側で一律の年数を決め打ちにはしていません。契約ごとに保存期限を設定し、期限が近いもの・過ぎたものを一覧で確認できるようにしています。年限そのものの判断は自社の運用ルールに合わせて設定してください。
署名そのものを行う機能は持っていません。すでに締結された契約データや、紙をスキャンしたPDFを案件・物件・当事者に紐づけて保管し、検索と期限管理を担う側です。締結の手段は今お使いのものを変えず、保管と更新管理だけを社内で一本にする使い方を想定しています。
遡ってすべてを電子化する必要はありません。更新期限が生きている契約と、問い合わせや係争の多い物件から先に登録し、原本の保管場所(支店名、キャビネット番号、ファイル番号)を項目として残す運用が現実的です。原本は現物のまま、所在だけ検索できる状態にするところから始められます。
名簿と契約は部署単位で閲覧範囲を分けられます。店舗をまたぐ共同仲介のときだけ対象の案件を共有する、といった運用ができます。誰でも全件を開ける状態にはしないという前提で権限を設計してください。
現時点で外部の物件情報サイトや流通機構との自動連携は持っていません。掲載の作業は今の手順のままで問題ありません。連携がなくても、どの入口から来た反響かを受付時に記録しておけば、追客から契約までの履歴は社内側で一本につながります。
説明と記名は資格を持つ人が行うものなので、AIがその責任を肩代わりすることはありません。AIが担うのは、保管された契約から更新期限や特約の該当箇所を拾い出す、提出前に項目の抜けを指摘する、といった手前の作業です。最終的な内容の確認は必ず人が行う前提で設計しています。
部署の単位で分けられます。支店内で完結する案件は支店の中だけで扱い、共同で追う案件だけを共有する形にできます。管理側から全体を横断して期限だけ確認する、という見方も取れます。