JP5875391B2 - 建築顧客支援システム - Google Patents

Description

本発明は、建築顧客支援システムに関し、特に、住居のリフォーム、増改築などの施工推奨時期を顧客に通知する建築顧客支援システムに関する。

特許文献１には、ネットワークを介して顧客専用の建築スケジュールを閲覧することによって、建築スケジュールを確認する建築スケジュール表示システムが開示されている。この建築スケジュール表示システムは、ネットワークを介して顧客に対して建築関連情報を提供する情報提供サイトを有し、情報提供サイトで新築、建て替え、増改築の建築種別と、建築着手時期の情報を入力して会員登録をおこなうための会員登録手段が設けられていて、建築種別に対応する複数種類の一般的な建築スケジュールモデルの中から顧客が会員登録の際に入力した建築種別により一つの建築スケジュールモデルを選択して、顧客が会員登録した日と、会員登録時に入力した建築着手時期に基づき実際の日に対応する顧客専用の建築スケジュールを作成して会員登録日以降の任意の日に情報提供サイトで閲覧可能とする建築スケジュール作成手段が設けられている。

特開２００２−１４０３８９号公報

しかし、特許文献１に開示されている建築スケジュール表示システムは、建築後に顧客に対するアフターフォローをすることには不向きである。通常、例えば、新築物件は、数年或いは数十年も経過すればリフォームを行うであろうし、増改築を行うこともあろう。係る場合に、顧客に対して適切な対応ができなければ、顧客満足度は向上しない。

そこで、本発明は、建築予定のスケジュールを有効利用することで、顧客に対するアフターフォローに好適な建築顧客支援システムを提供することを課題とする。

上記の課題を解決するために、本発明の建築顧客支援システムは、
各顧客の氏名、住所、連絡先、施工履歴、施工予定完了日時、リフォーム対象に係る交換推奨情報が格納されている格納媒体と、
前記格納媒体を参照して所定期日内に施工予定完了日時が到来する顧客の住所と前記施工履歴と前記交換推奨情報とに基づき施工推奨時期が到来する顧客を特定する特定手段とを備える。

また、本発明の建築顧客支援システムは、前記特定手段によって特定された顧客に対して前記施工推奨時期を通知する通知手段を備えたり、さらに、前記通知手段による通知先からの予約を受け付ける受付手段を備えたりしてもよい。

さらに、前記特定手段によって特定された顧客の氏名及び連絡先を再度特定するリマインダ手段と、前記受付手段によって受け付けられた予約元の住所と前記施工予定先の住所とに基づいて前記リマインダ手段による特定対象をフィルタリングするフィルタ手段とを備えることもできる。

以下、本発明の実施形態について、図面を参照して説明する。

図１は、本発明の実施形態の建築顧客支援システムの模式的な構成を示すブロック図である。図１には、以下説明する、管理者用情報処理装置１００と、データベース（以下、「ＤＢ」と称する）２００と、顧客用情報処理装置３００と、ネットワーク４００とを示している。

管理者用情報処理装置１００は、リフォーム業者の管理者等が操作するものであり、ＤＢ２００に対して必要な情報を入力したり、ＤＢ２００内に格納されている顧客情報に基づいて顧客に対する情報提供を行ったりするためのものである。管理者用情報処理装置１００としては、専用機を用いることもできるし、汎用的なパーソナルコンピュータ等を用いることもできる。

また、管理者用情報処理装置１００は、本実施形態では、以下説明する、特定手段１１０と、通知手段１２０と、受付手段１３０とを備える。

特定手段１１０は、ＤＢ２００に格納されている各種情報に基づいて施工推奨時期を通知する顧客を特定するものである。特定手段１１０は、後述する、読出手段１１２と、リマインダ手段１１４と、フィルタ手段１１６とを備える。なお、施工推奨時期とは、施工日を含む施工履歴と部品等の交換推奨時期を示す情報とに基づき算出されるものである。

通知手段１２０は、主として、特定手段１１０によって特定された顧客の連絡先に対して施工推奨時期、或いは、顧客にとって有益な情報を通知するものである。顧客にとって有益な情報を通知としては、ランニングコストが安価な新製品の紹介であったり、御用聞きに伺うといったものであったり、リフォームなどの無料見積・査定に伺うといったものであったり、物件のリフォーム対象についてのリフォーム時期の診断を行うといったものなど種々のものが考えられる。また、通知手段１２０は、所定の施工予約受付数に到達した場合に、施工推奨時期の通知済みの顧客の連絡先に対して、その旨を通知するものでもある。

