JP2017167655A - 予約サーバ、予約システム、および予約方法 - Google Patents

Abstract

【課題】会場調査における予約を迅速かつ低コストに行うための技術を提供する。【解決手段】参加者の数が設定された複数の時間枠と、参加者の属性に基づく割り付け条件が設定されたイベントの予約サーバであって、処理手段と、参加候補者の端末装置と通信を行う通信手段と、参加候補者の属性情報を格納する参加候補者ＤＢ、イベント情報を格納するイベントＤＢおよび各時間枠の予約状況と割り付け条件の充足状況を含むイベントの状況を管理する状況管理ＤＢを制御するＤＢ制御手段を有し、通信手段は参加候補者に参加依頼を行い、処理手段は参加候補者の端末装置に各時間枠が予約可能であるかどうかを属性情報、予約状況および充足状況に基づいて表示させ、ＤＢ制御手段は参加候補者による予約処理を受けて、予約済み参加者として登録する予約サーバを用いる。【選択図】図２

Description

本発明は、予約サーバ、予約システムおよび予約方法に関し、特に、会場調査の予約に利用される技術に関する。

企業のマーケティングに活用するために、実際の会場に参加者（モニタ）を集めて行われる、「会場調査（ＣＬＴ：Ｃｅｎｔｒａｌ Ｌｏｃａｔｉｏｎ Ｔｅｓｔ）」と呼ばれる調査方式が用いられている（以下単に、「会場調査」とも表記する）。会場調査は、所定の属性を有するモニタに一箇所に集まってもらい、「調査員」の進行によって、聞き取り調査や、自記入によるアンケートを行い、定量的に意見聴取を行う調査方式である。会場調査は、アンケートの評価対象となる評価物に直接触れたり食べたりしてもらう場合や、評価物に相当の機密事項が含まれる場合によく用いられる手法である。会場リサーチ、セントラルロケーションテストなどとも呼ばれる。また、フォーカスグループインタビューやデプスインタビューといった定性調査も、所定の属性を有するモニタに一箇所に集まってもらい、意見を聴取する方法である。

会場調査には、以下のような利点がある。まず、会場調査の依頼者（クライアント）の商品やサービスを、モニタが実際に体験しながら意見を聴取できる。そのため、実体験に基づく反応の観察や、具体的な問題点の把握が可能になる。また、評価物を一定のクオリティで管理・提供することで、アンケートのブレを抑制できる。例えば、飲料を一定温度で試飲させることにより味覚の判断基準のブレが抑えられる。さらに、モニタを調査員の目が届く範囲で管理するため、評価物の情報流出にも一定の効果を発揮する。例えば、評価物を撮影されることを防いだり、守秘義務契約を直接取り交わすことで情報流出への意識を高めたりできる。また、モニタの側は、金銭、物品、ポイントなどのインセンティブを得られる。

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

会場調査には上記の利点がある反面、モニタの属性に基づく制約と、時間的・場所的な制約がある。まずモニタの属性に基づく制約について述べる。マーケティングの目的に応じて、必要とされるモニタの属性（例えば、年齢・性別・未既婚・職業）は異なる。また、調査に応じて、「割り付け」と呼ばれる、同じ属性を持つモニタを何人ずつ集めるかという設定も異なる。例えば社会人女性向けファッションに関するマーケティングにおいて、２０歳代、３０歳代、４０歳代の女性をそれぞれ１０人ずつ集めるといった具合である。割り付け条件を細かくするほど分析精度は向上する反面、条件に合うモニタを集めることが難しくなる。

従来、所望の割り付け条件を満たすモニタを集めるために、リサーチ会社が有する候補者リストを用いた電話募集が行われていた。調査会社のオペレータは、リストから所望の属性を満たす候補者を抽出し、電話をかけて調査の内容、日時、報酬等の条件を伝えて参加を要請する。承諾が得られた候補者がモニタとして選定されることで、予約が行われる。また、調査日が迫ってきた時点で再び電話をかけて、出席の意志を確認する場合もある。しかし、モニタ候補者によっては、仕事や家事などの都合で電話に出られない場合もあ
るため、モニタを集めるのに時間がかかる。また、電話に出られない候補者は参加予約できないため、不公平感が醸成されたり、参加者の属性に偏りが生じたりするおそれがある。また、電話オペレータの人件費などにより、調査のコストが増大する。

続いて、時間的・場所的制約について述べる。会場調査では、決まった時間に会場までモニタが出向く必要がある。そのため、モニタの居住地や勤務時間などの時間的・場所的な条件が合わないと、参加が不可能である。

ここで、モニタを一箇所に集めるという会場調査の特性上、一度に調査できる人数は会場の広さに応じて制約を受ける。また一度に調査する人数が増えすぎると、調査員の対処能力を超えたり、モニタを観察し切れなくなったりという問題も生じる。したがって、多数のモニタを調査する場合、会場の収容能力等に応じた所定数のモニタごとに、時間枠を分けて複数回の調査が行われる。これにより、モニタ候補者が都合の良い時間を選べるという効果もある。

