JP5224487B2 - 仲介装置および仲介方法 - Google Patents

Description

本発明は仲介装置および仲介方法に関し、特に、ネット上で売り手と買い手の間の仲介を行う仲介装置および仲介方法において、買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法に関するものである。

近年、インターネットの普及に伴い、例えば商品等の売り手（Seller：セラー）がネット上において広告を出し、買い手（Buyer：バイヤー、ユーザ）は該広告を見て商談を申し込むことが広く行われている。

前記したような従来の売り手の決定方法においては、買い手は欲しい物がどこの広告に載っているのかを検索する必要があり、検索した結果、多数の売り手が判明した場合には、それら多数の売り手のそれぞれに対してメール等を使用して見積もり等を請求し、回答を得た売り手の中から一番条件のよさそうな売り手を選択する必要があった。更に、売り手が信用できる相手であるか否かを調査するためには、別の検索等が必要であり、多数の労力が必要であるにも関わらず、最適な売り手を選択することが困難であるという問題点があった。

本発明の目的は、前記のような従来技術の問題点を解決し、ネット上で売り手と買い手の間の仲介を行う仲介装置および仲介方法において、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる仲介装置および仲介方法を提供することにある。

本発明の売り手と買い手の仲介を行う仲介装置においては、売り手の登録手段と、買い手の登録手段と、買い手の発注情報の入力手段と、買い手の識別情報を除いた発注情報のみを売り手に表示する発注情報表示手段と、前記発注情報に対して売り手が応札情報を入力する応札情報入力手段と、応札情報を一覧表にして買い手に表示する応札情報表示手段と、買い手が希望する売り手に対して買い手の情報を含む商談依頼の通知を行う商談依頼通知手段とを備えたことを特徴とする。
本発明によれば、買い手および売り手が簡単にリクエストおよび応札を出すことが出来、かつ買い手が売り手の比較検討を容易に行うことができる。また、登録内容をシステム側で確認すること等により、買い手に信用情報を提供することも可能である。

以上述べたように、本発明の売り手と買い手の仲介を行う仲介装置および仲介方法においては、買い手にとっては、多数の企業の中から自社のニーズに適合した企業を容易に選択することができ、手間や時間をかけずに効率的にアクセス可能であるという効果がある。また、売り手にとっては、新しいセールスチャンスを獲得でき、顧客の方からリクエストが提示されてくるので、多額の広告や飛び込みの営業活動などを行う必要がなく、やはり効率的な営業活動ができるという効果がある。

本発明の仲介装置を含むシステム全体の構成を示すブロック図である。 本発明の仲介装置を含むシステム全体の他の構成例を示すブロック図である。 本発明の仲介装置において実行される仲介方法の概要を示す説明図である。 本発明の買い手への比較検討ページの表示処理の内容を示すフローチャートである。 本発明の買い手への比較検討ページの再表示処理の内容を示すフローチャートである。 本発明の買い手の商談申し込み処理の内容を示すフローチャートである。 本発明の買い手への比較検討ページの表示処理の詳細内容を示すフローチャートである。 本発明の買い手への比較検討ページの再表示処理の内容を示すフローチャートである。 本発明の買い手の商談申し込み処理の詳細内容を示すフローチャートである。 売り手のカテゴリー登録画面例を示す説明図である。 売り手の担当者登録画面例を示す説明図である。 売り手の企業情報登録画面例を示す説明図である。 買い手へのアピール情報登録画面例を示す説明図である。 売り手の地域フィルタ登録画面例を示す説明図である。 買い手のリクエスト（発注）登録画面例を示す説明図である。 売り手のアクセス時の初期画面例を示す説明図である。 リクエスト一覧表示画面例を示す説明図である。 売り手のリクエスト詳細表示画面例を示す説明図である。 売り手の応札情報入力画面例を示す説明図である。 買い手への応札情報一覧表示画面例を示す説明図である。 買い手への応札企業概要表示画面例を示す説明図である。 買い手への商談申し込み画面例を示す説明図である。 売り手への商談申し込み表示画面例を示す説明図である。 買い手への評価情報入力画面例を示す説明図である。

以下、本発明の実施の形態を詳細に説明する。図１は、本発明の仲介装置であるサーバーシステム１０を含むシステム全体の構成例を示すブロック図である。仲介装置１０には、Ｗｅｂ（WWW：World Wide Web）サーバ１１、Ｗｅｂアプリケーションサーバ１２、ＤＢ（データベース）を備えたデータベースサーバ１３、メール（SMTP：Simple Mail Transfer Protocol）サーバ１４が図示しないＬＡＮによって接続されており、更に、Ｗｅｂサーバ１１は、図示しないルータによってインターネット２０に接続されている。この他、ＬＡＮには図示しない複数の保守、管理用のサーバ、端末が接続されている。
データベースには、売り手や買い手の登録情報を格納する顧客ＤＢ、リクエストＤＢ、応札ＤＢ、商談申し込みＤＢ、メール用ＤＢなどが格納されており、後述する仲介装置１０の機能は、各サーバが分担して処理する。各サーバ１１〜１４の機能は周知であり、それぞれ周知の市販のサーバ装置に周知の市販のＯＳを搭載し、市販の、あるいは後述するような処理を実行するプログラムを実装することにより実現できる。

