JP2019040500A - 予約支援方法およびプログラム - Google Patents

Abstract

【課題】ユーザにとって手軽に利用でき、且つ、店舗側にとっても効果的な予約受付を実施できる予約支援方法を提供すること。【解決手段】一実施形態によれば、ユーザに関し、複数のパラメータに対応する値を決定するステップと、ユーザのサービス利用履歴に基づいて、複数のパラメータの優先順位を決定するステップと、予約情報を参照して、パラメータの優先順位および対応する値に基づいて、１つ以上の利用可能なサービス候補情報を特定するステップと、サービス候補情報をユーザに提示するステップと、ユーザによるサービス候補情報の内１つの選択に応じて、予約情報を更新するステップと、を含む。【選択図】図７

Description

本開示は、サービスの予約支援方法およびプログラムに関する。

ユーザが端末を用いて各種サービスをオンラインで予約する予約支援システムが知られる。このようなシステム（特に予約サイト）では、例えば、ユーザは候補サービスや候補日時の提示を受けるために、予約フォームに対しユーザが必要事項の全てを入力し、また、ユーザが希望する項目を纏めて指定する必要がある（例えば、特許文献１参照）。他のシステムでは、ユーザが希望する項目を指定する都度、該当する候補サービスや候補日時のリストを提示し、ユーザはリストを参照しながら入力により所望のサービスや候補日時を絞り込んでいく必要がある（例えば、特許文献２参照）。このように、従来技術のオンラインの予約サイトでは、予約フォームに対し、ユーザによる希望条件の都度入力を伴うものである。

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

ユーザにとって、予約サイトでの予約フォームへの希望条件の都度入力は、手間と時間が掛かるため面倒な作業となる。また、予約を受け付ける側（店舗）にとっても、ユーザからの予約に対し、中途半端な空き時間枠を生じさせる等、望まない時間枠が埋められてしまうことがあり効果的ではない。このような状況では、電話オペレータによる対応を導入せざるを得ず、ユーザにとって営業時間や通話場所の制約も多く、また、電話オペレータの対応負担の点でもあまり効果的とは言えない。

本開示は、上記課題の少なくとも一部を解決するために、ユーザにとって手軽に利用でき、且つ、店舗側にとっても効果的な予約受付を実施できる予約支援方法およびプログラムを提供することを目的とする。特に、ユーザ利用履歴に応じて推奨サービスを動的に最適化すると共に、店舗稼働率を最適化して効果的なリソース活用を実現するサービスの予約支援方法およびプログラムを提供することを目的とする。

本開示の一実施形態によれば、コンピュータによって実装されるサービスの予約支援方法が提供される。かかる方法は、ユーザに関し、複数のパラメータに対応する値を決定するステップと、ユーザのサービス利用履歴に基づいて、複数のパラメータの優先順位を決定するステップと、予約情報を参照して、パラメータの優先順位および対応する値に基づいて、１つ以上の利用可能なサービス候補情報を特定するステップと、サービス候補情報をユーザに提示するステップと、ユーザによるサービス候補情報の内１つの選択に応じて、予約情報を更新するステップと、を含む。

情報処理システムの基本構成図である。 サーバの例示のハードウェア構成図である。 ユーザ端末の例示のハードウェア構成図である。 サーバおよびユーザ端末の例示の機能ブロック図である。 サーバに格納される例示の情報項目である。 一実施形態によるサービス予約支援方法の処理フロー図である。 ユーザ端末に提供されるアプリケーションの例示の画面イメージである。 一実施形態によるサービス予約支援方法の処理フロー図である。 一実施形態によるサービス予約支援方法の処理フロー図である。 一実施形態によるサービス予約支援方法におけるサービス候補の特定に関する概念図である。

最初に、本開示の例示的な実施形態の構成を列記して説明する。本開示の実施形態による、サービスの予約支援方法およびプログラムは、以下のような構成を備えてもよい。

〔形態１〕形態１によれば、コンピュータによって実装されるサービスの予約支援方法が提供される。かかる方法は、ユーザに関し、複数のパラメータに対応する値を決定するステップと、ユーザのサービス利用履歴に基づいて、複数のパラメータの優先順位を決定するステップと、予約情報を参照して、パラメータの優先順位および対応する値に基づいて、１つ以上の利用可能なサービス候補情報を特定するステップと、サービス候補情報をユーザに提示するステップと、ユーザによるサービス候補情報の内１つの選択に応じて、予約情報を更新するステップと、を含む。

〔形態２〕形態２によれば、形態１の方法において、利用可能なサービス候補情報が更に、サービスを提供する店舗の稼働状況に基づく。

〔形態３〕形態３によれば、形態２の方法であって、更に、サービス利用履歴および／または店舗の稼働状況に基づいて、１つ以上の利用可能なサービス候補情報の順位を決定するステップを含み、上記順位にしたがって１つ以上のサービス候補情報が提示される。

〔形態４〕形態４によれば、サービス候補情報を特定するステップにおいて、複数のパラメータの内１つのパラメータの第１値に関連付けられる第２値を抽出し、第２値に関して利用可能なサービス候補情報が特定される。

〔形態５〕形態５によれば、形態１から４の何れかの方法において、上記パラメータが、店舗を特定するための店舗情報を少なくとも含み、複数の店舗情報の値が位置情報に基づいて関連付けられる。

〔形態６〕形態６によれば、形態１から５の何れかの方法において、優先順位が、ユーザによって指定可能とする。