上記のように、多人数を対象とする会場調査には、所定の属性や割り付け条件を満たすという制約と、時間的・場所的な制約があるため、必要なモニタを集めて予約を行うために時間とコストがかかる。また、モニタが会場調査の日を失念して欠席することを避けるため、調査前日などに電話確認をする場合がある。その場合はさらにコストが増大する。また、いったん時間枠を予約したモニタの都合が悪くなりキャンセルする場合、改めて別のモニタ候補者に電話を掛けて参加を依頼する必要もあり、さらにコストが増大する。

ここで、マーケティング目的で複数のモニタを対象に調査を行う技術について開示する特開２００２−３４４９１６号公報（特許文献１）では、インターネットや電話、郵便を用いてモニタ候補者を公募する。そして、候補者の属性や、メールや電話による事前調査結果に基づいて絞り込みを行い、調査の実施場所や日時を通知する。候補者がそれに応じて参加を承諾することで、予約が行われる。しかし特許文献１は、モニタの割り付け条件に応じたモニタ募集や、複数の時間枠を設けた場合の予約方法について何ら言及していない。また特許文献１は、モニタ募集、絞り込み、予約処理においてリサーチ会社のオペレータが介在する必要がある。そのため特許文献１の手法では、所望の割り付け条件を満たした予約管理や、調査の迅速化および低コスト化が実現できない。

本発明は上記の課題に鑑みてなされたものである。本発明の目的は、会場調査における予約を迅速かつ低コストに行うための技術を提供することにある。

上記の目的を達成するため、本発明は以下のような構成を採用する。すなわち、参加者の数が設定された複数の時間枠、および、参加者の属性に基づく割り付け条件が設定されたイベントの予約サーバであって、処理手段と、参加者の候補である参加候補者の端末装置と通信を行う通信手段と、参加候補者の属性情報を格納する参加候補者ＤＢ、イベントに関するイベント情報を格納するイベントＤＢ、および、複数の時間枠それぞれの予約状況と割り付け条件の充足状況とを含むイベントの状況を管理する状況管理ＤＢを制御するＤＢ制御手段と、を有し、通信手段は、参加候補者に前記イベントへの参加依頼を行い、処理手段は、参加依頼を受けた参加候補者の端末装置に、複数の時間枠それぞれが予約可能であるかどうかを、属性情報、予約状況および充足状況に基づいて表示させ、ＤＢ制御手段は、通信手段が参加候補者による時間枠の予約処理を受け付けると、参加候補者を予約済み参加者として登録することを特徴とする予約サーバである。

かかる構成によれば、時間枠と割り付け条件により制約される会場調査において、モニタ自身による予約処理が可能になり、コスト低減と時間短縮が実現する。

また、上記構成において、ＤＢ制御手段が属性情報に基づいて参加候補者ＤＢを参照して割り付け条件を満たす参加候補者を抽出し、通信手段が抽出された参加候補者に参加依頼を行うこともできる。これにより、モニタ抽出の効率と精度が向上する。

また、上記構成において、複数の時間枠の中に予約ができない時間枠がある場合、参加候補者の端末装置に、予約ができない時間枠のキャンセル待ちが可能であることを表示させることもできる。加えて、通信手段が予約済み参加者による時間枠のキャンセル処理を受け付けると、状況管理ＤＢを参照して、キャンセル待ちを行った参加候補者の中から、キャンセル処理を行った予約済み参加者の属性情報を満たすような参加候補者を抽出することもできる。これにより、モニタのキャンセル待ち登録処理を自動化できる。

また、上記構成において、イベントから所定の期間前に予約済み参加者に参加確認を行うこともできる。これにより、会場調査への参加意思確認を自動化できる。

また、上記構成において、参加候補者にイベント情報に関連する事前アンケートを依頼し、割り付け条件を満たす参加候補者を抽出するときに、事前アンケートの結果を用いることもできる。さらに、会場調査の終了後に、参加者に対して追加調査を依頼することもできる。これにより、分析精度が向上する。

本発明はまた、上記の予約サーバに相当する構成要素と操作端末を含む予約システムや、上記の予約サーバが実行する処理に対応する各ステップを含む予約方法や、当該予約方法の各ステップを情報処理装置に実行させるプログラムとしても実現できる。

本発明によれば、会場調査における予約を迅速かつ低コストに行うための技術を提供できる。

予約システムの全体構成を説明する図 実施形態１の予約処理を説明するフローチャート 実施形態１のキャンセル処理を説明するフローチャート データベース構成の一例を示す図 データベース構成の一例を示す図 表示画面の一例を示す図 実施形態２の確認処理を説明するフローチャート

