業務設計・支援事例
物件の販売状況を、使える記録へ。元付け業者への確認と基幹システムをつなぐAI電話
公開日：
よりひと多くの物件状況を確認し、回答を自社システムへ戻す作業があります。
ユウトCallforce編集部AIは売り出し状況、広告掲載可否、資料送付方法を聞き、物件IDへ結果を紐づけられます。よりひとメールやFAXで一覧が戻る場合や、担当者不在のかけ直しもあります。ユウトCallforce編集部電話で完了する範囲から始め、PDF・FAXは別工程として段階的に設計します。不動産の物件確認は、会話そのものは短くても、対象件数、担当者不在のかけ直し、メールやFAXの後処理が重なる業務です。物件の状態が古いままでは、広告掲載や購入検討者への案内にも影響するため、速さと正確さの両方が求められます。
対象となるのは、一棟物件を扱う不動産売買の企業です。多くの物件について元付け業者へ流通状況を確認し、新規登録物件には早く連絡したい一方、外注や社内の電話作業をどう効率化するかを検討していました。
Callforceでは、売り出し中・商談中・契約済みの確認から、広告掲載可否、資料送付、不在時の再発信、基幹システムへの記録までを整理します。電話で確かめることと、資料・記録を扱う工程をつなぐ支援内容を紹介します。
業務と支援内容
- 事業
- 一棟物件を扱う不動産売買・仲介
- 現在の業務
- 多くの流通状況を元付け業者へ確認
- 具体的な課題
- 大量の電話、担当者不在、メール・FAXの後処理
- Callforceの支援内容
- AIによる状態確認と自社基幹システムへの記録
物件確認は短い電話でも、件数と後処理が重い
対象は、一棟物件の売買を扱う不動産事業者様です。扱う物件は多岐にわたり、一定期間ごとに元付け業者へ電話し、現在も売り出し中か、商談中か、契約予定・契約済みかを確認しています。会話自体は一件一分前後でも、対象が多く、担当者不在によるかけ直しや記録作業が積み重なります。
確認できた内容は自社開発の基幹システムへ反映します。売り出し中なら広告掲載の可否を聞き、資料がなければ送付を依頼します。物件を複数持つ業者からは一覧をまとめて返してもらうこともあり、メールやFAX、手書きの丸印など回答形式が分かれます。
現在は外部業者へ依頼している工程もあり、社内で毎週まとめて対応する案も検討していました。Callforceでは、この定型の確認を切り出し、記録と後続処理へつながる電話を設計します。
電話の目的は営業ではなく、流通状態を正確に更新すること
最初の用途は、物件を売り込む電話ではありません。自社システムにある物件情報をもとに元付け業者へ連絡し、対象物件の現在の状態を聞き、広告掲載や資料送付の可否を確かめる確認業務です。結果の正確さが、その後に購入検討者へ案内できるかを左右します。
基本の会話は、会社名と対象物件を伝え、現在も売り出し中かを確認するところから始まります。売り出し中であれば広告掲載の可否と資料の有無を聞き、商談中・契約予定・契約済みならその状態を記録します。担当者が不在なら戻る時間を聞き、指定時刻に再発信する流れです。
AIが電話を完了したことだけを成果にすると、曖昧な回答がそのまま登録される危険があります。ステータスの選択肢、聞き直しの条件、判断できない回答を人へ回す基準を決め、更新内容を追跡できるようにする必要があります。
既存物件と新規物件では、発信条件を分ける
既存物件は、前回の流通確認から一定期間が経過したものを対象にします。基幹システムに確認日が残っていれば、30日経過などの条件で抽出し、元付け業者ごとにまとめて連絡できます。同じ業者が複数物件を持つ場合、一件ずつ別の電話をするより、一覧として確認する方が効率的です。
一方、新規登録物件は鮮度が価値になります。新しい物件の登録後は、曜日にかかわらず連絡する条件を整理し、売出状況・広告掲載・資料送付の項目を確かめます。対象件数を見極めながら、無理なく続けられる運用を考えています。
既存と新規を同じシナリオにせず、発信タイミング、冒頭の説明、確認項目、再発信回数を分けます。即時性を優先する新規と、重複を避けてまとめる既存では、AIへ渡すリストの作り方から異なります。
反響対応は、確認日を使って重複電話を防ぐ
同社には物件への問い合わせが継続的に寄せられ、複数の物件を広告に掲載しています。問い合わせが特定の人気物件へ集中すると、同じ元付け業者へ短期間に何度も状況確認をすることになります。相手にとっては、同じ質問を繰り返される負担になります。
そこで、問い合わせが入った時点で基幹システムの最終確認日とステータスを見ます。直近一週間以内など、十分新しい確認結果がある場合は再発信せず、その情報を使って資料送付へ進みます。情報が古い場合だけAIが電話し、売り出し中・商談中・契約済みなどを更新します。
確認結果を電話単位で保存するのではなく、物件IDへ紐づけることが重要です。問い合わせと物件、元付け業者、最終確認日を同じデータで見られれば、発信件数を抑えながら購入検討者へ早く回答できます。
電話の外側にあるPDF・メール・FAXを段階的に扱う
電話で口頭回答が得られるケースは比較的シンプルですが、一覧をメールやFAXで送り、手書きで返してもらう場合は別の自動化が必要です。返信PDFを読み、物件ごとの丸・ばつや注記を解釈し、基幹システムへ反映する工程まで一度に作ろうとすると、対象範囲が広がります。
まず電話だけで完了する確認を整え、メール送付、返信PDFの読み取り、FAX対応は段階を分けて設計します。人が読んでも判断しづらい筆跡や、物件を特定できない返信は、自動登録せず確認待ちに回します。
物件資料を自社用に整えて問い合わせ者へ送る工程は、電話の確認とは別に条件を定めます。これは電話の会話とは別の文書処理です。電話で取得する状態と資料加工・送付をつなぐには、入力項目と人の確認箇所を決め、既存システムで実現できる範囲を確認します。
自社基幹システムとの連携が運用の中心になる
同社は基幹システムを自社開発しており、柔軟に連携できる可能性があります。AIへ渡す情報は物件ID、物件名、元付け業者、電話番号、前回確認日、現在のステータスなど。AIから戻す情報は確認日時、回答者、売り出し状況、広告掲載可否、資料送付方法、再発信日時です。
重要なのは、AIが判断した内容を即時確定してよい項目と、人の確認を挟む項目を分けることです。口頭で「売り出し中」と明確に回答された場合と、メールで一覧を返すと言われた場合では、完了条件が違います。後者は返信待ちとして登録し、期限を過ぎたら担当者へ知らせます。
導入判断では、音声品質だけでなく、基幹システムから対象を抽出できるか、同じ物件への重複発信を防げるか、回答を正しく戻せるかをデモで確認します。電話とデータ更新を一つの業務として見る必要があります。
成果を作らず、三つの用途を順番に検証する
業務を、既存物件の定期確認、新規登録物件への即時確認、問い合わせが入った物件の確認と資料送付の三つに分けます。会員への面談案内へ用途を広げる場合も、物件確認とは対象・台本・情報の扱いを分けます。
ただし、最初から全用途を一括導入するのではなく、件数と会話が読みやすい確認業務から検証する方が安全です。平均通話時間、担当者接続までの回数、回答取得率、正しくシステムへ登録できた割合を測り、現在の外注費や社内工数と比較します。
開始前に対象と確認項目をそろえ、利用量と人へ残る工程を合わせて評価します。だからこそ、電話だけで完結する部分と、PDF・FAX・資料加工が必要な部分を分け、実現範囲と未解決事項を明示したうえで判断できる形にします。