〔形態７〕形態７によれば、形態１から６の何れかの方法において、サービス候補情報が、サービス候補情報に関連付けられる特典情報と共に提示される。

〔形態８〕形態８によれば、形態１から７の何れかの方法であって、更に、ユーザのサービス利用履歴に基づいて、サービス利用を促す予約催促メッセージをユーザに通知するステップを含む。

〔形態９〕形態９によれば、形態１から８の何れかの方法であって、更に、選択された１つのサービス候補情報に含まれるサービス利用日に基づいて、ユーザの予約情報に基づく予約リマインド・メッセージをユーザに通知するステップを含む。

〔形態１０〕形態１０によれば、形態１から９の何れかの方法において、ユーザが、トークルームにおけるチャットを通じて、コンピュータによって実装される仮想ユーザとの間で相互作用する。

〔形態１１〕形態１１によれば、形態１から１０の何れの方法をコンピュータに実施させるためのプログラムが提供される。

以下に、本開示に係るサービスの予約支援方法およびプログラムの実施形態を添付図面とともに説明する。添付図面において、同一または類似の要素には同一または類似の参照符号が付され、各実施形態の説明において同一または類似の要素に関する重複する説明は省略することがある。また、各実施形態で示される特徴は、互いに矛盾しない限り他の実施形態にも適用可能である。

図１は、情報処理システム１０００の全体概要図である。情報処理システム１０００は、サーバ１００と、複数のユーザ端末２００，３００と、を備える。サーバ１００は、ネットワーク４００を介してユーザ端末２００，３００に接続される。説明を簡単にするために、図１ではユーザ端末を２台だけ示しているが、これに限定されず、３台以上としてもよい。また、ユーザ端末２００，３００の具体的な機器は、図示したパーソナルコンピュータおよびスマートフォンに限定されず、これ以外にも、例えば、フィーチャーフォン、ＰＤＡ(Personal Digital Assistant)、またはタブレット端末等の電子機器としてもよい。

以下では、これに限定されないが、ユーザ端末２００は、主に、サービス提供側の担当者ユーザ（以下、「担当者」という。）が用いる端末を、また、ユーザ端末３００は、主に、サービス利用側のユーザ（以下、「一般ユーザ」という。）が用いる端末を想定する。例えば、ユーザ端末２００は、担当者が自身のスケジュールを登録する等、店舗管理のために使用される。また、ユーザ端末３００は、一般ユーザがサービスの予約を行うために使用される。

また、一般ユーザが予約して利用するサービスは、例示的に、担当者、店舗（設備）、および時間に関連付けられる個人フィットネス（パーソナル・トレーニング）サービスを想定するが、やはりこれに限定されない。他にも、各種レッスン・サービス、施設利用サービス、家事代行サービス、ベビーシッター・サービス、クラウドソーシング・サービス等、担当者、店舗（設備）、および時間の何れか１つ以上に関して予約およびマッチングを必要とするサービスが広範に想定される。

ユーザ端末３００には、インスタント・メッセージング（ＩＭ）サービス用のアプリケーションがインストールされ、一般ユーザによって利用される。当該アプリケーションでは自ユーザと相手ユーザとの間でアカウントを連携、リンクさせる（「友達」になる）ことにより、専用の仮想空間（「トークルーム」）を介して、メッセージング（特にチャット）をすることができる。他にも、ＳＮＳ（Social Networking Service）またはブログ（Blog）等、複数のユーザのアカウント間を連携させて、アカウント間でメッセージング（メッセージ・データの送受信）を行うことができる任意のアプリケーションやＷｅｂサービスが利用可能である。

図２および図３を参照して、サーバ１００およびユーザ端末２００，３００のハードウェア構成の概要について説明する。図２に示されるサーバ１００は、アプリケーションを通じてサービスを提供するための情報処理装置であり、例えばワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。サーバ１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信インタフェース（ＩＦ）１３、および入出力部１４等を備え、これらはバス１５を通じて相互に電気的に接続される。

プロセッサ１０は、サーバ１００全体の動作を制御し、各要素間におけるデータの送受信の制御、およびアプリケーションの実行に必要な情報処理等を行う演算装置である。例えばプロセッサ１０はＣＰＵ(Central Processing Unit)であり、ストレージ１２に格納されメモリ１１に展開されたプログラム等を実行して各情報処理を実施する。

メモリ１１は、ＤＲＡＭ(Dynamic Random Access Memory)等の揮発性記憶装置で構成される主記憶と、フラッシュメモリやＨＤＤ(Hard Disc Drive)等の不揮発性記憶装置で構成される補助記憶と、を含む。メモリ１１は、プロセッサ１０のワークエリア等として使用され、また、サーバ１００の起動時に実行されるＢＩＯＳ(Basic Input / Output System)、および各種設定情報等を格納する。ストレージ１２は、アプリケーション・プログラム、およびユーザの認証プログラム等の各種プログラムを格納する。アプリケーションの各処理に用いられるデータを格納したデータベースがストレージ１２に構築されていてもよい。

通信インタフェース１３は、サーバ１００をネットワーク４００に接続し、ユーザ端末２００，３００との通信を行う。入出力部１４は、マウスやキーボード等の情報入力機器、およびディスプレイ等の出力機器である。バス１５は、上記各要素に共通に接続され、例えば、アドレス信号、データ信号および各種制御信号を伝達する。