ここでは、具体的な通知方法としては、ファクシミリ、ｅメールなどのいずれかを用いることができるが、ｅメールを用いることが望ましい。これは、施工推奨時期が通知される顧客が複数ある場合に、複数の顧客から同じようなタイミングで施工予約がなされたことによって、予約のダブルブッキングが生じることがないように、略リアルタイムでＤＢ２００の更新をすることができるためである。

すなわち、複数の顧客から同じようなタイミングで施工予約がなされた場合には、最先の顧客からの予約を受け付け、他の顧客からの予約は受け付けないようにすることが必要であり、このためには、複数の電話オペレータが対応するといった手法ではなく、ｅメールを受信したら、ＤＢ２００のスケジュールの最新状況を確認してスケジュールが空いて入れば予約を受け付けるとともに、即座に、ＤＢ２００のスケジュールを更新するようにすればよい。一方、ＤＢ２００のスケジュールの最新状況を確認してスケジュールが空いて入れば予約を受けられない旨を返信すればよい。

もっとも、通知手段１２０を備えることは必須ではなく、通知手段１２０に代えて、例えば、電話オペレータなどが電話で顧客に施工推奨時期を知らせるようにしてもよい。

受付手段１３０は、通知手段１２０による通知に応じて、或いは、自発的に、顧客からなされる施工予約を受け付けるものである。ここでの具体的な受け付けには、例えばｅメール或いはファクシミリを用いることができる。

読出手段１１２は、ＤＢ２００に格納されているスケジュールを参照して、所定の期日内（例えば、当該参照日から１カ月以内）に到来する施工予定完了日時に対応する施工予定の顧客（例えば、顧客Ａ）の住所（例えば、○○区××町・・・）を読み出し、当該住所に基づいてＤＢ２００に格納されている顧客情報を参照することによって、当該住所に対応する住所（例えば、○○区△△町・・・、又は、○○区○○町・・・）を含んでいて、かつ、施工履歴と交換推奨情報とに基づき施工推奨時期が到来する顧客の氏名（例えば、Ｂ，Ｃ）及び連絡先（例えば、aaa@...、又は、bbb@...）を読み出すものである。

上記の「当該住所に対応する住所」とは、例えば、当該住所と市町村区まで住所が共通している、その隣接市町村区である、当該住所から所定距離内である、或いは、当該住所とリフォーム業者所在地とを結ぶ地域に割り当てられているものといったような条件を満たす住所とすればよい。

交換推奨情報は、例えば、リフォーム業者内の管理者等が例えば施工対象事項毎に管理者用情報処理装置１００を通じてＤＢ２００に登録しておけばよい。例示すると、水周りリフォームであれば、前回の水周りリフォームから例えば約１０年経過するタイミングが施工推奨時期となるようにしておくことが考えられるので、前回の水周りリフォームから１０年後となったときに、読出手段１１２によってピックアップされるようにしておけばよい。或いは、洗面台など各種製品には、通常、そのメーカ保証期間があることから、その期間に基づく時期となったときに、読出手段１１２によってピックアップされるようにしておけばよい。

なお、特定手段１１０は、顧客の氏名及び連絡先の読み出しに際して、施工推奨対象の種別なども考慮して、施工推奨時期を通知すべき顧客の氏名及び連絡先を特定することが好ましい。これは、簡易な部品交換作業とは異なり、丸一日リフォーム作業が必要な場合には、施工推奨対象が到来する場合には、敢えて、本実施形態の建築顧客支援システムにおいて通知をするよりも、別途、顧客が都合の良い日に訪問した方が好ましいからという理由である。このことは、複数日に亘ってリフォーム作業が必要な場合であって、その最終日も終日必要である場合にもあてはまる。

リマインダ手段１１４は、施工推奨時期が到来する顧客の氏名及び連絡先を、例えば、施工予定完了日時の１週間前などに再度特定するものである。リマインダ手段１１４を備えると、施工予約をしようとしていた顧客が予約忘却することを防止できることから、リフォーム業者等にとっても施工予約による売上向上に寄与するという利点がある。

フィルタ手段１１６は、受付手段１３０によって受け付けられた施工予約元の顧客の住所と当該住所に対応する施工予定先の住所とに基づいて、リマインダ手段１１４による特定対象をフィルタリングする、或いは、リマインダ手段１１４による特定に先立って所要のものを読み出し対象から予めフィルタリングしておくものである。フィルタ手段１１６を備えることによって、施工予約元、施工予定先に対して無意味な通知をすること、及び、これに基づく予約トラブルの未然防止が期待できる。