以下に図面を参照しつつ、本発明の好適な実施の形態を説明する。ただし、以下に記載されている構成ブロックやそれらの相対配置などは、発明が適用されるシステムの各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。

以下のフローでは、クライアントから依頼を受けるリサーチ会社と、当該リサーチ会社の保有するリストに登録されているモニタ候補者との間で予約処理が進められる。ただし、マーケティングを行う企業等が直接予約システムを運用管理してもよい。以降、予約システムを運用管理する立場の者を「管理者」と称する。また、それぞれの会場調査を「イベント」と称する。モニタのことを「参加者」、モニタ候補者のことを「参加候補者」とも称する。

本発明は特に、管理者が設定したイベントについて、会場調査のモニタが自ら端末を操作して時間枠の予約を行うような予約システムに好適である。本発明はまた、このような予約システムに用いられる予約サーバとしても捉えられる。本発明はまた、情報処理装置の演算資源を利用して当該情報処理装置を予約サーバとして稼働させるような予約プログラムや、当該予約ブログラムを格納したコンピュータにより読み取り可能な記憶媒体としても捉えられる。

＜実施形態１＞
本実施形態では、複数の時間枠がある会場調査の基本的な予約処理について説明する。

（システム構成）
図１を参照しながらシステム構成について説明する。システムは、Ｗｅｂ３を介して相互に通信可能な、端末装置１（１ａ，１ｂ，…）および予約サーバ２と、予約サーバ２と通信可能なＤＢサーバ４によって構成される。端末装置１は、会場調査のモニタ候補者がそれぞれ操作可能な装置である。端末装置１は、情報処理機能、表示機能、通信機能などを有する。端末装置１としては例えば、プロセッサ、記憶装置、通信装置、ユーザインタフェース等を備える、ＰＣ、携帯電話、スマートフォンなどの情報処理装置が好適である。ＰＣはデスクトップ型、ノート型、タブレット型など形式を問わない。端末装置１がＷｅｂサイトにアクセスして情報を送受信することで、モニタ候補者の予約システムへの参加が可能になる。端末装置１に表示されるＷｅｂサイトデータは、ユーザ入力（例えば検索サイトにおける検索結果からのリンクのクリック）に基づくＨＴＴＰリクエストで予約サーバ２に要求され、サーバからのレスポンスに基づいて表示される。

予約サーバ２は、管理者が運用管理するサーバである。予約サーバ２は、通信手段２１、ＣＰＵ２２、メモリ２３、ディスプレイ２４、ＤＢ制御手段２５を備える。予約サーバ２は、各種の演算資源やユーザインタフェース等を備え、プログラムに従って動作するＰＣやワークステーションにより実現できる。ＤＢサーバ４は、イベントＤＢ４５、モニタ候補者ＤＢ４６、状況管理ＤＢ４７など、後述する各種データベースを備える。データの入出力については、ＤＢＭＳ（データベース管理システム）などで構成されるＤＢ制御手段２５が行う。ＣＰＵ２２は、メモリ２３に格納されたプログラムに従って情報処理を行うことで、本発明の処理手段として機能する。

なお、サーバの構成やデータベースの配置は任意であり、図示したものに限定されない。例えば、クラウドサーバや仮想サーバを利用してもよいし、Ｗｅｂサーバ、アプリケーションサーバ、複数の物理的に離れた情報処理装置をオンライン接続して利用してもよい。

（予約処理フロー）
フローチャートを参照しつつ、本実施形態の基本的な処理を説明する。図２は、イベント設定から予約完了までのフローであり、図２（ａ）は管理者側の、図２（ｂ）はモニタ候補者側の処理を示す。ステップＳ１０１において、図４（ａ）に示すイベントＤＢ４５にイベント情報を設定する。具体的には、管理者が依頼者（クライアント）からの依頼に基づいて、マーケティングの目的に応じて会場調査の内容を決定し、予約システムの管理画面を用いて情報登録する。特に、モニタの属性に基づく割り付け条件と、会場等の制約に応じた時間枠の数および各枠の人数が決定される。

ステップＳ１０２において、図４（ｂ）に示すモニタ候補者ＤＢ４６から、割り付け条件を満たすモニタ候補者が抽出される。ここでは例えば、性別（男女それぞれ）、年代（１０代、２０代、３０代）の２つの条件で、２０人ずつモニタを集められるように、必要な数の候補者を抽出する。この例では候補者の居住地は問わないが、会場の所在地に応じ
た抽出が好ましい。所要モニタ人数は２×３×２０＝１２０人となるが、一度に１０人ずつという会場の制約があるため、１２個の時間枠が設定される。

ステップＳ１０３で、抽出された候補者に対してイベントへの参加を依頼するメールが送られる。このとき、各割り付け条件を満たす候補者全てにメールしても良いし、必要な人数から一定割合だけ多い候補者にメールしてもよい。