図３に示されるユーザ端末２００（３００）の例は、主に、タッチパネルを有するスマートフォン（３００）を想定している。ユーザ端末２００（３００）は、プロセッサ２０、メモリ２１、ストレージ２２、通信インタフェース２３、撮像部２４、タッチパネル２５、および検知部２６等を備え、バス２９を介して相互に電気的に接続される。

プロセッサ２０は、ユーザ端末２００（３００）の動作を制御し、各要素間におけるデータの送受信の制御、およびプリケーションの実行に必要な処理等を行う演算装置である。例えばプロセッサ２０はＣＰＵおよび／またはＧＰＵ(Graphical Processing Unit)等であり、ストレージ２２に格納され、メモリ２１に展開されたプログラム等を実行することによって必要な各情報処理を実施する。

メモリ２１は、ＲＡＭなどの揮発性記憶装置で構成される主記憶と、フラッシュメモリやＨＤＤ等の不揮発性記憶装置で構成される補助記憶と、を含む。メモリ２１はプロセッサ２０のワークエリア等として使用され、また、ユーザ端末２００（３００）の起動時に実行されるＢＩＯＳ、および各種設定情報等が格納される。ストレージ２２には、アプリケーション・プログラム等が格納される。アプリケーション・プログラムは通信インタフェース２３を通じてダウンロードにより格納することができる。

通信インタフェース２３は、ユーザ端末２００（３００）をネットワーク４００に接続し、サーバ１００と通信を行う。また、通信インタフェース２３には、Ｂｌｕｅｔｏｏｔｈ（登録商標）およびＢＬＥ(Bluetooth Low Energy)の近距離通信インタフェースも含まれる。撮像部２４は、カメラ機能を有し、ユーザによって撮像された画像をストレージ２２に格納する。

タッチパネル２５は、入力部２５１および表示部２５２を構成する。タッチパネルの入力部２５１は、ユーザによるタッチパネル２５への操作があったことを検知する。入力部２５１は、圧力検出方式、抵抗膜方式、静電容量方式、または電磁誘導方式等を採用することができる。そして、タッチパネル上の任意の位置で操作（タッチパネルに対する、タッチ操作、スライド動作、スワイプ操作、及びタップ操作等の物理的接触操作）による入力を受けると、その位置における押圧、電気抵抗、電気容量、または弾性波のエネルギー等の変化量が検知され、対応する接触位置座標が特定される。タッチパネルの表示部２５２は通常、液晶ディスプレイ等で構成される。

検知部２６は、内蔵型センサとして、これに限定されないが、加速度センサ、振動センサ、ジャイロセンサ、地磁気センサ、近接センサ、照度センサ、圧力センサ、およびＧＰＳ等を含み、一例としては、ユーザの歩数、移動距離および行動範囲等を含む活動情報を測定する活動量計として機能する。また、活動情報は、外部のウェアラブル・デバイス（非図示）と連携して、通信インタフェース２３を通じて受け取ってもよい。外部のウェアラブル・デバイスを使用することにより、ＥＣＧ（ｅｌｅｃｔｒｏｃａｒｄｉｏｇｒａｍ）センサや筋電センサのようなより詳細な生体情報を取得可能である。これ以外にも気象センサ等からの各種データも取得可能としてもよい。バス２９は、上記の各要素に共通に接続され、例えば、アドレス信号、データ信号、および各種制御信号を伝達する。

図４を参照して情報処理システム１０００の機能構成について説明する。図４は、サーバ１００、およびユーザ端末２００（３００）にそれぞれ実装される機能を中心に示した例示のブロック図である。サーバ１００は、通信部１１０、提案部１３０、予約部１５０、アプリケーション部１７０および記憶部１９０を含み、相互に作用する。提案部１３０は、更に、パラメータ決定部１３２、サービス候補特定部１３４、および提示部１３６を含む。予約部１５０は、更に、予約情報更新部１５２および決済部１５４を含む。記憶部１９０は、更に、一般ユーザ関連情報１９２、サービス事業者関連情報１９４、予約関連情報１９６、およびアプリケーション関連情報１９６を含む。

ユーザ端末２００（３００）は、通信部２１０、記憶部２２０、入力部２４０、出力部２５０、およびアプリケーション部２７０を含み、相互に作用する。ＩＭサービスを通じて、ユーザのアカウント間でメッセージングを行うＩＭアプリケーションがアプリケーション部２７０としてユーザ端末２００（３００）にインストールされる。複数のユーザ端末２００（３００）間では、各通信部２１０がネットワーク４００を介してサーバ１００の通信部１１０およびアプリケーション部１７０と連携し、メッセージングに係るデータの送受信を行う。

ＩＭサービスを利用するユーザにとって、メッセージングの相手は、サーバ１００のアプリケーション部１７０に実装される、ｂｏｔと称されることもある仮想ユーザでもよい。例えば、ユーザがメッセージを送信すると、仮想ユーザがメッセージ内容に応じて自動返信を行うことができ、または、ユーザに対して、適切なタイミングで仮想ユーザからメッセージを送信することができる。一実施形態では、ユーザは、ＩＭサービスで提供されるトークルーム内のメッセージングによって、アプリケーション部２７０に実装される仮想ユーザとの間で相互作用する。