Ｗｅｂアプリケーションサーバ１２の機能はＣＧＩやその他のスクリプトプログラムによって代替可能であり、省略することもできる。クライアント側の端末３０は例えば周知のＷｅｂブラウザ３１およびメールクライアント３２を備え、インターネット２０にアクセス可能な周知の市販のＰＣ（パソコン）であってもよい。

図２は、本発明の仲介装置であるサーバーシステム１０を含むシステム全体の他の構成例を示すブロック図である。この実施例は図１に示したシステム構成からメールサーバ１４およびメールクライアント３２を除いたものである。クライアントは、Ｗｅｂブラウザ３１によってサーバシステム１０にアクセスすることによって、本発明の全ての処理を実行するようにすることも可能である。

図３は、本発明の仲介装置１０において実行される仲介方法の概要を示す説明図である。図３に基づき、本発明の仲介方法の概要およびサイト１０の機能を説明する。なお、実施例においては、複数のカテゴリーに属する各種サービスの仲介を行う例について説明する。

（１）まず、買い手（バイヤー端末４０（３０））と売り手（セラー端末５０（３０））はそれぞれ本発明の仲介システム（サイト）１０に登録を行う。なお、売り手は自分の提供するサービスのカテゴリーも登録する。サイト１０は登録内容をデータベースに登録する。（２）次に、買い手は特定のカテゴリーを選択してリクエスト（発注情報）を入力する。サイト１０は、リクエストを買い手と対応づけて保存する。

（３）サイト１０は、リクエストをカテゴリーの一致する全ての売り手にメールで配信する。但し、このリクエストには買い手の企業名等の情報は付加されていない。（４）売り手は、本発明の仲介システムにアクセスし、自分の属するカテゴリーのリクエストを閲覧し、応札したいリクエストに対して応札情報を入力する。サイト１０は、応札情報をリクエストと対応して保存する。

（５）所定の応札期間内に、応札があった場合には、サイト１０は買い手にメールで応札があったことを通知し、（６）買い手は仲介システムにアクセスして応札情報を読み出す。サイトは全ての応札情報を一覧表に編集して買い手に表示する。この場合には応札企業の詳細情報も読み出すことができる。買い手は各応札情報を比較検討して、商談を申し込む売り手を決定する。そして、商談申し込み情報を入力する。

（７）サイト１０は、商談申し込みのあった売り手に対してメールで通知を出し、売り手はサイト１０にアクセスして、買い手の連絡先等の情報を付加した商談依頼通知を閲覧する。（８）その後は、売り手と買い手が直接連絡を取り、商談を進める。サイト１０は、例えば商談依頼通知を発送した売り手に対して所定の仲介料を請求するための請求書を発行する。（９）また、買い手には売り手の評価情報を入力してもらい、売り手の評価に反映させる。
次に、クライアントの端末に表示される画面例の図面を参照して仲介方法の詳細について説明する。

（１）ユーザ登録。

図１０は、売り手のカテゴリー登録画面例を示す説明図である。売り手は、登録時に自分の会社のサービスと対応するカテゴリーを１つ以上選択する。なお、該当するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、カテゴリーの追加申請を行うことができる。

図１１は、売り手の担当者登録画面例を示す説明図である。また、図１２は、売り手の企業情報登録画面例を示す説明図である。更に、図１３は、売り手から買い手へのアピール情報登録画面例を示す説明図である。図１３に示した各アピール情報はそれぞれ３００字以内の文章で自由に記載することができるようになっている。このような構成にすることにより、売り手がセールスポイントを的確に表現することが可能となり、買い手が売り手を選択する際の貴重な情報源となる。
図１４は、売り手の地域フィルタ登録画面例を示す説明図である。売り手は、この画面において地域を指定することにより、サービスを実施する地域が指定した地域と一致するリクエストのみを受け取ることができる。なお、買い手の登録内容は、売り手の登録内容からカテゴリー、アピール情報、指定地域等を除いたものである。以上のような画面によって入力された各種情報はサイト１０のデータベースに登録され、登録者にはＩＤおよびパスワードが発行される。登録内容の変更、解約も随時可能である。

（２）リクエスト（発注情報）の入力。

図１５は、買い手のリクエスト（発注）登録画面例を示す説明図である。買い手が仲介システムにアクセスし、例えばＩＤおよびパスワードによって認証をパスすると、サイト１０は、図１６に示すようなバイヤーセンター画面を表示し、買い手が画面下段に表示されているサービスのカテゴリー一覧表の中から該当するサービスカテゴリーを選択（クリック）すると図１５の画面に移行する。
図１５の画面においてはサービスの利用場所、時期、予算、応札受付終了日等の項目の入力の他、「リクエスト内容」、「自社概要」、「質問」の各項目について３００字以内の文章で自由に記載できるフォームを採用している。このように、フリーフォームで記入できるようにすることにより、多様なニーズに対応可能である。サイト１０は入力されたリクエストを買い手と対応してリクエストＤＢに保存する。