さらに、フィルタ手段１１６のフィルタリング処理のための判断材料として、住所情報に加えて地図情報、或いは、郵便番号情報を含めるとよい。こうすると、例えば、以下のような条件の場合に、リフォーム作業の効率化を図ることができる。

（条件１）
顧客Ａ，Ｂ宅が相互に比較的近い距離に位置し、顧客Ｃ宅がリフォーム業者所在地と顧客Ａ宅との略中間地点に位置していたとする。
（条件２）
顧客Ａが施工予定先の顧客であり、かつ、顧客Ｂ，Ｃが通知手段１１２による施工推奨時期が到来する旨の通知対象の顧客であったとする。
（条件３）
顧客Ａ宅のリフォーム完了日であって、その完了後の時間帯で顧客Ｃ宅から施工予約があったとする。

係る条件の場合には、仮に、顧客Ｂ宅からの施工予約があったとしても、顧客Ｃ宅の施工完了後に顧客Ｂ宅の施工を受けたのでは、顧客Ｃ宅から顧客Ｂ宅までの相対的に長い移動時間がかかるので作業効率が悪い。したがって、地図情報も考慮することで、顧客Ｂ宅に対してはフィルタ手段１１６によってフィルタリングすることで、リマインダ通知を行わないようにすることも一法である。

具体的には、顧客Ｃ宅からの施工予約があった場合には、顧客Ｃ宅とリフォーム業者所在地とを結ぶエリアから外れた住所の顧客の連絡先をフィルタリングすればよい。

ここで、上記例においては、仮に、顧客Ｂ宅もリフォーム予約をしようとしていた場合には、フィルタリング処理によって顧客Ｂ宛てのリマインダ通知を行わないとすれば、その結果として、顧客Ｂ宅からのリフォーム予約を取り逃がす可能性がある。これでは、顧客Ｂのようにフィルタリングによってリマインダ通知対象外となった顧客に対する十分なアフターフォローを行っているとは言えないので、リマインダ通知対象外となった顧客宅付近に提携先のリフォーム業者が存在するような場合には、それらの顧客宛てに、別途、提携先のリフォーム業者への相談、リフォーム予約を促すような通知を行ってもよい。逆に言えば、提携先のリフォーム業者が存在しなかったとしても、近所のリフォーム業者への相談、リフォーム予約を促すような通知を行ってもよい。こうすれば、顧客Ｂ宅の付近が所在地であるリフォーム業者に対して顧客Ｂに紹介することで、そのリフォーム業者と提携を図るといったことも可能となろう。

また、例えば、上記各条件１〜３に対して、下記条件が付加されたとする。
（条件４）
顧客Ａ宅のリフォーム完了時刻が例えば正午、顧客Ｃ宅での施工開始時刻が例えば１６時だったとする。

係る条件の場合には、顧客Ａ宅のリフォーム完了にリフォーム業者が一度会社に戻ってから再び顧客Ｃ宅のリフォームに出向くのは効率が悪い一方で、顧客Ａ，Ｃ宅からあまりに遠方の顧客からの施工に応じるほどの時間は見込めないといえる。

このような場合、顧客Ａ宅のリフォーム完了から顧客Ｃ宅での施工開始までの間に、顧客Ａ宅と顧客Ｃ宅との間のエリアの住所の顧客宅（例えば、顧客Ｂ宅）が連絡先として選定される一方で、顧客Ａ，Ｃ宅を結ぶ地域から離れた地域が住所となる顧客は選定されないような条件でフィルタリングすればよい。

ＤＢ２００は、管理者用情報処理装置１００に係るリフォーム業者の各顧客の氏名、住所、連絡先、施工履歴を含む顧客情報と、施工予定先の住所及び日時を含むスケジュールと、施工推奨時期を求めるために必要な部品等の交換推奨情報とが格納される格納媒体である。

ＤＢ２００に格納される各種情報については、図２を用いて後述するが、例えば、マンションのような集合住宅では、いわゆる管理会社がマンション管理を行っていることもある。この種の管理会社では、どのようなリフォームを行ったかということは非常に重要である。なぜなら、例えば、マンションの場合には、マンション内の配管詰まりを防止するために、配管内を定期的に高圧洗浄することがあるが、係る場合には、配管の一部がリフォームによって、例えば鉄管から塩化ビニール管に変わっていたとしたら、その継手等に対して悪影響を及ぼさないように洗浄条件を変更すべき場合もあるという理由からである。したがって、ＤＢ２００には、リフォーム等に関する様々な情報を格納するとよい。