仮想ユーザは、コンピュータ・プログラムによって実装される。コンピュータ・プログラムは、メッセージ内容の構文解析、自然言語処理、および画像解析等の人工知能に関する情報処理技術に関するプログラム等が含まれる。ユーザと仮想ユーザ間で共有されるトークルームにエージェントを常駐させることにより、エキスパート・システムによる自動応答が可能となる。エージェントは更に、人工知能（ＡＩ）エンジンを搭載して、これまでのメッセージングをはじめとした様々なユーザ関連の情報を自律的に学習することにより、よりダイナミック且つインタラクティブなメッセージングを可能とする。

図５を参照してサーバ１００の記憶部１９０に格納される各種情報の詳細について説明する。サービス予約に関する各種データの一例として、一般ユーザ情報１９２、サービス事業者情報１９４、および予約関連情報１９６の構成例が示される。一般ユーザ情報１９２は、アカウント情報１９２ａ、ユーザ情報１９２ｂ、およびサービス利用履歴情報１９２ｃを含む。サービス事業者情報１９４は、サービス情報１９４ａ、担当者情報１９４ｂ、担当者予定情報１９４ｃ、および店舗情報１９４ｄを含む。予約関連情報１９６は、予約情報１９６ａおよび特典情報１９６ｂを含む。これらの情報は、記憶部１９０において、例えばテーブル形式で、データベースにてレコードが管理されるのがよい。図５に示した情報以外にも、上述したＩＭサービスを提供するためのアプリケーション関連情報をはじめとした情報および／またはプログラムも記憶部１９０に含まれる。

アカウント情報１９２ａは、アプリケーションを利用する際のユーザのアカウント情報を管理するものである。具体的には、一般ユーザおよび担当者等の各ユーザを一意に特定するユーザＩＤ、ログイン用のＩＤおよびパスワード、並びにユーザのニックネーム等が含まれ、ユーザのサービス登録時にレコードが追加される。ユーザ情報１９２ｂは、ユーザＩＤが割り当てられたユーザに関する情報を管理するものである。具体的には、ユーザの性別や年齢等の属性、メールアドレスや電話番号やＩＭアプリケーションのアカウント等の連絡先、住所、勤務先住所、無料会員や有料会員を区別する会員種別、およびユーザのアイコン画像等が含まれ、サービス登録時にレコードが追加される。ユーザ情報１９２ｂには、他にも、サービス登録時の初期サーベイを通じて、ユーザの趣味や好みのような嗜好情報が含まれてもよい。サービス利用履歴情報１９２ｃは、一般ユーザによるサービス利用履歴を管理するためのものである。具体的には、ユーザＩＤに対し、利用日時、店舗ＩＤ、コースＩＤ、および担当者ＩＤ等が含まれ、ユーザによってサービスが利用される毎にレコードが追加される。

サービス情報１９４ａは、一般ユーザに提供可能なサービスを管理するためのものである。具体的には、サービスのコースを一意に特定するコースＩＤ、並びにコースＩＤに対する占有時間枠およびコース詳細情報（料金等）等が含まれ、サービス運営者によってレコードが追加および更新される。担当者情報１９４ｂは、サービス提供時に実際に担当する担当者を管理するためのものである。具体的には、担当者を一意に特定するユーザＩＤ（担当者ＩＤ）、連絡先（ＩＭアプリケーションのアカウント）、所属している店舗ＩＤ、対応可能なサービスのコースＩＤ、および対応可能なエリアＩＤ等が含まれる。担当者情報１９４ｂは、担当者が登録されるときに、ユーザ情報１９２ｂと共にレコードが登録および更新される。

担当者予定情報１９４ｃには、担当者の出勤スケジュールを管理するものである。具体的には、出勤日、出勤時刻、および退勤時刻等が含まれる。担当者がユーザ端末２００を用いてアプリケーションから自分のスケジュールを定期的に登録／修正することによりレコードが追加／更新される。店舗情報１９４ｄは、各サービス店舗を管理するためのものである。具体的には、サービス店舗を一意に特定するための店舗ＩＤ、所在地の住所、複数の店舗ＩＤを関連付けるエリアＩＤ、営業時間（開始時刻／終了時刻）、部屋や設備を一意に特定する部屋／設備ＩＤ、および店舗毎に設定可能な基準時間枠（ＴＳ）等を含む。店舗情報１９４ｄは、サービス店舗が追加されるときに、サービス運営者によってレコードが追加および更新される。

以下に、サービス提供者情報１９４に関する一例を示す。例えば、サービス情報１９４ａとして「筋トレ ４５分」に対応するＩＤがコースＩＤとして割り当てられる。占有時間枠は４５分である。「筋トレ ４５分」の他にも、「３０分」「６０分」「４５分」「９０分」のような１５分刻みの「筋トレ」が各サービスとして設定されている。これに対応するように、店舗情報１９４ｄにおける基準時間枠（ＴＳ）として「１５分」がセットされている。「筋トレ ４５分」のコースＩＤに対し、担当可能な担当者情報１９４ｂとして「佐藤太郎」をはじめ複数の担当者（トレーナー）が、店舗およびエリアと共に関連付けられている。また、担当者「佐藤太郎」は、担当者予定情報１９４ｃとして、「１１月２０日１０：００〜１９：００」のような個人スケジュールが登録されている。更に、担当者情報１９４ｂとして、担当者「佐藤太郎」の所属先に「銀座店」の店舗ＩＤが登録されている。加えて、対応可能なエリアとして、「銀座エリア」に対応するエリアＩＤも登録されており、担当者「佐藤太郎」は、所属先の他に、「銀座エリア」にある店舗でも担当することができる。「銀座店」の詳細は店舗情報１９４ｄとして登録されている。店舗情報１９４ｄでは、「銀座店」のみならず、「東銀座店」や「有楽町店」の店舗ＩＤも「銀座エリア」としてエリアＩＤに関連付けられている。