なお、予約システムからモニタ候補者や予約済みモニタに対する連絡には、ショートメッセージ、スマートフォン用アプリやタブレット用アプリのプッシュ通知、ソーシャルネットワーキングサービスのメッセージ機能など、任意の連絡手段を利用できる。またモニタ候補者や予約済みモニタから予約システム側への連絡手段としても、Ｗｅｂサイトの入力フォームなどだけではなく、メール等の任意の方法を利用できる。

また、ステップＳ１０２〜Ｓ１０３のように管理者が特定したモニタ候補者に参加依頼をするのではなく、参加条件をＷｅｂサイトで公開し、その条件を見たモニタ候補者側から予約サイトにアクセスする仕組みでもよい。その場合でも、モニタ募集を開始したことを一斉メール等で周知することが好ましい。詳しくは後述するが、予備的アンケートを行う場合もある。

図２（ｂ）に移り、ステップＳ２０１において、モニタ候補者は予約サイトにアクセスし、図６（ａ）に示すイベント一覧画面を用いて該当するイベントを選択し、イベント詳細画面に移る。アクセス時には、モニタのユーザ名とパスワードを用いたログイン処理によりセキュリティを確保することが好ましい。ステップＳ２０２において、モニタ候補者は図６（ｂ）に示すイベント詳細画面を確認し、諸条件を勘案して参加を希望するかどうかを決定し、時間枠の予約を行う。希望の時間枠に空きがあれば、ステップＳ２０３に進んで予約送信する。一方空きが無い場合は、ステップＳ２０４に進んでキャンセル待ち登録をする。なお、イベント参加を希望しない場合は特に操作はない。予約サーバ２の通信手段２１は送信された情報を受け付ける。

なお、予約サーバ２は、モニタ候補者の属性と、各割り付け条件の充足の程度に応じて、ステップＳ２０２で表示されるイベント詳細画面を変える。例えばモニタ候補者が「男性、３０代」であり、その割り付けの必要人数が既に満たされている場合、ＧＵＩ（ボタン）をクリック不能にしたり、予約ボタンの代わりにキャンセル待ちボタンを表示したりといった方法で、予約を不可能にする。一方、「女性、２０代」という割り付けが必要人数に達していなければ、そのような属性を持つモニタ候補者に対しては予約を可能にする。ただし、所定の人数が埋まった時間枠についてはキャンセル待ち表示とする。

なお、各モニタ候補者は必ずしも、イベントの割り付け条件や、自分がどの割り付けに属しているかということや、各割り付けの充足状況を知る必要はない。イベント詳細画面から予約可能またはキャンセル待ち可能な時間枠を探し、候補者自身のスケジュールに応じて好みの枠を選択すれば良い。またキャンセル待ちには、割り付け条件が埋まったことによるキャンセル待ちと、時間枠が埋まったことによるキャンセル待ちがあり、前者の場合は何れの時間枠も予約不可能である。しかしモニタ候補者は、時間枠の予約状況や割り付けの充足状況を知る必要はない。その裏で予約サーバ２は、各割り付けが満たされているかという観点と、各時間枠が満たされているかという観点から表示制御を行っている。また、各時間枠内におけるモニタ候補者の割り付けの配分は特に限定されない。言い換えると、全ての時間枠における参加者を合計した中で、割り付け条件が満たされていれば良い。

図２（ａ）に戻り、ステップＳ１０４において、モニタ候補者から受け付けた送信内容
に基づいて、図５（ａ）、図５（ｂ）に示す状況管理ＤＢ４７を更新する。これによりモニタ候補者が、予約済みモニタ、またはキャンセル待ちモニタとして、状況管理ＤＢの該当する時間枠に登録される。また、割り付けの充足状況も更新される。なお、所定の募集期間内に所望の割り付け条件および時間枠を満たすだけの予約が行われなかった場合は、ステップＳ１０２に戻って再募集をかけても良い。

以上のフローにより、日程および時間枠が設定され、かつ割り付け条件を満たすようなモニタを集める必要がある会場調査において、モニタ候補者が自らＷｅｂを経由して時間枠を予約する。このとき予約サーバが各割り付け条件の充足状況を判断するため、時間枠および割り付け条件を満たすような自動予約処理が実現される。その結果、管理者が電話によるモニタ募集を行う必要がなくなり、コスト低減と時間短縮が可能になる。

（キャンセル対応フロー）
図３を参照して、予約システムをキャンセル対応に利用する場合の処理フローを説明する。図３（ａ）は管理者側、図３（ｂ）はモニタ候補者側の処理を表す。ステップＳ１１１では、予約サーバが、予約済みのモニタからのキャンセル処理を受け付ける。キャンセル処理は、イベント一覧画面やイベント詳細画面におけるボタン等により実行できる。予約済みモニタは、予約完了後、キャンセル可能な時期の間は随時マイページにログインしてキャンセル処理を実行できる。また、調査直前に管理者が参加確認する場合は、そのタイミングでキャンセルされる場合もある。