（３）リクエスト配信。

サイト１０は買い手の入力したリクエスト情報をカテゴリーの一致する全ての売り手にメールで配信する。但し、買い手の企業名や電話番号など買い手を特定可能な情報は付加されていない。

（４）応札情報の入力。

図１６は、売り手のアクセス時の初期画面例を示す説明図である。売り手が仲介システムにアクセスし、例えばＩＤおよびパスワードによって認証をパスすると、サイト１０は、図１６に示すようなセーラーセンターおよびバイヤーセンター画面を表示する。買い手の場合にはバイヤーセンターのみが表示されるが、売り手の場合には買い手になる可能性もあるので、双方が表示される。
セラーセンターの上段のリストは当売り手が登録しているサービスの各カテゴリー（「ホームページ作成」と「インターネット広告」の２つ）におけるリクエスト数を表示しており、右欄の「応札へ」をクリックすると、図１７の画面に移行する。

図１７は、リクエスト一覧表示画面例を示す説明図である。売り手は、任意のリクエストの「案件名」の部分をクリックするか、最右端のチェックボタンの１つあるいは複数個にチェックを入れて、下段の「詳細情報一覧表示」ボタンをクリックすることにより、図１８のリクエストの詳細情報を見ることができる。
なお、図１７の応札中リクエスト一覧画面は、未登録のユーザも見ることができ、登録する前に本発明の仲介システムにおいてどのような発注が出されているのかが確認できるようになっている。但し、未登録ユーザはリクエストの詳細情報を見ることはできない。

図１８は、売り手のリクエスト詳細表示画面例を示す説明図である。売り手はこのリクエストの詳細情報を見て応札を希望する場合には下段の「応札する」ボタンをクリックする。
図１９は、売り手の応札情報入力画面例を示す説明図である。応札情報としては、価格レンジ、提案の有効期間と共に、「質問への回答」「提供サービスのアピール」の項目について、３００字以内の文章で自由に記載できるフォームを採用している。サイト１０は応札情報をリクエストと対応して応札ＤＢに保存する。

（５）応札通知。

所定の応札期間内に応札があった場合には、サイト１０は買い手にメールで応札があっとことを通知する。

（６）応札情報の比較検討、商談の申し込み。

図２０は、買い手への応札情報一覧表示画面例を示す説明図である。買い手が仲介システムにアクセスすると表示される図１６のバイヤーセンター画面には、受付中あるいは受付終了したリクエストのリストが表示され、所望のリクエストの「比較検討する」ボタンをクリックすることにより、図２０の一覧表示画面に移行する。

図４は、本発明の仲介装置１０における買い手への比較検討ページの表示処理の内容を示すフローチャートである。買い手端末４０のＷｅｂブラウザーには図１６のバイヤーセンター画面が表示されているものとする。Ｓ００１において、バイヤーセンター画面には、受付中あるいは受付終了したリクエストのリストが表示され、所望のリクエストの「比較検討する」ボタンをクリックすることにより、埋め込まれているリクエスト番号がサイト１０へ送信される。

サイト１０は、Ｓ００２において、指定されたリクエスト番号を抽出条件として応札データベースからリクエストに対する全応札データを抽出する。Ｓ００３においては、抽出した各応札データに削除フラグが立っているか否かをチェックし、フラグが立っているものを削除する。Ｓ００４においては、抽出した各応札データの応答の有効期間が期限切れしているか否かチェックし、期限が切れているものを削除する。Ｓ００５においては、応札内容比較検討テーブル（一覧表）HTMLファイルを生成し、買い手端末４０へ送信する。買い手端末４０のブラウザーは受信した一覧表HTMLファイル（図２０）を表示する。
図７は、本発明の仲介装置における買い手への比較検討ページの表示処理の詳細内容を示すフローチャートである。図７におけるステップ番号は図４と対応しており、図７においては図４の処理内容に加えて一覧表の表示項目についても記載されている。

一覧表示画面においては、全ての応札情報が一覧表示され、売り手の企業名も表示されている。買い手は左欄の「企業概要」ボタンをクリックすることにより、売り手の詳細（登録）情報を表示させることができる。図２１は、買い手への応札企業概要表示画面例を示す説明図である。また、買い手は左欄の「断る」ボタンをクリックすることにより、当該応札を一覧表から削除することができる。

図５は、本発明の仲介装置における買い手への比較検討ページの再表示処理の内容を示すフローチャートである。買い手端末４０のＷｅｂブラウザーには図２０の一覧表画面が表示されているものとする。Ｓ００７において、買い手が断りたいリクエストの「断る」ボタンをクリックすることにより、クリック位置情報と共に埋め込まれている応札番号がサイト１０へ送信される。