予約情報１９６ａは、各一般ユーザが予約した情報を纏めて格納して管理する。具体的には、予約を一意に特定する予約ＩＤ、ユーザＩＤ、予約を行った日時、予約のサービスＩＤ、サービス利用日時、予約された店舗ＩＤおよび部屋／設備ＩＤ、担当者ＩＤ、並びに占有時間を特定する占有時間枠ＩＤ等が含まれる。予約情報１９６ａは、ユーザによって予約処理が行われる毎にレコードが追加され、特に、予約の変更に伴いレコードが更新される。また、店舗ＩＤを使用して予約情報１９６ａを参照することにより、そのサービス店舗の稼働状況を確認することができる。例えば、サービス店舗毎の稼働率を計算することができる。特典情報１９６ｂは、予約に付随して配布することができるクーポンや割引情報等を管理するものである。具体的には、特典を一意に特定するＩＤ、配布先の店舗ＩＤ、配布期間、および特典の内容（クーポン画像）等を含む。特典情報１９６ｂは、特典を作成するときに、サービス運営者によってレコードが追加される。

図２および図３に示した上記のサーバ１００およびユーザ端末２００（３００）の各ハードウェア構成における各要素、図４に示した各機能ブロック、並びに図５に示した各情報は一例に過ぎず、これらに限定されない。特に、図４に示した各機能ブロックは、ハードウェアの一部として実装されても、および／またはソフトウェアの一部として実装されてもよい。また、図４に示したサーバ１００の各機能ブロックの少なくとも一部は、ユーザ端末２００（３００）が有するように構成してもよい。ユーザ端末２００（３００）の各機能の少なくとも一部も、サーバ１００が有するように構成してもよい。つまり、一実施形態による方法は、サーバ１００およびユーザ端末２００（３００）から任意に選択される情報処理装置が実行できるものである。加えて、図５に示す例示の情報は、図示されるテーブル構成、データ種別、およびデータ項目に限定されないことが認められる。

図６および図７を参照して、一実施形態によるサービス予約支援方法について、ＩＭサービスにおけるユーザと仮想ユーザの間のメッセージング（チャット）によって実現された態様を説明する。図６は、サービス予約支援処理全般に関する、サーバ１００の予約部１５０とユーザ端末３００との相互作用による例示の処理フロー図であり、図７は、処理フローに対応するユーザ端末３００上の例示の画面イメージである。

サービス予約支援処理は、サーバ１００の予約部１５０において予約催促をユーザ端末３００に通知することで開始される（Ｓ１１）。ユーザ端末３００の出力部２５０には、チャット・アプリケーションからのプッシュ通知として「今月のレッスン予約はお済みですか？」のようなサービス利用を促す予約催促メッセージが表示される（画面Ｄ１）。通知のタイミングは、一般ユーザのサービス利用履歴情報１９２ｃに基づいて決定されるのがよい。一例では、一般ユーザのサービス利用履歴情報１９２ｃからこれまでのサービス利用履歴を抽出して次回のサービス利用日時を推定し、推定されたサービス利用日時に基づいて決定される日時（例えば２週間前）に通知を行うのがよい。

予約催促メッセージを確認した一般ユーザは、アプリケーション部２７０によるチャット・アプリケーションを起動し、トークルーム「予約チャット」内で仮想ユーザとのチャットを開始する。具体的には、ユーザ端末２００のアプリケーション部２７０は、サーバ１００のアプリケーション部１７０との間でチャットによる対話処理を行いながら、候補となるサービスを検索し、所望のサービスの予約を確定させる（Ｓ３１）。サーバ１００では、これと並行して、予約部１５０によって、店舗、時間および担当者を含むサービス候補情報１９４ｂを特定し、サービス候補を一般ユーザに随時提示しながら、一般ユーザのサービス候補の選択による予約を受け付ける（Ｓ１３；詳細は後述する。）。

ユーザ端末３００の出力部２５０では、サービス利用履歴情報１９２ｃから前回の利用履歴（店舗：「有楽町店」、担当者：「佐藤太郎」、コース：「筋トレ ４５分 ４，５００円」）が抽出され、仮想ユーザからのチャットで提示されている（画面Ｄ２）。なお、日程として「２０１６／１１／２０」が指定済みである（不図示）。次いで、一般ユーザが「はい」を入力（選択）すると、前回の利用履歴を基礎にして、「銀座店 ２０１６／１１／２０ １７：００」および「有楽町店 ２０１６／１１／２０ １８：００」の順序でサービス候補を決定し、ユーザに提示する（画面Ｄ２）。提示を受けた一般ユーザは、都合のいいものを選択するか、或いは、別日程で予約したい場合は「日程を選択する」を選択して日程を指定し直せばよい。

予約処理の後、サーバ１００の予約部１５０において、選択されたサービス候補情報に含まれるサービス利用日に基づいて、予約リマインド・メッセージを一般ユーザにプッシュ通知する（Ｓ１５）。ユーザ端末３００の出力部２５０には、チャット・アプリケーションからの通知として「［予約リマインド］本日１７：００より銀座店」のような予約リマインド・メッセージが表示される（画面Ｄ３）。通知のタイミングは、予約情報１９６ａに含まれるサービス利用日に従い、例えば、サービス利用日当日の午前零時に通知を行うのがよい。また、予約リマインド・メッセージもユーザの予約情報１９６ａに含まれる情報を用いて生成するのがよい。

