物件についてフォームから相談した後、別の店舗から連絡があり、希望条件を最初から説明し直す。店舗が複数ある不動産会社では、問い合わせ自体は届いていても、次に対応する人へ必要な情報が渡っていないことがあります。転送メールを増やすだけでは、誰が返答するのかまで明確になりません。
サイトを見直す際は、物件、問い合わせ、受付店舗、現在の担当店舗、対応履歴を分けてつなぎます。この記事では、不動産仲介会社の経営者やWeb担当者に向けて、架空の物件P-01への受付Q-01を店舗Aから店舗Bへ渡す設計例を示します。実際の引受可否や取引条件を決めるものではなく、フォーム・完了画面・通知・管理画面の改修範囲を整理するための例です。
転送できることと、相談を引き継げることは違う
まず、現在の問い合わせがどこへ届くかを確かめます。本部の共通窓口、物件を掲載した店舗、利用者が選んだ店舗など、入口によって受信先が違うかもしれません。サイトのボタンに書かれた店舗と、実際の通知先が一致しているかを、一件の流れでたどります。
店舗Aが受信し、担当エリアの店舗Bへメールを転送する運用なら、Bが受け取ったことをどこで確認しているかも見ます。送った側が「引継ぎ済み」、受ける側が「まだ確認前」と考えていれば、その間の問い合わせが宙に浮きます。転送した日時だけで、対応を始めた状態に変えないことが大切です。
Webの改修依頼では、「問い合わせを共有したい」という一言を具体化します。物件の情報が欠けるのか、相談内容がメールに残らないのか、引継ぎ先が不明なのか、受領の記録がないのかで、直す場所が変わります。現場で聞き直している質問を集め、入力欄が足りない問題と、入力済みの内容を渡せていない問題を分けてください。
後者なのにフォームの必須項目を増やすと、利用者の負担だけが大きくなります。すでに受け取っている希望条件を次の担当者が見られる形にする方が、先に必要かもしれません。新しい仕組みを選ぶ前に、一件の相談について、入口から返答までの情報の欠け方を確かめます。
物件IDと受付IDを分けて、同じ相談を追えるようにする
物件IDは対象の物件を、受付IDは一回の問い合わせを識別するための番号です。同じ物件に複数の人が問い合わせることも、一人が別々の物件を相談することもあるため、物件番号だけで問い合わせを管理しようとすると対応関係が曖昧になります。
物件詳細ページからフォームへ進んだ場合は、対象物件を引き継ぎ、送信前にも利用者が確認できるようにします。社内の番号だけでなく、ページで見ていた物件名や住戸など、自社で案内に用いる情報を組み合わせます。番号を利用者に手入力してもらう設計なら、入力間違いが起きたときにどう確かめるかも必要です。
いえらぶCLOUDの顧客管理の案内では、自社ホームページなどからの問い合わせを取り込み、問い合わせ物件の情報を扱う仕組みが説明されています。ここから参考にしたいのは、連絡先だけでなく、何を見て問い合わせたのかを一緒に扱う考え方です。現在使っているシステムで同じ連携ができるかは、個別に確認します。
架空例では、物件P-01に関する問い合わせへ受付Q-01を付けます。店舗Bへ引き継ぐときも、Q-01を別の新規受付として作り直さず、同じ相談をたどれる形にします。既存の仕組みで店舗ごとの番号が必要なら、元の受付番号との対応を残す方法を検討します。番号の形式を統一することより、元の相談へ戻れることが目的です。
一方、物件を指定しない相談もあります。希望条件から探したい人に、物件番号を必須入力させないようにします。「物件を指定した相談」と「条件からの相談」を区別して受け付け、後から提案した物件を関連付けられるかを確認します。物件が未定であることと、入力が欠けたことを同じ扱いにしない設計です。
受付店舗と、現在の担当店舗を同じ欄にしない
店舗名には複数の意味があります。ページを掲載した店舗、利用者が連絡を希望した店舗、最初に受け付けた店舗、現在対応する店舗です。すべてを一つの「店舗」欄で上書きすると、なぜそこへ問い合わせたのか、誰が最初に応対したのかを後から追いにくくなります。
次の表は、Q-01を引き継ぐ際の照合例です。AとBは架空の店舗名です。公開画面へ見せる内容と、担当者が管理する情報を分け、実際の受付方針に合わせて項目を調整します。
| 対応させる情報 | 架空Q-01での扱い | 利用者向け画面の確認 | 社内側で残すもの |
|---|---|---|---|
| 対象の物件 | P-01を相談対象として保持 | 送信前に対象物件が分かる | 物件IDと相談時点の対象 |
| 問い合わせ | Q-01を引継ぎ後も追える | 受付の控えで相談を特定できる | 元の入力内容と受付日時 |
| 店舗 | Aで受付、Bへ対応を依頼 | 受付窓口と次の連絡元の案内 | 受付店舗、現在の担当、変更履歴 |
| 対応履歴 | 済んだ説明と未回答を分ける | 追加で確認する内容が分かる | 応対内容、残る質問、次の行動 |
| 引継ぎ状態 | 依頼中と受領確認後を区別 | 確定していない担当を断言しない | 依頼先、受領した人、確認日時 |
フォームで店舗を選んでもらう場合、その選択が何を意味するかを明記します。「相談したい店舗」という希望なのか、必ずその店舗が対応する指定なのかで、完了画面の文言も変わります。対応店舗が後から決まる運用なのに「選択店舗の担当者から連絡します」と固定すると、実際の連絡元と食い違います。
利用者が店舗を判断できない場合の入口も確かめます。物件や用件から窓口で振り分ける運用なら、「店舗を相談して決めたい」などの選択肢を設ける考え方があります。ただし、共通窓口が実際に受けられることを確認してから表示します。未定を選べるようにした結果、通知先が空欄になる設計は避けます。
引継ぎの依頼と受領確認を、画面と通知で区別する
店舗AからBへ渡す際は、Aが依頼した段階と、Bが内容を確認した段階を区別します。管理画面の名前は自社で使いやすいものにできますが、「転送済み」の一つだけで両方を表さないようにします。確認前の案件を誰が見守るかも、担当者と決めておきます。
引継ぎ依頼には、物件P-01、受付Q-01、これまでに回答したこと、未回答の質問、次に必要な行動を関連付けます。履歴をすべて本文へ貼り付けるより、必要な記録へ戻れる場所を示す方が確認しやすい場合もあります。通知を読むだけで終える運用か、管理画面で受領を記録する運用かを確かめ、通知と記録の役割を分けます。
Bが対応できない場合の戻し先も決めます。別店舗を探すのか、Aが内容を確かめ直すのかが決まっていないと、依頼中のまま残ります。制作会社へは、通常の振分けだけでなく、受領できない理由の記録と、元の受付が確認できる表示まで相談します。戻された案件を、新しい問い合わせと混同しないことも要点です。
利用者向けには、社内の全履歴を見せる必要はありません。受け付けたこと、次にどの窓口が連絡するか、未確定ならどのように案内するかを、現場の運用に合わせて伝えます。担当店舗が変わるときも、確認していない返答時刻を約束せず、連絡元が変わることを説明できる形にします。
受付の控えは、問い合わせを送ったことの確認です。内見の日時や物件の確保、契約が決まったという意味を持たせないようにします。実際にどこまで受け付けたのかを事業者に確認し、フォームのボタン、完了画面、返信文の表現をそろえます。
対応履歴は、必要な範囲で共有する
聞き直しを減らすためでも、全店舗へ同じ情報を一律に見せる設計が必要とは限りません。誰がどの相談を確認するのかを決め、現在の受付方針や情報の取扱いと合わせます。店舗が同じブランド名でも、運営や共有の範囲が同じとは限らないため、制作側の判断で閲覧先を増やさないようにします。
いい生活の営業支援サービスの案内には、顧客情報の重複候補を知らせる機能や、店舗別の設定・権限管理が示されています。情報を集めることに加え、重複候補をどう確認し、誰が閲覧するかを考える参考になります。製品の説明だけで、自社の共有範囲が決まるわけではありません。
同じ電話番号や氏名の問い合わせが来ても、それだけで同じ相談と決めつけないことが大切です。家族が同じ連絡先を使う場合や、以前とは違う物件を相談する場合も考えられます。重複の可能性を担当者へ知らせることと、記録を一つにまとめることを分け、元の受付内容を失わない確認方法を決めます。
履歴には、本人が入力した希望と、担当者が補足したメモを区別して残します。「駅に近い物件を希望」と入力されたのか、担当者が会話からそう推測したのかでは、次の確認が変わります。電話で条件が変わった場合も、過去の入力を黙って置き換えるのではなく、変更内容と確認した時点をたどれるようにします。
共有のために、初回フォームへ大量の資料提出を追加することも避けたいところです。引継ぎに必要な情報が不足しているなら、何をどの段階で確認するかを決めます。公開フォーム、担当者からの追加確認、管理画面の記録を使い分け、必要な情報を必要な担当者が確認できる範囲へ整理します。
四つの場面を通して、改修範囲を決める
公開前の確認では、通常の問い合わせだけでなく、店舗未定、店舗変更、再問い合わせの場面を用意します。テスト用の物件と架空の連絡情報を使い、入力、完了画面、受付の控え、社内通知、担当者側の記録を一続きで確認します。本番の顧客記録に混ざらない方法も先に決めておきます。
通常の場面では、詳細ページで選んだ物件が送信前の画面と受付記録に残るかを見ます。店舗未定の場面では、利用者が無理に選ばなくても受付先が決まるかを見ます。どちらも画面の表示だけではなく、通知先で対象と用件を読み取れることまで確認します。
スマートフォンでも物件名と店舗名が途中で切れず、入力を修正して戻った後に選択内容が保たれるかを確認します。
店舗変更では、Aが依頼した直後と、Bが受領した後の表示を比べます。元の受付番号で相談を追えるか、回答済みの内容が残るか、まだ返答していない質問が分かるかを確認します。Bが受領できない場合も試し、Aがその状態に気付けるかを見ます。
再問い合わせでは、同じ物件の続きなのか、別物件についての新しい相談なのかを確認できるかが要点です。候補を通知する仕組みがある場合は、誤ってまとめたくない二つの受付でも試します。「同じ人らしい」という理由だけで、異なる希望条件や担当店舗が上書きされないことを確かめます。
制作会社へ渡す資料は、現在のフォーム、返信文、通知先の一覧、物件の識別方法、店舗を変更する条件、引継ぎで必要な履歴です。そこから、表示文言の修正だけで足りる部分と、記録の項目追加や既存システムとの接続確認が必要な部分を分けます。接続できると決めつけず、実際に渡せる項目と受け取れる項目を照合します。
まず一件の相談を、利用者の入力から別店舗の受領確認まで追ってください。物件と受付の番号を残し、受付店舗と現在の担当を分け、回答済みと未回答を渡せるようにする。その対応関係が整うと、聞き直しが発生する場所を具体的な画面と通知の修正へ結び付けられます。
参照資料：いえらぶCLOUDの顧客管理案内、いい生活賃貸クラウド営業支援の案内。2026年9月21日確認。問い合わせ物件の情報・重複候補・店舗別設定の説明を参照。自社での接続や共有可否、導入効果を保証するものではありません。