サイト１０は、Ｓ００８において、指定された応札番号に対し削除フラグを立てるために、応札データベースを更新する。Ｓ００９においては、更新が成功したか否かをチェックし、不成功の場合には端末４０にエラー表示HTMLファイルを送信し、端末４０においては、Ｓ０１１において当該ファイルを表示する。この後の処理は図４のＳ００２以降の処理と同一であるので説明は省略する。図８は、本発明の仲介装置における買い手への比較検討ページの再表示処理の内容を示すフローチャートである。内容としては図５と同一である。
買い手は図２０に示す画面において各応札情報を比較し、商談を申し込む売り手を決定して、当該売り手と対応する「商談を申し込む」ボタンをクリックする。

図６は、本発明の仲介装置における買い手の商談申し込み処理の内容を示すフローチャートである。買い手端末４０のＷｅｂブラウザーには図２０の一覧表画面が表示されているものとする。Ｓ０１２において、買い手が商談を申し込みたいリクエストの「商談を申し込む」ボタンをクリックすることにより、クリック位置情報と共に埋め込まれている応札番号がサイト１０へ送信される。

サイト１０は、Ｓ０１３において、指定された応札番号を選択条件として顧客データベースから売り手情報を取得する。Ｓ０１４においては、図２２に表示例を示すような商談申し込みHTMLファイルを生成する。買い手端末４０においては、Ｓ０１５において商談申し込みHTMLファイルを表示し、Ｓ０１６において担当者名、部署、連絡方法、コメント等を入力させ、送信する。

サイト１０は、Ｓ０１７において商談申し込み番号を新たに採番し、商談申し込みデータベースを更新すると共に、当該応札データに削除フラグを立てるために応札データベースを更新する。Ｓ１８においては、更新が成功したか否かがチェックされ、不成功の場合には端末４０にエラー表示HTMLファイルを送信し、端末４０においては、Ｓ０２１において当該ファイルを表示する。

データベースの更新が成功した場合にはＳ０１９に移行し、売り手登録情報としてメール通知を希望しているか否かがチェックされる。そして、メール通知を希望している場合にはＳ２０に移行して、商談申し込みが行われたことをメールで売り手に通知すると共にメール用データベースに保存する。

図９は、本発明の仲介装置における買い手の商談申し込み処理の詳細内容を示すフローチャートである。図９におけるステップ番号は図６と対応しており、図９においては図６の処理内容に加えて表示項目についても記載されている。図２２は、買い手への商談申し込み画面例を示す説明図である（申し込み記入後の確認画面）。

（７）商談依頼通知。

サイト１０は、商談申し込みのあった売り手に対して買い手の名称や担当者名、電話番号などが記載されたメールで通知を出し、この時点において売り手に買い手が判明する。売り手はサイト１０にアクセスして、買い手の連絡先等の情報を付加した商談依頼通知を確認することもできる。図２３は、売り手への商談申し込み表示画面例を示す説明図である。この画面においては、買い手の名称や担当者名、電話番号などが記載されている。

（８）直接商談。

その後は、売り手と買い手が直接連絡を取り、商談を進める。サイト１０は、例えば商談依頼通知を発送した売り手に対して所定の仲介料を請求するための請求書を発行する。

（９）評価情報の入力。

買い手には売り手の評価情報を入力してもらい、売り手の評価に反映させる。図２４は、買い手への評価情報入力画面例を示す説明図である。この画面は１回の商談申し込みにつき１回だけ記入可能であり、評価はポイントとして数値化、積算され、例えば売り手の詳細情報表示画面（図２１）において閲覧できるにしてもよい。

以上、本発明の実施例を開示したが、本実施例には下記のような変形例も考えられる。実施例においては、仲介装置１０内に登録された売り手の情報を表示する実施例を開示したが、更に、買い手が売り手のサーバにアクセスすることにより、売り手の広告ホームページにアクセスすることができるように構成してもよい。

実施例としては、各カテゴリーに共通するリクエストフォームを使用してリクエストを入力する例を開示したが、カテゴリーによって、リクエストする場合の項目内容や項目数が異なる場合もある。従って、カテゴリー毎に最適なリクエストフォームを作成してもよい。更に、買い手が自らリクエストフォームをカスタマイズでき、そのフォームに応じて応札フォームが生成されるようにしてもよい。このような構成にすることにより、精度の高い見積もりや提案を受けることができる。

例えばインターネットに接続可能な携帯電話やＰＨＳでリクエストや応札を可能とするために、特にフリーフォームの入力欄に文章を入力するために、定型リクエスト文の選択、穴埋め式定型文、カスタマイズ可能な定型文などを利用できるようにしてもよい。
実施例においては、登録情報、リクエスト、応札などの情報としては文字（コード）情報のみを扱う例を開示したが、図形、画像、音声その他のマルチメディア情報（ファイル）も扱えるようにしてもよい。

実施例においては、買い手はまず登録を行ってからリクエストを入力する例を開示したが、登録に抵抗感のあるユーザは当該サイトを覗きにきても、登録せずに終了してしまうことが予想される。そこで、未登録の会員でもリクエストを記入することが出来、リクエストの入力が完了した時点で登録画面へと移行するようにしてもよい。この場合、リクエストは登録完了後に初めて有効となるようにする。このような構成とすることにより、当システムへの登録者がより増加することが期待できる。