顧客用情報処理装置３００は、管理者用情報処理装置１００に係る顧客が操作するものであり、管理者用情報処理装置１００からネットワーク４００を通じて提供される情報を受信するとともに、当該情報に対する返答を送信するものである。顧客用情報処理装置３００としては、専用機を用いてもよいし、汎用的なパーソナルコンピュータ、電話機、ファクシミリ装置等としてもよい。

ネットワーク４００は、主として、管理者用情報処理装置１００と顧客用情報処理装置３００とを接続するものであり、典型的には、インターネットが挙げられるが、電話回線などを含む、他の通信回線を採用することも可能である。

なお、図１には、ネットワーク４００には、管理者用情報処理装置１００と顧客用情報処理装置３００とが一台ずつしか接続されていないように示されているが、実際には、顧客用情報処理装置３００が複数台接続されており、規模に応じて管理者用情報処理装置１００も複数台接続されていることが通常であろう。また、ＤＢ２００も図示しないイントラネットなどのネットワークに対して複数台が接続されていてもよい。

図２は、図１に示すＤＢ２００に格納されている情報の概要を示す図である。図２に示すように、ＤＢ２００に格納される情報は、各顧客の氏名、住所、連絡先、施工履歴を含む「顧客情報」と、リフォーム或いは増改築等の施工予定が決定している顧客の住所及び日時を含む「スケジュール」と、施工対象毎の「交換推奨情報」とが挙げられる。

「顧客情報」には、少なくとも、顧客の氏名、住所、連絡先、施工履歴を含めるようにしている。連絡先としては、電話番号・ファクシミリ番号・メールアドレス等、種々のものが考えられるが、既述のように、ダブルブッキングの問題を回避するためにはｅメールを用いることが望ましい。

もっとも、メールの通信環境が整っていない顧客も存在する可能性があるので、係る場合には、電話番号、ファクシミリ番号等の他の連絡先を用いればよい。施工履歴には、施工実施日、施工内容を含めるようにしている。施工内容としては、例えば、洗面台の取替を行った場合には、取り替えた洗面台のメーカ名、型番などの情報も含めるとよい。なお、以下説明する「スケジュール」の場合とは異なり、施工履歴には、施工実施時間まで含めなくてよく、施工実施日で足りる。

「スケジュール」には、施工予定日時、施工予定内容を含めるようにしている。施工予定日時としては、２０１２年１月１０日の１０：００〜１１：００などのような情報とすればよい。ここでいう、施工予定日時とは、施工が一日以内に完了する場合にはその日におけるものであり、施工が複数日に亘って行われる場合には施工完了予定日におけるものという意味である。なお、本実施形態では、施工予定日時としては、施工開始予定時刻はもとより、施工終了予定時刻が重要である。その後の施工予約に対して順調に対処していくためである。

また、施工予定内容としては、例えば、洗面台の取替を行うような場合には、取り替える洗面台のメーカ名、型番などの情報も含めるとよい。

「交換推奨情報」としては、施工対象事項毎に、対応する期間を格納すればよく、例えば、キッチン周りの部品交換として５年であるとか、洗面台の取替として１０年であるとか、期間と施工対象とを一対で格納すればよい。

つぎに、図１の建築顧客支援システムの動作概要について説明する。まず、図１の建築顧客支援システムの前提条件について説明する。

（前提条件）
・読出手段１１２に関しては、
（１）ＤＢ２００に格納されている「スケジュール」を参照した際に、当該参照日から例えば１カ月以内に到来する施工予定完了の日時に係る顧客の住所を読み出すこと、
（２）当該住所に基づいてＤＢ２００に格納されている顧客情報を参照した際に、当該住所と市町村区まで住所が共通していて、かつ、施工推奨時期が上記参照日から±３カ月以内に到来する顧客の氏名及び連絡先を読み出すこと、
が設定されていたとする。もちろん、この設定条件は、管理者が任意に選択して設定可能とすればよい。

