(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0011】
[第一実施形態]
以下、第一実施形態について説明する。
図1は、本実施形態に係る車検見積システム1のシステム構成を示す図である。
本実施形態の車検見積システム1は、ユーザに対して、複数の業者から出された車検にかかる見積額を一括で提供する、いわゆる、車検一括見積サービスを提供する情報処理システムである。なお、本実施形態における「車検」とは、自動車検査登録制度に従って実施する自動車(車両)の検査を指す。
この車検見積システム1は、
図1に示すように、情報処理装置であるサーバ装置10と、サーバ装置10にネットワーク(例えばインターネット等)を介して通信可能に接続される複数のユーザ端末20と、サーバ装置10にネットワークを介して通信可能に接続される複数の業者端末30と、を備えて構築されている。ここで、本実施形態において、ユーザ端末20は、車検代行を依頼するユーザが操作するコンピュータであり、業者端末30は、車検代行を実施する車検業者が管理及び操作するコンピュータであり、サーバ装置10は、ユーザと車検業者とを仲介する仲介者が管理するコンピュータである。
以下、このような車検見積システム1の各構成について詳細に説明する。
【0012】
[サーバ装置10の構成]
図2は、本実施形態のサーバ装置10の概略構成を示すブロック図である。
本実施形態のサーバ装置10は、コンピュータにより構成され、通信部11と、記憶部12と、制御部13と、等を含んで構成されている。
通信部11は、ネットワークに接続されており、ネットワークを介してユーザ端末20や、ネットワーク上のその他の装置と通信する。
【0013】
記憶部12は、例えばメモリ、ハードディスク等により構成された情報記録装置であり、各種情報や各種プログラムが記憶されている。
この記憶部12は、ユーザデータベース(ユーザDB12A)と、業者データベース(業者DB12B)と、車検履歴データベース(車検履歴DB12C)と、を含んで構成されている。
なお、ここでは、サーバ装置10の記憶部12に、ユーザDB12A、業者DB12B、及び車検履歴DB12Cが設けられる例を示すが、サーバ装置10とネットワークを介して通信可能に接続された他のデータサーバに、これらのユーザDB12A、業者DB12B、及び車検履歴DB12Cが設けられる構成としてもよい。
さらに、記憶部12には、サーバ装置10を情報処理装置として機能させるための情報処理プログラムが記憶されている。
【0014】
(ユーザDB12Aに記憶されるユーザ情報)
図3は、ユーザDB12Aに記録されるユーザ情報に含まれる各種情報の一例を示す図である。
ユーザDB12Aは、ユーザ毎のユーザ情報を記憶するデータベースである。このユーザ情報は、ユーザID、連絡先情報、所有車両情報等を含む。
ユーザIDは、個々のユーザを識別するための情報である。
連絡先情報は、ユーザの連絡先を記録した情報であり、例えばメールアドレスや電話番号、居所等が記録される。
【0015】
所有車両情報は、ユーザが所有する自動車に関する情報である。所有車両情報としては、例えば、ユーザが所有する自動者のメーカー名、車種(車検対象車両の自動車の種類)、年式または車台番号を示す車両情報を含む。
また、所有車両情報は、車両情報に関連付けられた自動車の状態や整備履歴や整備手帳を記録した整備情報を記録する。整備情報は、自動車の走行距離や、タイヤの溝深さ、整備箇所や整備項目、交換した部品等を記録したテキストデータを含んでいてもよい。また、整備情報に、整備手帳をキャプチャした画像データが記録されていてもよい。
【0016】
(業者DB12Bに記憶される業者情報)
図4は、業者DB12Bに記録される業者情報に含まれる各種情報の一例を示す図である。
業者DB12Bには、車検業者に関する業者情報が記憶されている。業者情報には、業者ID、業者連絡先情報、支払先情報、実績情報、見積不適合回数、優良見積回数等が含まれる。
業者IDは、車検業者を識別するための情報である。
業者連絡先情報は、車検業者の連絡先であるメールアドレスや、車検業者が公開するホームページのURL、車検業者の電話番号や住所等が記録されている。
支払先情報は、車検代行に係る実金額を支払う先の銀行口座等が記録されている。
【0017】
実績情報は、車検対象車両の自動車の車検代行に係る見積履歴、車検代行を実施した際の実金額履歴等を含む情報である。
見積履歴は、ユーザ端末20から車検依頼があり、業者端末30から車検代行に係る総見積額を含む見積提示情報が送信された場合に登録される情報であり、業者端末30からの見積提示情報を受信する毎に蓄積される。
ここで、本実施形態における総見積額は、上述のように、車検に係る法定費用と、車検業者の利益分である車検代行に係る代行手数料と、車検業者が実施する各作業の作業料(作業見積額)等を含む。また、車検業者が実施する各作業としては、車検時の検査作業や、車検を通すために必要な作業(例えば消耗品の交換作業)の他、車検後に実施される12か月点検等の車検業者毎のオプション作業も含まれる。実績情報の見積履歴としては、これらの、法定費用、代行手数料、作業見積額、及びこれらを合算した総見積額の他、見積時に予定される各作業の内容(作業予定)の履歴が記録されている。
また、実金額履歴は、車検業者が、車検対象車両の自動車に対して車検代行を行った際に、実際に車検代行に掛かった費用の履歴である。つまり、車検業者がユーザに選択されて実際に車検代行を実施した際に記録される。この実金額履歴には、見積履歴と同様、法定費用と、代行手数料と、車検時の各作業の作業料と、各作業の作業内容と、が含まれている。
【0018】
見積不適合回数は、実金額から総見積額を引いた差額が、第一閾値以上となった回数、つまり、実金額が総見積額よりも第一閾値以上高くなった回数である。
また、優良見積回数は、実金額から総見積額を引いた差額が0または負の値となる回数、つまり、実金額が総見積額以下となった回数である。
【0019】
(車検履歴DB12Cに記録される車検履歴情報)
車検履歴DB12Cには、車種ごとの車検履歴情報が記録されている。
車検履歴情報は、車種情報と、車検作業情報とを含む。
車種情報は、自動車の車種や年式等を記録する。
車検作業情報は、車種情報にて示される車両の車検時の情報である。この車検作業情報には、ユーザが依頼時に入力する整備情報と、実際に車検業者が車検時に実施した作業の作業内容と、その作業料と、が含まれる。
つまり、本実施形態では、業者情報の実績情報として、車検の作業内容の履歴を記録するとともに、車両毎に対しても車検の作業内容の履歴を記録する。これにより、業者毎の作業内容や作業料の傾向のみならず、特定の車両に係る作業内容や作業傾向をも容易に把握することが可能となる。
【0020】
(制御部13の機能構成)
制御部13は、CPU(Central Processing Unit)等の演算回路、RAM(Random Access Memory)等の記憶回路により構成される。制御部13は、記憶部12等に記憶されているプログラムをRAMに展開し、RAMに展開されたプログラムとの協働で、各種処理を実行する。
そして、制御部13は、記憶部12に記憶された情報処理プログラムを読み取り実行することで、
図2に示すように、依頼取得部131、依頼送信部132、見積受信部133、見積送信部134、完了内容取得部135、車検履歴蓄積部136、ユーザ決済取得部137、決済処理部138、回数カウント部139、依頼適正判定部140、差額要求部141等として機能する。
【0021】
依頼取得部131は、ユーザ端末20から、車検の見積を依頼する旨の見積依頼情報を取得する。見積依頼情報は、ユーザがユーザ端末20を操作することで入力される情報であり、車検対象車両であるユーザの自動車の車両情報、整備情報、車検を実施する地域に関する地域情報、及びユーザのメールアドレス等のユーザ連絡先情報を含む。
依頼送信部132は、見積依頼情報を取得した際に、複数の業者端末30に対して、総見積額を要求する見積要求情報を送信する。
見積受信部133は、業者端末30から、見積要求情報に対する総見積額を含む見積提示情報を受信する。
見積送信部134は、業者端末30から受信した見積提示情報に基づいて総見積額や作業見積額をユーザ端末20に送信する。なお、本実施形態では、見積送信部134は、各車検業者が出した総見積額を一覧表示させる見積一括表示コンテンツを生成及び更新する。この見積一括表示コンテンツは、見積依頼情報を送信したユーザが、ユーザID及びパスワードを入力することで閲覧可能な、インターネット上に公開された情報である。見積送信部134は、ユーザ端末20から見積一括表示コンテンツへのアクセスがあった場合に、ユーザ端末20に見積一括表示コンテンツを送信することで、総見積額や作業見積額を送信する。
【0022】
完了内容取得部135は、業者端末30から車検内容情報を受信する。車検内容情報は、車検業者が自動車の車検に係る各作業を完了させた後、車検業者により入力される情報である。この車検内容情報には、車検業者が車検を実施した車両に関する検査車両情報と、実際の車検代行作業に掛かる費用である実金額(法定費用、代行手数料、各作業の作業料の合計金額)が記録される。また、車検内容情報には、車検時に実施された各種作業の作業内容や、車検後に実施される12か月点検等のオプション作業内容も記録される。
また、車検内容情報として、実際に車検を行った車両が、見積額依頼情報に含まれた車両情報や整備情報と一致していたかを示す依頼適正情報が含まれていてもよい。
車検履歴蓄積部136は、見積依頼情報に含まれる車両情報及び整備情報と、車検内容情報に記録される作業内容及び作業料とを関連付けた車検履歴情報を生成し、車検履歴DB12Cに記録する。
【0023】
ユーザ決済取得部137は、ユーザから車検が依頼された後、ユーザが車検に掛かる費用を支払った旨のユーザ決済情報を取得する。本実施形態の車検見積システム1では、見積一括表示コンテンツを閲覧したユーザが、車検代行を依頼する車検業者を選択した後、選択した車検業者が提示した総見積額と、サービス利用料とを含む全見積額を仲介者に支払う。この支払いは、例えば銀行振込による支払であってもよく、クレジットカードを用いた支払であってもよい。本実施形態では、サーバ装置10は、銀行が管理する銀行管理サーバや、クレジットカード会社が管理するカード管理サーバと提携し、インターネットを介して通信可能に接続されている。このため、ユーザ決済取得部137は、ユーザから車検費用を支払った旨のユーザ決済情報を、銀行管理サーバやカード管理サーバから取得することができる。
【0024】
決済処理部138は、仲介者が車検業者に対して、車検内容情報に含まれる実金額に対応する金銭を支払う決済処理を実施する。本実施形態の車検見積システム1では、ユーザが、仲介者に対して総見積額に対応する金銭を支払った後、仲介者が車検業者に対して、実金額に対応する金銭を支払う。決済処理部138は、業者情報に記録されている支払先情報を参照し、銀行管理サーバに対して、車検業者の銀行口座に実金額を振込む旨の振込情報を送信する。
【0025】
回数カウント部139は、車検業者が車検代行を実施した後に提示した実金額から、車検業者が車検前に提示した総見積額を減算した差額が第一閾値以上となる回数をカウントする。差額が正の値となる場合は、総見積額より実金額が高く、仲介者が差額分を負担していることを意味する。差額が第一閾値以上となる場合は、総見積額と実金額とが大きく乖離しており、仲介者の負担が過大であることを意味する。回数カウント部139は、差額が第一閾値以上となった回数を見積不適合回数として車検業者毎にカウントし、業者情報の見積実績情報として記録する。
また、回数カウント部139は、差額が0以下となる(実金額が総見積額以下となる)回数を優良見積回数として車検業者毎にカウントし、業者情報の見積実績情報として記録する。
つまり、本実施形態の回数カウント部139は、見積不適合回数カウント部、及び、優良見積回数カウント部として機能する。
【0026】
依頼適正判定部140は、見積依頼情報に含まれる車両情報及び整備情報と、車検内容情報に含まれる検査車両情報及び作業内容とを比較することで、車検対象車両の自動車が、見積依頼時の車両情報や整備情報に合致するか否かを判定する。
差額要求部141は、依頼適正判定部140に、車検対象車両の自動車が、見積依頼時の車両情報や整備情報に合致していないと判定し、かつ、実金額から総見積額を減算した差額が正の値となる場合に、差額の支払いを要求する請求情報をユーザ端末20に送信する。
【0027】
[ユーザ端末20及び業者端末30の構成]
ユーザ端末20は、上述のように、ユーザが保有するコンピュータであり、例えばスマートフォンやタブレット端末、パーソナルコンピュータ等により構成される。つまり、ユーザ端末20は、各種情報を表示させる表示ディスプレイ、各種情報を入力操作するための入力操作部、インターネットを介してサーバ装置10等を通信する通信部、各種情報を記憶する記憶部、及びユーザ端末20を制御する制御部等を含んで構成される。
業者端末30は、上述のように、車検業者が保有及び管理するコンピュータであり、例えばスマートフォンやタブレット端末、パーソナルコンピュータ等により構成される。つまり、業者端末30は、各種情報を表示させる表示ディスプレイ、各種情報を入力操作するための入力操作部、インターネットを介してサーバ装置10等を通信する通信部、各種情報を記憶する記憶部、及び業者端末30を制御する制御部等を含んで構成される。
【0028】
[情報処理方法]
次に、上述したような車検見積システム1における情報処理方法について説明する。
図5は、サーバ装置10の情報処理方法を含む、車検見積システム1の車検見積方法を示すフローチャートである。
本実施形態の車検見積システム1では、ユーザが車検代行を行う車検業者を探す際、ユーザは、ユーザ端末20を操作して、サーバ装置10がインターネット上に公開する案内コンテンツにアクセスする。
図6は、案内コンテンツの一例を示す模式図である。
案内コンテンツ600は、車検の一括見積を案内するコンテンツであり、
図6に示すように、ユーザが車検代行を依頼する自動車のメーカーや車種等の車両情報を入力する車両情報入力欄601、整備情報を入力する整備情報入力欄602、郵便番号等の車検代行を依頼する地域を入力する地域指定入力欄603、ユーザの連絡先を入力する連絡先入力欄604等が設けられている。なお、
図6に示す例では、整備情報入力欄602として、整備手帳の画像データの位置を指定する旨の入力欄、走行距離を入力する入力欄を例示しているが、その他の入力欄が設けられていてもよい。例えばエンジンオイルの交換日を入力する入力欄等が別途設けられていてもよい。
そして、ユーザがユーザ端末20を操作して、案内コンテンツの案内に従って各種情報を入力すると、ユーザ端末20からサーバ装置10に車両情報、整備情報、車検を行う地域に関する地域情報、ユーザ連絡先情報等を含む見積依頼情報が送信される(ステップS201)。
【0029】
サーバ装置10では、依頼取得部131が、ユーザ端末20から見積依頼情報を受信すると(ステップS101)、依頼送信部132は、受信した車検依頼情報の地域情報に基づいて、業者DBから対応する地域の車検業者を抽出する(ステップS102)。なお、ステップS201において、ユーザが複数の地域を設定していてもよく、この場合、設定された全ての地域から車検業者を抽出する。
【0030】
また、依頼送信部132は、抽出した車検業者の見積実績情報に記録される見積不適合回数に応じた遅延時間を設定する(ステップS103)。つまり、依頼送信部132は、所定期間あたり(例えば直近1か月)の見積不適合回数が第二閾値以上となる車検業者に対して、見積不適合回数に応じて長くなる遅延時間を設定する。
【0031】
さらに、依頼送信部132は、車検履歴DB12Cから、ステップS101で受信した車両情報に対応する車種情報の車検履歴情報を抽出し、ステップS101で受信した整備情報に対応する車検作業情報を読み込む(ステップS104)。
つまり、依頼送信部132は、過去の車検履歴情報から、今回の車検対象車両の自動車と同じ車種であり、同様の整備状態の自動車に対する車検履歴情報を抽出する。
【0032】
この後、依頼送信部132は、ステップS102により抽出された車検業者の車検情報に記録される連絡情報に基づいて、各車検業者の業者端末30に見積要求情報を送信する(ステップS105)。この際、依頼送信部132は、見積依頼情報に基づく車両情報と、整備情報と、ステップS104で抽出した車検履歴情報の車検作業情報と、を含む見積要求情報を生成して業者端末30に送信する。
また、このステップS105では、依頼送信部132は、ステップS103で設定された遅延時間に基づいて見積要求情報を送信する。
つまり、依頼送信部132は、まず、見積不適合回数が第二閾値未満の車検業者の業者端末30に対して見積要求情報を送信する。そして、見積不適合回数が第二閾値未満の車検業者への見積要求情報の送信タイミングから、ステップS103で設定した遅延時間だけ遅延したタイミングで、見積不適合回数が第二閾値以上の車検業者の業者端末30に見積要求情報を送信する。
【0033】
業者端末30は、サーバ装置10から送信される見積要求情報を受信する(ステップS301)。車検業者は、業者端末30で見積要求情報を受信すると、車検対象車両の自動車の車検代行に係る総見積額を算出する。
ここで、従来の車検一括見積サービスでは、ユーザから入力される車検対象車両の情報は、メーカー名や車種や年式といった最も基本的な情報のみであるため、車両の詳細な内容が不明となる。したがって、従来では、法定費用と代行手数料とのみを加算した見積額か、あるいは、車種と年式から予想されるあいまいな見積額しか算出することができない。
しかしながら、本実施形態では、見積要求情報として、車両情報に加え、整備手帳の画像データ等、整備状況を知らせる整備情報が含まれる。さらには、見積要求情報に、過去の同様の整備状況の車検対象車両に対して実施された様々な車検業者による作業内容、各作業に係る作業料、過去の総見積額等を記録した車検作業情報が含まれる。このため、車検業者は、これらの情報を元にして、車検対象車両の自動車の車検代行を引き受ける場合のより正確な総見積額を算出することが可能となる。
【0034】
また、本実施形態では、車検業者は、車検代行に係る各作業内容の予定(作業予定)と、各作業見積額とを含む総見積額を算出する必要がある。これに対し、本実施形態では、見積要求情報に、過去の車検履歴情報の車検作業情報が含まれているので、車検作業情報を参照することで、必要な各作業予定を特定することも容易となる。なお、作業予定として、車検時に必須となる作業以外が含まれていてもよい。例えば、「法定12か月点検作業」とその作業見積額が含まれていてもよい。
そして、車検業者は、業者端末30を操作して、複数項目の作業予定と、作業見積額と、法定費用と、代行手数料と、総見積額と、を含む見積提示情報をサーバ装置10に送信する(ステップS302)
なお、業者端末30において、任意の見積額算出プログラムがインストールされ、当該見積額算出プログラムによって、総見積額が算出され、見積提示情報がサーバ装置10に送信されてもよい。
【0035】
サーバ装置10は、見積受信部133により、業者端末30から見積提示情報を受信する(ステップS106)。また、見積受信部133は、受信した見積提示情報を業者情報の実績情報として記録する。
ステップS106により、見積提示情報が受信されると、見積送信部134は、総見積額が、所定の下限額より低いか否かを判定する(ステップS107)。ここで、下限額は、車両情報及び整備情報に基づいて設定される金額である。例えば、所定期間(例えば直近半年間)の車検履歴情報から、同車種、同年式、整備情報が近い自動車に対する車検履歴情報を抽出し、これらの総見積額(または実金額)の平均値から車種や年式等に応じた所定の設定値を減算した値を下限額とする。
このステップS107で、Yesと判定された場合、つまり、業者端末30から受信した見積提示情報に含まれる総見積額が、車両情報及び整備情報に応じて設定される下限額よりも低い金額である場合、見積送信部134は、その総見積額を含む見積提示情報を送信した業者端末30の車検業者、及び当該総見積額をユーザ端末20に送信しない。つまり、本実施形態では、例えば法定金額を下回るような低い総見積額等、現実的にあり得ない車検の総見積額は、ユーザに提示されない。
なお、見積送信部134による、見積額の送信方法としては特に限定されないが、本実施形態では、ユーザ端末20からインターネットを介して閲覧可能な見積一括表示コンテンツ610(
図7参照)を作成し、ユーザ端末20から当該見積一括表示コンテンツ610へのアクセスがあった際に、当該見積一括表示コンテンツ610をユーザ端末20に送信する。つまり、見積送信部134は、見積提示情報に基づいて、見積一括表示コンテンツ610を更新し、見積一括表示コンテンツ610の更新を知らせる連絡情報をユーザ端末20に送信する。したがって、ステップS107においてYesと判定される場合は、見積送信部134は、見積一括表示コンテンツ610に、下限額よりも低い総見積額、及びその総見積額を出した車検業者の情報を記載しない。
【0036】
一方、ステップS107においてNoと判定される場合、つまり、総見積額が下限額よりも高い場合、見積送信部134は、受信した見積提示情報に基づいて、見積提示情報を送信した車検業者と、その車検業者が提示した総見積額にサービス利用料を加算した全見積額をユーザ端末20に送信する(ステップS108)。つまり、ステップS108では、見積送信部134は、見積提示情報に基づいて、見積一括表示コンテンツ610に、全見積額と、車検業者とを追加し、見積一括表示コンテンツ610の更新を知らせる連絡情報をユーザ端末20に送信する。
【0037】
ユーザ端末20において、ユーザがユーザID及びパスワードを用いて見積一括表示コンテンツ610にアクセスする操作を行うことで、見積送信部134が当該見積一括表示コンテンツ610をユーザ端末20に送信し、ユーザ端末20の表示ディスプレイに表示される(ステップS202)。
図7は、見積一括表示コンテンツ610の一例を示す図である。
見積一括表示コンテンツ610は、
図7に示すように、複数の車検業者名611と、全見積額612とのセットが、一覧表示されたコンテンツである。
なお、本例では、車検業者名611に、車検業者の名称のみが表示されているが、車検業者の場所、ユーザの自宅からの距離等が記録されていてもよい。
全見積額612は、上述したように、業者端末30から送信された見積提示情報に含まれる総見積額に、仲介者が設定したサービス利用料を加算した金額である。つまり、ユーザ端末20が見積一括表示コンテンツ610にアクセスすると、見積送信部134は、車検業者から提示された総見積額に対してサービス利用料を加算した全見積額をユーザに送信する。
【0038】
また、見積一括表示コンテンツ610では、所定期間あたり(例えば直近1か月)の優良見積回数が第三閾値以上である車検業者に対して、当該車検業者が優良業者である旨を示す優良情報613が表示される。つまり、見積送信部134は、優良見積回数が第三閾値以上となる車検業者に対して、優良業者である旨を示す優良情報613を送信する。
【0039】
この見積一括表示コンテンツ610には、
図7に示すように、さらに、車検を依頼する旨の依頼ボタン614、車検業者の詳細を表示させる旨の詳細ボタン615が、車検業者毎、つまり車検業者名611のそれぞれに対応して表示される。
依頼ボタン614は、ユーザが車検業者に車検代行を依頼する際に選択される入力ボタンである。ユーザによって依頼ボタン614が選択された際の処理については後述する。
【0040】
詳細ボタン615は、車検業者の詳細情報、及び、車検業者が出した、車検代行作業時の各作業予定と、各作業予定に対する見積額とを表示させる表示ボタンである。
図8は、詳細ボタン615が選択された際の見積一括表示コンテンツ610の一例を示す図である。
本実施形態では、見積送信部134は、
図7に示すような、各車検業者と、全見積額とを一覧表示させる初期表示状態の見積一括表示コンテンツ610を生成するとともに、詳細ボタン615が選択された際に、
図8に示すように、対象となる車検業者の下部に表示領域616を設け、その表示領域616内に車検時の作業予定617と、各作業予定に対する作業見積額618とを表示させる制御スクリプトを挿入する。つまり、本実施形態では、見積送信部134は、各車検業者が提示した総見積額と、仲介者が設定したサービス利用料とを加算した全見積額の他、車検業者が車検代行作業時に実施する各作業予定617と、その作業見積額618とを送信する。
なお、ここでは、
図8に示すように、見積一括表示コンテンツ610内に、作業予定617及び作業見積額618を表示させる例を示すが、例えばポップアップ表示等によって、見積一括表示コンテンツ610とは異なる表示ウィンドウにより、作業予定や作業見積額を表示する詳細表示コンテンツを表示させてもよい。
このような作業予定617や作業見積額618が表示されることで、ユーザは、車検業者が、見積額の範囲内で、車検に必要な作業以外に、どのようなオプション作業をサービスしてくれるのかを容易に確認することが可能となる。例えば、「12か月点検」等のオプションの有無が含まれているか否かをユーザが確認することが可能となる。また、作業予定として、通常の車検で必須となる作業と、車検で必須ではないオプション作業とが明示されていてもよい。
【0041】
また、表示領域616に表示される情報としては、作業予定617及び作業見積額618の他、車検業者の住所や連絡先等の車検業者を紹介する情報、車検業者が実施しているキャンペーンに関する情報等が表示されていてもよい。さらには、車検業者が車検作業を実施可能な日時が表示されていてもよく、車検日時や車検内容、見積額に関する問い合わせ先を示すメッセージフォーム等が表示されていてもよい。
【0042】
図9は、ユーザ端末20において、見積一括表示コンテンツ610に表示されたいずれかの車検業者の依頼ボタン614が選択された後の処理を示すフローチャートである。
ユーザ端末20において、ユーザが、見積一括表示コンテンツ610に表示されたいずれかの車検業者の依頼ボタン614が選択されると、ユーザ端末20は、当該車検業者に車検代行を依頼する旨の代行依頼情報を、サーバ装置10に送信する(ステップS203)。そして、サーバ装置10は、ユーザ端末20から代行依頼情報を受信すると(ステップS109)、支払案内コンテンツをユーザ端末20に送信する(ステップS110)。
ユーザ端末20は、支払案内コンテンツを受信すると、その支払案内コンテンツを表示ディスプレイに表示させる(ステップS204)。この支払案内コンテンツは、全見積額の金銭を仲介者に支払うための案内ページであり、ユーザは、ユーザ端末20に表示された支払案内コンテンツの案内に従って、ユーザ端末20を操作することで見積額の金銭を仲介者に支払うことが可能となる。
この後、サーバ装置10のユーザ決済取得部137は、ユーザが全見積額の金銭を支払った旨のユーザ決済情報を取得する(ステップS111)。全見積額の支払いは、インターネットを介した決済処理を用いてもよく、ユーザが銀行等の金融機関で金銭を振り込んでもよい。これらの支払いに係る決済処理は、公知の技術を利用できる。例えばクレジットカードの支払いでは、ユーザ端末20において、クレジットカードのカード番号が入力されると、クレジットカード会社が管理するカード管理サーバに、カード番号が送信される。そして、カード管理サーバにおいて、カード番号の照会が行われ、承認が得られると、支払完了を示す旨の情報が、ユーザ端末20及びサーバ装置10に送信される。また、インターネットバンキングから振り込みを行った場合も同様であり、ユーザが銀行管理サーバにアクセスして振り込み処理を行うことで、銀行管理サーバからサーバ装置10にユーザ決済情報が送信される。
また、このユーザの支払いは、車検を行う前であってもよく、車検後であってもよいが、本例は、車検の前にユーザの支払いが行われるものとする。
【0043】
この後、ユーザが、ステップS203で選択した車検業者のもとに、車検対象車両の自動車を持ち込むことで、車検業者が車検代行の各作業を行う。
車検代行作業の後、車検業者は、業者端末30からサーバ装置10に、車検代行作業において実際に掛かった実金額を含む車検内容情報を送信する(ステップS303)。この車検内容情報には、上述したように、車検代行を実施した対象車両である検査車両情報、車検代行において実際に実施した作業内容、各作業内容に対する作業料(交換部品費用を含む)、車検にかかる法定費用、及び車検業者の代行手数料等が含まれる。
【0044】
サーバ装置10の完了内容取得部135は、業者端末30から車検内容情報を受信すると(ステップS112)、車検履歴蓄積部136は、業者情報及び車検履歴情報を更新する(ステップS113)。つまり、車検履歴蓄積部136は、当該車検内容情報に対応する見積依頼情報の車両情報に対応する車種情報の車検履歴情報を特定し、整備情報と、当該車検内容情報に対応する見積提示情報の見積額(総見積額、法定費用、代行手数料、作業予定、作業見積額等を含む)と、車検内容情報と、を関連付けて記録するまた、車検履歴蓄積部136は、業者情報の実績情報として、実金額、作業内容、及び作業料を記録する。
【0045】
この後、決済処理部138は、業者情報の支払先情報を参照し、車検業者が指定した支払先に対して、実金額の金銭を支払う決済処理を実施する(ステップS114)。このステップS114における決済処理においても公知の技術を利用でき、例えばクレジットカードを用いた決済処理、インターネットバンキングを経由した振込決済処理等を利用できる。
【0046】
また、決済処理部138は、車検内容情報に記録された実金額から、見積提示情報に記録された総見積額を減算した差額を算出する(ステップS115)。そして、決済処理部138は、ステップS115において算出された差額が正の値であるか否か、つまり、実金額が総見積額を上回るか否かを判定する(ステップS116)。
【0047】
ステップS116において、Yesと判定された場合、依頼適正判定部140は、ユーザ端末20から送信された見積依頼情報に含まれる車両情報及び整備情報と、業者端末30から送信された作業内容とを比較して、見積依頼情報に含まれる車両情報や整備情報が適正であるか否かを判定する(ステップS117)。
このステップS117では、車検内容情報に含まれる検査車両情報が、見積依頼情報の車両情報に一致するか否か、整備情報に記載された情報と作業内容とに矛盾があるか否かを判定する。
例えば、見積依頼情報に記録された車両情報に「2015年式、Aメーカー、車種B」との記載があり、車検内容情報に記録された検査車両情報に「2008年式、Aメーカー、車種C」との記載がある場合、見積依頼時の車両と、実際の車検代行を行った車両とが異なることを示す。また、整備情報に1か月前にタイヤ交換を行った旨が記録されているが、作業内容において、タイヤの減りが限界値であり、タイヤ交換作業を行った旨が記録されている場合では、整備情報の情報に誤りがあることを示す。これらの場合、ステップS117においてNo(依頼不適正)と判定される。
【0048】
ステップS117でNoと判定された場合、差額要求部141は、ユーザ端末20に対して、実金額と見積額との差額分の支払いを要求する請求情報をユーザ端末20に送信する(ステップS118)。この請求情報として、見積依頼情報と、車検内容情報とを含ませてもよい。これにより、請求情報を受信したユーザ端末20では、差額分の支払いを要求する請求情報が表示される(ステップS205)。つまり、不適正な情報に基づいて算出された見積額が、実金額よりも安い場合、差額分はユーザ負担となる。
【0049】
一方、ステップS117でYesと判定される場合(ユーザから提供された見積依頼情報が適正である場合)、回数カウント部139は、ステップS115で算出された、実金額から総見積額を減算した差額が第一閾値以上であるか否かを判定する(ステップS119)。
ステップS119でYesと判定される場合、回数カウント部139は、見積不適合回数に1を加算し、業者情報の見積不適合回数を更新する(ステップS120)。ここで、本実施形態では、所定期間(例えば直近1か月)の見積不適合回数に基づいて、車検業者に対するペナルティを設定する。このため、回数カウント部139は、ステップS120において、見積不適合と判定した日時を見積不適合回数に関連付けて記録する。なお、見積不適合回数に関連付けられる複数の日時のうち、1か月以上前の日付がある場合、回数カウント部139は、これらの日時を削除してもよく、削除した日時の数だけ、見積不適合回数を減らしてもよい。
【0050】
ステップS119においてNoと判定される場合、つまり、実金額から総見積額を減算した差額が正の値ではあるが、第一閾値未満である場合、見積不適合回数にはカウントされない。また、ステップS117でNoと判定された場合も、実金額と総見積額との差額は、車検業者の責任ではないとして、見積不適合回数にはカウントされない。
【0051】
また、ステップS116において、Noと判定される場合、つまり、実金額から総見積額を減算した差額が0以下であり、実金額が見積額よりも安い場合、回数カウント部139は、優良見積回数に1を加算し、業者情報の優良見積回数を更新する(ステップS121)。ここでも、回数カウント部139は、ステップS116においてNoと判定した日時を優良見積回数に関連付けて記録する。
【0052】
[本実施形態の作用効果]
本実施形態のサーバ装置10では、依頼取得部131が、ユーザ端末20から車検対象車両の自動車の車種や年式等を示す車両情報と、その自動車の整備履歴を示した整備情報とを含む、見積依頼情報を受信すると、依頼送信部132は、業者端末30に見積依頼情報に基づいた車検の見積額を要求する見積要求情報を送信する。この後、見積受信部133が、業者端末30から、車検に係る法定費用と、車検業者の車検代行に係る代行手数料と、車両情報及び整備情報に基づいた車検時の作業に対する作業料と、を加算した総見積額を含む見積提示情報を受信し、見積送信部134は、受信した総見積額をユーザ端末20に送信する。
つまり、本実施形態では、車検業者は、車検対象車両の自動車の車種や年式に加え、その自動車の整備情報を含む詳細な情報に基づいて、車検の見積額を算出することができる。このため、車検業者の業者端末30から見積提示情報を受信したサーバ装置10は、ユーザ端末20に対して、車検時に必要となる、より正確な総見積額を提示することができる。このため、ユーザが実際に車検を行った際の見積額と実金額との差を小さくでき、ユーザと車検業者との間の金銭トラブルを抑制することができる。また、各車検業者の業者端末30から、適正な総見積額を含む見積提示情報がサーバ装置10に送信される。このため、従来のように、実際の作業に基づいた適正な見積額を出したために、他の車検業者よりも見積額が高くなり、ユーザの選択肢から外れてしまうといった、車検業者側の不利益も抑制されることになり、ユーザ及び車検業者の双方にとって有益な取引を支援することができる。
【0053】
本実施形態のサーバ装置10では、完了内容取得部135が、業者端末30から、車検業者が実際の車検作業を実施した際に掛かった車検の実金額と、車検業者が実施した各作業内容と、を含む車検内容情報を受信し、車検履歴蓄積部136が、車検履歴DB12Cの車検履歴情報として車検内容情報を蓄積する。そして、依頼送信部132は、見積要求情報に記録された車両情報や整備情報に加え、同車種の車検履歴情報を業者端末30に送信する。
このため、車検業者は、車検対象車両の車両情報と整備情報に加え、過去に同じ車種に対して実施された車検の実績、つまり、過去の車検で実施された各作業内容や、過去の車検で請求されている実金額に基づいて、車検対象車両の総見積額を算出することができる。例えば、特定の部品が摩耗しやすい車種等では、過去の車検情報から、当該特定の部品が摩耗している可能性を容易に判断することができる。この場合、車検業者は、当該部品を交換するための作業予定、及び工賃及び部品費用を含む作業見積額を算出することができ、実際に車検を通すために必要な作業(自動車検査登録を受けるために必要な作業)をより正確に算出することが可能となる。
【0054】
本実施形態のサーバ装置10は、見積受信部133は、車検業者が実施する作業予定、及びその作業見積額を含む見積提示情報を受信する。そして、見積送信部134は、見積一括表示コンテンツ610において、詳細ボタン615が選択された際に、作業予定617及び作業見積額618が表示される制御スクリプトを挿入して、ユーザ端末20に送信する。つまり、見積送信部134は、総見積額とともに、その内訳である作業予定と作業見積額をユーザ端末20に送信する。
このため、ユーザは、車検において、車検業者が実施する作業を確認することができる。これにより、例えば、車検に必要な作業以外を実施して欲しくないユーザは、余計な作業予定が入っていない車検業者を容易に特定できる。また、12か月点検等のオプションを望むユーザは、自身が望む作業予定を行ってくれる車検業者を容易に特定できる。すなわち、ユーザは、自分の希望に合った作業内容、作業見積額、及び総見積額の車検業者を容易に見つけることができる。
【0055】
本実施形態のサーバ装置10では、見積送信部134は、車検業者が算出した総見積額にサービス利用料を加算した全見積額を表示した見積一括表示コンテンツ610をユーザ端末20に送信する。また、サーバ装置10では、ユーザ決済取得部137が、ユーザが全見積額の金銭を仲介者に支払った旨のユーザ決済情報を受信し、完了内容取得部135が、業者端末30から車検作業に掛かった実金額を含む車検内容情報を受信すると、決済処理部138が、その実金額分を車検業者に支払う決済処理を実施する。
つまり、本実施形態では、ユーザは、車検代行を依頼する車検業者を決定すると、サーバ装置10の管理者である仲介者に対して全見積額の金銭を支払い、仲介者が車検業者に対して、車検代行において実際に必要となった実金額分を支払う。この場合、ユーザは、見積一括表示コンテンツ610で表示された全見積額の分のみを支払えばよく、車検後に別途追加料金等が発生することがない。また、車検業者は、車検において、実金額が総見積額よりも高くなってしまった場合でも、仲介者から当該実金額の分だけ、金銭を受け取ることができる。さらに、仲介業者が、車検見積システム1を利用した全ユーザから、サービス利用料を受け取ることで利益を得ることができ、仮に、一部の車検において、実金額が総見積額よりも高くなった場合でも、サービス利用料により補うことができる。すなわち、本実施形態の車検見積システム1では、ユーザ、車検業者、及び仲介者の三者にとって有益であり、それぞれの満足度を高めることができる。
【0056】
本実施形態のサーバ装置10では、回数カウント部139が、実金額から総見積額を引いた差額が第一閾値以上となる回数である見積不適合回数を、車検業者毎にカウントする。
本実施形態では、上述のように、車検業者は、車検に掛かった実金額を含む車検内容情報をサーバ装置10に送信すれば、実金額分の支払いを受けることができる。このような車検見積システム1では、見積要求情報に対して実際よりも低い総見積額を返して、顧客を獲得する車検業者が現れる可能性がある。しかしながら、本実施形態では、見積不適合回数をカウントすることで、上記のような不正を行う車検業者を特定することができる。これにより、不正を行った車検業者に対してペナルティを設けることができ、健全なシステム運用を行うことが可能となる。
【0057】
より具体的には、本実施形態の依頼送信部132は、見積不適合回数が第二閾値未満となる車検業者に対して、見積依頼情報を受信したタイミングで見積要求情報を送信する。一方、見積不適合回数が第二閾値以上となる車検業者に対して、見積不適合回数に応じた遅延時間が経過した後、見積要求情報を送信する。
一般に、車検の一括見積では、ユーザは、早く見積額を出した車検業者を選択する傾向がある。したがって、車検の見積額の提示が遅れた車検業者は、それだけ、ユーザに選択される可能性(車検代行を依頼してもらえる可能性)が低くなる。つまり、本実施形態では、見積不適合回数が多いほど大きいペナルティを受けることになり、上記のように、ユーザの獲得数を増やすために、実際に係る実金額よりも低くなる総見積額を提示する車検業者は、ユーザから選択される可能性が低くなる。よって、車検業者は、ユーザの獲得数を増やすために、より正確な総見積額を算出するようになり、車検見積システム1の健全な運用が可能となる。
【0058】
また、本実施形態では、回数カウント部139は、実金額から総見積額を引いた差額が0以下となる回数である優良見積回数を、車検業者毎にカウントする。
これにより、本実施形態では、優良見積回数が多い車検業者を容易に特定することができる。この場合、これらの車検業者を優遇することで、車検業者は、ユーザの獲得数を増やすことができる。つまり、従来の車検の一括見積サービスでは、多くのユーザに選択されるために、より安い見積額を提示する傾向にあった。これに対して、本実施形態の車検見積システム1では、優良見積回数が多い車検業者ほど、ユーザに選択される可能性が高くなる。この際、本実施形態では、総見積額を高くして、実金額を総見積額よりも安くすることで、優良見積回数を増やすことも可能であるが、この場合、車検業者が車検代行に見合った利益を得ることができない場合もあり、総見積額が高いことでユーザから選択される可能性も低くなってしまう。よって、車検業者は、優良見積回数を高め、より多くのユーザから選択されるために、総見積額と実金額との差がなくなるような、より正確な総見積額を算出するようになる。これにより、車検見積システム1において、ユーザに提示される総見積額(全見積額)が、より適正な金額となり、ユーザ満足度をより高めることが可能となる。さらに、ユーザ満足度が高くなると、車検見積システム1に参入する車検業者の数も多くなり、システムのさらなる活性化によって、ユーザの満足度をさらに向上させることが可能となる。
【0059】
本実施形態では、見積送信部134は、優良見積回数が第三閾値以上となる車検業者の業者端末30から受信した見積提示情報に基づいた全見積額及び車検業者名を、その車検業者が優良業者である旨を示す優良情報613とともにユーザ端末20に送信する。
これにより、ユーザは、車検業者が優良業者であることを一目で確認することができ、優良業者が選択される可能性を高めることができる。
【0060】
ところで、本実施形態の車検見積システム1では、上述のように、実金額よりも低い総見積額を提示してユーザを獲得する不正車検業者に対して、見積要求情報の送信時期を遅らせることで、ペナルティを与える。これによって、不正車検業者は、一定数のユーザから依頼が得られなくなる可能性が高くなり、不利益を受けることになる。しかしながら、極端に総見積額が低い場合、ユーザに対する見積額の提示が遅くなったとしても、ユーザが当該総見積額の車検業者を選択する可能性は高い。つまり、車検業者の選択に迷っているユーザにとって、遅延して送信された総見積額が極端に低い車検業者は魅力的に映り、当該車検業者が選択される可能性が高くなる。
そこで、本実施形態では、総見積額が、車両情報及び整備情報に応じて設定される下限額よりも低い金額である場合に、その総見積額、及び総見積額を出した車検業者を見積一括表示コンテンツ610に表示させない。つまり、その車検業者と総見積額の情報をユーザに送信しない。これにより、極端に見積額が低い車検業者を排除することができる。
【0061】
また、ユーザが、見積一括表示コンテンツ610に表示された全見積額を仲介者に支払えば、その後、追加費用を支払わなくてもよいシステムとする場合、最初の見積依頼情報として、偽りの車両情報や整備情報を送信する不正ユーザが現れることがある。
これに対して、本実施形態のサーバ装置10は、依頼適正判定部140が、車検内容情報に基づいて、見積依頼情報に含まれる車両情報及び整備情報が適正であるか否かを判定し、適正ではないと判定した場合に、差額要求部141が、ユーザ端末20に、総見積額と実金額との差額を要求する請求情報を送信する。このため、見積依頼情報として、偽りの情報を提供して、総見積額及び全見積額を低価格にした場合、実金額と総見積額との差額分がユーザに請求されることになる。すなわち、ユーザは、実質、車検代行に係る実金額の全額と、サービス利用料を支払うことになる。これにより、ユーザは、見積依頼情報として、正確な車両情報及び整備情報を送信することになり、システムの健全な運用が可能となる。
【0062】
[第二実施形態]
次に、第二実施形態について説明する。
上述した第一実施形態では、ステップS103において、依頼送信部132は、見積不適合回数が第二閾値以上となる車検業者に対して、見積不適合回数に応じた遅延時間を設定し、ステップS105において、設定した遅延時間で、見積要求情報を業者端末30に送信した。これに対して、第二実施形態では、依頼送信部132は、見積不適合回数が多い車検業者に対する見積要求情報の送信を、一定期間停止する点で第一実施形態と相違する。
なお、以降の説明にあたり、既に説明した事項については同符号を付し、その説明を省略または簡略化する。
【0063】
本実施形態では、第一実施形態と同様の構成を有し、サーバ装置10における制御部13の一部の機能、より具体的には、見積送信部134の機能が一部異なるのみであり、その他の構成及び、制御部13の各機能については、第一実施形態と同様である。したがって、第二実施形態におけるサーバ装置10の具体的な構成は、
図2に示す通りであり、制御部13の各機能構成の詳細についての説明は省略する。
【0064】
本実施形態では、
図9に示すステップS119においてYesと判定され、ステップS120において、回数カウント部139が見積不適合回数に1を加算した後、回数カウント部139は、さらに、見積不適合回数が、第二閾値以上となったか否かを判定する。
そして、回数カウント部139は、見積不適合回数が第二閾値以上となった場合に、その車検業者の業者端末30に対する見積要求情報の送信を停止する所定の停止期間を設定する。
例えば、回数カウント部139は、見積不適合回数が第二閾値以上となった停止開始日時と、見積要求情報の停止を解除する停止解除日時とを、業者情報の見積不適合回数に関連付けて記録する。この場合、見積不適合回数が第二閾値以上となった日時から、見積要求情報の停止を解除する日時が停止期間である。
なお、この停止期間は、各車検業者に対して一定であってもよく、見積要求情報の送信が停止されたトータル回数や、一定期間において見積要求情報の送信が停止された回数(頻度)、あるいは、所定期間における見積不適合回数の増加数(見積不適合回数の増加速度)に応じて、停止期間を長くしてもよい。
【0065】
このような本実施形態では、
図5に示すステップS102において、車検業者を抽出する際に、停止期間が設定されていない車検業者を抽出する。つまり、依頼送信部132は、業者情報の見積不適合回数に停止解除日時が関連付けられている場合に、停止解除日時が現在日時より後である業者情報は、ステップS102における車検業者の抽出対象から除外する。これにより、停止期間が設定されている車検業者には、ステップS105において、見積要求情報が送信されない。
また、本実施形態では、ステップS103の遅延時間の設定処理を省略することができる。
【0066】
なお、上記の例では、ステップS102において、停止期間が設定されている車検業者を抽出対象から除外する例であるが、これに限定されない。
例えば、ステップS105において、依頼送信部132が、車検業者の業者情報に停止期間が設定されているか否かを判定してもよい。
さらに、現在日時から停止解除日時までの期間が所定期間内である場合、つまり、現在日時から停止解除日時までの期間が短い場合、依頼送信部132は、停止解除日時以降に見積依頼情報を送信してもよい。
【0067】
[本実施形態の作用効果]
本実施形態では、依頼送信部132は、見積不適合回数が第二閾値以上となる車検業者に対して、所定の停止期間を設定して、見積要求情報の送信を停止する。
この場合、第一実施形態に比べて、見積不適合回数が多い車検業者に対するペナルティがより重くなり、システムのより健全な運用が可能となる。
つまり、第一実施形態では、見積不適合回数が第二閾値以上となる車検業者の見積情報(車検業者名及び全見積額)の送信を遅らせることで、見積不適合回数が多い車検業者に対するペナルティを与えている。しかしながら、見積不適合回数が多い車検業者に対して、早期に車検代行先の車検業者を決定したいユーザからの依頼が減るものの、車検代行先の選定を急いでいないユーザに対しては見積情報が提示されるので、見積不適合回数が多い車検業者に対するペナルティとしては効果が薄いことがある。
これに対して、本実施形態では、見積不適合回数が第二閾値以上となる車検業者には見積依頼情報が送信されないため、当該車検業者の見積情報がユーザ端末20に送信されることがない。このため、見積不適合回数が多い車検業者に対するペナルティをより重くすることができる。
【0068】
[変形例]
なお、本発明は、上述した実施形態に限定されるものではなく、本発明の目的を達成できる範囲で、以下に示される変形をも含むものである。
[変形例1]
第一実施形態では、依頼送信部132は、見積不適合回数が第二閾値以上となる車検業者の業者端末30に対して、見積不適合回数に応じた遅延時間を設定して見積要求情報を送信した。また、第二実施形態では、見積不適合回数が第二閾値以上となる車検業者に対して停止期間を設定し、依頼送信部132は、停止期間の間、見積要求情報の送信を停止した。
これに対して、依頼送信部132は、見積不適合回数が第二閾値以上となる車検業者に対して、見積要求情報の送信頻度を変更してもよい。具体的には、回数カウント部139は、
図9のステップS120において、見積不適合回数に1を加算した後、見積不適合回数に応じた送信頻度を設定する。例えば、見積不適合回数が初めて第二閾値以上となった車検業者に対して、4回のうち1回を、見積要求情報を停止する頻度として設定し、見積不適合回数が第二閾値以上となる回数が増えるほど、見積要求情報を停止する頻度を高くする。
または、依頼送信部132は、見積不適合回数が第二閾値以上となる車検業者に対して、特定の車種の見積要求情報の送信を停止させてもよい。例えば、部品交換頻度が高い車種や、代行手数料や作業見積額等が高額となる高級車に関する見積依頼情報を停止してもよい。
【0069】
[変形例2]
さらには、実金額から総見積額を減算した差額が第一閾値以上となる車種を分析し、総見積額が実金額よりも高くなる傾向にある車種を特定してもよい。この場合、依頼送信部132は、当該特定の車種に関する見積要求情報の送信を停止したり、送信頻度を低下させたりすることができる。
つまり、車検業者が得意とする車種(正確な総見積額を算出可能な車種)に関しては、ペナルティを受けることなく見積依頼情報がサーバ装置10から業者端末30に送信される。一方、車検業者にとって、不得意な特定の車種では、作業時間が長くなったり、予想外の作業が発生したりする場合がある。この場合、車検業者に不正を行う意思はなくとも、実金額と総見積額とが大きく乖離することがある。これに対して、上記のように、実金額から総見積額を減算した差額が第一閾値以上となる車種を分析し、差額が第一閾値以上となる特定の車種に関して、見積依頼情報の送信を停止したり、送信頻度を低下させたりすることで、各車検業者に、得意とする車種に関する見積依頼情報が送信されるようになる。この場合、車検業者は、総見積額や作業見積額として適正な金額を算出することが可能であり、車検時の作業効率も向上するため、ユーザ満足度を高めることができる。
【0070】
[変形例3]
第一実施形態において、ステップS103で見積不適合回数に応じて長くなる遅延時間を設定し、ステップS105で見積依頼情報の受信タイミングから遅延時間だけ遅延させて見積要求情報を送信した。
これに対して、ステップS112で総見積額を受信した後、ステップS106で、見積送信部134が、設定した遅延時間だけ遅延させてユーザに総見積額(全見積額)をユーザ端末20に送信してもよい。つまり、見積送信部134は、見積一括表示コンテンツ610において、見積不適合回数が第二閾値以上となる車検業者に関する情報(車検業者名及び全見積額)を、見積不適合回数に応じた遅延時間で遅延させて表示させる。
この際、見積送信部134は、全ての優良車検業者からの見積提示情報が送信されたタイミングを基準タイミングとし、全ての優良車検業者、及び、基準タイミングで見積提示情報を受信済みの見積不適合回数が第二閾値未満のその他の車検業者に関する見積情報(車検業者名及び全見積額)を基準タイミングで送信する(見積一括表示コンテンツに情報を掲載する)。そして、基準タイミングから、見積不適合回数に応じて設定した遅延時間の経過後に、見積不適合回数が第二閾値以上の車検業者に関する見積情報を送信する。
これにより、優良車検業者からの見積情報が、見積不適合回数が第二閾値以上の車検業者の見積情報の後に送信される不都合を防止することができる。すなわち、優良車検業者は、総見積額や作業見積額を精度よく算出するため、業者端末30から送信される見積提示情報の送信タイミングが、他の車検業者よりも遅くなる場合が考えられる。これに対して、上記の処理により、優良車検業者からの見積情報を優遇してユーザ端末20に送信することができる。
【0071】
また、見積一括表示コンテンツ610の更新に際し、例えば、全ての優良車検業者からの見積提供情報を受信した後、優良見積回数が多い車検業者の全見積額を順に表示させ、その後、一定時間経過後に、通常の車検業者の全見積額を表示させ、さらにその後、見積不適合回数に応じた遅延時間で、見積不適合回数が多い車検業者からの全見積額を表示させるようにしてもよい。この際、優良車検業者の見積額を表示する際に、例えば「1日後にその他の車検業者の見積額も表示されます」といった表示を行うことで、ユーザは、優良車検業者以外にも見積額を出してくれている車検業者がいることを認識することができる。なお、通常の車検業者の見積額が表示される際、見積不適合回数の多い車検業者の見積額の表示時期を知らせないようにすることで、見積不適合回数の多い車検業者に対するペナルティも重くなる。
【0072】
[変形例4]
第一実施形態及び第二実施形態において、見積不適合回数が多い車検業者に対して、見積要求情報の送信を遅らせたり、見積要求情報の送信を停止させたりすることでペナルティを課す例を示した。
これに対して、仲介者が車検業者に支払う金銭として上限値を設定し、実金額が総見積額よりも大きい場合に、決済処理部138は、上限値を限度額として車検業者に費用を支払うようにしてもよい。この上限値としては、例えば総見積額にサービス利用料を加算した金額(つまり、全見積額)としてもよく、総見積額を基準とした所定額(例えば総見積額の1.5倍)としてもよい。
【0073】
[変形例5]
また、上記実施形態では、実金額から総見積額を減算した差額が負の値となる場合、つまり、実金額が総見積額より安い場合、ステップS121で優良見積回数を加算するのみであったが、さらに、決済処理部138が、ユーザが指定した口座に差額分を支払う支払処理を行ってもよい。この場合、ユーザが、優良車検業者に車検代行を依頼するメリットが増大するため、優良車検業者はユーザを獲得しやすくなる。このため、多数の車検業者が適正な総見積額を含む見積提示情報を送信するようになり、車検見積システム1のさらなる活性化を図れる。
【0074】
[変形例6]
上記実施形態において、依頼送信部132は、見積依頼情報に含まれる車両情報及び整備情報に対応する車検履歴情報を読み込んで、見積要求情報に含ませる例を示した。
これに対して、依頼送信部132は、車検履歴情報に含まれる総見積額と、実金額との金額差が所定値以上である車検作業情報が複数含まれる場合に、見積依頼情報に車検履歴情報または車検作業情報を含ませてもよい。
この場合、総見積額と実金額とが異なる場合が特に多いパターンである旨の注意喚起を、各車検業者に知らせることができ、車検業者は、より正確な総見積額を算出することが可能となる。
【0075】
[変形例7]
上記実施形態では、ユーザ決済取得部137が、ユーザが仲介者に対して全見積額を支払う旨のユーザ決済情報を受信し、完了内容取得部135が実金額を含む車検内容情報を受信した後、決済処理部138が車検業者に対して実金額を支払う決済処理を実施した。これに対して、ユーザが仲介者を介さず車検業者に実金額を支払ってもよい。この場合でも、各車検業者から、法定費用及び代行手数料に加え、車検時に実施する各作業の作業料を加算した総見積額を含む見積提示情報が、各業者端末30から送信されるので、従来に比べて、ユーザは、適正な車検の総見積額を知ることができる。また、この場合、全見積額でなく、総見積額をユーザ端末20に送信すればよい。
【0076】
[変形例8]
上記実施形態では、回数カウント部139が、実金額から総見積額を引いた差額が0以下となる回数である優良見積回数を車検業者毎にカウントしたが、これに限定されない。
例えば、回数カウント部139は、実金額から総見積額を引いた差額が所定の金額内である場合に、優良見積回数を加算するようにしてもよい。つまり、総見積額と実金額との差額が一定金額、一定割合内に収まっている車検業者(総見積額の算出精度が高い車検業者)を優良業者としてもよい。
【0077】
また、上記実施形態では、優良見積回数が第三閾値以上となる車検業者を優良業者とする例を示したが、これに限定されない。
優良業者の選定は、優良見積回数のみではなく、さらに、車検業者に対するユーザの評価を加味してもよい。つまり、サーバ装置10は、車検終了後に、ユーザ端末20から、車検業者に対する評価を受信する。そして、サーバ装置10は、実金額よりも安い総見積額、もしくは総見積額の算出精度が一定値以上の車検業者であって、かつ、ユーザから得られる評価も一定値以上となる車検業者を、優良業者として認定する。
【0078】
さらに、上記実施形態や上記例では、優良業者を特定しているが、優良業者の特定を行わなくてもよい。この場合、回数カウント部139は、見積不適合回数のカウントのみを行い、優良見積回数のカウントを行わなくてもよく、
図9におけるステップS119及びステップS121を不要にできる。
【0079】
その他、本発明の実施の際の具体的な構造及び手順は、本発明の目的を達成できる範囲で他の構造などに適宜変更できる。