実施例においては、サービスについての仲介システムの例を開示したが、本発明の仲介装置および仲介方法は任意のサービスをはじめ、任意の商品など全ての商取引について同様に実施可能である。

更に、以下に各機能や処理ごとの変形例を示す。
＜登録プロセス＞
登録プロセスにおいて、仲介市場の加盟メンバーを増やし市場を活性化するために、メンバー登録時に紹介者の氏名またはメールアドレスを入力できるようにしてもよい。口コミによる紹介による効果（一定の信頼できるメンバーを獲得できる）を利用し、信頼できる加盟者の獲得につながる。さらに、加盟メンバーに対し紹介インセンティブを提供する仕組みにも活用できる。
登録情報として、設立年（営業開始年）、資本金、従業員数、売上の項目についてセラーだけでなく、バイヤーも入力させ、売り手に対しても取引上の信用情報を提供するようにしてもよい。
加盟メンバーの信頼性を高めるために、仮登録方式を導入し、実在するメールアドレス以外を登録しない限り、利用できないようにしてもよい。こうすれば、無料で利用できるメールアカウントの利用も防止することができる。
加盟ユーザーになる場合、一定の基準を設け、その基準に適合する場合、電子的な個人認証を発行し、仲介サービス取引の際に利用できるようにすることができるようにしてもよい。それにより、利用メンバー（買い手及び売り手）の信頼性を向上し、取引上のなりすましの防止、契約や見積内容に対する否認の防止なども行うことが可能となる。
買い手が提供するサービスとして選択できるサービスカテゴリーの拡充・精緻化をはかり、買い手と売り手の高精度なマッチングを可能としてもよい。売り手の登録数が十分ではないカテゴリーがあることから、カテゴリーの２部制を導入してもよい。第１部のカテゴリーでは売り手もサービス提供カテゴリーとして登録できるし、買い手もそのカテゴリーに対しリクエストすることができる。一方、第２部のカテゴリでは売り手はそのカテゴリーを登録時に選択できるが、買い手はそのカテゴリに対しリクエストはできないようにしてもよい。
登録情報として、各自フリーフォーマットで記入できる項目（事業概要、提供サービス詳細、特色・PRポイント、今までの実績・主要取引先、関連企業、所属協会・団体名など）については記入例を付加してもよい。各メンバーの記入レベルを一定以上に合わせることで各自が信頼できる情報提供することを支援することができる。

＜見積依頼＞
サービスカテゴリーの拡充・精緻化をはかり、買い手と売り手の高精度なマッチングが可能としてもよい。2部制導入により、2部のものはリクエストできないようにしてもよい。
支払方法、支払時期などの信用情報をリクエスト時に買い手にフォームに入力させることで、売り手にとって応札しやすい情報提供が可能になるようにしてもよい。
電子認証を保持するユーザーからのリクエストの場合、通常のユーザーからのリクエストと異なり、「信頼できる買い手からのリクエスト」という形で信用情報を追加し、売り手に安心感を提供することができるようにしてもよい。
いたずら・冷やかしのリクエスト登録を防ぐ、または情報が不足しているリクエストを改善するため、一度目視確認をした後、当該リクエストを承認する手続きを行った後、正式なリクエストとして売り手に通知することができるようにしてもよい。
サービスカテゴリ毎に、リクエスト時に記入すべき事項を表示させ、買い手がリクエスト時に何をどうのように書いたら分からないという状況を大幅に改善し、正確な見積を獲得できるようなリクエストを当該サービスについては素人であることの多い買い手でも作成することができるようにしてもよい。
フリーフォーマットで記入できる項目（リクエスト内容、その他コメントなど）については、具体的な記入例をつけることで、売り手が見積しやすい見積依頼を作成することが可能となるようにしてもよい。
リクエスト時に選択されるカテゴリー毎に、バナー広告などの表示が変化し、カテゴリーとは直接競合しない、あるいは補完し合えるような広告をサイト上に露出させるようにしてもよい。仮にカテゴリと競合するような広告が表示される場合、買い手がリクエストを行うことなく、広告先のサイトに移動してしまう危険性がある。ユーザー毎に広告のクリック履歴をトラッキングすることで、ユーザーの嗜好調査や、広告効果測定なども可能となる。