ステップＳ１１２において、予約サーバ２は状況管理ＤＢ４７を参照し、キャンセルした予約済みモニタと同じ割り付けに属し、キャンセル待ちリストに登録しているモニタ候補者を抽出する。続くステップＳ１１３で、抽出された候補者に対してイベントへの参加を依頼するメールが送られる。メールを送る対象は、キャンセル待ちリストの先着順でも良いし、複数の候補者に送っても良い。なお、キャンセルした予約済みモニタと同じ割り付け条件を満たすキャンセル待ちの候補者がいない場合は、改めてモニタ候補者ＤＢ４６から抽出処理が行われる。

図３（ｂ）に移り、キャンセル待ち登録済みのモニタ候補者は、ステップＳ２１１において予約サイトにアクセスして当該イベントを選択する。続いてステップＳ２１２で参加可能と判断すれば、ステップＳ２１３でＧＵＩのボタン等で予約処理を行う。なお本フローでは、キャンセル待ち登録後にモニタ候補者の予定が変わった場合を考えてＳ２１１〜Ｓ２１３の処理を行う。しかし、キャンセル待ち登録している候補者を自動的に予約者として追加し、候補者にはその旨を通知する構成でもよい。図３（ａ）に戻り、ステップＳ１１４で全ての時間枠や割り付け条件が満たされているかどうかを判断し、必要に応じて参加依頼を続ける。

以上のフローにより、予約済みモニタがキャンセルを行った場合にも、キャンセル待ちリストに基づいて自動的に参加要請が行われる。モニタ候補者は自ら予約サイトにアクセスして予約処理を行うので、コスト低減と時間短縮が可能になる。ただし、キャンセル待ち処理を予約システムで行わず、電話などを用いた手法によっても構わない。

（データ構造）
図４、図５に、本実施形態で主に利用されるデータベースのデータ構造を例示する。イベントＤＢ４５、モニタ候補者ＤＢ４６、状況管理ＤＢ４７、その他本発明で利用されるデータベースは、ハードディスクやフラッシュメモリ等の記憶媒体を備え、情報処理装置により読み書きが可能な記憶装置に格納される。データベースには関係型、階層型など任意の方式を利用できる。またＤＢサーバ４はオンラインまたはオフライン接続された複数の装置で構成されてもよい。なお、以下に示すデータ定義やデータベース構造は一例に過
ぎず、データベースの分け方、項目、参照関係などは、条件に応じて任意に定められる。また「データベース」という名称に捕らわれることなく、本発明の実施に必要なデータを更新可能に保持していればよい。

図４（ａ）に示すイベントＤＢ４５には、会場調査ごとに情報が登録される、イベントに関するマスタＤＢである。イベントＤＢ４５は、例えば符号４０１のようなテーブルを保持する。依頼者（クライアント）のマーケティングの目的に応じてイベントＤＢの各エントリーが設定される。この例では、イベントごとに割り振られるイベントＩＤ、依頼者、イベント名、割り付け条件、開催場所、時間枠数／枠ごとの人数、各時間枠の開催日時という項目が設定されている。他に、イベントの詳細情報、モニタのインセンティブなど、イベントに設定される固定的な諸条件を設定してもよい。

本発明の予約システムは、リサーチ会社のオペレータが上記の情報を登録するためのＧＵＩ等の操作手段を提供する。オペレータは管理者権限で予約システムにログインし、依頼者の目的に応じた条件でエントリーを作成する。依頼者からの要求やモニタ募集の進行状況に応じて、動的に割り付け条件や時間枠を変更できるようにしてもよい。

図４（ｂ）に示すモニタ候補者ＤＢ４６は、各候補者の属性に関するマスタＤＢである。モニタ候補者ＤＢ４６は、例えば符号４０２のようなテーブルを保持する。モニタ候補者ＤＢ４６としては、リサーチ会社が保有する候補者リストが使用される。また、Ｗｅｂを通じた公募、街頭での勧誘、人的つながりを通じた方法でモニタ候補者を集めてもよい。図４（ｂ）の例では、各エントリーには、モニタ候補者ＩＤ、氏名、性別、年代、未既婚の別、居住地、職業、および、連絡先（ここではメールアドレス）が含まれる。他に例えば、収入、家族構成、ペットの有無、保有している商品や購入意向のある商品の情報、学歴、趣味、嗜好、メール以外の連絡先（例えば電話番号）など、様々な内容を含み得る。

予約システムは、モニタ候補者自らが端末装置１を用いて上記の情報を登録するためのＧＵＩ等の操作手段を提供することが好ましい。モニタ候補者がＷｅｂサイト等を経由して属性を入力することにより、リサーチ会社側のコストが低減される。また、予約サーバ２がＷｅｂサーバとして機能して、各モニタ候補者の端末装置１に「マイページ」を提供する。マイページでは、上記の属性入力・編集のほか、募集中の会場調査（イベント）の表示、イベント予約やキャンセル待ち登録などが可能である。また、リサーチ会社の業務として会場調査以外にＷｅｂアンケートがある場合、Ｗｅｂアンケートへの回答と、会場調査の受付をシームレスに実施できる。