予約催促メッセージを確認した一般ユーザは、アプリケーション部２７０によるチャット・アプリケーションを起動し、トークルーム「予約チャット」内で予約情報の詳細を確認、或いは、予約の変更または取り消しを行うことができる（Ｓ３３）。予約の変更または取り消しを行う際には、ユーザ端末２００のアプリケーション部２７０は、やはり、サーバ１００のアプリケーション部１７０との間でチャットによる対話処理を行う。サーバ１００のアプリケーション部１７０は、予約処理と同様の手法で予約修正処理を実施する（Ｓ１７）。予約の変更の場合は、店舗、時間、および担当者の何れか１つ以上を変更することになる。

一実施形態によれば、サービス候補を検索する際に、ユーザは全てのパラメータを入力する必要なくサービス候補の提示を受けることができる。これにより、従来の予約サイトのように、候補を検索する度に同じ情報を入力しなければならないという手間を解消することができる。特に、サービス店舗毎に空き時間を確認しなければならないという手間を解消することができる。

また、チャット・アプリケーションを通じたサービス予約支援方法を提供することにより、一般ユーザからの予約を、営業時間に制約されることなく、２４時間受け付けることを可能にする。実際のサービス予約に要する時間は１分程度のため効率的である。これにより、ユーザは隙間時間を利用してチャットにより簡単に予約可能となり、また、ユーザ端末３００の操作を行う場所や環境も制限されることはない。

更に、一実施形態によれば、ユーザは、予約催促受領、予約操作、および予約確認の一連の操作を同一トークルーム内、即ち同一インタフェースで実施し完了させることができる点で有利である。これにより、例えば、従来の予約サイトでの予約確認を電子メールで受信した場合に、ユーザの受信ボックス内で予約確認メールが埋もれてしまうというような事態を回避することができる。

次に、図８から図１０を参照して、図６のＳ１３で示したサービス候補の提示および予約受け付けに関する処理の詳細を説明する。図８はサービス候補の提示および予約受け付けの全体処理を示す処理フロー図であり、図９は、その内のサービス候補の特定処理に関する詳細処理フロー図である。そして、図１０は、サービス候補の特定処理に関連する概念図である。

Ｓ１３の処理を開始すると、パラメータ決定部１３２は、ユーザに関し、複数のパラメータおよび該パラメータに対応する値を決定する（Ｓ５１）。複数のパラメータは、例えば、「サービス店舗」、「担当者」および「コース」を含む。パラメータ「サービス店舗」は、店舗を特定するための店舗情報を少なくとも含み、例えば複数の店舗情報の値が位置情報（例えば、所在地の住所情報）に基づいて関連付けられる。これにより、例えば徒歩１５分圏内にある近隣店舗を関連付け、および／または特定のエリア内にある店舗として関連付けることができる。また、パラメータ「担当者」は、担当者を特定するための担当者情報を少なくとも含み、例えば複数の担当者情報の値が担当者に関連付けられる店舗情報に基づいて関連付けられる。これにより、例えば特定の店舗に所属する同僚を関連付けることができる。パラメータ「コース」は、コースを特定するためのコース情報を少なくとも含み、例えば複数のコース情報の値が占有時間情報に基づいて関連付けることができる。これにより、例えば特定のコースにおける複数の時間期間情報を関連付けることができる。

複数のパラメータに対応する値は、上述したとおり、サービス店舗「有楽町店」、担当者「佐藤太郎」、コース「筋トレ ４５分」である（画面Ｄ２）。加えて、「サービス利用日：２０１６／１１／２０」もセットされている。複数のパラメータに対応する値は、そのユーザのサービス利用履歴情報１９２ｃを参照して、前回のサービス利用履歴から抽出するのがよい。これにより、前回の利用内容を加味した形で候補サービスを提案することができ、ユーザ利便性が高いものとなる。

パラメータ決定部１３２は、更に、ユーザのサービス利用履歴情報１９２ｃに基づいて、複数のパラメータの優先順位を決定する（Ｓ５２）。パラメータの優先順位は、次の処理でサービス候補情報を特定する際のキー・パラメータを決定するためのものである。一例では、「第１順位：コース」「第２順位：サービス店舗」および「第３順位：担当者」といった具合である。ここで、パラメータの優先順位は、そのユーザのサービス利用履歴情報１９２ｃを参照して、決定するのがよい。例えば、その一般ユーザが、特定のサービス店舗（例えば「有楽町店」）を多く利用していると集計される場合には、「サービス店舗」パラメータの優先順位を上げるようにするのがよい（他の「担当者」パラメータや「コース」パラメータについても同様である。）。加えて、一般ユーザがどのパラメータを優先させるかについて、チャット画面において一般ユーザに指定させてもよい。これにより、一般ユーザは、好みのパラメータ（「サービス店舗」「担当者」および／または「コース」）に基づいてサービス候補を検索することができる。