・ＤＢ２００に格納されている情報としては、
（１）図２に示すように「顧客Ａ」宅では、「２０１１年１２月１５日１０時００分〜１１時００分」に「キッチンリフォーム」を行う予定であり、
（２）「顧客Ｂ」に係る施工履歴として「２００１年１２月２０日」に「洗面台取替」を行ったこと、
（３）「顧客Ｃ」に係る施工履歴として「１９９６年１１月１４日」に「クロス貼替」を行ったこと、
（４）「洗面台取替」に係る施工推奨時期が例えば１０年であり、「クロス貼替」に係る交換推奨情報が例えば１５年であること、
であったとする。

以上の前提の下では、図１の建築顧客支援システムの動作は以下のようになる。

（動作概要）
２０１１年１１月１５日になると、当該参照日から１カ月以内に施工予定完了の日時が到来する「２０１１年１２月１５日１０時００分〜１１時００分」に、「顧客Ａ」宅で「キッチンリフォーム」を行う予定であることがＤＢ２００に格納されているので、読出手段１１２がＤＢ２００に格納されているスケジュールを参照した場合には「顧客Ａ」の住所である「○○区××町・・・」が読み出される。

つぎに、読出手段１１２は、その住所「○○区××町・・・」に基づいてＤＢ２００に格納されている顧客情報等を参照し、当該住所に対応する住所として同一区内のもので、かつ、施工履歴と交換推奨情報とに基づき施工推奨時期が到来する顧客の氏名及び連絡先があれば、それを読み出すことになる。

ここでは、顧客Ｂの住所に着目すると、顧客Ａの住所と対比して「○○区」までが同一であり、しかも、顧客Ｂの施工履歴として「２００１年１２月２０日」に「洗面台取替」を行ったことが格納されているから、２０１１年１１月１５日現在では、前回の「洗面台取替」から約９年１１カ月が経過していることになる。

そして、「洗面台取替」に係る交換推奨情報が１０年であるから、顧客Ｂの「洗面台取替」についての施工推奨時期は、ＤＢ２００の参照日である２０１１年１１月１５日から±３カ月以内に到来するものであるから、顧客Ｂの氏名及び連絡先が読み出される。

また、顧客Ｃの住所に着目した場合も、顧客Ａの住所と対比して「○○区」までが同一であり、しかも、顧客Ｃの施工履歴として「１９９６年１１月１４日」に「クロス貼替」を行ったことが格納されているから、２０１１年１１月１５日現在では、前回の「クロス貼替」から約１４年１１カ月が経過していることになる。

そして、「クロス貼替」に係る交換推奨情報が１５年であるから、顧客Ｃの「クロス貼替」についての施工推奨時期は、ＤＢ２００の参照日である２０１１年１１月１５日から±３カ月以内に到来するので、顧客Ｃの氏名及び連絡先も読み出される。

ここでは、理解容易のため、特定手段１１０による、施工推奨対象の種別などに基づく顧客の連絡先の特定についての説明を割愛するが、既述のように、これらを考慮して施工推奨時期を通知すべき氏名及び連絡先を特定してもよい。

つぎに、通知手段１２０は、特定手段１１０によって特定された顧客の連絡先に対して、ｅメールによって施工推奨時期として施工予定日と同日で、かつ、施工予定完了時刻に対して移動時間、完了時間の若干の延長などを考慮して例えば３０分を加えて、「２０１１年１２月１５日１１時３０分以降」であれば施工可能である旨を通知する。

具体的には、２０１１年１２月１５日１１時００分に完了予定のリフォーム等の施工が、近所の別宅で予定されているので、その後に、お宅でもリフォーム等の施工が可能である、或いは、御用聞きに伺うことが可能である旨などの内容で通知をすればよい。

これらの通知は、ネットワーク４００を通じて送信され、それぞれ顧客Ｂ，Ｃの顧客用情報処理装置３００で受信されることになる。したがって、顧客Ｂ，Ｃは、それぞれ、当該ｅメールを参照することによって、「洗面台取替」、「クロス貼替」の時期が近付いていることを知ることができる。換言すると、リフォーム業者としては、このような通知によって、顧客Ｂ，Ｃからの潜在的な施工予約を見込むことができる。

なお、仮に、顧客Ｂ，Ｃのいずれかに、ｅメールを行うための通信環境が整っていなかった場合には、管理者用情報処理装置１００は、付帯するディスプレイに他の連絡先としての電話番号或いはファクシミリ番号を表示するなどして、管理者用情報処理装置１００の管理者に電話或いはファクシミリによる通知を促すとよい。