＜見積＞
買い手が当該案件を、まだ登録していないユーザーに対して紹介できるようにしてもよい。これにより、紹介されたユーザーが加盟ユーザとなる場合、売り手の加盟ユーザが増えることで、買い手のニーズに対して十分に応えることが可能となる。また、紹介先の担当者が登録に至ったかどうかまでトラッキングする機能も提供することができる。
サービスカテゴリ毎に見積時に記入する項目（リクエストに対する提案/サービスのPR、参考見積価格など）を、次回の見積作成時に利用できるようにすることができるようにしてもよい。
フリーフォーマットで記入できる項目（バイヤーに対する質問）については、具体的な記入例をつけることで、買い手が見積比較しやすい情報を提供することが可能となるようにしてもよい。
見積作成時、セラー用の登録情報として入力したものがデフォルト表示され（ホームページ、提供サービス詳細、特色・PRポイント、今までの実績・取引先など、関連企業、所属協会・団体名）、毎回同じ内容の記入を不要にすることができるようにしてもよい。一方、当該リクエストに見合ったＰＲなどの記述に変更することや、登録情報にその内容を反映するようにしてもよい。
リクエスト時のバイヤーからセラーへの質問以外に、見積提案時にもセラーからバイヤーへの質問を可能にし、商談を進める過程でお互いの不明点を明らかにすることで、実際の商談にスムーズに入れるようにすることができるようにしてもよい。
電子証明を保持する売り手からの見積の場合、通常のユーザーからの見積（応札）とは異なり、「信頼できる売り手からの見積」という形で信用情報を提供するようにしてもよい。買い手に安心感を提供することができる。
リクエスト詳細を閲覧するときに、バイヤーの信用情報（事業概要、設立年、資本金、従業員数、前年度売上）を表示し、売り手が買い手の信用について判断することができるようにしてもよい。
売り手に見積をしたにもかかわらず、連絡が全くこない場合、その売り手に対し「催促メール」を送信できるようにしてもよい。
買い手が対処できる数の見積数の上限を設け、原則早く見積を出した順番で見積を作成することができるようにしてもよい。その場合上限の数を超えて見積を出そうとしても、見積は登録できないようにしてもよい。

＜見積比較＞
見積比較テーブルの企業欄に、各セラーの評価結果がマーク表示され（例えば３段階）、比較テーブル上で直感的に評価ランク付けが分かるようにしてもよい。
当仲介サービスで、商談依頼まで発生した取引について、買い手が売り手に対して、評価を行うようにしてもよい。評価は一定の算式に応じて点数化され、表示上に反映することができるようにしてもよい。
売り手に対して過去に行われたすべての評価およびサービス利用の有無が一覧で閲覧することができ、商談相手として信頼できるかどうか記入されている内容（評判）から判断することができるようにしてもよい。
評価を行ったときに他のバイヤーから問い合わせを受け付けると指定した買い手に対して、そのつど買い手にそのセラーについて質問を投げることができるようにしてもよい。
過去に問合せされた内容については、すべて問合せ履歴としてそのすべてを一覧できるようにしてもよい。
他のバイヤーから、過去に利用したセラーについての問合せに対し、回答を行うことができるようにしてもよい。
見積時のセラーからバイヤーへ質問を回答する以外に、商談依頼時にバイヤーからセラーに質問を回答することを可能にし、商談を進める過程でお互いの不明点を明らかにすることができるようにしてもよい。実際の商談にスムーズに入れるようにすることができる。
フリーフォーマットで記入できる項目（コメントなど）については、具体的な記入例をつけてもよい。売り手が商談を進めやすい商談依頼を作成することが可能となる。
見積の拒否理由を入力させ、なぜ今回の見積が断われたかを売り手に知らせるようにしてもよい。次回の見積や商談に生かせるようにすることができる。
電子証明を保持する売り手からの見積の場合、通常のユーザーからの商談依頼とは異なり、「信頼できるバイヤーからの商談依頼」という形で信用情報を提供でき、売り手に安心感を提供することができる。
買い手に商談を申込んだにもかかわらず、連絡が全くこない場合、その買い手に対し「催促メール」を送信できるようにしてもよい。

＜情報の開示＞
電子証明を利用した場合、電子証明ごとに情報の閲覧権限を設定することで、加盟ユーザごとに見ることのできる情報を制御するようにしてもよい。これ以外の方法でも、加盟ユーザーごとに権限プロファイルを設定し、閲覧できる情報や実行できる対象を制御することができるようにしてもよい。例えば、加盟ユーザーが、ある他社の加盟ユーザーに対し、一定期間ぐらい信用情報を閲覧する権利を任意に与えることができ、自分の許可するユーザーにのみ重要な情報を公開できる。仲介取引の中で蓄積した情報を、仲介取引をはじめ各種取引において加盟メンバーについての信用情報を指定する第三者や加盟メンバーに提供できる。
＜メールのやりとり＞
電子認証を保持する場合、メールクライアントに認証をインストールすれば、仲介サイトとユーザーとのメールのやりとり、および加盟ユーザー間のメールのやり取りにおいて、データの保全を確保することに利用できるようにしてもよい。