次いで、サービス候補特定部１３４は、予約情報１９６ａを参照して、パラメータの優先順位およびパラメータに対応する値に基づいて、１つ以上の利用可能なサービス候補情報を特定する（Ｓ５３）。具体的には、第１順位のパラメータで予約情報１９６ａを参照することで予約済みレコードを抽出し、未予約の占有時間枠を特定する。同様に、第２順位のパラメータを参照することで予約済みレコードを抽出し、先の第１順位のパラメータで特定された占有時間枠を更に限定した未予約の占有時間枠を特定する。第３順位以降についても同様である。これらの結果、未予約の利用可能なサービス候補情報が１つ以上特定されることになる（Ｓ５３の詳細は図９および図１０で後述する。）。

次いで、候補順位決定部１３６は、Ｓ５３で得られた１つ以上の利用可能なサービス候補情報について、順位を決定する（Ｓ５４）。順位は、サービス利用履歴１９２ｃによるユーザ利用状況、および／または予約情報１９６ａから算出されるサービス店舗の稼働状況に基づいて決定するのがよい。サービス利用履歴１９２ｃに基づくことにより、一般ユーザの利用状況に応じて、利用可能なサービス候補を上位にすることができる。つまり、ユーザのニーズにより則した候補をリコメンドすることができる。他方、サービス店舗の稼働状況に基づくことにより、サービス運営者の事情でユーザに利用させたいサービスを上位にすることができ、マーケティング利用が可能になる。つまり、所望の（例えば、稼働率が低い）サービス店舗に対し、ユーザを効果的に誘導するよう候補をリコメンドすることができる。

次いで、提案部１３０は、Ｓ５３で特定した１つ以上のサービス候補情報をユーザ端末３００の出力部２５０に提示する（Ｓ５５）。その際、Ｓ５４で決定した順位にしたがって所定の数（Ｄ２の例では２つ）だけ抽出して提示するのがよい。また、特典情報１９６ｂを用いて、サービス候補情報のそれぞれに特典情報を関連付け、特典情報と共に一般ユーザに提示してもよい。これにより、サービスに特典という付加価値を提供することができ、一般ユーザによるサービス利用を一層促進させることができる。

Ｓ５５で提示された１つ以上のサービス候補情報に対し、ユーザ端末３００の入力部２４０により１つが選択される。サーバ１００の予約部１５０は、一般ユーザによるサービス候補情報の内１つの選択を受け（Ｓ５６）、これに応じて、予約情報更新部１５２は、予約情報１９６ａにレコード追加して更新することにより予約処理を完了させる（Ｓ５７）。予約処理が完了すると、引き続き、決済部１５４による決済処理を実施してもよい（不図示）。

上述したＳ５３における、１つ以上の利用可能なサービス候補情報を特定する処理の詳細についてこれより図９および図１０を参照して更に説明する。Ｓ５３において、全てのパラメータの値を満たすサービス候補が存在しないような場合に、図９および図１０に示す処理によってサービス候補を特定するのがよい。具体的には、複数のパラメータの内１つのパラメータの第１値に関連付けられる第２値を抽出し、第２値に関して利用可能なサービス候補情報が特定されるというものである。

ここでも上述した例を用いて説明する。即ち、パラメータおよびその値を、サービス店舗「有楽町店」、担当者「佐藤太郎」およびコース「筋トレ ４５分」とする。また、パラメータの優先順位を「第１順位：サービス店舗」「第２順位：コース」および「第３順位：担当者」として、「サービス利用日：２０１６／１１／２０」について１つ以上の利用可能なサービス候補情報を特定することを想定する。簡単のため、担当者「佐藤太郎」は、サービス利用日に、「有楽町店」「銀座店」「東銀座店」の銀座エリア内で全て対応可能である旨が担当情報１９４ｂおよび担当者予定情報１９４に登録されている。

最初に、所定の日付「サービス利用日：２０１６／１１／２０」の予約情報１９６ａを抽出して、図１０のようなサービス店舗毎の予約スケジュールを作成する（Ｓ６１）。図１０の例では、他の一般ユーザによる予約ａ１〜ｃ３の時間枠が既に埋まっている。つまり、サービス店舗「有楽町店」、担当者「佐藤太郎」およびコース「筋トレ ４５分」を満たすサービス候補はこの状況では存在しない。

そこで、まずは「第１順位：サービス店舗」の値「有楽町店」を固定し、「第２順位：コース」を修正できるかを試みる。つまり、特定パラメータ「コース」の値「筋トレ ４５分」に対し、利用可能なサービス候補が存在するかについて判定を行う（Ｓ６２）。具体的には、１５分間隔の基準時間枠３つ分を連続して埋めることができる部分が存在するかを判定する。図１０のように「有楽町店」では、ＴＳ＃４〜＃５の２つ分しか確保できず、連続した３つが存在しないことが分かる（Ｎｏ）。これに応じて、サービス情報１９４ａを参照し、特定パラメータ「コース」の占有時間枠として、現在の「４５分」に関連する「３０分」（基準時間枠２つ）を特定する（Ｓ６３）。その結果、サービス店舗「有楽町店」、担当者「佐藤太郎」およびコース「筋トレ ３０分」という利用可能なサービス候補が１つ特定される（Ｓ６４）。