実際に、例えば、顧客Ｂが顧客用情報処理装置３００を操作することによって、施工業者宛てに施工予約のｅメールを送信したとすると、当該ｅメールは、ネットワーク４００を通じて、管理者用情報処理装置１００の受付手段１３０によって受信されることになる。

この際、最も好ましいのは、例えば、顧客Ｂから「２０１１年１２月１５日１３時００分以降」のように、顧客Ａ宅のリフォーム予定日と同日で、かつ、当該リフォーム完了時刻よりも後に、施工予約が入ることである。ただ、そうでなくとも、顧客Ｂであろうが顧客Ｃであろうが、施工予約が入れば、リフォーム業者の売上向上といった効果は得られるので、本実施形態の建築顧客支援システムを活用する意義はある。

つぎに、建築顧客支援システムの管理者は、顧客Ｂから「２０１１年１２月１５日１３時００分〜」の施工予約がされた場合には、管理者用情報処理装置１００を操作することによって、リフォーム内容に応じて、例えば、施工予定完了の日時として「２０１１年１２月１５日１３時００分〜１５時００分」という情報をＤＢ２００に格納すればよい。

（リマインダ処理）
その後に、この例では、施工予定日の一週間前の２０１１年１２月８日が到来すると、リマインダ手段１１４は、施工推奨時期が到来する顧客の氏名及び連絡先を再度特定する。

ここで、本実施形態では、フィルタ手段１１６は、リマインダ手段１１４による特定に先立ってフィルタリングをするようにしている。すなわち、本実施形態では、例えば、顧客Ｂからの施工予約の際に、顧客Ａ，Ｂを紐付けて、これらの一方に基づいてリマインダ手段１１４による特定の際には他方が読み出されないようにしている。

こうして、施工予定日である２０１１年１２月８日に顧客Ａ，Ｂ宅が登録されていることから、顧客Ａのスケジュールに基づいて顧客Ｂの氏名及び連絡先が読み出されないように、また、顧客Ｂのスケジュールに基づいて顧客Ａの氏名及び連絡先が読み出されないように、同日スケジュールの顧客については、フラグを立てるなどし、フラグに基づいてフィルタリング処理を行うとよい。

また、この場合、顧客Ｃに対して、顧客Ａ，Ｂの各々のスケジュールに基づくリマインダ通知を行うと、無用に、２通のリマインダ通知を行うことになるので、これを回避することも一法である。このために、例えば、リマインダ通知を一度送ったらその旨のフラグを立てるなどし、フラグに基づいてフィルタリング処理を行うとよい。

つぎに、通知手段１２０は、リマインダ手段１１４によって読み出され、フィルタ手段１１６によってフィルタリングされた後の特定顧客の連絡先に対して、例えばｅメールによってリマインダ通知を行う。

以上説明したように、本実施形態の建築顧客支援システムによれば、建築予定のスケジュールを有効利用することで、リフォーム等の時期のアドバイスを効果的に行えることになる。

本発明の実施形態の建築顧客支援システムの模式的な構成を示すブロック図である。 図１に示すＤＢ２００に格納されている情報の概要を示す図である。

１００ 管理者用情報処理装置
１１０ 特定手段
１１２ 読出手段
１１４ リマインダ手段
１１６ フィルタ手段
１２０ 通知手段
１３０ 受付手段
２００ ＤＢ
３００ 顧客用情報処理装置
４００ ネットワーク

Claims (4)

1. 各顧客の氏名、住所、連絡先、施工履歴、施工予定完了日時、リフォーム対象に係る交換推奨情報が格納されている格納媒体と、
   前記格納媒体を参照して所定期日内に施工予定完了日時が到来する顧客の住所と前記施工履歴と前記交換推奨情報とに基づき施工推奨時期が到来する顧客を特定する特定手段とを備える建築顧客支援システム。
2. さらに、前記特定手段によって特定された顧客に対して前記施工推奨時期を通知する通知手段を備える、請求項１記載の建築顧客支援システム。
3. さらに、前記通知手段による通知先からの予約を受け付ける受付手段を備える、請求項２記載の建築顧客支援システム。
4. さらに、前記特定手段によって特定された顧客の氏名及び連絡先を再度特定するリマインダ手段と、
   前記受付手段によって受け付けられた予約元の住所と当該住所に対応する施工予定先の住所とに基づいて前記リマインダ手段による特定対象をフィルタリングするフィルタ手段とを備える、請求項３記載の建築顧客支援システム。

Images