仲介装置および仲介方法
【課題】買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法を提供すること。
【解決手段】仲介装置10においては、売り手、買い手の登録手段と、買い手の発注情報の入力手段と、買い手の識別情報を除いた発注情報のみを売り手に表示する手段と、発注情報に対して売り手が応札情報を入力する手段と、応札情報を一覧表にして買い手に表示する手段と、買い手が希望する売り手に対して買い手の情報を含む商談依頼の通知を行う手段とを備える。本発明によれば、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる。
【解決手段】仲介装置10においては、売り手、買い手の登録手段と、買い手の発注情報の入力手段と、買い手の識別情報を除いた発注情報のみを売り手に表示する手段と、発注情報に対して売り手が応札情報を入力する手段と、応札情報を一覧表にして買い手に表示する手段と、買い手が希望する売り手に対して買い手の情報を含む商談依頼の通知を行う手段とを備える。本発明によれば、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は仲介装置および仲介方法に関し、特に、ネット上で売り手と買い手の間の仲介を行う仲介装置および仲介方法において、買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法に関するものである。
【背景技術】
【0002】
近年、インターネットの普及に伴い、例えば商品等の売り手(Seller:セラー)がネット上において広告を出し、買い手(Buyer:バイヤー、ユーザ)は該広告を見て商談を申し込むことが広く行われている。
【発明の概要】
【発明が解決しようとする課題】
【0003】
前記したような従来の売り手の決定方法においては、買い手は欲しい物がどこの広告に載っているのかを検索する必要があり、検索した結果、多数の売り手が判明した場合には、それら多数の売り手のそれぞれに対してメール等を使用して見積もり等を請求し、回答を得た売り手の中から一番条件のよさそうな売り手を選択する必要があった。更に、売り手が信用できる相手であるか否かを調査するためには、別の検索等が必要であり、多数の労力が必要であるにも関わらず、最適な売り手を選択することが困難であるという問題点があった。
【0004】
本発明の目的は、前記のような従来技術の問題点を解決し、ネット上で売り手と買い手の間の仲介を行う仲介装置および仲介方法において、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法を提供することにある。
【課題を解決するための手段】
【0005】
本発明の売り手と買い手の仲介を行う仲介装置においては、売り手の登録手段と、買い手の登録手段と、買い手の発注情報の入力手段と、買い手の識別情報を除いた発注情報のみを売り手に表示する発注情報表示手段と、前記発注情報に対して売り手が応札情報を入力する応札情報入力手段と、応札情報を一覧表にして買い手に表示する応札情報表示手段と、買い手が希望する売り手に対して買い手の情報を含む商談依頼の通知を行う商談依頼通知手段とを備えたことを特徴とする。
本発明によれば、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる。また、登録内容をシステム側で確認すること等により、買い手に信用情報を提供することも可能である。
【発明の効果】
【0006】
以上述べたように、本発明の売り手と買い手の仲介を行う仲介装置および仲介方法においては、買い手にとっては、多数の企業の中から自社のニーズに適合した企業を容易に選択することができ、手間や時間をかけずに効率的にアクセス可能であるという効果がある。また、売り手にとっては、新しいセールスチャンスを獲得でき、顧客の方からリクエストが提示されてくるので、多額の広告や飛び込みの営業活動などを行う必要がなく、やはり効率的な営業活動ができるという効果がある。
【図面の簡単な説明】
【0007】
【図1】本発明の仲介装置を含むシステム全体の構成を示すブロック図である。
【図2】本発明の仲介装置を含むシステム全体の他の構成例を示すブロック図である。
【図3】本発明の仲介装置において実行される仲介方法の概要を示す説明図である。
【図4】本発明の買い手への比較検討ページの表示処理の内容を示すフローチャートである。
【図5】本発明の買い手への比較検討ページの再表示処理の内容を示すフローチャートである。
【図6】本発明の買い手の商談申し込み処理の内容を示すフローチャートである。
【図7】本発明の買い手への比較検討ページの表示処理の詳細内容を示すフローチャートである。
【図8】本発明の買い手への比較検討ページの再表示処理の内容を示すフローチャートである。
【図9】本発明の買い手の商談申し込み処理の詳細内容を示すフローチャートである。
【図10】売り手のカテゴリー登録画面例を示す説明図である。
【図11】売り手の担当者登録画面例を示す説明図である。
【図12】売り手の企業情報登録画面例を示す説明図である。
【図13】買い手へのアピール情報登録画面例を示す説明図である。
【図14】売り手の地域フィルタ登録画面例を示す説明図である。
【図15】買い手のリクエスト(発注)登録画面例を示す説明図である。
【図16】売り手のアクセス時の初期画面例を示す説明図である。
【図17】リクエスト一覧表示画面例を示す説明図である。
【図18】売り手のリクエスト詳細表示画面例を示す説明図である。
【図19】売り手の応札情報入力画面例を示す説明図である。
【図20】買い手への応札情報一覧表示画面例を示す説明図である。
【図21】買い手への応札企業概要表示画面例を示す説明図である。
【図22】買い手への商談申し込み画面例を示す説明図である。
【図23】売り手への商談申し込み表示画面例を示す説明図である。
【図24】買い手への評価情報入力画面例を示す説明図である。
【発明を実施するための形態】
【0008】
以下、本発明の実施の形態を詳細に説明する。図1は、本発明の仲介装置であるサーバーシステム10を含むシステム全体の構成例を示すブロック図である。仲介装置10には、Web(WWW:World Wide Web)サーバ11、Webアプリケーションサーバ12、DB(データベース)を備えたデータベースサーバ13、メール(SMTP:Simple Mail Transfer Protocol)サーバ14が図示しないLANによって接続されており、更に、Webサーバ11は、図示しないルータによってインターネット20に接続されている。この他、LANには図示しない複数の保守、管理用のサーバ、端末が接続されている。
データベースには、売り手や買い手の登録情報を格納する顧客DB、リクエストDB、応札DB、商談申し込みDB、メール用DBなどが格納されており、後述する仲介装置10の機能は、各サーバが分担して処理する。各サーバ11〜14の機能は周知であり、それぞれ周知の市販のサーバ装置に周知の市販のOSを搭載し、市販の、あるいは後述するような処理を実行するプログラムを実装することにより実現できる。
【0009】
Webアプリケーションサーバ12の機能はCGIやその他のスクリプトプログラムによって代替可能であり、省略することもできる。クライアント側の端末30は例えば周知のWebブラウザ31およびメールクライアント32を備え、インターネット20にアクセス可能な周知の市販のPC(パソコン)であってもよい。
【0010】
図2は、本発明の仲介装置であるサーバーシステム10を含むシステム全体の他の構成例を示すブロック図である。この実施例は図1に示したシステム構成からメールサーバ14およびメールクライアント32を除いたものである。クライアントは、Webブラウザ31によってサーバシステム10にアクセスすることによって、本発明の全ての処理を実行するようにすることも可能である。
【0011】
図3は、本発明の仲介装置10において実行される仲介方法の概要を示す説明図である。図3に基づき、本発明の仲介方法の概要およびサイト10の機能を説明する。なお、実施例においては、複数のカテゴリーに属する各種サービスの仲介を行う例について説明する。
【0012】
(1)まず、買い手(バイヤー端末40(30))と売り手(セラー端末50(30))はそれぞれ本発明の仲介システム(サイト)10に登録を行う。なお、売り手は自分の提供するサービスのカテゴリーも登録する。サイト10は登録内容をデータベースに登録する。(2)次に、買い手は特定のカテゴリーを選択してリクエスト(発注情報)を入力する。サイト10は、リクエストを買い手と対応づけて保存する。
【0013】
(3)サイト10は、リクエストをカテゴリーの一致する全ての売り手にメールで配信する。但し、このリクエストには買い手の企業名等の情報は付加されていない。(4)売り手は、本発明の仲介システムにアクセスし、自分の属するカテゴリーのリクエストを閲覧し、応札したいリクエストに対して応札情報を入力する。サイト10は、応札情報をリクエストと対応して保存する。
【0014】
(5)所定の応札期間内に、応札があった場合には、サイト10は買い手にメールで応札があったことを通知し、(6)買い手は仲介システムにアクセスして応札情報を読み出す。サイトは全ての応札情報を一覧表に編集して買い手に表示する。この場合には応札企業の詳細情報も読み出すことができる。買い手は各応札情報を比較検討して、商談を申し込む売り手を決定する。そして、商談申し込み情報を入力する。
【0015】
(7)サイト10は、商談申し込みのあった売り手に対してメールで通知を出し、売り手はサイト10にアクセスして、買い手の連絡先等の情報を付加した商談依頼通知を閲覧する。(8)その後は、売り手と買い手が直接連絡を取り、商談を進める。サイト10は、例えば商談依頼通知を発送した売り手に対して所定の仲介料を請求するための請求書を発行する。(9)また、買い手には売り手の評価情報を入力してもらい、売り手の評価に反映させる。
次に、クライアントの端末に表示される画面例の図面を参照して仲介方法の詳細について説明する。
【0016】
(1)ユーザ登録。
【0017】
図10は、売り手のカテゴリー登録画面例を示す説明図である。売り手は、登録時に自分の会社のサービスと対応するカテゴリーを1つ以上選択する。なお、該当するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、カテゴリーの追加申請を行うことができる。
【0018】
図11は、売り手の担当者登録画面例を示す説明図である。また、図12は、売り手の企業情報登録画面例を示す説明図である。更に、図13は、売り手から買い手へのアピール情報登録画面例を示す説明図である。図13に示した各アピール情報はそれぞれ300字以内の文章で自由に記載することができるようになっている。このような構成にすることにより、売り手がセールスポイントを的確に表現することが可能となり、買い手が売り手を選択する際の貴重な情報源となる。
図14は、売り手の地域フィルタ登録画面例を示す説明図である。売り手は、この画面において地域を指定することにより、サービスを実施する地域が指定した地域と一致するリクエストのみを受け取ることができる。なお、買い手の登録内容は、売り手の登録内容からカテゴリー、アピール情報、指定地域等を除いたものである。以上のような画面によって入力された各種情報はサイト10のデータベースに登録され、登録者にはIDおよびパスワードが発行される。登録内容の変更、解約も随時可能である。
【0019】
(2)リクエスト(発注情報)の入力。
【0020】
図15は、買い手のリクエスト(発注)登録画面例を示す説明図である。買い手が仲介システムにアクセスし、例えばIDおよびパスワードによって認証をパスすると、サイト10は、図16に示すようなバイヤーセンター画面を表示し、買い手が画面下段に表示されているサービスのカテゴリー一覧表の中から該当するサービスカテゴリーを選択(クリック)すると図15の画面に移行する。
図15の画面においてはサービスの利用場所、時期、予算、応札受付終了日等の項目の入力の他、「リクエスト内容」、「自社概要」、「質問」の各項目について300字以内の文章で自由に記載できるフォームを採用している。このように、フリーフォームで記入できるようにすることにより、多様なニーズに対応可能である。サイト10は入力されたリクエストを買い手と対応してリクエストDBに保存する。
【0021】
(3)リクエスト配信。
【0022】
サイト10は買い手の入力したリクエスト情報をカテゴリーの一致する全ての売り手にメールで配信する。但し、買い手の企業名や電話番号など買い手を特定可能な情報は付加されていない。
【0023】
(4)応札情報の入力。
【0024】
図16は、売り手のアクセス時の初期画面例を示す説明図である。売り手が仲介システムにアクセスし、例えばIDおよびパスワードによって認証をパスすると、サイト10は、図16に示すようなセーラーセンターおよびバイヤーセンター画面を表示する。買い手の場合にはバイヤーセンターのみが表示されるが、売り手の場合には買い手になる可能性もあるので、双方が表示される。
セラーセンターの上段のリストは当売り手が登録しているサービスの各カテゴリー(「ホームページ作成」と「インターネット広告」の2つ)におけるリクエスト数を表示しており、右欄の「応札へ」をクリックすると、図17の画面に移行する。
【0025】
図17は、リクエスト一覧表示画面例を示す説明図である。売り手は、任意のリクエストの「案件名」の部分をクリックするか、最右端のチェックボタンの1つあるいは複数個にチェックを入れて、下段の「詳細情報一覧表示」ボタンをクリックすることにより、図18のリクエストの詳細情報を見ることができる。
なお、図17の応札中リクエスト一覧画面は、未登録のユーザも見ることができ、登録する前に本発明の仲介システムにおいてどのような発注が出されているのかが確認できるようになっている。但し、未登録ユーザはリクエストの詳細情報を見ることはできない。
【0026】
図18は、売り手のリクエスト詳細表示画面例を示す説明図である。売り手はこのリクエストの詳細情報を見て応札を希望する場合には下段の「応札する」ボタンをクリックする。
図19は、売り手の応札情報入力画面例を示す説明図である。応札情報としては、価格レンジ、提案の有効期間と共に、「質問への回答」「提供サービスのアピール」の項目について、300字以内の文章で自由に記載できるフォームを採用している。サイト10は応札情報をリクエストと対応して応札DBに保存する。
【0027】
(5)応札通知。
【0028】
所定の応札期間内に応札があった場合には、サイト10は買い手にメールで応札があっとことを通知する。
【0029】
(6)応札情報の比較検討、商談の申し込み。
【0030】
図20は、買い手への応札情報一覧表示画面例を示す説明図である。買い手が仲介システムにアクセスすると表示される図16のバイヤーセンター画面には、受付中あるいは受付終了したリクエストのリストが表示され、所望のリクエストの「比較検討する」ボタンをクリックすることにより、図20の一覧表示画面に移行する。
【0031】
図4は、本発明の仲介装置10における買い手への比較検討ページの表示処理の内容を示すフローチャートである。買い手端末40のWebブラウザーには図16のバイヤーセンター画面が表示されているものとする。S001において、バイヤーセンター画面には、受付中あるいは受付終了したリクエストのリストが表示され、所望のリクエストの「比較検討する」ボタンをクリックすることにより、埋め込まれているリクエスト番号がサイト10へ送信される。
【0032】
サイト10は、S002において、指定されたリクエスト番号を抽出条件として応札データベースからリクエストに対する全応札データを抽出する。S003においては、抽出した各応札データに削除フラグが立っているか否かをチェックし、フラグが立っているものを削除する。S004においては、抽出した各応札データの応答の有効期間が期限切れしているか否かチェックし、期限が切れているものを削除する。S005においては、応札内容比較検討テーブル(一覧表)HTMLファイルを生成し、買い手端末40へ送信する。買い手端末40のブラウザーは受信した一覧表HTMLファイル(図20)を表示する。
図7は、本発明の仲介装置における買い手への比較検討ページの表示処理の詳細内容を示すフローチャートである。図7におけるステップ番号は図4と対応しており、図7においては図4の処理内容に加えて一覧表の表示項目についても記載されている。
【0033】
一覧表示画面においては、全ての応札情報が一覧表示され、売り手の企業名も表示されている。買い手は左欄の「企業概要」ボタンをクリックすることにより、売り手の詳細(登録)情報を表示させることができる。図21は、買い手への応札企業概要表示画面例を示す説明図である。また、買い手は左欄の「断る」ボタンをクリックすることにより、当該応札を一覧表から削除することができる。
【0034】
図5は、本発明の仲介装置における買い手への比較検討ページの再表示処理の内容を示すフローチャートである。買い手端末40のWebブラウザーには図20の一覧表画面が表示されているものとする。S007において、買い手が断りたいリクエストの「断る」ボタンをクリックすることにより、クリック位置情報と共に埋め込まれている応札番号がサイト10へ送信される。
【0035】
サイト10は、S008において、指定された応札番号に対し削除フラグを立てるために、応札データベースを更新する。S009においては、更新が成功したか否かをチェックし、不成功の場合には端末40にエラー表示HTMLファイルを送信し、端末40においては、S011において当該ファイルを表示する。この後の処理は図4のS002以降の処理と同一であるので説明は省略する。図8は、本発明の仲介装置における買い手への比較検討ページの再表示処理の内容を示すフローチャートである。内容としては図5と同一である。
買い手は図20に示す画面において各応札情報を比較し、商談を申し込む売り手を決定して、当該売り手と対応する「商談を申し込む」ボタンをクリックする。
【0036】
図6は、本発明の仲介装置における買い手の商談申し込み処理の内容を示すフローチャートである。買い手端末40のWebブラウザーには図20の一覧表画面が表示されているものとする。S012において、買い手が商談を申し込みたいリクエストの「商談を申し込む」ボタンをクリックすることにより、クリック位置情報と共に埋め込まれている応札番号がサイト10へ送信される。
【0037】
サイト10は、S013において、指定された応札番号を選択条件として顧客データベースから売り手情報を取得する。S014においては、図22に表示例を示すような商談申し込みHTMLファイルを生成する。買い手端末40においては、S015において商談申し込みHTMLファイルを表示し、S016において担当者名、部署、連絡方法、コメント等を入力させ、送信する。
【0038】
サイト10は、S017において商談申し込み番号を新たに採番し、商談申し込みデータベースを更新すると共に、当該応札データに削除フラグを立てるために応札データベースを更新する。S18においては、更新が成功したか否かがチェックされ、不成功の場合には端末40にエラー表示HTMLファイルを送信し、端末40においては、S021において当該ファイルを表示する。
【0039】
データベースの更新が成功した場合にはS019に移行し、売り手登録情報としてメール通知を希望しているか否かがチェックされる。そして、メール通知を希望している場合にはS20に移行して、商談申し込みが行われたことをメールで売り手に通知すると共にメール用データベースに保存する。
【0040】
図9は、本発明の仲介装置における買い手の商談申し込み処理の詳細内容を示すフローチャートである。図9におけるステップ番号は図6と対応しており、図9においては図6の処理内容に加えて表示項目についても記載されている。図22は、買い手への商談申し込み画面例を示す説明図である(申し込み記入後の確認画面)。
【0041】
(7)商談依頼通知。
【0042】
サイト10は、商談申し込みのあった売り手に対して買い手の名称や担当者名、電話番号などが記載されたメールで通知を出し、この時点において売り手に買い手が判明する。売り手はサイト10にアクセスして、買い手の連絡先等の情報を付加した商談依頼通知を確認することもできる。図23は、売り手への商談申し込み表示画面例を示す説明図である。この画面においては、買い手の名称や担当者名、電話番号などが記載されている。
【0043】
(8)直接商談。
【0044】
その後は、売り手と買い手が直接連絡を取り、商談を進める。サイト10は、例えば商談依頼通知を発送した売り手に対して所定の仲介料を請求するための請求書を発行する。
【0045】
(9)評価情報の入力。
【0046】
買い手には売り手の評価情報を入力してもらい、売り手の評価に反映させる。図24は、買い手への評価情報入力画面例を示す説明図である。この画面は1回の商談申し込みにつき1回だけ記入可能であり、評価はポイントとして数値化、積算され、例えば売り手の詳細情報表示画面(図21)において閲覧できるにしてもよい。
【0047】
以上、本発明の実施例を開示したが、本実施例には下記のような変形例も考えられる。実施例においては、仲介装置10内に登録された売り手の情報を表示する実施例を開示したが、更に、買い手が売り手のサーバにアクセスすることにより、売り手の広告ホームページにアクセスすることができるように構成してもよい。
【0048】
実施例としては、各カテゴリーに共通するリクエストフォームを使用してリクエストを入力する例を開示したが、カテゴリーによって、リクエストする場合の項目内容や項目数が異なる場合もある。従って、カテゴリー毎に最適なリクエストフォームを作成してもよい。更に、買い手が自らリクエストフォームをカスタマイズでき、そのフォームに応じて応札フォームが生成されるようにしてもよい。このような構成にすることにより、精度の高い見積もりや提案を受けることができる。
【0049】
例えばインターネットに接続可能な携帯電話やPHSでリクエストや応札を可能とするために、特にフリーフォームの入力欄に文章を入力するために、定型リクエスト文の選択、穴埋め式定型文、カスタマイズ可能な定型文などを利用できるようにしてもよい。
実施例においては、登録情報、リクエスト、応札などの情報としては文字(コード)情報のみを扱う例を開示したが、図形、画像、音声その他のマルチメディア情報(ファイル)も扱えるようにしてもよい。
【0050】
実施例においては、買い手はまず登録を行ってからリクエストを入力する例を開示したが、登録に抵抗感のあるユーザは当該サイトを覗きにきても、登録せずに終了してしまうことが予想される。そこで、未登録の会員でもリクエストを記入することが出来、リクエストの入力が完了した時点で登録画面へと移行するようにしてもよい。この場合、リクエストは登録完了後に初めて有効となるようにする。このような構成とすることにより、当システムへの登録者がより増加することが期待できる。
【0051】
実施例においては、サービスについての仲介システムの例を開示したが、本発明の仲介装置および仲介方法は任意のサービスをはじめ、任意の商品など全ての商取引について同様に実施可能である。
【0052】
更に、以下に各機能や処理ごとの変形例を示す。
<登録プロセス>
登録プロセスにおいて、仲介市場の加盟メンバーを増やし市場を活性化するために、メンバー登録時に紹介者の氏名またはメールアドレスを入力できるようにしてもよい。口コミによる紹介による効果(一定の信頼できるメンバーを獲得できる)を利用し、信頼できる加盟者の獲得につながる。さらに、加盟メンバーに対し紹介インセンティブを提供する仕組みにも活用できる。
登録情報として、設立年(営業開始年)、資本金、従業員数、売上の項目についてセラーだけでなく、バイヤーも入力させ、売り手に対しても取引上の信用情報を提供するようにしてもよい。
加盟メンバーの信頼性を高めるために、仮登録方式を導入し、実在するメールアドレス以外を登録しない限り、利用できないようにしてもよい。こうすれば、無料で利用できるメールアカウントの利用も防止することができる。
加盟ユーザーになる場合、一定の基準を設け、その基準に適合する場合、電子的な個人認証を発行し、仲介サービス取引の際に利用できるようにすることができるようにしてもよい。それにより、利用メンバー(買い手及び売り手)の信頼性を向上し、取引上のなりすましの防止、契約や見積内容に対する否認の防止なども行うことが可能となる。
買い手が提供するサービスとして選択できるサービスカテゴリーの拡充・精緻化をはかり、買い手と売り手の高精度なマッチングを可能としてもよい。売り手の登録数が十分ではないカテゴリーがあることから、カテゴリーの2部制を導入してもよい。第1部のカテゴリーでは売り手もサービス提供カテゴリーとして登録できるし、買い手もそのカテゴリーに対しリクエストすることができる。一方、第2部のカテゴリでは売り手はそのカテゴリーを登録時に選択できるが、買い手はそのカテゴリに対しリクエストはできないようにしてもよい。
登録情報として、各自フリーフォーマットで記入できる項目(事業概要、提供サービス詳細、特色・PRポイント、今までの実績・主要取引先、関連企業、所属協会・団体名など)については記入例を付加してもよい。各メンバーの記入レベルを一定以上に合わせることで各自が信頼できる情報提供することを支援することができる。
【0053】
<見積依頼>
サービスカテゴリーの拡充・精緻化をはかり、買い手と売り手の高精度なマッチングが可能としてもよい。2部制導入により、2部のものはリクエストできないようにしてもよい。
支払方法、支払時期などの信用情報をリクエスト時に買い手にフォームに入力させることで、売り手にとって応札しやすい情報提供が可能になるようにしてもよい。
電子認証を保持するユーザーからのリクエストの場合、通常のユーザーからのリクエストと異なり、「信頼できる買い手からのリクエスト」という形で信用情報を追加し、売り手に安心感を提供することができるようにしてもよい。
いたずら・冷やかしのリクエスト登録を防ぐ、または情報が不足しているリクエストを改善するため、一度目視確認をした後、当該リクエストを承認する手続きを行った後、正式なリクエストとして売り手に通知することができるようにしてもよい。
サービスカテゴリ毎に、リクエスト時に記入すべき事項を表示させ、買い手がリクエスト時に何をどうのように書いたら分からないという状況を大幅に改善し、正確な見積を獲得できるようなリクエストを当該サービスについては素人であることの多い買い手でも作成することができるようにしてもよい。
フリーフォーマットで記入できる項目(リクエスト内容、その他コメントなど)については、具体的な記入例をつけることで、売り手が見積しやすい見積依頼を作成することが可能となるようにしてもよい。
リクエスト時に選択されるカテゴリー毎に、バナー広告などの表示が変化し、カテゴリーとは直接競合しない、あるいは補完し合えるような広告をサイト上に露出させるようにしてもよい。仮にカテゴリと競合するような広告が表示される場合、買い手がリクエストを行うことなく、広告先のサイトに移動してしまう危険性がある。ユーザー毎に広告のクリック履歴をトラッキングすることで、ユーザーの嗜好調査や、広告効果測定なども可能となる。
【0054】
<見積>
買い手が当該案件を、まだ登録していないユーザーに対して紹介できるようにしてもよい。これにより、紹介されたユーザーが加盟ユーザとなる場合、売り手の加盟ユーザが増えることで、買い手のニーズに対して十分に応えることが可能となる。また、紹介先の担当者が登録に至ったかどうかまでトラッキングする機能も提供することができる。
サービスカテゴリ毎に見積時に記入する項目(リクエストに対する提案/サービスのPR、参考見積価格など)を、次回の見積作成時に利用できるようにすることができるようにしてもよい。
フリーフォーマットで記入できる項目(バイヤーに対する質問)については、具体的な記入例をつけることで、買い手が見積比較しやすい情報を提供することが可能となるようにしてもよい。
見積作成時、セラー用の登録情報として入力したものがデフォルト表示され(ホームページ、提供サービス詳細、特色・PRポイント、今までの実績・取引先など、関連企業、所属協会・団体名)、毎回同じ内容の記入を不要にすることができるようにしてもよい。一方、当該リクエストに見合ったPRなどの記述に変更することや、登録情報にその内容を反映するようにしてもよい。
リクエスト時のバイヤーからセラーへの質問以外に、見積提案時にもセラーからバイヤーへの質問を可能にし、商談を進める過程でお互いの不明点を明らかにすることで、実際の商談にスムーズに入れるようにすることができるようにしてもよい。
電子証明を保持する売り手からの見積の場合、通常のユーザーからの見積(応札)とは異なり、「信頼できる売り手からの見積」という形で信用情報を提供するようにしてもよい。買い手に安心感を提供することができる。
リクエスト詳細を閲覧するときに、バイヤーの信用情報(事業概要、設立年、資本金、従業員数、前年度売上)を表示し、売り手が買い手の信用について判断することができるようにしてもよい。
売り手に見積をしたにもかかわらず、連絡が全くこない場合、その売り手に対し「催促メール」を送信できるようにしてもよい。
買い手が対処できる数の見積数の上限を設け、原則早く見積を出した順番で見積を作成することができるようにしてもよい。その場合上限の数を超えて見積を出そうとしても、見積は登録できないようにしてもよい。
【0055】
<見積比較>
見積比較テーブルの企業欄に、各セラーの評価結果がマーク表示され(例えば3段階)、比較テーブル上で直感的に評価ランク付けが分かるようにしてもよい。
当仲介サービスで、商談依頼まで発生した取引について、買い手が売り手に対して、評価を行うようにしてもよい。評価は一定の算式に応じて点数化され、表示上に反映することができるようにしてもよい。
売り手に対して過去に行われたすべての評価およびサービス利用の有無が一覧で閲覧することができ、商談相手として信頼できるかどうか記入されている内容(評判)から判断することができるようにしてもよい。
評価を行ったときに他のバイヤーから問い合わせを受け付けると指定した買い手に対して、そのつど買い手にそのセラーについて質問を投げることができるようにしてもよい。
過去に問合せされた内容については、すべて問合せ履歴としてそのすべてを一覧できるようにしてもよい。
他のバイヤーから、過去に利用したセラーについての問合せに対し、回答を行うことができるようにしてもよい。
見積時のセラーからバイヤーへ質問を回答する以外に、商談依頼時にバイヤーからセラーに質問を回答することを可能にし、商談を進める過程でお互いの不明点を明らかにすることができるようにしてもよい。実際の商談にスムーズに入れるようにすることができる。
フリーフォーマットで記入できる項目(コメントなど)については、具体的な記入例をつけてもよい。売り手が商談を進めやすい商談依頼を作成することが可能となる。
見積の拒否理由を入力させ、なぜ今回の見積が断われたかを売り手に知らせるようにしてもよい。次回の見積や商談に生かせるようにすることができる。
電子証明を保持する売り手からの見積の場合、通常のユーザーからの商談依頼とは異なり、「信頼できるバイヤーからの商談依頼」という形で信用情報を提供でき、売り手に安心感を提供することができる。
買い手に商談を申込んだにもかかわらず、連絡が全くこない場合、その買い手に対し「催促メール」を送信できるようにしてもよい。
【0056】
<情報の開示>
電子証明を利用した場合、電子証明ごとに情報の閲覧権限を設定することで、加盟ユーザごとに見ることのできる情報を制御するようにしてもよい。これ以外の方法でも、加盟ユーザーごとに権限プロファイルを設定し、閲覧できる情報や実行できる対象を制御することができるようにしてもよい。例えば、加盟ユーザーが、ある他社の加盟ユーザーに対し、一定期間ぐらい信用情報を閲覧する権利を任意に与えることができ、自分の許可するユーザーにのみ重要な情報を公開できる。仲介取引の中で蓄積した情報を、仲介取引をはじめ各種取引において加盟メンバーについての信用情報を指定する第三者や加盟メンバーに提供できる。
<メールのやりとり>
電子認証を保持する場合、メールクライアントに認証をインストールすれば、仲介サイトとユーザーとのメールのやりとり、および加盟ユーザー間のメールのやり取りにおいて、データの保全を確保することに利用できるようにしてもよい。
【0057】
<評価プロセス>
セラーと実際に取引があったかどうか、商談態度やサービス品質、他の利用者からの問合せ、コメントについて記入し、セラーの商談活動を評価することができるようにしてもよい。
評価時にバイヤーからサービス提供を受けたかどうかをきくことができるので、契約したかどうかが分かる。
取引の有無を把握することで、セラーからコミッションを徴収する場合に利用できる。
電子認証を保持するユーザーによる評価の場合、通常のユーザーからのリクエストと異なり、「信頼できるユーザーからの評価」という形で信用情報を追加し、買い手に安心感を提供することができる。
<商談結果報告>
セラーがバイヤーに実際にサービスを提供(契約)したかどうか、結果を報告させることができるようにしてもよい。報告する場合に、必要であれば契約書や請求書も併せて送付してもらうことで、取引実績を証明することもできる。
取引の有無を把握することで、セラーからコミッションを徴収する場合に利用できる。
【0058】
<成約確認・請求>
成約まで至った可能性のある案件について、確認メールを送信し、その取引内容を確認することができるようにしてもよい。
応札料、商談依頼料、登録料金、およびコミッション料金について、過去に発生したトランザクションから算出して毎月請求書を作成するようにしてもよい。
毎月の請求内容について、SSLなどで暗号化した接続を利用してその内容をユーザーが閲覧することができるようにしてもよい。
<請求書照合>
ユーザーからの入金額について、入力することができるようにしてもよい。
ユーザーからの振込み金額と請求との間に過不足がないかどうかを確認することができるようにしてもよい。その結果については、支払履歴としてユーザーごとに管理され、その支払実績を評価することもできるようにしてもよい。
【0059】
<顧客サポート>
見積依頼促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
見積促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
商談依頼促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
ユーザー毎に、問合せがある毎にその履歴をデータベースに登録し、担当者が変ったとしても一貫したサポートを提供することができるようにしてもよい。ユーザーが指定の意見・質問フォームを利用して問合せをすれば、問合せ管理画面で情報を一元管理できるようにしてもよい。
促進活動以後の対応したユーザーのアクティビティーを表示し、どの程度効果があるかどうかをみることができるようにしてもよい。
【0060】
<アカウント管理>
バイヤー登録後、セラーとして登録変更できるようにしてもよい。
メールアドレスの変更中は、ログインできず、確認メールにあるURLをクリックすることではじめて新しいメールアドレスが反映されるようにしてもよい。
パスワード忘れの場合、自動検索機能により、メールアドレスもしくは電話番号を入力することで、自動的に該当するメールアドレスにパスワードを通知することができるようにしてもよい。
<知人紹介>
自らの紹介により加盟したユーザー(バイヤー・セラー)について、一覧で閲覧できるようにしてもよい。加盟ユーザー数に応じてポイントが溜まる仕組みになっており、加盟ユーザー獲得のインセンティブを提供してもよい。一種の口コミによる紹介という枠組みを利用し、ある程度の信頼できる加盟ユーザーを獲得することができる。知人紹介により獲得したポイントに応じて、Webサイトから各種商品・サービスと交換できる仕組みを提供してもよい。
【0061】
<加盟ユーザーディレクトリー>
登録しているセラーについて、基本的な信用情報や企業概要を掲載してもよい。また、電子認証を受けているユーザーであれば、その点についても表示することができる。
<サイト訪問履歴管理>
サイトを訪問するセラー・バイヤーが、登録前はどこからサイトにアクセスしたのか、登録後日々の利用はどれぐらいの画面数なのか、使用頻度の低いページはどれか、処理がよく中断するページはどこか、などユーザー毎のサイト移動履歴をとることができるようにしてもよい。
<バナー広告表示>
リクエストのカテゴリに応じて、表示するバナーなどの広告を変化させるようにしてもよい。バナーの表示回数や、クリック回数についても併せてトラッキングを行うことができる。
【0062】
<スケジュール管理・グループウェア>
他社の提供するスケジュール管理機能との統合。商談プロセス(見積から契約、サービス導入、評価まですべて)に渡り、アカウントページのステータスとスケジュールが連携したり、コンタクトしたセラー・バイヤーについて連絡先として登録できたり、書類などファイルの共有ができるなど、商談を円滑に進めるために外部ソフトウェアとのインターフェースを作成することで、マイアカウントページの情報とスケジュール管理ソフトとの情報が同期することができるようにしてもよい。スケジュール管理以外の機能でも、同様の連携は可能。
<リソースバンク>
セラーやバイヤーの経営活動を支えるコンテンツを提供してもよい。最も単純なのは相互リンクであるが、他社のサイトが自社内のフレームの中に入り込む形で表示させるなどの形で実現してもよい。サイト連携により、どれ位のユーザーが自社サイトに、ないし提携サイトに流れ、ユーザー登録までいたっかどうかトラッキングできる仕組みを提供することができる。
【0063】
<エキスパートコラム>
各専門分野におけるプロフェッショナルの方などからサイトコンテンツを収集する上で、各専門家、フリーライターや記者などの方にコンテンツ提供ページを提供し、そこに直接コンテンツ(記事など)をWebサイトを経由して提供することができ、その内容は社内で内容確認して承認することで、本番のサーバー上で閲覧できるようになるようにしてもよい。コンテンツ編集・管理プロセスを効率的に行うことができる。
<メールマガジン>
メールマガジンの購読申込み、配信先変更、解約ができるようにしてもよい。メンバー登録する場合は、自動的にメールマガジン登録申し込みがなされるようにしてもよい。
【符号の説明】
【0064】
10…仲介装置(サーバーシステム)、11…Webサーバ、12…Webアプリケーションサーバ、13…データベースサーバ、14…メールサーバ、20…インターネット、30…クライアント側端末、31…Webブラウザ、32…メールクライアント、40…買い手端末、50…売り手端末
【技術分野】
【0001】
本発明は仲介装置および仲介方法に関し、特に、ネット上で売り手と買い手の間の仲介を行う仲介装置および仲介方法において、買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法に関するものである。
【背景技術】
【0002】
近年、インターネットの普及に伴い、例えば商品等の売り手(Seller:セラー)がネット上において広告を出し、買い手(Buyer:バイヤー、ユーザ)は該広告を見て商談を申し込むことが広く行われている。
【発明の概要】
【発明が解決しようとする課題】
【0003】
前記したような従来の売り手の決定方法においては、買い手は欲しい物がどこの広告に載っているのかを検索する必要があり、検索した結果、多数の売り手が判明した場合には、それら多数の売り手のそれぞれに対してメール等を使用して見積もり等を請求し、回答を得た売り手の中から一番条件のよさそうな売り手を選択する必要があった。更に、売り手が信用できる相手であるか否かを調査するためには、別の検索等が必要であり、多数の労力が必要であるにも関わらず、最適な売り手を選択することが困難であるという問題点があった。
【0004】
本発明の目的は、前記のような従来技術の問題点を解決し、ネット上で売り手と買い手の間の仲介を行う仲介装置および仲介方法において、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法を提供することにある。
【課題を解決するための手段】
【0005】
本発明の売り手と買い手の仲介を行う仲介装置においては、売り手の登録手段と、買い手の登録手段と、買い手の発注情報の入力手段と、買い手の識別情報を除いた発注情報のみを売り手に表示する発注情報表示手段と、前記発注情報に対して売り手が応札情報を入力する応札情報入力手段と、応札情報を一覧表にして買い手に表示する応札情報表示手段と、買い手が希望する売り手に対して買い手の情報を含む商談依頼の通知を行う商談依頼通知手段とを備えたことを特徴とする。
本発明によれば、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる。また、登録内容をシステム側で確認すること等により、買い手に信用情報を提供することも可能である。
【発明の効果】
【0006】
以上述べたように、本発明の売り手と買い手の仲介を行う仲介装置および仲介方法においては、買い手にとっては、多数の企業の中から自社のニーズに適合した企業を容易に選択することができ、手間や時間をかけずに効率的にアクセス可能であるという効果がある。また、売り手にとっては、新しいセールスチャンスを獲得でき、顧客の方からリクエストが提示されてくるので、多額の広告や飛び込みの営業活動などを行う必要がなく、やはり効率的な営業活動ができるという効果がある。
【図面の簡単な説明】
【0007】
【図1】本発明の仲介装置を含むシステム全体の構成を示すブロック図である。
【図2】本発明の仲介装置を含むシステム全体の他の構成例を示すブロック図である。
【図3】本発明の仲介装置において実行される仲介方法の概要を示す説明図である。
【図4】本発明の買い手への比較検討ページの表示処理の内容を示すフローチャートである。
【図5】本発明の買い手への比較検討ページの再表示処理の内容を示すフローチャートである。
【図6】本発明の買い手の商談申し込み処理の内容を示すフローチャートである。
【図7】本発明の買い手への比較検討ページの表示処理の詳細内容を示すフローチャートである。
【図8】本発明の買い手への比較検討ページの再表示処理の内容を示すフローチャートである。
【図9】本発明の買い手の商談申し込み処理の詳細内容を示すフローチャートである。
【図10】売り手のカテゴリー登録画面例を示す説明図である。
【図11】売り手の担当者登録画面例を示す説明図である。
【図12】売り手の企業情報登録画面例を示す説明図である。
【図13】買い手へのアピール情報登録画面例を示す説明図である。
【図14】売り手の地域フィルタ登録画面例を示す説明図である。
【図15】買い手のリクエスト(発注)登録画面例を示す説明図である。
【図16】売り手のアクセス時の初期画面例を示す説明図である。
【図17】リクエスト一覧表示画面例を示す説明図である。
【図18】売り手のリクエスト詳細表示画面例を示す説明図である。
【図19】売り手の応札情報入力画面例を示す説明図である。
【図20】買い手への応札情報一覧表示画面例を示す説明図である。
【図21】買い手への応札企業概要表示画面例を示す説明図である。
【図22】買い手への商談申し込み画面例を示す説明図である。
【図23】売り手への商談申し込み表示画面例を示す説明図である。
【図24】買い手への評価情報入力画面例を示す説明図である。
【発明を実施するための形態】
【0008】
以下、本発明の実施の形態を詳細に説明する。図1は、本発明の仲介装置であるサーバーシステム10を含むシステム全体の構成例を示すブロック図である。仲介装置10には、Web(WWW:World Wide Web)サーバ11、Webアプリケーションサーバ12、DB(データベース)を備えたデータベースサーバ13、メール(SMTP:Simple Mail Transfer Protocol)サーバ14が図示しないLANによって接続されており、更に、Webサーバ11は、図示しないルータによってインターネット20に接続されている。この他、LANには図示しない複数の保守、管理用のサーバ、端末が接続されている。
データベースには、売り手や買い手の登録情報を格納する顧客DB、リクエストDB、応札DB、商談申し込みDB、メール用DBなどが格納されており、後述する仲介装置10の機能は、各サーバが分担して処理する。各サーバ11〜14の機能は周知であり、それぞれ周知の市販のサーバ装置に周知の市販のOSを搭載し、市販の、あるいは後述するような処理を実行するプログラムを実装することにより実現できる。
【0009】
Webアプリケーションサーバ12の機能はCGIやその他のスクリプトプログラムによって代替可能であり、省略することもできる。クライアント側の端末30は例えば周知のWebブラウザ31およびメールクライアント32を備え、インターネット20にアクセス可能な周知の市販のPC(パソコン)であってもよい。
【0010】
図2は、本発明の仲介装置であるサーバーシステム10を含むシステム全体の他の構成例を示すブロック図である。この実施例は図1に示したシステム構成からメールサーバ14およびメールクライアント32を除いたものである。クライアントは、Webブラウザ31によってサーバシステム10にアクセスすることによって、本発明の全ての処理を実行するようにすることも可能である。
【0011】
図3は、本発明の仲介装置10において実行される仲介方法の概要を示す説明図である。図3に基づき、本発明の仲介方法の概要およびサイト10の機能を説明する。なお、実施例においては、複数のカテゴリーに属する各種サービスの仲介を行う例について説明する。
【0012】
(1)まず、買い手(バイヤー端末40(30))と売り手(セラー端末50(30))はそれぞれ本発明の仲介システム(サイト)10に登録を行う。なお、売り手は自分の提供するサービスのカテゴリーも登録する。サイト10は登録内容をデータベースに登録する。(2)次に、買い手は特定のカテゴリーを選択してリクエスト(発注情報)を入力する。サイト10は、リクエストを買い手と対応づけて保存する。
【0013】
(3)サイト10は、リクエストをカテゴリーの一致する全ての売り手にメールで配信する。但し、このリクエストには買い手の企業名等の情報は付加されていない。(4)売り手は、本発明の仲介システムにアクセスし、自分の属するカテゴリーのリクエストを閲覧し、応札したいリクエストに対して応札情報を入力する。サイト10は、応札情報をリクエストと対応して保存する。
【0014】
(5)所定の応札期間内に、応札があった場合には、サイト10は買い手にメールで応札があったことを通知し、(6)買い手は仲介システムにアクセスして応札情報を読み出す。サイトは全ての応札情報を一覧表に編集して買い手に表示する。この場合には応札企業の詳細情報も読み出すことができる。買い手は各応札情報を比較検討して、商談を申し込む売り手を決定する。そして、商談申し込み情報を入力する。
【0015】
(7)サイト10は、商談申し込みのあった売り手に対してメールで通知を出し、売り手はサイト10にアクセスして、買い手の連絡先等の情報を付加した商談依頼通知を閲覧する。(8)その後は、売り手と買い手が直接連絡を取り、商談を進める。サイト10は、例えば商談依頼通知を発送した売り手に対して所定の仲介料を請求するための請求書を発行する。(9)また、買い手には売り手の評価情報を入力してもらい、売り手の評価に反映させる。
次に、クライアントの端末に表示される画面例の図面を参照して仲介方法の詳細について説明する。
【0016】
(1)ユーザ登録。
【0017】
図10は、売り手のカテゴリー登録画面例を示す説明図である。売り手は、登録時に自分の会社のサービスと対応するカテゴリーを1つ以上選択する。なお、該当するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、カテゴリーの追加申請を行うことができる。
【0018】
図11は、売り手の担当者登録画面例を示す説明図である。また、図12は、売り手の企業情報登録画面例を示す説明図である。更に、図13は、売り手から買い手へのアピール情報登録画面例を示す説明図である。図13に示した各アピール情報はそれぞれ300字以内の文章で自由に記載することができるようになっている。このような構成にすることにより、売り手がセールスポイントを的確に表現することが可能となり、買い手が売り手を選択する際の貴重な情報源となる。
図14は、売り手の地域フィルタ登録画面例を示す説明図である。売り手は、この画面において地域を指定することにより、サービスを実施する地域が指定した地域と一致するリクエストのみを受け取ることができる。なお、買い手の登録内容は、売り手の登録内容からカテゴリー、アピール情報、指定地域等を除いたものである。以上のような画面によって入力された各種情報はサイト10のデータベースに登録され、登録者にはIDおよびパスワードが発行される。登録内容の変更、解約も随時可能である。
【0019】
(2)リクエスト(発注情報)の入力。
【0020】
図15は、買い手のリクエスト(発注)登録画面例を示す説明図である。買い手が仲介システムにアクセスし、例えばIDおよびパスワードによって認証をパスすると、サイト10は、図16に示すようなバイヤーセンター画面を表示し、買い手が画面下段に表示されているサービスのカテゴリー一覧表の中から該当するサービスカテゴリーを選択(クリック)すると図15の画面に移行する。
図15の画面においてはサービスの利用場所、時期、予算、応札受付終了日等の項目の入力の他、「リクエスト内容」、「自社概要」、「質問」の各項目について300字以内の文章で自由に記載できるフォームを採用している。このように、フリーフォームで記入できるようにすることにより、多様なニーズに対応可能である。サイト10は入力されたリクエストを買い手と対応してリクエストDBに保存する。
【0021】
(3)リクエスト配信。
【0022】
サイト10は買い手の入力したリクエスト情報をカテゴリーの一致する全ての売り手にメールで配信する。但し、買い手の企業名や電話番号など買い手を特定可能な情報は付加されていない。
【0023】
(4)応札情報の入力。
【0024】
図16は、売り手のアクセス時の初期画面例を示す説明図である。売り手が仲介システムにアクセスし、例えばIDおよびパスワードによって認証をパスすると、サイト10は、図16に示すようなセーラーセンターおよびバイヤーセンター画面を表示する。買い手の場合にはバイヤーセンターのみが表示されるが、売り手の場合には買い手になる可能性もあるので、双方が表示される。
セラーセンターの上段のリストは当売り手が登録しているサービスの各カテゴリー(「ホームページ作成」と「インターネット広告」の2つ)におけるリクエスト数を表示しており、右欄の「応札へ」をクリックすると、図17の画面に移行する。
【0025】
図17は、リクエスト一覧表示画面例を示す説明図である。売り手は、任意のリクエストの「案件名」の部分をクリックするか、最右端のチェックボタンの1つあるいは複数個にチェックを入れて、下段の「詳細情報一覧表示」ボタンをクリックすることにより、図18のリクエストの詳細情報を見ることができる。
なお、図17の応札中リクエスト一覧画面は、未登録のユーザも見ることができ、登録する前に本発明の仲介システムにおいてどのような発注が出されているのかが確認できるようになっている。但し、未登録ユーザはリクエストの詳細情報を見ることはできない。
【0026】
図18は、売り手のリクエスト詳細表示画面例を示す説明図である。売り手はこのリクエストの詳細情報を見て応札を希望する場合には下段の「応札する」ボタンをクリックする。
図19は、売り手の応札情報入力画面例を示す説明図である。応札情報としては、価格レンジ、提案の有効期間と共に、「質問への回答」「提供サービスのアピール」の項目について、300字以内の文章で自由に記載できるフォームを採用している。サイト10は応札情報をリクエストと対応して応札DBに保存する。
【0027】
(5)応札通知。
【0028】
所定の応札期間内に応札があった場合には、サイト10は買い手にメールで応札があっとことを通知する。
【0029】
(6)応札情報の比較検討、商談の申し込み。
【0030】
図20は、買い手への応札情報一覧表示画面例を示す説明図である。買い手が仲介システムにアクセスすると表示される図16のバイヤーセンター画面には、受付中あるいは受付終了したリクエストのリストが表示され、所望のリクエストの「比較検討する」ボタンをクリックすることにより、図20の一覧表示画面に移行する。
【0031】
図4は、本発明の仲介装置10における買い手への比較検討ページの表示処理の内容を示すフローチャートである。買い手端末40のWebブラウザーには図16のバイヤーセンター画面が表示されているものとする。S001において、バイヤーセンター画面には、受付中あるいは受付終了したリクエストのリストが表示され、所望のリクエストの「比較検討する」ボタンをクリックすることにより、埋め込まれているリクエスト番号がサイト10へ送信される。
【0032】
サイト10は、S002において、指定されたリクエスト番号を抽出条件として応札データベースからリクエストに対する全応札データを抽出する。S003においては、抽出した各応札データに削除フラグが立っているか否かをチェックし、フラグが立っているものを削除する。S004においては、抽出した各応札データの応答の有効期間が期限切れしているか否かチェックし、期限が切れているものを削除する。S005においては、応札内容比較検討テーブル(一覧表)HTMLファイルを生成し、買い手端末40へ送信する。買い手端末40のブラウザーは受信した一覧表HTMLファイル(図20)を表示する。
図7は、本発明の仲介装置における買い手への比較検討ページの表示処理の詳細内容を示すフローチャートである。図7におけるステップ番号は図4と対応しており、図7においては図4の処理内容に加えて一覧表の表示項目についても記載されている。
【0033】
一覧表示画面においては、全ての応札情報が一覧表示され、売り手の企業名も表示されている。買い手は左欄の「企業概要」ボタンをクリックすることにより、売り手の詳細(登録)情報を表示させることができる。図21は、買い手への応札企業概要表示画面例を示す説明図である。また、買い手は左欄の「断る」ボタンをクリックすることにより、当該応札を一覧表から削除することができる。
【0034】
図5は、本発明の仲介装置における買い手への比較検討ページの再表示処理の内容を示すフローチャートである。買い手端末40のWebブラウザーには図20の一覧表画面が表示されているものとする。S007において、買い手が断りたいリクエストの「断る」ボタンをクリックすることにより、クリック位置情報と共に埋め込まれている応札番号がサイト10へ送信される。
【0035】
サイト10は、S008において、指定された応札番号に対し削除フラグを立てるために、応札データベースを更新する。S009においては、更新が成功したか否かをチェックし、不成功の場合には端末40にエラー表示HTMLファイルを送信し、端末40においては、S011において当該ファイルを表示する。この後の処理は図4のS002以降の処理と同一であるので説明は省略する。図8は、本発明の仲介装置における買い手への比較検討ページの再表示処理の内容を示すフローチャートである。内容としては図5と同一である。
買い手は図20に示す画面において各応札情報を比較し、商談を申し込む売り手を決定して、当該売り手と対応する「商談を申し込む」ボタンをクリックする。
【0036】
図6は、本発明の仲介装置における買い手の商談申し込み処理の内容を示すフローチャートである。買い手端末40のWebブラウザーには図20の一覧表画面が表示されているものとする。S012において、買い手が商談を申し込みたいリクエストの「商談を申し込む」ボタンをクリックすることにより、クリック位置情報と共に埋め込まれている応札番号がサイト10へ送信される。
【0037】
サイト10は、S013において、指定された応札番号を選択条件として顧客データベースから売り手情報を取得する。S014においては、図22に表示例を示すような商談申し込みHTMLファイルを生成する。買い手端末40においては、S015において商談申し込みHTMLファイルを表示し、S016において担当者名、部署、連絡方法、コメント等を入力させ、送信する。
【0038】
サイト10は、S017において商談申し込み番号を新たに採番し、商談申し込みデータベースを更新すると共に、当該応札データに削除フラグを立てるために応札データベースを更新する。S18においては、更新が成功したか否かがチェックされ、不成功の場合には端末40にエラー表示HTMLファイルを送信し、端末40においては、S021において当該ファイルを表示する。
【0039】
データベースの更新が成功した場合にはS019に移行し、売り手登録情報としてメール通知を希望しているか否かがチェックされる。そして、メール通知を希望している場合にはS20に移行して、商談申し込みが行われたことをメールで売り手に通知すると共にメール用データベースに保存する。
【0040】
図9は、本発明の仲介装置における買い手の商談申し込み処理の詳細内容を示すフローチャートである。図9におけるステップ番号は図6と対応しており、図9においては図6の処理内容に加えて表示項目についても記載されている。図22は、買い手への商談申し込み画面例を示す説明図である(申し込み記入後の確認画面)。
【0041】
(7)商談依頼通知。
【0042】
サイト10は、商談申し込みのあった売り手に対して買い手の名称や担当者名、電話番号などが記載されたメールで通知を出し、この時点において売り手に買い手が判明する。売り手はサイト10にアクセスして、買い手の連絡先等の情報を付加した商談依頼通知を確認することもできる。図23は、売り手への商談申し込み表示画面例を示す説明図である。この画面においては、買い手の名称や担当者名、電話番号などが記載されている。
【0043】
(8)直接商談。
【0044】
その後は、売り手と買い手が直接連絡を取り、商談を進める。サイト10は、例えば商談依頼通知を発送した売り手に対して所定の仲介料を請求するための請求書を発行する。
【0045】
(9)評価情報の入力。
【0046】
買い手には売り手の評価情報を入力してもらい、売り手の評価に反映させる。図24は、買い手への評価情報入力画面例を示す説明図である。この画面は1回の商談申し込みにつき1回だけ記入可能であり、評価はポイントとして数値化、積算され、例えば売り手の詳細情報表示画面(図21)において閲覧できるにしてもよい。
【0047】
以上、本発明の実施例を開示したが、本実施例には下記のような変形例も考えられる。実施例においては、仲介装置10内に登録された売り手の情報を表示する実施例を開示したが、更に、買い手が売り手のサーバにアクセスすることにより、売り手の広告ホームページにアクセスすることができるように構成してもよい。
【0048】
実施例としては、各カテゴリーに共通するリクエストフォームを使用してリクエストを入力する例を開示したが、カテゴリーによって、リクエストする場合の項目内容や項目数が異なる場合もある。従って、カテゴリー毎に最適なリクエストフォームを作成してもよい。更に、買い手が自らリクエストフォームをカスタマイズでき、そのフォームに応じて応札フォームが生成されるようにしてもよい。このような構成にすることにより、精度の高い見積もりや提案を受けることができる。
【0049】
例えばインターネットに接続可能な携帯電話やPHSでリクエストや応札を可能とするために、特にフリーフォームの入力欄に文章を入力するために、定型リクエスト文の選択、穴埋め式定型文、カスタマイズ可能な定型文などを利用できるようにしてもよい。
実施例においては、登録情報、リクエスト、応札などの情報としては文字(コード)情報のみを扱う例を開示したが、図形、画像、音声その他のマルチメディア情報(ファイル)も扱えるようにしてもよい。
【0050】
実施例においては、買い手はまず登録を行ってからリクエストを入力する例を開示したが、登録に抵抗感のあるユーザは当該サイトを覗きにきても、登録せずに終了してしまうことが予想される。そこで、未登録の会員でもリクエストを記入することが出来、リクエストの入力が完了した時点で登録画面へと移行するようにしてもよい。この場合、リクエストは登録完了後に初めて有効となるようにする。このような構成とすることにより、当システムへの登録者がより増加することが期待できる。
【0051】
実施例においては、サービスについての仲介システムの例を開示したが、本発明の仲介装置および仲介方法は任意のサービスをはじめ、任意の商品など全ての商取引について同様に実施可能である。
【0052】
更に、以下に各機能や処理ごとの変形例を示す。
<登録プロセス>
登録プロセスにおいて、仲介市場の加盟メンバーを増やし市場を活性化するために、メンバー登録時に紹介者の氏名またはメールアドレスを入力できるようにしてもよい。口コミによる紹介による効果(一定の信頼できるメンバーを獲得できる)を利用し、信頼できる加盟者の獲得につながる。さらに、加盟メンバーに対し紹介インセンティブを提供する仕組みにも活用できる。
登録情報として、設立年(営業開始年)、資本金、従業員数、売上の項目についてセラーだけでなく、バイヤーも入力させ、売り手に対しても取引上の信用情報を提供するようにしてもよい。
加盟メンバーの信頼性を高めるために、仮登録方式を導入し、実在するメールアドレス以外を登録しない限り、利用できないようにしてもよい。こうすれば、無料で利用できるメールアカウントの利用も防止することができる。
加盟ユーザーになる場合、一定の基準を設け、その基準に適合する場合、電子的な個人認証を発行し、仲介サービス取引の際に利用できるようにすることができるようにしてもよい。それにより、利用メンバー(買い手及び売り手)の信頼性を向上し、取引上のなりすましの防止、契約や見積内容に対する否認の防止なども行うことが可能となる。
買い手が提供するサービスとして選択できるサービスカテゴリーの拡充・精緻化をはかり、買い手と売り手の高精度なマッチングを可能としてもよい。売り手の登録数が十分ではないカテゴリーがあることから、カテゴリーの2部制を導入してもよい。第1部のカテゴリーでは売り手もサービス提供カテゴリーとして登録できるし、買い手もそのカテゴリーに対しリクエストすることができる。一方、第2部のカテゴリでは売り手はそのカテゴリーを登録時に選択できるが、買い手はそのカテゴリに対しリクエストはできないようにしてもよい。
登録情報として、各自フリーフォーマットで記入できる項目(事業概要、提供サービス詳細、特色・PRポイント、今までの実績・主要取引先、関連企業、所属協会・団体名など)については記入例を付加してもよい。各メンバーの記入レベルを一定以上に合わせることで各自が信頼できる情報提供することを支援することができる。
【0053】
<見積依頼>
サービスカテゴリーの拡充・精緻化をはかり、買い手と売り手の高精度なマッチングが可能としてもよい。2部制導入により、2部のものはリクエストできないようにしてもよい。
支払方法、支払時期などの信用情報をリクエスト時に買い手にフォームに入力させることで、売り手にとって応札しやすい情報提供が可能になるようにしてもよい。
電子認証を保持するユーザーからのリクエストの場合、通常のユーザーからのリクエストと異なり、「信頼できる買い手からのリクエスト」という形で信用情報を追加し、売り手に安心感を提供することができるようにしてもよい。
いたずら・冷やかしのリクエスト登録を防ぐ、または情報が不足しているリクエストを改善するため、一度目視確認をした後、当該リクエストを承認する手続きを行った後、正式なリクエストとして売り手に通知することができるようにしてもよい。
サービスカテゴリ毎に、リクエスト時に記入すべき事項を表示させ、買い手がリクエスト時に何をどうのように書いたら分からないという状況を大幅に改善し、正確な見積を獲得できるようなリクエストを当該サービスについては素人であることの多い買い手でも作成することができるようにしてもよい。
フリーフォーマットで記入できる項目(リクエスト内容、その他コメントなど)については、具体的な記入例をつけることで、売り手が見積しやすい見積依頼を作成することが可能となるようにしてもよい。
リクエスト時に選択されるカテゴリー毎に、バナー広告などの表示が変化し、カテゴリーとは直接競合しない、あるいは補完し合えるような広告をサイト上に露出させるようにしてもよい。仮にカテゴリと競合するような広告が表示される場合、買い手がリクエストを行うことなく、広告先のサイトに移動してしまう危険性がある。ユーザー毎に広告のクリック履歴をトラッキングすることで、ユーザーの嗜好調査や、広告効果測定なども可能となる。
【0054】
<見積>
買い手が当該案件を、まだ登録していないユーザーに対して紹介できるようにしてもよい。これにより、紹介されたユーザーが加盟ユーザとなる場合、売り手の加盟ユーザが増えることで、買い手のニーズに対して十分に応えることが可能となる。また、紹介先の担当者が登録に至ったかどうかまでトラッキングする機能も提供することができる。
サービスカテゴリ毎に見積時に記入する項目(リクエストに対する提案/サービスのPR、参考見積価格など)を、次回の見積作成時に利用できるようにすることができるようにしてもよい。
フリーフォーマットで記入できる項目(バイヤーに対する質問)については、具体的な記入例をつけることで、買い手が見積比較しやすい情報を提供することが可能となるようにしてもよい。
見積作成時、セラー用の登録情報として入力したものがデフォルト表示され(ホームページ、提供サービス詳細、特色・PRポイント、今までの実績・取引先など、関連企業、所属協会・団体名)、毎回同じ内容の記入を不要にすることができるようにしてもよい。一方、当該リクエストに見合ったPRなどの記述に変更することや、登録情報にその内容を反映するようにしてもよい。
リクエスト時のバイヤーからセラーへの質問以外に、見積提案時にもセラーからバイヤーへの質問を可能にし、商談を進める過程でお互いの不明点を明らかにすることで、実際の商談にスムーズに入れるようにすることができるようにしてもよい。
電子証明を保持する売り手からの見積の場合、通常のユーザーからの見積(応札)とは異なり、「信頼できる売り手からの見積」という形で信用情報を提供するようにしてもよい。買い手に安心感を提供することができる。
リクエスト詳細を閲覧するときに、バイヤーの信用情報(事業概要、設立年、資本金、従業員数、前年度売上)を表示し、売り手が買い手の信用について判断することができるようにしてもよい。
売り手に見積をしたにもかかわらず、連絡が全くこない場合、その売り手に対し「催促メール」を送信できるようにしてもよい。
買い手が対処できる数の見積数の上限を設け、原則早く見積を出した順番で見積を作成することができるようにしてもよい。その場合上限の数を超えて見積を出そうとしても、見積は登録できないようにしてもよい。
【0055】
<見積比較>
見積比較テーブルの企業欄に、各セラーの評価結果がマーク表示され(例えば3段階)、比較テーブル上で直感的に評価ランク付けが分かるようにしてもよい。
当仲介サービスで、商談依頼まで発生した取引について、買い手が売り手に対して、評価を行うようにしてもよい。評価は一定の算式に応じて点数化され、表示上に反映することができるようにしてもよい。
売り手に対して過去に行われたすべての評価およびサービス利用の有無が一覧で閲覧することができ、商談相手として信頼できるかどうか記入されている内容(評判)から判断することができるようにしてもよい。
評価を行ったときに他のバイヤーから問い合わせを受け付けると指定した買い手に対して、そのつど買い手にそのセラーについて質問を投げることができるようにしてもよい。
過去に問合せされた内容については、すべて問合せ履歴としてそのすべてを一覧できるようにしてもよい。
他のバイヤーから、過去に利用したセラーについての問合せに対し、回答を行うことができるようにしてもよい。
見積時のセラーからバイヤーへ質問を回答する以外に、商談依頼時にバイヤーからセラーに質問を回答することを可能にし、商談を進める過程でお互いの不明点を明らかにすることができるようにしてもよい。実際の商談にスムーズに入れるようにすることができる。
フリーフォーマットで記入できる項目(コメントなど)については、具体的な記入例をつけてもよい。売り手が商談を進めやすい商談依頼を作成することが可能となる。
見積の拒否理由を入力させ、なぜ今回の見積が断われたかを売り手に知らせるようにしてもよい。次回の見積や商談に生かせるようにすることができる。
電子証明を保持する売り手からの見積の場合、通常のユーザーからの商談依頼とは異なり、「信頼できるバイヤーからの商談依頼」という形で信用情報を提供でき、売り手に安心感を提供することができる。
買い手に商談を申込んだにもかかわらず、連絡が全くこない場合、その買い手に対し「催促メール」を送信できるようにしてもよい。
【0056】
<情報の開示>
電子証明を利用した場合、電子証明ごとに情報の閲覧権限を設定することで、加盟ユーザごとに見ることのできる情報を制御するようにしてもよい。これ以外の方法でも、加盟ユーザーごとに権限プロファイルを設定し、閲覧できる情報や実行できる対象を制御することができるようにしてもよい。例えば、加盟ユーザーが、ある他社の加盟ユーザーに対し、一定期間ぐらい信用情報を閲覧する権利を任意に与えることができ、自分の許可するユーザーにのみ重要な情報を公開できる。仲介取引の中で蓄積した情報を、仲介取引をはじめ各種取引において加盟メンバーについての信用情報を指定する第三者や加盟メンバーに提供できる。
<メールのやりとり>
電子認証を保持する場合、メールクライアントに認証をインストールすれば、仲介サイトとユーザーとのメールのやりとり、および加盟ユーザー間のメールのやり取りにおいて、データの保全を確保することに利用できるようにしてもよい。
【0057】
<評価プロセス>
セラーと実際に取引があったかどうか、商談態度やサービス品質、他の利用者からの問合せ、コメントについて記入し、セラーの商談活動を評価することができるようにしてもよい。
評価時にバイヤーからサービス提供を受けたかどうかをきくことができるので、契約したかどうかが分かる。
取引の有無を把握することで、セラーからコミッションを徴収する場合に利用できる。
電子認証を保持するユーザーによる評価の場合、通常のユーザーからのリクエストと異なり、「信頼できるユーザーからの評価」という形で信用情報を追加し、買い手に安心感を提供することができる。
<商談結果報告>
セラーがバイヤーに実際にサービスを提供(契約)したかどうか、結果を報告させることができるようにしてもよい。報告する場合に、必要であれば契約書や請求書も併せて送付してもらうことで、取引実績を証明することもできる。
取引の有無を把握することで、セラーからコミッションを徴収する場合に利用できる。
【0058】
<成約確認・請求>
成約まで至った可能性のある案件について、確認メールを送信し、その取引内容を確認することができるようにしてもよい。
応札料、商談依頼料、登録料金、およびコミッション料金について、過去に発生したトランザクションから算出して毎月請求書を作成するようにしてもよい。
毎月の請求内容について、SSLなどで暗号化した接続を利用してその内容をユーザーが閲覧することができるようにしてもよい。
<請求書照合>
ユーザーからの入金額について、入力することができるようにしてもよい。
ユーザーからの振込み金額と請求との間に過不足がないかどうかを確認することができるようにしてもよい。その結果については、支払履歴としてユーザーごとに管理され、その支払実績を評価することもできるようにしてもよい。
【0059】
<顧客サポート>
見積依頼促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
見積促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
商談依頼促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
ユーザー毎に、問合せがある毎にその履歴をデータベースに登録し、担当者が変ったとしても一貫したサポートを提供することができるようにしてもよい。ユーザーが指定の意見・質問フォームを利用して問合せをすれば、問合せ管理画面で情報を一元管理できるようにしてもよい。
促進活動以後の対応したユーザーのアクティビティーを表示し、どの程度効果があるかどうかをみることができるようにしてもよい。
【0060】
<アカウント管理>
バイヤー登録後、セラーとして登録変更できるようにしてもよい。
メールアドレスの変更中は、ログインできず、確認メールにあるURLをクリックすることではじめて新しいメールアドレスが反映されるようにしてもよい。
パスワード忘れの場合、自動検索機能により、メールアドレスもしくは電話番号を入力することで、自動的に該当するメールアドレスにパスワードを通知することができるようにしてもよい。
<知人紹介>
自らの紹介により加盟したユーザー(バイヤー・セラー)について、一覧で閲覧できるようにしてもよい。加盟ユーザー数に応じてポイントが溜まる仕組みになっており、加盟ユーザー獲得のインセンティブを提供してもよい。一種の口コミによる紹介という枠組みを利用し、ある程度の信頼できる加盟ユーザーを獲得することができる。知人紹介により獲得したポイントに応じて、Webサイトから各種商品・サービスと交換できる仕組みを提供してもよい。
【0061】
<加盟ユーザーディレクトリー>
登録しているセラーについて、基本的な信用情報や企業概要を掲載してもよい。また、電子認証を受けているユーザーであれば、その点についても表示することができる。
<サイト訪問履歴管理>
サイトを訪問するセラー・バイヤーが、登録前はどこからサイトにアクセスしたのか、登録後日々の利用はどれぐらいの画面数なのか、使用頻度の低いページはどれか、処理がよく中断するページはどこか、などユーザー毎のサイト移動履歴をとることができるようにしてもよい。
<バナー広告表示>
リクエストのカテゴリに応じて、表示するバナーなどの広告を変化させるようにしてもよい。バナーの表示回数や、クリック回数についても併せてトラッキングを行うことができる。
【0062】
<スケジュール管理・グループウェア>
他社の提供するスケジュール管理機能との統合。商談プロセス(見積から契約、サービス導入、評価まですべて)に渡り、アカウントページのステータスとスケジュールが連携したり、コンタクトしたセラー・バイヤーについて連絡先として登録できたり、書類などファイルの共有ができるなど、商談を円滑に進めるために外部ソフトウェアとのインターフェースを作成することで、マイアカウントページの情報とスケジュール管理ソフトとの情報が同期することができるようにしてもよい。スケジュール管理以外の機能でも、同様の連携は可能。
<リソースバンク>
セラーやバイヤーの経営活動を支えるコンテンツを提供してもよい。最も単純なのは相互リンクであるが、他社のサイトが自社内のフレームの中に入り込む形で表示させるなどの形で実現してもよい。サイト連携により、どれ位のユーザーが自社サイトに、ないし提携サイトに流れ、ユーザー登録までいたっかどうかトラッキングできる仕組みを提供することができる。
【0063】
<エキスパートコラム>
各専門分野におけるプロフェッショナルの方などからサイトコンテンツを収集する上で、各専門家、フリーライターや記者などの方にコンテンツ提供ページを提供し、そこに直接コンテンツ(記事など)をWebサイトを経由して提供することができ、その内容は社内で内容確認して承認することで、本番のサーバー上で閲覧できるようになるようにしてもよい。コンテンツ編集・管理プロセスを効率的に行うことができる。
<メールマガジン>
メールマガジンの購読申込み、配信先変更、解約ができるようにしてもよい。メンバー登録する場合は、自動的にメールマガジン登録申し込みがなされるようにしてもよい。
【符号の説明】
【0064】
10…仲介装置(サーバーシステム)、11…Webサーバ、12…Webアプリケーションサーバ、13…データベースサーバ、14…メールサーバ、20…インターネット、30…クライアント側端末、31…Webブラウザ、32…メールクライアント、40…買い手端末、50…売り手端末
【特許請求の範囲】
【請求項1】
売り手端末及び買い手端末が通信網を介して接続された仲介装置において、
売り手が提供するサービスのカテゴリーを含む売り手の登録情報を格納する売り手登録情報格納手段と、
買い手の登録情報を格納する買い手登録情報格納手段と、
前記買い手が選択したサービスのカテゴリーを含む前記買い手の発注情報を受信する発注情報受信手段と、
前記買い手が選択したカテゴリーと一致するカテゴリーが登録されている前記売り手にのみ、前記買い手の識別情報を除いた前記発注情報を送信して前記売り手端末に表示させる発注情報表示手段と、
前記発注情報に対して売り手が入力した応札情報を受信する応札情報受信手段と、
受信した前記応札情報を前記買い手端末に送信して表示させる応札情報表示手段と、
前記買い手端末に表示された前記応札情報の中から買い手が選択した応札情報と対応する識別情報を取得し、買い手が選択した売り手に対して商談依頼の通知を行う商談依頼通知手段とを備え、
前記カテゴリーの内の一部は、前記売り手は提供するサービスのカテゴリーとして前記売り手の登録情報に登録可能であるが、前記買い手は前記発注情報の中で希望するカテゴリーとして選択ができない
ことを特徴とする売り手と買い手の仲介を行う仲介装置。
【請求項2】
前記売り手のサービスと対応するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、前記売り手がカテゴリーの追加申請を行うことができることを特徴とする請求項1に記載の仲介装置。
【請求項3】
前記売り手の登録手段は、商品またはサービスを提供する地域を指定可能であり、前記発注情報表示手段は、発注情報において指定された地域と前記サービスを提供する地域とが一致する売り手にのみ発注情報を表示することを特徴とする請求項1または2の何れか一項に記載の仲介装置。
【請求項4】
売り手端末及び買い手端末が通信網を介して接続された仲介装置における仲介方法において、
前記仲介装置が、
(イ)売り手が提供するサービスのカテゴリーを含む売り手の登録情報をデータベースに登録する工程
(ロ)買い手の登録情報をデータベースに登録する工程
(ハ)前記サービスのカテゴリーの内の一部は、前記買い手が発注情報の中で希望するカテゴリーとして選択ができないものであり、前記買い手が選択可能なカテゴリーの中から選択したカテゴリーを含む前記買い手が入力した発注情報を受信し、保存する工程
(ニ)前記買い手が選択したカテゴリーと一致するカテゴリーが登録されている前記売り手にのみ、前記買い手の識別情報を除いた前記発注情報を送信して前記売り手端末に表示させる工程
(ホ)前記発注情報に対して前記売り手が入力した応札情報を受信し、保存する工程
(ヘ)受信した前記応札情報を前記買い手端末に送信して表示させる工程
(ト)前記買い手端末に表示された前記応札情報の中から前記買い手が選択した応札情報と対応する識別情報を取得し、前記買い手が選択した前記売り手に対して商談依頼の通知を送信する工程
の各工程を実行することを含むことを特徴とするネット上で売り手と買い手の仲介を行う仲介方法。
【請求項5】
前記工程(イ)において、売り手のサービスと対応するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、前記売り手がカテゴリーの追加申請を行うことができることを特徴とする請求項4に記載の仲介方法。
【請求項6】
前記工程(イ)において、サービスを提供する地域を指定可能であり、前記工程(ニ)においては、発注情報において指定された地域と前記サービスを提供する地域とが一致する売り手にのみ発注情報を表示することを特徴とする請求項4または5の何れか一項に記載の仲介方法。
【請求項1】
売り手端末及び買い手端末が通信網を介して接続された仲介装置において、
売り手が提供するサービスのカテゴリーを含む売り手の登録情報を格納する売り手登録情報格納手段と、
買い手の登録情報を格納する買い手登録情報格納手段と、
前記買い手が選択したサービスのカテゴリーを含む前記買い手の発注情報を受信する発注情報受信手段と、
前記買い手が選択したカテゴリーと一致するカテゴリーが登録されている前記売り手にのみ、前記買い手の識別情報を除いた前記発注情報を送信して前記売り手端末に表示させる発注情報表示手段と、
前記発注情報に対して売り手が入力した応札情報を受信する応札情報受信手段と、
受信した前記応札情報を前記買い手端末に送信して表示させる応札情報表示手段と、
前記買い手端末に表示された前記応札情報の中から買い手が選択した応札情報と対応する識別情報を取得し、買い手が選択した売り手に対して商談依頼の通知を行う商談依頼通知手段とを備え、
前記カテゴリーの内の一部は、前記売り手は提供するサービスのカテゴリーとして前記売り手の登録情報に登録可能であるが、前記買い手は前記発注情報の中で希望するカテゴリーとして選択ができない
ことを特徴とする売り手と買い手の仲介を行う仲介装置。
【請求項2】
前記売り手のサービスと対応するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、前記売り手がカテゴリーの追加申請を行うことができることを特徴とする請求項1に記載の仲介装置。
【請求項3】
前記売り手の登録手段は、商品またはサービスを提供する地域を指定可能であり、前記発注情報表示手段は、発注情報において指定された地域と前記サービスを提供する地域とが一致する売り手にのみ発注情報を表示することを特徴とする請求項1または2の何れか一項に記載の仲介装置。
【請求項4】
売り手端末及び買い手端末が通信網を介して接続された仲介装置における仲介方法において、
前記仲介装置が、
(イ)売り手が提供するサービスのカテゴリーを含む売り手の登録情報をデータベースに登録する工程
(ロ)買い手の登録情報をデータベースに登録する工程
(ハ)前記サービスのカテゴリーの内の一部は、前記買い手が発注情報の中で希望するカテゴリーとして選択ができないものであり、前記買い手が選択可能なカテゴリーの中から選択したカテゴリーを含む前記買い手が入力した発注情報を受信し、保存する工程
(ニ)前記買い手が選択したカテゴリーと一致するカテゴリーが登録されている前記売り手にのみ、前記買い手の識別情報を除いた前記発注情報を送信して前記売り手端末に表示させる工程
(ホ)前記発注情報に対して前記売り手が入力した応札情報を受信し、保存する工程
(ヘ)受信した前記応札情報を前記買い手端末に送信して表示させる工程
(ト)前記買い手端末に表示された前記応札情報の中から前記買い手が選択した応札情報と対応する識別情報を取得し、前記買い手が選択した前記売り手に対して商談依頼の通知を送信する工程
の各工程を実行することを含むことを特徴とするネット上で売り手と買い手の仲介を行う仲介方法。
【請求項5】
前記工程(イ)において、売り手のサービスと対応するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、前記売り手がカテゴリーの追加申請を行うことができることを特徴とする請求項4に記載の仲介方法。
【請求項6】
前記工程(イ)において、サービスを提供する地域を指定可能であり、前記工程(ニ)においては、発注情報において指定された地域と前記サービスを提供する地域とが一致する売り手にのみ発注情報を表示することを特徴とする請求項4または5の何れか一項に記載の仲介方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【公開番号】特開2013−12234(P2013−12234A)
【公開日】平成25年1月17日(2013.1.17)
【国際特許分類】
【出願番号】特願2012−198007(P2012−198007)
【出願日】平成24年9月10日(2012.9.10)
【分割の表示】特願2009−239997(P2009−239997)の分割
【原出願日】平成12年5月26日(2000.5.26)
【出願人】(399037405)楽天株式会社 (416)
【公開日】平成25年1月17日(2013.1.17)
【国際特許分類】
【出願日】平成24年9月10日(2012.9.10)
【分割の表示】特願2009−239997(P2009−239997)の分割
【原出願日】平成12年5月26日(2000.5.26)
【出願人】(399037405)楽天株式会社 (416)
[ Back to top ]