図５に示す状況管理ＤＢ４７は、イベントが終了するまでの間、モニタや時間枠の充足状況などを格納するデータベースであり、オペレータやモニタ候補者の操作に応じて動的に変更される。図５（ａ）は割り付け条件ごとの状況を管理するためのテーブル５０１である。図５（ｂ）は時間枠ごとの状況を管理するためのテーブル５０２である。管理者であるリサーチ会社のオペレータが管理者用の画面を操作してイベントＤＢ４５に新規イベントを登録し、割り付け条件や人数を設定することで、イベントＩＤをキーとして状況管理ＤＢ４７にもエントリーが作成される。

予約サーバ２は、このＤＢを参照して端末装置１に表示される画面を変更する。例えば予約可能な時間枠にはＧＵＩとして予約ボタンを表示し、既に埋まっている時間枠にはキャンセル待ちボタンを表示する。そして、モニタ候補者の画面上での操作に応じてＤＢを更新する。本実施形態では、各割り付けと各時間枠における充足状況およびキャンセル待ち状況が更新される。

（操作画面）
図６に、端末装置１の表示画面に表示される操作画面を例示する。図６（ａ）は、モニタ候補者に提示されるイベント一覧画面である。イベント一覧画面６０１には、予約可能またはキャンセル待ち登録が可能な時間枠が存在するイベントを表示するための、予約可能イベント欄６０１１と、予約またはキャンセル待ちを済ませたイベントを表示するための、予約済みイベント欄６０１２が存在する。また詳しくは後述するが、出席確定イベント欄６０１３も存在する。

図６（ｂ）は、予約可能イベント欄６０１１から一つのイベントを選択したときの遷移先である、イベント詳細画面６０２を示す。画面中、イベント情報欄６０２１にはイベントの詳しい情報が、時間枠表示欄６０２２には、各時間枠の予約可否に関する情報と、予約またはキャンセル待ちのためのＧＵＩ（ボタン）が表示されている。

以上述べたように、本実施形態の予約システムによれば、会場調査において割り付け条件と時間枠に関する条件を満たした予約が、予約サーバによって表示されるＷｅｂサイトを経由して、モニタ候補者自らによって行われる。モニタ候補者は、自らの都合の良い時間に予約処理を行える。その結果、電話による処理が不要となり、コスト低減、準備期間短縮、不公平感の低減などの効果が得られる。

（変形例１）
上記フローでは、モニタ候補者は希望の時間枠を選択してキャンセル待ち登録していた。しかし、時間枠を設定させずに、単純にキャンセル待ちをする旨だけを登録させても良い。この場合、モニタ候補者がキャンセルされた時間枠に参加できるかどうか不明であり、参加できない場合は他の候補者に当たる必要があり、二度手間になるおそれがある。一方で、管理者にとってはキャンセル待ちリストの管理やキャンセル時の処理が簡易になる。また、複数のキャンセル待ち登録者に同時に参加依頼することで、空きの出た時間枠を早く埋めることが可能になる。

（変形例２）
また、モニタ候補者がキャンセル待ち登録するときに、複数の時間枠の設定や、ＮＧの時間枠の設定を可能にしても良い。

（変形例３）
上記フローでは、各時間枠内での割り付けの配分は特に限定せず、全てのモニタの中で割り付け条件が満たされるようにしていた。しかし、各時間枠の中で、ある程度モニタの属性を設定したい場合もあり得る。例えばディスカッション形式の会場調査で、同質の属性のモニタばかりが集まると意見が固定化されるような場合である。そこで予約サーバ２は、各時間枠で既に予約を済ませているモニタの属性に基づいて、後から予約をしようとするモニタ候補者の操作端末に表示される画面における、予約が可能か否かの表示を変更してもよい。

＜実施形態２＞
本実施形態では、基本的な予約処理に加えて、予約済みモニタの出席確認をシステム化する例を述べる。本実施形態の予約システムの全体構成や基本的な処理フローは実施形態１と同じであるため、以下では相違点や追加点を中心に説明する。

図７は、予約済みモニタへの参加確認のフローであり、図７（ａ）は管理者側の、図７（ｂ）は予約済みモニタ側の処理を示す。イベント開催日から所定の期間前（例えばイベント３日前）になったら、ステップＳ１２１において、予約サーバ２から参加確認メールが送信される。図７（ｂ）に移り、ステップＳ２２１において予約済みモニタは予約サイ
トにアクセスし、図６（ａ）の予約済みイベント欄６０１２から当該イベントを選択する。そしてステップＳ２２２で予約済みイベントの時間枠に参加するか否かの最終判断を行い、予約確認した旨を送信する（ステップＳ２２３）か、キャンセルする旨を送信する（ステップＳ２２４）。