＜評価プロセス＞
セラーと実際に取引があったかどうか、商談態度やサービス品質、他の利用者からの問合せ、コメントについて記入し、セラーの商談活動を評価することができるようにしてもよい。
評価時にバイヤーからサービス提供を受けたかどうかをきくことができるので、契約したかどうかが分かる。
取引の有無を把握することで、セラーからコミッションを徴収する場合に利用できる。
電子認証を保持するユーザーによる評価の場合、通常のユーザーからのリクエストと異なり、「信頼できるユーザーからの評価」という形で信用情報を追加し、買い手に安心感を提供することができる。
＜商談結果報告＞
セラーがバイヤーに実際にサービスを提供（契約）したかどうか、結果を報告させることができるようにしてもよい。報告する場合に、必要であれば契約書や請求書も併せて送付してもらうことで、取引実績を証明することもできる。
取引の有無を把握することで、セラーからコミッションを徴収する場合に利用できる。

＜成約確認・請求＞
成約まで至った可能性のある案件について、確認メールを送信し、その取引内容を確認することができるようにしてもよい。
応札料、商談依頼料、登録料金、およびコミッション料金について、過去に発生したトランザクションから算出して毎月請求書を作成するようにしてもよい。
毎月の請求内容について、SSLなどで暗号化した接続を利用してその内容をユーザーが閲覧することができるようにしてもよい。
＜請求書照合＞
ユーザーからの入金額について、入力することができるようにしてもよい。
ユーザーからの振込み金額と請求との間に過不足がないかどうかを確認することができるようにしてもよい。その結果については、支払履歴としてユーザーごとに管理され、その支払実績を評価することもできるようにしてもよい。

＜顧客サポート＞
見積依頼促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
見積促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
商談依頼促進を目的に、登録当初で失望させないためにサポートが必要なユーザーをリストアップ、および継続して利用させるためにサポートが必要なユーザーをリストアップし、そのユーザー毎にメール送信など適宜対応することができるようにしてもよい。
ユーザー毎に、問合せがある毎にその履歴をデータベースに登録し、担当者が変ったとしても一貫したサポートを提供することができるようにしてもよい。ユーザーが指定の意見・質問フォームを利用して問合せをすれば、問合せ管理画面で情報を一元管理できるようにしてもよい。
促進活動以後の対応したユーザーのアクティビティーを表示し、どの程度効果があるかどうかをみることができるようにしてもよい。

＜アカウント管理＞
バイヤー登録後、セラーとして登録変更できるようにしてもよい。
メールアドレスの変更中は、ログインできず、確認メールにあるURLをクリックすることではじめて新しいメールアドレスが反映されるようにしてもよい。
パスワード忘れの場合、自動検索機能により、メールアドレスもしくは電話番号を入力することで、自動的に該当するメールアドレスにパスワードを通知することができるようにしてもよい。
＜知人紹介＞
自らの紹介により加盟したユーザー（バイヤー・セラー）について、一覧で閲覧できるようにしてもよい。加盟ユーザー数に応じてポイントが溜まる仕組みになっており、加盟ユーザー獲得のインセンティブを提供してもよい。一種の口コミによる紹介という枠組みを利用し、ある程度の信頼できる加盟ユーザーを獲得することができる。知人紹介により獲得したポイントに応じて、Webサイトから各種商品・サービスと交換できる仕組みを提供してもよい。

＜加盟ユーザーディレクトリー＞
登録しているセラーについて、基本的な信用情報や企業概要を掲載してもよい。また、電子認証を受けているユーザーであれば、その点についても表示することができる。
＜サイト訪問履歴管理＞
サイトを訪問するセラー・バイヤーが、登録前はどこからサイトにアクセスしたのか、登録後日々の利用はどれぐらいの画面数なのか、使用頻度の低いページはどれか、処理がよく中断するページはどこか、などユーザー毎のサイト移動履歴をとることができるようにしてもよい。
＜バナー広告表示＞
リクエストのカテゴリに応じて、表示するバナーなどの広告を変化させるようにしてもよい。バナーの表示回数や、クリック回数についても併せてトラッキングを行うことができる。

＜スケジュール管理・グループウェア＞
他社の提供するスケジュール管理機能との統合。商談プロセス（見積から契約、サービス導入、評価まですべて）に渡り、アカウントページのステータスとスケジュールが連携したり、コンタクトしたセラー・バイヤーについて連絡先として登録できたり、書類などファイルの共有ができるなど、商談を円滑に進めるために外部ソフトウェアとのインターフェースを作成することで、マイアカウントページの情報とスケジュール管理ソフトとの情報が同期することができるようにしてもよい。スケジュール管理以外の機能でも、同様の連携は可能。
＜リソースバンク＞
セラーやバイヤーの経営活動を支えるコンテンツを提供してもよい。最も単純なのは相互リンクであるが、他社のサイトが自社内のフレームの中に入り込む形で表示させるなどの形で実現してもよい。サイト連携により、どれ位のユーザーが自社サイトに、ないし提携サイトに流れ、ユーザー登録までいたっかどうかトラッキングできる仕組みを提供することができる。

