(58)【調査した分野】(Int.Cl.,DB名)
前記処理手段は、前記複数の時間枠の中に予約ができない時間枠がある場合、前記参加候補者の前記端末装置に、当該予約ができない時間枠のキャンセル待ちが可能であることを表示させる
ことを特徴とする請求項1または2に記載の予約サーバ。
前記DB制御手段は、前記通信手段が前記予約済み参加者による前記時間枠のキャンセル処理を受け付けると、前記状況管理DBを参照して、キャンセル待ちを行った前記参加候補者の中から、キャンセル処理を行った前記予約済み参加者の前記属性情報を満たすような前記参加候補者を抽出する
ことを特徴とする請求項3に記載の予約サーバ。
【発明の概要】
【発明が解決しようとする課題】
【0005】
会場調査には上記の利点がある反面、モニタの属性に基づく制約と、時間的・場所的な制約がある。まずモニタの属性に基づく制約について述べる。マーケティングの目的に応じて、必要とされるモニタの属性(例えば、年齢・性別・未既婚・職業)は異なる。また、調査に応じて、「割り付け」と呼ばれる、同じ属性を持つモニタを何人ずつ集めるかという設定も異なる。例えば社会人女性向けファッションに関するマーケティングにおいて、20歳代、30歳代、40歳代の女性をそれぞれ10人ずつ集めるといった具合である。割り付け条件を細かくするほど分析精度は向上する反面、条件に合うモニタを集めることが難しくなる。
【0006】
従来、所望の割り付け条件を満たすモニタを集めるために、リサーチ会社が有する候補者リストを用いた電話募集が行われていた。調査会社のオペレータは、リストから所望の属性を満たす候補者を抽出し、電話をかけて調査の内容、日時、報酬等の条件を伝えて参加を要請する。承諾が得られた候補者がモニタとして選定されることで、予約が行われる。また、調査日が迫ってきた時点で再び電話をかけて、出席の意志を確認する場合もある。しかし、モニタ候補者によっては、仕事や家事などの都合で電話に出られない場合もあ
るため、モニタを集めるのに時間がかかる。また、電話に出られない候補者は参加予約できないため、不公平感が醸成されたり、参加者の属性に偏りが生じたりするおそれがある。また、電話オペレータの人件費などにより、調査のコストが増大する。
【0007】
続いて、時間的・場所的制約について述べる。会場調査では、決まった時間に会場までモニタが出向く必要がある。そのため、モニタの居住地や勤務時間などの時間的・場所的な条件が合わないと、参加が不可能である。
【0008】
ここで、モニタを一箇所に集めるという会場調査の特性上、一度に調査できる人数は会場の広さに応じて制約を受ける。また一度に調査する人数が増えすぎると、調査員の対処能力を超えたり、モニタを観察し切れなくなったりという問題も生じる。したがって、多数のモニタを調査する場合、会場の収容能力等に応じた所定数のモニタごとに、時間枠を分けて複数回の調査が行われる。これにより、モニタ候補者が都合の良い時間を選べるという効果もある。
【0009】
上記のように、多人数を対象とする会場調査には、所定の属性や割り付け条件を満たすという制約と、時間的・場所的な制約があるため、必要なモニタを集めて予約を行うために時間とコストがかかる。また、モニタが会場調査の日を失念して欠席することを避けるため、調査前日などに電話確認をする場合がある。その場合はさらにコストが増大する。また、いったん時間枠を予約したモニタの都合が悪くなりキャンセルする場合、改めて別のモニタ候補者に電話を掛けて参加を依頼する必要もあり、さらにコストが増大する。
【0010】
ここで、マーケティング目的で複数のモニタを対象に調査を行う技術について開示する特開2002−344916号公報(特許文献1)では、インターネットや電話、郵便を用いてモニタ候補者を公募する。そして、候補者の属性や、メールや電話による事前調査結果に基づいて絞り込みを行い、調査の実施場所や日時を通知する。候補者がそれに応じて参加を承諾することで、予約が行われる。しかし特許文献1は、モニタの割り付け条件に応じたモニタ募集や、複数の時間枠を設けた場合の予約方法について何ら言及していない。また特許文献1は、モニタ募集、絞り込み、予約処理においてリサーチ会社のオペレータが介在する必要がある。そのため特許文献1の手法では、所望の割り付け条件を満たした予約管理や、調査の迅速化および低コスト化が実現できない。
【0011】
本発明は上記の課題に鑑みてなされたものである。本発明の目的は、会場調査における予約を迅速かつ低コストに行うための技術を提供することにある。
【課題を解決するための手段】
【0012】
上記の目的を達成するため、本発明は以下のような構成を採用する。すなわち、参加者の数が設定された複数の時間枠、および、参加者の属性に基づく割り付け条件が設定されたイベントの予約サーバであって、処理手段と、参加者の候補である参加候補者の端末装置と通信を行う通信手段と、参加候補者の属性情報を格納する参加候補者DB、イベントに関するイベント情報を格納するイベントDB、および、複数の時間枠それぞれの予約状況と割り付け条件の充足状況とを含むイベントの状況を管理する状況管理DBを制御するDB制御手段と、を有し、通信手段は、参加候補者に前記イベントへの参加依頼を行い、処理手段は、参加依頼を受けた参加候補者の端末装置に、複数の時間枠それぞれが予約可能であるかどうかを、属性情報、予約状況および充足状況に基づいて表示させ、DB制御手段は、通信手段が参加候補者による時間枠の予約処理を受け付けると、参加候補者を予約済み参加者として登録することを特徴とする予約サーバである。
【0013】
かかる構成によれば、時間枠と割り付け条件により制約される会場調査において、モニタ自身による予約処理が可能になり、コスト低減と時間短縮が実現する。
【0014】
また、上記構成において、DB制御手段が属性情報に基づいて参加候補者DBを参照して割り付け条件を満たす参加候補者を抽出し、通信手段が抽出された参加候補者に参加依頼を行うこともできる。これにより、モニタ抽出の効率と精度が向上する。
【0015】
また、上記構成において、複数の時間枠の中に予約ができない時間枠がある場合、参加候補者の端末装置に、予約ができない時間枠のキャンセル待ちが可能であることを表示させることもできる。加えて、通信手段が予約済み参加者による時間枠のキャンセル処理を受け付けると、状況管理DBを参照して、キャンセル待ちを行った参加候補者の中から、キャンセル処理を行った予約済み参加者の属性情報を満たすような参加候補者を抽出することもできる。これにより、モニタのキャンセル待ち登録処理を自動化できる。
【0016】
また、上記構成において、イベントから所定の期間前に予約済み参加者に参加確認を行うこともできる。これにより、会場調査への参加意思確認を自動化できる。
【0017】
また、上記構成において、参加候補者にイベント情報に関連する事前アンケートを依頼し、割り付け条件を満たす参加候補者を抽出するときに、事前アンケートの結果を用いることもできる。さらに、会場調査の終了後に、参加者に対して追加調査を依頼することもできる。これにより、分析精度が向上する。
【0018】
本発明はまた、上記の予約サーバに相当する構成要素と操作端末を含む予約システムや、上記の予約サーバが実行する処理に対応する各ステップを含む予約方法や、当該予約方法の各ステップを情報処理装置に実行させるプログラムとしても実現できる。
【発明の効果】
【0019】
本発明によれば、会場調査における予約を迅速かつ低コストに行うための技術を提供できる。
【発明を実施するための形態】
【0021】
以下に図面を参照しつつ、本発明の好適な実施の形態を説明する。ただし、以下に記載されている構成ブロックやそれらの相対配置などは、発明が適用されるシステムの各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。
【0022】
以下のフローでは、クライアントから依頼を受けるリサーチ会社と、当該リサーチ会社の保有するリストに登録されているモニタ候補者との間で予約処理が進められる。ただし、マーケティングを行う企業等が直接予約システムを運用管理してもよい。以降、予約システムを運用管理する立場の者を「管理者」と称する。また、それぞれの会場調査を「イベント」と称する。モニタのことを「参加者」、モニタ候補者のことを「参加候補者」とも称する。
【0023】
本発明は特に、管理者が設定したイベントについて、会場調査のモニタが自ら端末を操作して時間枠の予約を行うような予約システムに好適である。本発明はまた、このような予約システムに用いられる予約サーバとしても捉えられる。本発明はまた、情報処理装置の演算資源を利用して当該情報処理装置を予約サーバとして稼働させるような予約プログラムや、当該予約ブログラムを格納したコンピュータにより読み取り可能な記憶媒体としても捉えられる。
【0024】
<実施形態1>
本実施形態では、複数の時間枠がある会場調査の基本的な予約処理について説明する。
【0025】
(システム構成)
図1を参照しながらシステム構成について説明する。システムは、Web3を介して相互に通信可能な、端末装置1(1a,1b,…)および予約サーバ2と、予約サーバ2と通信可能なDBサーバ4によって構成される。端末装置1は、会場調査のモニタ候補者がそれぞれ操作可能な装置である。端末装置1は、情報処理機能、表示機能、通信機能などを有する。端末装置1としては例えば、プロセッサ、記憶装置、通信装置、ユーザインタフェース等を備える、PC、携帯電話、スマートフォンなどの情報処理装置が好適である。PCはデスクトップ型、ノート型、タブレット型など形式を問わない。端末装置1がWebサイトにアクセスして情報を送受信することで、モニタ候補者の予約システムへの参加が可能になる。端末装置1に表示されるWebサイトデータは、ユーザ入力(例えば検索サイトにおける検索結果からのリンクのクリック)に基づくHTTPリクエストで予約サーバ2に要求され、サーバからのレスポンスに基づいて表示される。
【0026】
予約サーバ2は、管理者が運用管理するサーバである。予約サーバ2は、通信手段21、CPU22、メモリ23、ディスプレイ24、DB制御手段25を備える。予約サーバ2は、各種の演算資源やユーザインタフェース等を備え、プログラムに従って動作するPCやワークステーションにより実現できる。DBサーバ4は、イベントDB45、モニタ候補者DB46、状況管理DB47など、後述する各種データベースを備える。データの入出力については、DBMS(データベース管理システム)などで構成されるDB制御手段25が行う。CPU22は、メモリ23に格納されたプログラムに従って情報処理を行うことで、本発明の処理手段として機能する。
【0027】
なお、サーバの構成やデータベースの配置は任意であり、図示したものに限定されない。例えば、クラウドサーバや仮想サーバを利用してもよいし、Webサーバ、アプリケーションサーバ、複数の物理的に離れた情報処理装置をオンライン接続して利用してもよい。
【0028】
(予約処理フロー)
フローチャートを参照しつつ、本実施形態の基本的な処理を説明する。
図2は、イベント設定から予約完了までのフローであり、
図2(a)は管理者側の、
図2(b)はモニタ候補者側の処理を示す。ステップS101において、
図4(a)に示すイベントDB45にイベント情報を設定する。具体的には、管理者が依頼者(クライアント)からの依頼に基づいて、マーケティングの目的に応じて会場調査の内容を決定し、予約システムの管理画面を用いて情報登録する。特に、モニタの属性に基づく割り付け条件と、会場等の制約に応じた時間枠の数および各枠の人数が決定される。
【0029】
ステップS102において、
図4(b)に示すモニタ候補者DB46から、割り付け条件を満たすモニタ候補者が抽出される。ここでは例えば、性別(男女それぞれ)、年代(10代、20代、30代)の2つの条件で、20人ずつモニタを集められるように、必要な数の候補者を抽出する。この例では候補者の居住地は問わないが、会場の所在地に応じ
た抽出が好ましい。所要モニタ人数は2×3×20=120人となるが、一度に10人ずつという会場の制約があるため、12個の時間枠が設定される。
【0030】
ステップS103で、抽出された候補者に対してイベントへの参加を依頼するメールが送られる。このとき、各割り付け条件を満たす候補者全てにメールしても良いし、必要な人数から一定割合だけ多い候補者にメールしてもよい。
【0031】
なお、予約システムからモニタ候補者や予約済みモニタに対する連絡には、ショートメッセージ、スマートフォン用アプリやタブレット用アプリのプッシュ通知、ソーシャルネットワーキングサービスのメッセージ機能など、任意の連絡手段を利用できる。またモニタ候補者や予約済みモニタから予約システム側への連絡手段としても、Webサイトの入力フォームなどだけではなく、メール等の任意の方法を利用できる。
【0032】
また、ステップS102〜S103のように管理者が特定したモニタ候補者に参加依頼をするのではなく、参加条件をWebサイトで公開し、その条件を見たモニタ候補者側から予約サイトにアクセスする仕組みでもよい。その場合でも、モニタ募集を開始したことを一斉メール等で周知することが好ましい。詳しくは後述するが、予備的アンケートを行う場合もある。
【0033】
図2(b)に移り、ステップS201において、モニタ候補者は予約サイトにアクセスし、
図6(a)に示すイベント一覧画面を用いて該当するイベントを選択し、イベント詳細画面に移る。アクセス時には、モニタのユーザ名とパスワードを用いたログイン処理によりセキュリティを確保することが好ましい。ステップS202において、モニタ候補者は
図6(b)に示すイベント詳細画面を確認し、諸条件を勘案して参加を希望するかどうかを決定し、時間枠の予約を行う。希望の時間枠に空きがあれば、ステップS203に進んで予約送信する。一方空きが無い場合は、ステップS204に進んでキャンセル待ち登録をする。なお、イベント参加を希望しない場合は特に操作はない。予約サーバ2の通信手段21は送信された情報を受け付ける。
【0034】
なお、予約サーバ2は、モニタ候補者の属性と、各割り付け条件の充足の程度に応じて、ステップS202で表示されるイベント詳細画面を変える。例えばモニタ候補者が「男性、30代」であり、その割り付けの必要人数が既に満たされている場合、GUI(ボタン)をクリック不能にしたり、予約ボタンの代わりにキャンセル待ちボタンを表示したりといった方法で、予約を不可能にする。一方、「女性、20代」という割り付けが必要人数に達していなければ、そのような属性を持つモニタ候補者に対しては予約を可能にする。ただし、所定の人数が埋まった時間枠についてはキャンセル待ち表示とする。
【0035】
なお、各モニタ候補者は必ずしも、イベントの割り付け条件や、自分がどの割り付けに属しているかということや、各割り付けの充足状況を知る必要はない。イベント詳細画面から予約可能またはキャンセル待ち可能な時間枠を探し、候補者自身のスケジュールに応じて好みの枠を選択すれば良い。またキャンセル待ちには、割り付け条件が埋まったことによるキャンセル待ちと、時間枠が埋まったことによるキャンセル待ちがあり、前者の場合は何れの時間枠も予約不可能である。しかしモニタ候補者は、時間枠の予約状況や割り付けの充足状況を知る必要はない。その裏で予約サーバ2は、各割り付けが満たされているかという観点と、各時間枠が満たされているかという観点から表示制御を行っている。また、各時間枠内におけるモニタ候補者の割り付けの配分は特に限定されない。言い換えると、全ての時間枠における参加者を合計した中で、割り付け条件が満たされていれば良い。
【0036】
図2(a)に戻り、ステップS104において、モニタ候補者から受け付けた送信内容
に基づいて、
図5(a)、
図5(b)に示す状況管理DB47を更新する。これによりモニタ候補者が、予約済みモニタ、またはキャンセル待ちモニタとして、状況管理DBの該当する時間枠に登録される。また、割り付けの充足状況も更新される。なお、所定の募集期間内に所望の割り付け条件および時間枠を満たすだけの予約が行われなかった場合は、ステップS102に戻って再募集をかけても良い。
【0037】
以上のフローにより、日程および時間枠が設定され、かつ割り付け条件を満たすようなモニタを集める必要がある会場調査において、モニタ候補者が自らWebを経由して時間枠を予約する。このとき予約サーバが各割り付け条件の充足状況を判断するため、時間枠および割り付け条件を満たすような自動予約処理が実現される。その結果、管理者が電話によるモニタ募集を行う必要がなくなり、コスト低減と時間短縮が可能になる。
【0038】
(キャンセル対応フロー)
図3を参照して、予約システムをキャンセル対応に利用する場合の処理フローを説明する。
図3(a)は管理者側、
図3(b)はモニタ候補者側の処理を表す。ステップS111では、予約サーバが、予約済みのモニタからのキャンセル処理を受け付ける。キャンセル処理は、イベント一覧画面やイベント詳細画面におけるボタン等により実行できる。予約済みモニタは、予約完了後、キャンセル可能な時期の間は随時マイページにログインしてキャンセル処理を実行できる。また、調査直前に管理者が参加確認する場合は、そのタイミングでキャンセルされる場合もある。
【0039】
ステップS112において、予約サーバ2は状況管理DB47を参照し、キャンセルした予約済みモニタと同じ割り付けに属し、キャンセル待ちリストに登録しているモニタ候補者を抽出する。続くステップS113で、抽出された候補者に対してイベントへの参加を依頼するメールが送られる。メールを送る対象は、キャンセル待ちリストの先着順でも良いし、複数の候補者に送っても良い。なお、キャンセルした予約済みモニタと同じ割り付け条件を満たすキャンセル待ちの候補者がいない場合は、改めてモニタ候補者DB46から抽出処理が行われる。
【0040】
図3(b)に移り、キャンセル待ち登録済みのモニタ候補者は、ステップS211において予約サイトにアクセスして当該イベントを選択する。続いてステップS212で参加可能と判断すれば、ステップS213でGUIのボタン等で予約処理を行う。なお本フローでは、キャンセル待ち登録後にモニタ候補者の予定が変わった場合を考えてS211〜S213の処理を行う。しかし、キャンセル待ち登録している候補者を自動的に予約者として追加し、候補者にはその旨を通知する構成でもよい。
図3(a)に戻り、ステップS114で全ての時間枠や割り付け条件が満たされているかどうかを判断し、必要に応じて参加依頼を続ける。
【0041】
以上のフローにより、予約済みモニタがキャンセルを行った場合にも、キャンセル待ちリストに基づいて自動的に参加要請が行われる。モニタ候補者は自ら予約サイトにアクセスして予約処理を行うので、コスト低減と時間短縮が可能になる。ただし、キャンセル待ち処理を予約システムで行わず、電話などを用いた手法によっても構わない。
【0042】
(データ構造)
図4、
図5に、本実施形態で主に利用されるデータベースのデータ構造を例示する。イベントDB45、モニタ候補者DB46、状況管理DB47、その他本発明で利用されるデータベースは、ハードディスクやフラッシュメモリ等の記憶媒体を備え、情報処理装置により読み書きが可能な記憶装置に格納される。データベースには関係型、階層型など任意の方式を利用できる。またDBサーバ4はオンラインまたはオフライン接続された複数の装置で構成されてもよい。なお、以下に示すデータ定義やデータベース構造は一例に過
ぎず、データベースの分け方、項目、参照関係などは、条件に応じて任意に定められる。また「データベース」という名称に捕らわれることなく、本発明の実施に必要なデータを更新可能に保持していればよい。
【0043】
図4(a)に示すイベントDB45には、会場調査ごとに情報が登録される、イベントに関するマスタDBである。イベントDB45は、例えば符号401のようなテーブルを保持する。依頼者(クライアント)のマーケティングの目的に応じてイベントDBの各エントリーが設定される。この例では、イベントごとに割り振られるイベントID、依頼者、イベント名、割り付け条件、開催場所、時間枠数/枠ごとの人数、各時間枠の開催日時という項目が設定されている。他に、イベントの詳細情報、モニタのインセンティブなど、イベントに設定される固定的な諸条件を設定してもよい。
【0044】
本発明の予約システムは、リサーチ会社のオペレータが上記の情報を登録するためのGUI等の操作手段を提供する。オペレータは管理者権限で予約システムにログインし、依頼者の目的に応じた条件でエントリーを作成する。依頼者からの要求やモニタ募集の進行状況に応じて、動的に割り付け条件や時間枠を変更できるようにしてもよい。
【0045】
図4(b)に示すモニタ候補者DB46は、各候補者の属性に関するマスタDBである。モニタ候補者DB46は、例えば符号402のようなテーブルを保持する。モニタ候補者DB46としては、リサーチ会社が保有する候補者リストが使用される。また、Webを通じた公募、街頭での勧誘、人的つながりを通じた方法でモニタ候補者を集めてもよい。
図4(b)の例では、各エントリーには、モニタ候補者ID、氏名、性別、年代、未既婚の別、居住地、職業、および、連絡先(ここではメールアドレス)が含まれる。他に例えば、収入、家族構成、ペットの有無、保有している商品や購入意向のある商品の情報、学歴、趣味、嗜好、メール以外の連絡先(例えば電話番号)など、様々な内容を含み得る。
【0046】
予約システムは、モニタ候補者自らが端末装置1を用いて上記の情報を登録するためのGUI等の操作手段を提供することが好ましい。モニタ候補者がWebサイト等を経由して属性を入力することにより、リサーチ会社側のコストが低減される。また、予約サーバ2がWebサーバとして機能して、各モニタ候補者の端末装置1に「マイページ」を提供する。マイページでは、上記の属性入力・編集のほか、募集中の会場調査(イベント)の表示、イベント予約やキャンセル待ち登録などが可能である。また、リサーチ会社の業務として会場調査以外にWebアンケートがある場合、Webアンケートへの回答と、会場調査の受付をシームレスに実施できる。
【0047】
図5に示す状況管理DB47は、イベントが終了するまでの間、モニタや時間枠の充足状況などを格納するデータベースであり、オペレータやモニタ候補者の操作に応じて動的に変更される。
図5(a)は割り付け条件ごとの状況を管理するためのテーブル501である。
図5(b)は時間枠ごとの状況を管理するためのテーブル502である。管理者であるリサーチ会社のオペレータが管理者用の画面を操作してイベントDB45に新規イベントを登録し、割り付け条件や人数を設定することで、イベントIDをキーとして状況管理DB47にもエントリーが作成される。
【0048】
予約サーバ2は、このDBを参照して端末装置1に表示される画面を変更する。例えば予約可能な時間枠にはGUIとして予約ボタンを表示し、既に埋まっている時間枠にはキャンセル待ちボタンを表示する。そして、モニタ候補者の画面上での操作に応じてDBを更新する。本実施形態では、各割り付けと各時間枠における充足状況およびキャンセル待ち状況が更新される。
【0049】
(操作画面)
図6に、端末装置1の表示画面に表示される操作画面を例示する。
図6(a)は、モニタ候補者に提示されるイベント一覧画面である。イベント一覧画面601には、予約可能またはキャンセル待ち登録が可能な時間枠が存在するイベントを表示するための、予約可能イベント欄6011と、予約またはキャンセル待ちを済ませたイベントを表示するための、予約済みイベント欄6012が存在する。また詳しくは後述するが、出席確定イベント欄6013も存在する。
【0050】
図6(b)は、予約可能イベント欄6011から一つのイベントを選択したときの遷移先である、イベント詳細画面602を示す。画面中、イベント情報欄6021にはイベントの詳しい情報が、時間枠表示欄6022には、各時間枠の予約可否に関する情報と、予約またはキャンセル待ちのためのGUI(ボタン)が表示されている。
【0051】
以上述べたように、本実施形態の予約システムによれば、会場調査において割り付け条件と時間枠に関する条件を満たした予約が、予約サーバによって表示されるWebサイトを経由して、モニタ候補者自らによって行われる。モニタ候補者は、自らの都合の良い時間に予約処理を行える。その結果、電話による処理が不要となり、コスト低減、準備期間短縮、不公平感の低減などの効果が得られる。
【0052】
(変形例1)
上記フローでは、モニタ候補者は希望の時間枠を選択してキャンセル待ち登録していた。しかし、時間枠を設定させずに、単純にキャンセル待ちをする旨だけを登録させても良い。この場合、モニタ候補者がキャンセルされた時間枠に参加できるかどうか不明であり、参加できない場合は他の候補者に当たる必要があり、二度手間になるおそれがある。一方で、管理者にとってはキャンセル待ちリストの管理やキャンセル時の処理が簡易になる。また、複数のキャンセル待ち登録者に同時に参加依頼することで、空きの出た時間枠を早く埋めることが可能になる。
【0053】
(変形例2)
また、モニタ候補者がキャンセル待ち登録するときに、複数の時間枠の設定や、NGの時間枠の設定を可能にしても良い。
【0054】
(変形例3)
上記フローでは、各時間枠内での割り付けの配分は特に限定せず、全てのモニタの中で割り付け条件が満たされるようにしていた。しかし、各時間枠の中で、ある程度モニタの属性を設定したい場合もあり得る。例えばディスカッション形式の会場調査で、同質の属性のモニタばかりが集まると意見が固定化されるような場合である。そこで予約サーバ2は、各時間枠で既に予約を済ませているモニタの属性に基づいて、後から予約をしようとするモニタ候補者の操作端末に表示される画面における、予約が可能か否かの表示を変更してもよい。
【0055】
<実施形態2>
本実施形態では、基本的な予約処理に加えて、予約済みモニタの出席確認をシステム化する例を述べる。本実施形態の予約システムの全体構成や基本的な処理フローは実施形態1と同じであるため、以下では相違点や追加点を中心に説明する。
【0056】
図7は、予約済みモニタへの参加確認のフローであり、
図7(a)は管理者側の、
図7(b)は予約済みモニタ側の処理を示す。イベント開催日から所定の期間前(例えばイベント3日前)になったら、ステップS121において、予約サーバ2から参加確認メールが送信される。
図7(b)に移り、ステップS221において予約済みモニタは予約サイ
トにアクセスし、
図6(a)の予約済みイベント欄6012から当該イベントを選択する。そしてステップS222で予約済みイベントの時間枠に参加するか否かの最終判断を行い、予約確認した旨を送信する(ステップS223)か、キャンセルする旨を送信する(ステップS224)。
【0057】
図7(a)に戻り、予約サーバ2は、ステップS122において状況管理DBを更新する。続いてステップS123において、時間枠や割り付けが満たされているかどうかを判断する。もし予約済みモニタがキャンセルを行っていなければ「S123=NO」となるので、ステップS124に進み、
図3のフローで説明したようなキャンセル時の対応を行う。一方、予約確認が送信された場合は確定処理が行われ、当該イベントは
図6(a)の出席確定イベント欄6013に表示されるようになる。
【0058】
以上述べたように、本実施形態では、会場調査が開催される直前の電話確認をシステム化し、予約済みモニタは自らWebサイトを経由して最終的な意志確認(参加確定またはキャンセル)を行う。そして、キャンセルがあった場合は自動的にキャンセル時対応がなされる。その結果、電話による処理が不要となり、コスト低減効果が得られる。
【0059】
<実施形態3>
本実施形態では、基本的な予約処理に先立って、モニタの予備的な抽出を行う例を述べる。リサーチ会社が保有するモニタ候補者DB46には様々な属性情報が格納されているが、マーケティングの目的や会場調査の内容によっては、既登録情報では不十分な場合がある。そこで予め必要な情報を取得してからモニタ候補者を抽出することで、より詳細な調査が可能になる。予約サーバ2は、このような事前情報取得のために、例えば
図2のステップS102の前に、モニタ候補者DB46に載っているモニタ全員にメールを送付して事前アンケートを依頼する。リサーチ会社がWebアンケート業務を行っている場合は、かかる事前アンケートを容易に実施できる。
【0060】
以上述べたように、本実施形態によれば、調査目的に応じた適切な属性を持つモニタ候補者を抽出できる。さらに、事前アンケートで得られた情報をモニタ候補者DBに追加することも好ましい。また事前アンケートにインセンティブを付与することで、モニタ候補者の満足感も高まる。
【0061】
<実施形態4>
本実施形態では、基本的な予約処理に加えて、会場調査終了後に追加的な調査を行う例について述べる。会場調査の結果に対して、依頼者がさらに詳しい分析を希望する場合がある。その場合、予約システムからモニタに対してメール等を送ってWebによる事後アンケートを依頼したり、個別インタビューや電話インタビューを依頼したりできる。本実施形態によれば、会場調査で得られた知見をさらに深く掘り下げることで、より精度の高いマーケティングが可能になる。
【0062】
<実施形態5>
以上の各実施形態では、会場調査の予約システムについて説明したが、本発明は他の予約システムにも適用可能である。すなわち、管理者の側で所望の割り付けが設定され、さらに時間枠の制約があるイベントであって、イベント参加者が自ら予約を行い得るようなイベントであれば、本発明を適用できる。このようなイベントとして例えば、就職説明会や採用面接の予約システムがある。就職説明会においては会場の制約から時間枠を設ける必要がある。また、最終的な採用者のバランスを取ったり、グループ討論を円滑に進めたりするために、全参加者の合計において、地域や性別などの割り付け条件を設定する場合がある。かかる就職説明会に本発明を適用することで、企業等の採用活動を低コスト化できる。
【0063】
また本発明は、オンラインゲームまたはオフラインゲームの大会の参加予約システムにも適用できる。オンラインゲームにおいては仕様上の問題やゲーム性の観点から同時に参加できる人数が限られる。またオフラインゲームにおいては会場の制約に起因する人数制限がある。さらに、ゲームへの習熟度もしくは技量、または、管理者への寄与度もしくは支払金額に応じて、割り付け条件が設定される場合がある。本発明によれば、かかる参加予約システムを低コストかつ短時間で運営できる。
【0064】
本発明は、上記処理の少なくとも一部を含む方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記構成要素および処理の各々は可能な限り互いに組み合わせて使用できる。例えば上記各実施形態の一部処理を、電話等を用いた処理で代替してもよい。例えば管理者側の参加確認処理、キャンセル対応処理、事前アンケート、事後アンケートなどを電話で行ったり、モニタ候補者の予約処理や予約済みモニタのキャンセル処理を電話で行ったりしてもよい。
【解決手段】参加者の数が設定された複数の時間枠と、参加者の属性に基づく割り付け条件が設定されたイベントの予約サーバであって、処理手段と、参加候補者の端末装置と通信を行う通信手段と、参加候補者の属性情報を格納する参加候補者DB、イベント情報を格納するイベントDBおよび各時間枠の予約状況と割り付け条件の充足状況を含むイベントの状況を管理する状況管理DBを制御するDB制御手段を有し、通信手段は参加候補者に参加依頼を行い、処理手段は参加候補者の端末装置に各時間枠が予約可能であるかどうかを属性情報、予約状況および充足状況に基づいて表示させ、DB制御手段は参加候補者による予約処理を受けて、予約済み参加者として登録する予約サーバを用いる。