図７（ａ）に戻り、予約サーバ２は、ステップＳ１２２において状況管理ＤＢを更新する。続いてステップＳ１２３において、時間枠や割り付けが満たされているかどうかを判断する。もし予約済みモニタがキャンセルを行っていなければ「Ｓ１２３＝ＮＯ」となるので、ステップＳ１２４に進み、図３のフローで説明したようなキャンセル時の対応を行う。一方、予約確認が送信された場合は確定処理が行われ、当該イベントは図６（ａ）の出席確定イベント欄６０１３に表示されるようになる。

以上述べたように、本実施形態では、会場調査が開催される直前の電話確認をシステム化し、予約済みモニタは自らＷｅｂサイトを経由して最終的な意志確認（参加確定またはキャンセル）を行う。そして、キャンセルがあった場合は自動的にキャンセル時対応がなされる。その結果、電話による処理が不要となり、コスト低減効果が得られる。

＜実施形態３＞
本実施形態では、基本的な予約処理に先立って、モニタの予備的な抽出を行う例を述べる。リサーチ会社が保有するモニタ候補者ＤＢ４６には様々な属性情報が格納されているが、マーケティングの目的や会場調査の内容によっては、既登録情報では不十分な場合がある。そこで予め必要な情報を取得してからモニタ候補者を抽出することで、より詳細な調査が可能になる。予約サーバ２は、このような事前情報取得のために、例えば図２のステップＳ１０２の前に、モニタ候補者ＤＢ４６に載っているモニタ全員にメールを送付して事前アンケートを依頼する。リサーチ会社がＷｅｂアンケート業務を行っている場合は、かかる事前アンケートを容易に実施できる。

以上述べたように、本実施形態によれば、調査目的に応じた適切な属性を持つモニタ候補者を抽出できる。さらに、事前アンケートで得られた情報をモニタ候補者ＤＢに追加することも好ましい。また事前アンケートにインセンティブを付与することで、モニタ候補者の満足感も高まる。

＜実施形態４＞
本実施形態では、基本的な予約処理に加えて、会場調査終了後に追加的な調査を行う例について述べる。会場調査の結果に対して、依頼者がさらに詳しい分析を希望する場合がある。その場合、予約システムからモニタに対してメール等を送ってＷｅｂによる事後アンケートを依頼したり、個別インタビューや電話インタビューを依頼したりできる。本実施形態によれば、会場調査で得られた知見をさらに深く掘り下げることで、より精度の高いマーケティングが可能になる。

＜実施形態５＞
以上の各実施形態では、会場調査の予約システムについて説明したが、本発明は他の予約システムにも適用可能である。すなわち、管理者の側で所望の割り付けが設定され、さらに時間枠の制約があるイベントであって、イベント参加者が自ら予約を行い得るようなイベントであれば、本発明を適用できる。このようなイベントとして例えば、就職説明会や採用面接の予約システムがある。就職説明会においては会場の制約から時間枠を設ける必要がある。また、最終的な採用者のバランスを取ったり、グループ討論を円滑に進めたりするために、全参加者の合計において、地域や性別などの割り付け条件を設定する場合がある。かかる就職説明会に本発明を適用することで、企業等の採用活動を低コスト化できる。

また本発明は、オンラインゲームまたはオフラインゲームの大会の参加予約システムにも適用できる。オンラインゲームにおいては仕様上の問題やゲーム性の観点から同時に参加できる人数が限られる。またオフラインゲームにおいては会場の制約に起因する人数制限がある。さらに、ゲームへの習熟度もしくは技量、または、管理者への寄与度もしくは支払金額に応じて、割り付け条件が設定される場合がある。本発明によれば、かかる参加予約システムを低コストかつ短時間で運営できる。

本発明は、上記処理の少なくとも一部を含む方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記構成要素および処理の各々は可能な限り互いに組み合わせて使用できる。例えば上記各実施形態の一部処理を、電話等を用いた処理で代替してもよい。例えば管理者側の参加確認処理、キャンセル対応処理、事前アンケート、事後アンケートなどを電話で行ったり、モニタ候補者の予約処理や予約済みモニタのキャンセル処理を電話で行ったりしてもよい。

１：端末装置、２：予約サーバ、２１：通信手段、２２：ＣＰＵ、４：ＤＢサーバ、イベントＤＢ４５、モニタ候補者ＤＢ４６、状況管理ＤＢ４７

Claims (10)