＜エキスパートコラム＞
各専門分野におけるプロフェッショナルの方などからサイトコンテンツを収集する上で、各専門家、フリーライターや記者などの方にコンテンツ提供ページを提供し、そこに直接コンテンツ（記事など）をWebサイトを経由して提供することができ、その内容は社内で内容確認して承認することで、本番のサーバー上で閲覧できるようになるようにしてもよい。コンテンツ編集・管理プロセスを効率的に行うことができる。
＜メールマガジン＞
メールマガジンの購読申込み、配信先変更、解約ができるようにしてもよい。メンバー登録する場合は、自動的にメールマガジン登録申し込みがなされるようにしてもよい。

１０…仲介装置（サーバーシステム）、１１…Ｗｅｂサーバ、１２…Ｗｅｂアプリケーションサーバ、１３…データベースサーバ、１４…メールサーバ、２０…インターネット、３０…クライアント側端末、３１…Ｗｅｂブラウザ、３２…メールクライアント、４０…買い手端末、５０…売り手端末

Claims (6)

1. 売り手端末及び買い手端末が通信網を介して接続された仲介装置において、
   売り手が提供するサービスのカテゴリーを含む売り手の登録情報を格納する売り手登録情報格納手段と、
   買い手の登録情報を格納する買い手登録情報格納手段と、
   前記買い手が選択したサービスのカテゴリーを含む前記買い手の発注情報を受信する発注情報受信手段と、
   前記買い手が選択したカテゴリーと一致するカテゴリーが登録されている前記売り手にのみ、前記買い手の識別情報を除いた前記発注情報を送信して前記売り手端末に表示させる発注情報表示手段と、
   前記発注情報に対して売り手が入力した応札情報を受信する応札情報受信手段と、
   受信した前記応札情報を前記買い手端末に送信して表示させる応札情報表示手段と、
   前記買い手端末に表示された前記応札情報の中から買い手が選択した応札情報と対応する識別情報を取得し、買い手が選択した売り手に対して商談依頼の通知を行う商談依頼通知手段とを備え、
   前記カテゴリーを第１部と売り手の登録数が十分ではない第２部に分け、第１部のカテゴリーでは、前記売り手は提供するサービスのカテゴリーとして前記売り手の登録情報に登録可能であると共に、前記買い手も前記カテゴリーに対して発注をすることができる一方、第２部のカテゴリーでは、前記売り手は提供するサービスのカテゴリーとして前記売り手の登録情報に登録可能であるが、前記買い手は前記発注情報の中で希望するカテゴリーとして選択することができない
   ことを特徴とする売り手と買い手の仲介を行う仲介装置。
2. 前記売り手のサービスと対応するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、前記売り手がカテゴリーの追加申請を行うことができることを特徴とする請求項１に記載の仲介装置。
3. 前記売り手の登録手段は、商品またはサービスを提供する地域を指定可能であり、前記発注情報表示手段は、発注情報において指定された地域と前記サービスを提供する地域とが一致する売り手にのみ発注情報を表示することを特徴とする請求項１または２の何れか一項に記載の仲介装置。
4. 売り手端末及び買い手端末が通信網を介して接続された仲介装置における仲介方法において、
   売り手が提供するサービスのカテゴリーが、前記売り手は提供するサービスのカテゴリーとして前記売り手の登録情報に登録可能であると共に、買い手も前記カテゴリーに対して発注をすることができる第１部のカテゴリーと、売り手の登録数が十分ではなく、前記売り手は提供するサービスのカテゴリーとして前記売り手の登録情報に登録可能であるが、前記買い手は前記発注情報の中で希望するカテゴリーとして選択することができない第２部のカテゴリーに分かれており、
   前記仲介装置が、
   （イ）売り手が提供するサービスのカテゴリーを含む売り手の登録情報をデータベースに登録する工程
   （ロ）買い手の登録情報をデータベースに登録する工程
   （ハ）前記買い手が選択したカテゴリーを含む前記買い手が入力した発注情報を受信し、前記発注情報に含まれるカテゴリーが前記第１のカテゴリーである場合に限り、保存する工程
   （ニ）前記買い手が選択したカテゴリーと一致するカテゴリーが登録されている前記売り手にのみ、前記買い手の識別情報を除いた前記発注情報を送信して前記売り手端末に表示させる工程
   （ホ）前記発注情報に対して前記売り手が入力した応札情報を受信し、保存する工程
   （ヘ）受信した前記応札情報を前記買い手端末に送信して表示させる工程
   （ト）前記買い手端末に表示された前記応札情報の中から前記買い手が選択した応札情報と対応する識別情報を取得し、前記買い手が選択した前記売り手に対して商談依頼の通知を送信する工程
   の各工程を実行することを含むことを特徴とするネット上で売り手と買い手の仲介を行う仲介方法。
5. 前記工程（イ）において、売り手のサービスと対応するカテゴリーが無い場合には新規カテゴリー申請画面に移行して、前記売り手がカテゴリーの追加申請を行うことができることを特徴とする請求項４に記載の仲介方法。
6. 前記工程（イ）において、サービスを提供する地域を指定可能であり、前記工程（ニ）においては、発注情報において指定された地域と前記サービスを提供する地域とが一致する売り手にのみ発注情報を表示することを特徴とする請求項４または５の何れか一項に記載の仲介方法。

Images