住宅会社の来場前アンケートを商談へ引き継ぐ方法｜項目・更新責任・利用時点の設計

来場前アンケートで予算、希望エリア、入居時期、家づくりの優先事項を聞いている。それなのに商談担当は、打ち合わせの冒頭でもう一度同じ質問をする。回答がないのではなく、追客で使うシステムと商談で使うシステムの間で止まっている状態です。

解決に必要なのは、大きなシステム統合ではありません。「どの顧客の、どの回答を、いつ、どの項目へ渡し、どちらを正しい値として扱うか」を片方向の仕様にします。反響受付や返信そのものを見直したい場合は、不動産反響の対応設計が別の入口になります。

先に、引き継ぎ元・引き継ぎ先・顧客IDを固定する

今回の引き継ぎ元は、来場前アンケートの回答を受け付け、予約まで追うシステムです。引き継ぎ先は、商談担当が提案や見積もりの前に開くシステムです。最初にこの方向を一本に固定します。

氏名だけで一致させると、同姓同名や漢字・カナの違いを判定できません。顧客IDがない場合は、自動で新規登録せず、候補を人が確認します。複数システムを残したまま役割を分ける考え方は、CRMを併用するときの原本と更新方向で詳しく整理しています。

項目対応表は、名前だけでなく型と選択肢まで書く

「予算を予算へ渡す」だけでは仕様になりません。引き継ぎ元の設問、保存される値、引き継ぎ先の項目名、型、空欄時の扱いを一行にします。設問名が同じでも、自由記述と選択式では扱いが違います。

選択肢には表示名とは別に変わりにくいコードを持たせます。たとえば表示を「半年以内」から「6か月以内」へ直しても、同じ意味ならコードは変えません。項目名・型・目的・選択肢を先に決める手順は、CRM構築前のデータ定義書も参考になります。物件名や顧客名の表記をそろえる範囲は、CRMの物件名・顧客名ルールと分けて管理してください。

実例では、設問と選択肢を対応させてボタンで登録・更新する

Cocoliveとダイテックは2026年8月19日、追客・商談管理サービスと住宅営業向け商談システムの連携を発表しました。発表では、顧客の基本情報と来場前アンケート回答を引き継ぎ、元のアンケート設問を引き継ぎ先の設問・選択肢へ対応づけられると説明しています。

また、顧客詳細画面のボタンから顧客登録または情報更新を行い、商談側では来場前の回答を見ながら提案や概算見積もりへ進む利用場面が示されています。これは両社が公表した製品間連携の内容です。リアルタイム、完全自動、双方向の同期や商談成果を示すものではありません。

正本、空欄、競合、上書きのルールを一枚にする

片方向でも、更新ルールがなければ回答が消えます。次の四つを項目対応表の横に書きます。

• 正本：来場前に顧客が入力した回答は、引き継ぎ元を正本にする。
• 空欄：元が空欄なら、引き継ぎ先の既存値を空欄で上書きしない。
• 競合：両側に異なる値がある場合は自動で選ばず、更新日時と入力者を表示して担当者が判断する。
• 上書き：来場前回答用の項目だけを更新対象にし、商談中のヒアリングメモは触らない。

来場前の「予算帯」と、商談後に確認した「資金計画上の予算」を同じ欄にすると、最初の希望が見えなくなります。事前回答と商談確認を分け、差分そのものを会話の材料にします。

商談前・商談中・商談後で使う値を分ける

来場の受付自体をQRやスマホへ変える話は、スマホで来場データを記録する方法の範囲です。今回は、すでに取れた回答を商談へ渡すところだけを扱います。

受入テストは正常系より例外から作る

本番で試す前に、個人を特定しないテストデータで次のケースを通します。画面に値が見えたかだけでなく、更新してはいけない項目が変わっていないことも確認します。

効果は、転記と聞き直しが残った場所で測る

連携の効果を成約率だけで判断すると、商談担当、商品、来場経路など別の要因が混ざります。まず運用に近い四つを同じ期間で記録します。

• 商談前に担当者が手入力し直したアンケート項目
• 引き継ぎ先で欠けていた必須回答
• 登録・更新に失敗した顧客と失敗理由
• 顧客へ同じ質問を繰り返した項目

数が増えたら「入力を徹底する」で終わらせず、項目対応、選択肢、ID、実行時点のどこで止まったかに戻します。

来週始めるためのチェックリスト

1. 引き継ぎ元と引き継ぎ先を一つずつ決める。
2. 両方で保持できる顧客IDまたは連携IDを確認する。
3. 次回商談で実際に使うアンケート項目だけを選ぶ。
4. 項目名、型、選択肢コード、空欄ルールを対応表にする。
5. 来場前回答の正本と、商談側で編集できる項目を分ける。
6. 新規・更新・空欄・不一致・重複・失敗のテストを通す。
7. 再入力、欠け、失敗、聞き直しを月次で確認する担当を決める。