1. 参加者の数が設定された複数の時間枠、および、前記参加者の属性に基づく割り付け条件が設定されたイベントの予約サーバであって、
   処理手段と、
   前記参加者の候補である参加候補者の端末装置と通信を行う通信手段と、
   前記参加候補者の属性情報を格納する参加候補者ＤＢ、前記イベントに関するイベント情報を格納するイベントＤＢ、および、前記複数の時間枠それぞれの予約状況と前記割り付け条件の充足状況とを含む前記イベントの状況を管理する状況管理ＤＢを制御するＤＢ制御手段と、
   を有し、
   前記通信手段は、前記参加候補者に前記イベントへの参加依頼を行い、
   前記処理手段は、前記参加依頼を受けた前記参加候補者の前記端末装置に、前記複数の時間枠それぞれが予約可能であるかどうかを、前記属性情報、前記予約状況および前記充足状況に基づいて表示させ、
   前記ＤＢ制御手段は、前記通信手段が前記参加候補者による前記時間枠の予約処理を受け付けると、前記参加候補者を予約済み参加者として登録する
   ことを特徴とする予約サーバ。
2. 前記ＤＢ制御手段は、前記属性情報に基づいて、前記参加候補者ＤＢを参照して前記割り付け条件を満たす前記参加候補者を抽出し、
   前記通信手段は、抽出された前記参加候補者に前記参加依頼を行う
   ことを特徴とする請求項１に記載の予約サーバ。
3. 前記処理手段は、前記複数の時間枠の中に予約ができない時間枠がある場合、前記参加候補者の前記端末装置に、当該予約ができない時間枠のキャンセル待ちが可能であることを表示させる
   ことを特徴とする請求項１または２に記載の予約サーバ。
4. 前記ＤＢ制御手段は、前記通信手段が前記予約済み参加者による前記時間枠のキャンセル処理を受け付けると、前記状況管理ＤＢを参照して、キャンセル待ちを行った前記参加候補者の中から、キャンセル処理を行った前記予約済み参加者の前記属性情報を満たすような前記参加候補者を抽出する
   ことを特徴とする請求項３に記載の予約サーバ。
5. 前記通信手段は、前記イベントから所定の期間前に前記予約済み参加者に参加確認を行う
   ことを特徴とする請求項１ないし４のいずれか１項に記載の予約サーバ。
6. 前記通信手段は、前記参加候補者に、前記イベント情報に関連する事前アンケートを依頼し、
   前記ＤＢ制御手段は、前記割り付け条件を満たす前記参加候補者を抽出するときに、前記事前アンケートの結果を用いる
   ことを特徴とする請求項１ないし５のいずれか１項に記載の予約サーバ。
7. 前記通信手段は、前記イベントの終了後に、前記参加者に対して追加調査を依頼する
   ことを特徴とする請求項１ないし６のいずれか１項に記載の予約サーバ。
8. 参加者の数が設定された複数の時間枠、および、前記参加者の属性に基づく割り付け条件が設定されたイベントの予約システムであって、
   前記参加者の候補である参加候補者が用いる端末装置と、
   処理手段と、
   前記端末装置と通信を行う通信手段と、
   前記参加候補者の属性情報を格納する参加候補者ＤＢ、前記イベントに関するイベント情報を格納するイベントＤＢ、および、前記複数の時間枠それぞれの予約状況と前記割り付け条件の充足状況とを含む前記イベントの状況を管理する状況管理ＤＢを制御するＤＢ制御手段と、
   を有し、
   前記通信手段は、前記参加候補者に前記イベントへの参加依頼を行い、
   前記処理手段は、前記参加依頼を受けた前記参加候補者の前記端末装置に、前記複数の時間枠それぞれが予約可能であるかどうかを、前記属性情報、前記予約状況および前記充足状況に基づいて表示させ、
   前記ＤＢ制御手段は、前記通信手段が前記参加候補者による前記時間枠の予約処理を受け付けると、前記参加候補者を予約済み参加者として登録する
   ことを特徴とする予約システム。
9. 参加者の数が設定された複数の時間枠、および、前記参加者の属性に基づく割り付け条件が設定されたイベントの予約方法であって、
   前記参加者の候補である参加候補者の端末装置と通信を行い、前記参加候補者に前記イベントへの参加依頼を行う通信ステップと、
   前記参加候補者の属性情報を格納する参加候補者ＤＢ、前記イベントに関するイベント情報を格納するイベントＤＢ、および、前記複数の時間枠それぞれの予約状況と前記割り付け条件の充足状況とを含む前記イベントの状況を管理する状況管理ＤＢを制御するＤＢ制御ステップと、
   前記参加依頼を受けた前記参加候補者の前記端末装置に、前記複数の時間枠それぞれが予約可能であるかどうかを、前記属性情報、前記予約状況および前記充足状況に基づいて表示させる表示ステップと、
   前記参加候補者による前記時間枠の予約処理を受け付ける受付ステップと、
   前記予約処理を行った前記参加候補者を予約済み参加者として登録する登録ステップと、
   を有することを特徴とする予約方法。
10. 請求項９に記載の予約方法の各ステップを情報処理装置に実行させるプログラム。

Images