次に、優先順位にしたがって、「第２順位：コース」の値「筋トレ ４５分」を固定し、「サービス店舗」を修正できるかを試みる。つまり、特定パラメータを「サービス店舗」に遷移させる（Ｓ６５）。上述したとおり、「有楽町店」では連続した３つが存在しないため（Ｓ６２：Ｎｏ）、同じ「銀座エリア」として関連付けられる別の値「銀座店」が特定される（Ｓ６３）。図１０のように、「銀座店」ではＴＳ＃３〜＃５、およびＴＳ＃４〜＃６の２つが特定され、サービス店舗「銀座店」、担当者「佐藤太郎」およびコース「筋トレ ４５分」という利用可能なサービス候補が２つ特定される。更には、「銀座店」の店舗稼働率を考慮した場合、コース「筋トレ ４５分」よりも「筋トレ ６０分」とした方がサービス店舗にとって好ましい。その結果、店舗の稼働状況に応じて、更に、サービス店舗「銀座店」、担当者「佐藤太郎」およびコース「筋トレ ６０分」という別の利用可能なサービス候補が特定されるのがよい。

全ての特定パラメータについて値の修正を試みた後に（Ｓ６６）、本処理フローは終了する。最終的には、次の４つの利用可能なサービス候補が特定されたことが理解される。即ち、（１）サービス店舗「有楽町店」、担当者「佐藤太郎」、コース「筋トレ ３０分」（ＴＳ＃４〜＃５）、（２）サービス店舗「銀座店」、担当者「佐藤太郎」、コース「筋トレ ４５分」（ＴＳ＃３〜＃５）、（３）サービス店舗「銀座店」、担当者「佐藤太郎」、コース「筋トレ ４５分」（ＴＳ＃４〜＃６）、および（４）サービス店舗「銀座店」、担当者「佐藤太郎」、コース「筋トレ ６０分」（ＴＳ＃３〜＃６）である。

上述したとおり、図８のＳ５４では、１つ以上の利用可能なサービス候補情報について、一般ユーザに提示するための順位を決定する。上記（１）〜（４）をそのまま提示順位としてもよい。他方、時間枠の充填率の点では、（１）と比べて（４）の方が「銀座」エリアの店舗稼働率が高くなり、また、（２）および（３）と比べて、（４）の方が「銀座店」の店舗稼働率が高くなることが理解される。つまり、サービス運営者にとっては、ユーザに（４）を選択してもらうことが好ましく、Ｓ５４で設定される順序を（４）→（１）→（２）→（３）とするのが都合がよい。また、（２）および（３）の順序は、サービス利用履歴情報１９２ｃを参照して、例えばその一般ユーザがＴＳ＃６の基準時間枠をこれまで多く利用している事実があるような場合には、（２）よりも（３）を上位に設定するのがよい。

一実施形態によれば、パラメータの値をフレキシブルに設定しながら、例えば、特定の店舗が混雑している場合に、フレキシブルに時間を短縮したサービスを提案し、または近隣店舗を利用したサービスを提案する等の対応をすることができる。これにより、ユーザおよびサービス店舗の双方にとって都合のいいサービス候補を特定することができる。

上述した実施形態は、本発明の理解を容易にするための例示に過ぎず、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良することができると共に、本発明にはその均等物が含まれることは言うまでもない。

Claims (11)

1. コンピュータによって実装されるサービスの予約支援方法であって、
   ユーザに関し、複数のパラメータに対応する値を決定するステップと、
   前記ユーザのサービス利用履歴に基づいて、前記複数のパラメータの優先順位を決定するステップと、
   予約情報を参照して、前記パラメータの優先順位および前記対応する値に基づいて、１つ以上の利用可能なサービス候補情報を特定するステップと、
   前記サービス候補情報を前記ユーザに提示するステップと、
   前記ユーザによる前記サービス候補情報の内１つの選択に応じて、前記予約情報を更新するステップと、
   を含む方法。
2. 請求項１記載の方法において、前記利用可能なサービス候補情報が更に、サービスを提供する店舗の稼働状況に基づく、方法。
3. 請求項２記載の方法であって、更に、
   前記サービス利用履歴および／または前記店舗の稼働状況に基づいて、前記１つ以上の利用可能なサービス候補情報の順位を決定するステップを含み、
   前記順位にしたがって前記１つ以上のサービス候補情報が提示される、方法。
4. 請求項１から３の何れか一項記載の方法において、
   前記サービス候補情報を特定するステップにおいて、前記複数のパラメータの内１つのパラメータの第１値に関連付けられる第２値を抽出し、前記第２値に関して利用可能なサービス候補情報が特定される、方法。
5. 請求項１から４の何れか一項記載の方法において、前記パラメータが、店舗を特定するための店舗情報を少なくとも含み、複数の前記店舗情報の値が位置情報に基づいて関連付けられる、方法。
6. 請求項１から５の何れか一項記載の方法において、前記優先順位が、前記ユーザによって指定可能とする、方法。
7. 請求項１から６の何れか一項記載の方法において、前記サービス候補情報が、前記サービス候補情報に関連付けられる特典情報と共に提示される、方法。
8. 請求項１から７の何れか一項記載の方法であって、更に、
   前記ユーザのサービス利用履歴に基づいて、サービス利用を促す予約催促メッセージを前記ユーザに通知するステップを含む、方法。
9. 請求項１から８の何れか一項記載の方法であって、更に、
   前記選択された１つのサービス候補情報に含まれるサービス利用日に基づいて、前記ユーザの予約情報に基づく予約リマインド・メッセージを前記ユーザに通知するステップを含む、方法。
10. 請求項１から９の何れか一項記載の方法において、前記ユーザが、トークルームにおけるチャットを通じて、前記コンピュータによって実装される仮想ユーザとの間で相互作用する、方法。
11. 請求項１から１０の何れか一項記載の方法を前記コンピュータに実施させるためのプログラム。