(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0007】
おすすめ料理の提案は店員の裁量に任されていることが多いが、店員がユーザとのコミュニケーションに時間を割けない状況があると、適切な提案ができない。これに対して、ポスレジ・システムを利用しておすすめ料理を提案する場合、提案が単調になるという問題点がある。ユーザの食べたいものや飲みたいものは、飲食店への入店後、時々刻々と変化する。
【0008】
これらの事情に鑑み、本発明は、おすすめ料理の動的な提案により顧客満足度を向上させることを目的とする。
【課題を解決するための手段】
【0009】
上記目的を達成する本発明に係る一態様は、制御部を具備する情報処理装置である。
上記制御部は、ユーザの入店からの経過時間に基づいて統計的に1以上のおすすめ料理候補を選択する。
上記制御部は、選択されたおすすめ料理候補の中からユーザ入店後に注文された料理と上記おすすめ料理候補との相関に基づいて1以上のおすすめ料理を動的に決定する。
上記制御部は、決定したおすすめ料理をユーザに提示するための表示情報を生成する制御部を具備する。
【0010】
上記ユーザは、料理が提供される飲食店の来店客を含む。なお、ユーザは2人以上の複数であってもよく、グループとして捉える場合はユーザグループと呼ぶ。
上記料理には飲食店が提供可能な飲食物を含み、したがって、アルコール飲料やソフトドリンク類も含む。
上記情報処理装置は、飲食店の内部に設置されたコンピュータとして実施されてもよいし、外部に設置されたサーバとして実施されてもよく、その実施の態様に特別の限定はない。上記情報処理装置が飲食店のテーブルの上や傍に設置された注文受付機能を備えたセルフオーダー端末や、デジタルサイネージであるような態様も一例として挙げられる。
上記表示情報は、例えばスマートフォンに表示される画面や、デジタルサイネージの画面でもよい。表示情報を実際に表示する表示装置について限定はしない。表示情報は例えばマークアップランゲージによりコーディングされた情報でもよいし、その他の方法により生成された情報であってもよい。
【0011】
上記情報処理装置によれば、ユーザの入店後の注文に応じて動的に変化するおすすめ料理が、入店からの経過時間に基づいて判断される適切なタイミングで提案されるため、おすすめ料理の動的な提案が実現し、顧客満足度を向上させることができる。
【0012】
上記情報処理装置において、上記制御部は、上記経過時間に基づいて食事の終了が予想される時間が近づいてきたタイミングで、注文品の累計が所定の金額に、到達したか否かを判定し、到達していない場合にもう一品追加の提案をしてもよい。
【0013】
上記構成における所定の金額は、例えば、ユーザグループの人数と、想定される一人当たりの客単価とを乗算した金額でもよい。
【0014】
上記構成によれば、ユーザ又はユーザグループが享受したサービスが、飲食店の提供可能なサービスの標準的な水準に未だ達していないような場合に、もう一品追加の料理の提案をすることができるので、顧客満足度を向上させることができる。
【0015】
上記情報処理装置において、上記制御部は、上記相関を料理に紐付けされるメタデータに基づいて決定してもよい。
【0016】
上記メタデータは、限定するものではないが、例えば、カロリーや食材、調理法などのデータが含まれる。例えば、食材と調理法が共通する2つの料理が両方とも注文される例が統計的に少ないことが、あらかじめわかっている場合、2つの料理には負の相関がある。制御部は、メタデータに基づいて、このような負の相関があると決定(判断)する。逆に、一方の料理が注文された場合、他方の料理も注文されやすいような料理のペアには、正の相関があると決定(判断)する。制御部は、「ユーザ入店後に注文された料理」に対して「おすすめ料理候補」が負の相関を持つ場合にはおすすめ料理にすることに対して消極的になるような情報処理をしてもよい。また、逆の場合にはおすすめ料理にすることに対して積極的になるような情報処理をしてもよい。
【0017】
上記構成によれば、おすすめ料理をユーザの入店後の注文に応じて動的に変化させる具体的方法を提供することができる。
【0018】
上記情報処理装置において、上記制御部は、提示したおすすめ料理をユーザが選択した場合に提案に乗ったと判断し、おすすめ料理の提案の処理を積極的に実行してもよい。
【0019】
おすすめ料理の提示を見て当該料理を注文したユーザは、おすすめ情報に対する感度が高いものと考えられる。このようなユーザに対しては、飲食サービス提供側からの情報提供を積極的に行うことが顧客満足度の向上につながる。ここで「積極的に実行する」には、提案頻度を上げる、おすすめ情報の表示強度を上げる(目立つようにする)、などの態様が含まれる。
【0020】
上記構成によれば、おすすめ情報への感度の高いユーザに対しては情報提供が積極的になされるので、さらに顧客満足度を向上させることができる。
【0021】
上記情報処理装置において、上記制御部は、上記入店時刻からの経過時間及び/又は滞在時間帯をパラメータにした統計的情報に基づくおすすめ料理候補の選択を行ってもよい。
【0022】
例えばフレンチレストランを例に取るとアラカルトで注文を受ける場合、前菜として注文される料理、デセールとして注文される料理がある、入店時間からの経過時間と注文ニーズとの間に相関が認められる場合がある。上記統計的情報は、例えば、上記情報処理装置が設置される飲食店において過去に注文された料理の履歴データベースとすることができる。この履歴データベースは、「入店からの経過時間」と「滞在時間帯」をパラメータに有することが好ましく、例えば、入店後例えば10分経過した時点の注文頻度を料理ごとに有するといったようなデータ構造にしてもよい。
【0023】
上記構成によれば、おすすめ料理候補の選択を行う情報処理を具体的に提供することができる。
【0024】
上記情報処理装置において、上記制御部は、ユーザから注文を受けた時刻を少なくとも一時的に記憶し、記憶した複数の時刻の間隔に係る注文間隔に応じて、おすすめ料理の決定頻度を変更してもよい。
【0025】
上記決定頻度の変更においては、料理の注文間隔が狭いユーザに対して頻繁におすすめ料理を提示するようにしてもよい。逆に、注文間隔が広いユーザに対しては頻繁なおすすめ料理の提示を抑制してもよい。あるいは、注文間隔が広いユーザに対しては、入店からの経過時間が所定の時間が経つ前であっても、上記所定の時間の後におすすめ料理候補として選択される料理の中からおすすめ料理候補が選択されるようにしてもよい。この場合、所定の時間としては、例えばデザートや食後の口直しをおすすめ料理として提示することを開始する時間とすることができる。
【0026】
上記構成によれば、注文間隔によりユーザの空腹度合いを推し量ることができ、これに応じた頻度の変更を行うことで適切なおすすめ料理の提案が可能になる。
【0027】
上記情報処理装置において、上記制御部は、提案することが決定したおすすめ料理に係る第1の料理を第1のタイミングで提案すると、上記第1の料理の提供が上記第1の料理とは異なる注文済みの第2の料理の提供と同時になる場合、上記第1の料理を第1のタイミングよりも遅い第2のタイミングで提案してもよい。
【0028】
上記構成によれば、第1の料理と第2の料理の提供が同時にならないようにすることにより、適切なタイミングでのおすすめ料理の提案が可能になる。
【0029】
上記情報処理装置において、上記制御部は、入店からの経過時間に基づいて第1の時間帯に選択されるおすすめ料理候補に該当する料理が、上記第1の時間帯よりも前に注文された場合、上記経過時間が上記第1の時間帯よりも前の第2の時間帯に入っているか否かに関わらず、上記第2の時間帯に選択されるおすすめ料理候補からおすすめ料理を決定してもよい。
【0030】
上記第1の時間帯は、限定するものではないが、例えば、食事の最後のほうの時間帯にしてもよい。この場合、居酒屋で「〆の料理」と呼ばれる料理やデザートなどが注文されがちな時間帯にすることができる。上記第1の時間帯は、例えば、飲食店に来店した過去のユーザの平均的な滞在時間から導き出されたものでもよく、例えば、平均滞在時間が120分の場合入店後90分から120分までの時間帯を第1の時間帯としてもよい。
上記第2の時間帯は、上記第1の時間帯よりも時間的に先に位置する時間帯である。上記第1の時間帯よりも前の時間帯の全部又は一部としてもよい。例えば、入店後30分から90分までの時間帯を第2の時間帯としてもよい。
【0031】
上記構成によれば、第1の時間帯におすすめ料理候補として選択されるような料理が、第1の時間帯よりも前の時間において注文されたような場合に、第1の時間帯よりも前の時間帯(第2の時間帯)におすすめ料理候補として選択されるような料理を、第2の時間帯でなくてもおすすめ料理として決定し、提案する情報処理が行われることによって、飲食店が本来、大きな満足を与えることができるはずの料理を享受する機会を逃さないように、ユーザに提案することができる。その結果として、顧客満足度を向上させることができる。
例えば、「〆の料理」やデザートなどをユーザが比較的早期に注文した場合、ユーザは本来その店舗で楽しむことができる目玉料理を食べ逃してしまう可能性があったが、上記情報処理装置によれば、そのような可能性を低減させることができ、顧客満足度の向上につながる。
【0032】
上記情報処理装置において、上記制御部は、入店してからユーザが注文した酒類の履歴と、注文した料理との相関とに基づいて、提案する酒類を決定してもよい。
【0033】
飲食店は特定の銘柄の日本酒に合う料理を開発したり、特定の料理に合うワインを特別に選定したりする場合があり、酒類に関しては特定の料理との結びつきが強い場合がある。
【0034】
上記情報処理装置によれば、そのような酒類に関する飲食店の強いこだわりを、おすすめ料理に反映することができる。
【0035】
上記情報処理装置において、上記制御部は、調理時間が所定の第1の時間を越える料理をおすすめ料理候補とする場合、入店からの経過時間に調理時間及び/又はサーブまでの時間を加えた時間が、所定の第2の時間を越えない場合にのみ、上記調理時間が上記第1の時間を越える料理をおすすめ料理候補としてもよい。
【0036】
上記構成によれば、上記調理時間が上記第1の時間を越える料理については、おすすめ料理候補とするにあたって入店からの経過時間が遅くなりすぎないように考慮がなされ、これにより、顧客満足度を向上させることができる。
【0037】
上記情報処理装置において、上記制御部は、上記調理時間が上記第1の時間を越える料理が注文されると、上記調理時間が上記第1の時間を越える料理がユーザに提供されるまでの時間内に提供可能な料理を、優先的におすすめ料理候補としてもよい。
【0038】
上記構成によれば、上記調理時間が上記第1の時間を越える料理が注文された場合においては、ユーザを待たせている比較的長い時間の間に、提供可能な料理をユーザに提案することによって、顧客満足度を向上させることができる。
【0039】
上記情報処理装置は、さらに、おすすめ料理の提案を店員の操作する可搬型端末に出力する出力部を有してもよい。
上記情報処理装置によれば、店員の可搬型端末に表示情報を出力することができる。
【発明の効果】
【0040】
以上に説明したように、本発明によれば、おすすめ料理の動的な提案が実現し、顧客満足度が向上する。
【発明を実施するための形態】
【0042】
以下、図面を参照しながら、本発明の実施形態を説明する。
【0043】
[システムの構成]
図1は、本実施形態に係る料理情報提供システム1の構成を示した図である。同図に示すように、本実施形態に係る料理情報提供システム1は、飲食店の店舗内で完結したシステムであり、店舗端末100とユーザ端末200と従業員端末300を含む。なお、
図1のシステム構成例は一例に過ぎず、店舗内で完結したシステムにしない実施も可能である。また、従業員端末300は必ずしも必要ではない。
【0044】
本実施形態に係る制御部が構成される店舗端末100は、汎用のコンピュータを利用した端末として構成することができる。店舗端末100は、おすすめ料理情報をユーザ端末200に送信する。なお、ネットワークの態様はどのようなものでもよいが、例えば、無線ローカルエリアネットワークによるものが利用できる。
【0045】
ユーザ端末200も、汎用のコンピュータを利用した端末として構成することができるが、例えば、スマートデバイスやタブレット型端末などのデバイスを利用してもよい。
図1中には、店舗内のテーブル席に据え置きされる注文受付(セルフオーダー)機能も備えた卓上端末200aが示されている。また、ユーザが個人的に持っているスマートフォンをユーザ端末200として利用してもよい。
図1中には、ユーザが有するスマートフォン200bが示されている。ユーザ端末200は表示装置と通信装置を備え、ユーザにおすすめ料理情報を表示装置に表示する。
【0046】
本実施形態において、店舗端末100に注文情報を送信するデバイスとしては、ユーザ端末200のほかに、従業員端末300がある。従業員端末300は、ユーザ(来店客)から注文を聞き取った従業員(ホール係)が操作入力した料理の注文に係る情報を店舗端末100に送信する。このように、注文情報の入力は、ユーザ端末200以外の装置からも可能である。
【0047】
なお、従業員がユーザ端末200を操作してもよい。また、以下では、単に「ユーザ」と表記した場合、複数のユーザからなるグループを指すこともあることとする。
【0048】
[店舗端末のハードウェア構成]
図2は、店舗端末100のハードウェア構成を示した図である。同図に示すように、店舗端末100は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、入出力インタフェース15、及び、これらを互いに接続するバス14を備える。
【0049】
CPU11は、必要に応じてRAM13等に適宜アクセスし、各種演算処理を行いながら各ブロック全体を統括的に制御する。ROM12は、CPU11に実行させるOS、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。RAM13は、CPU11の作業用領域等として用いられ、OS、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。
【0050】
入出力インタフェース15には、表示部16、操作受付部17、記憶部18、通信部19等が接続される。表示部16は、例えばLCD(Liquid Crystal Display)、OELD(Organic Electro-Luminescence Display)、CRT(Cathode Ray Tube)等を用いた表示デバイスである。操作受付部17は、例えばマウス等のポインティングデバイス、キーボード、その他の入力装置である。なお、表示部16と操作受付部17を液晶タッチパネルにより一つにまとめてもよい。
【0051】
記憶部18は、例えばHDD(Hard Disk Drive)や、フラッシュメモリ(SSD;Solid State Drive)、その他の固体メモリ等の不揮発性メモリである。当該記憶部18には、上記OSや各種アプリケーション、各種データが記憶される。
【0052】
通信部19は、例えばNIC(Network Interface Card)や無線LAN等の無線通信用の各種モジュールである。通信部19により本端末の他端末とのデータの送受信が可能になる。
なお、ユーザ端末200のハードウェア構成も、上述の店舗端末100と同様の構成としてもよい。
【0053】
なお、上述のハードウェア構成を採用することで、複数のユーザ及び/又はユーザ端末からの注文情報を一元的に店舗端末100に集めることができ、効率的な情報処理が可能になる。
【0054】
[記憶部のデータ内容]
記憶部18が記憶する各種データのうち、以下で説明する本実施形態の構成及び動作に関係するものについて説明する。
【0055】
図3は、記憶部18が記憶する各種データの構成例を示す図である。
図3に示すように、記憶部18は、料理情報データベース181と売上情報データベース182と注文情報データベース183を有している。各データベースは相互に関連付けがなされており、全体として一つのリレーショナルデータベースとして構築されている。なお、これは説明のための便宜的な一例であり、他の実施形態においては、リレーショナルデータベースとしなくてもよい。また、データベースと呼べるような規模のものではなく、単純な記憶テーブルのようなものでもよい。
【0056】
料理情報データベース181は、
図1の店舗で提供可能な各料理の情報が記憶されたデータベースである。ここで言う料理にはアルコールドリンクを含む。売上情報データベース182は、
図1の店舗の過去の売上に関連する情報が記憶されたデータベースである。注文情報データベース183は、
図1の店舗に来店中のユーザ(来店客)のした注文をユーザごとに記憶するデータベースである。
【0057】
図4を参照して料理情報データベース181の記憶内容やデータ構造について説明する。
図4は、料理情報データベース181の構成を説明するための模式図である。料理情報データベース181は、
図4の模式図に示すように、店舗が提供可能な「料理」を中心に構成されていて、「料理」の名称や、分類、食材、相性のいい料理、相性のいいアルコールドリンク、相性の悪い料理、等々がメタデータとして「料理」に紐付けされて格納されている。以下では、このようなメタデータを「タグ」と呼び、紐付けのことを「タグ付け」と呼ぶことがある。
【0058】
図4中に示す「分類」は、例えば、「アントレ/メインディッシュ/デザート」のような分け方に基づく分類でもよいし、「野菜料理/肉料理/海鮮料理」のような分類でもよい。一つの料理に異なる分け方に基づく複数の分類が紐付けられてもよい。なお、各料理に紐付けされるメタデータとしては、図示のもののほかに、例えば、カロリー量や、相性のいい料理の分類(例えば、「海鮮料理との相性がよい」といった情報が紐付く)などがあってもよい。
【0059】
次に、
図5を参照して、売上情報データベース182の記憶内容やデータ構造について説明する。売上情報データベース182は、
図5に示すような相関テーブルを持つ。
図5(a)に示されるテーブルは、ある料理の注文された数量とその時間帯の関係を記録するテーブルである。売上情報データベース182は、このような時間帯と注文数の相関テーブルを料理ごとに有する。
【0060】
図5(b)に示されるテーブルは、ある料理が注文された時間(ただし、この時間は入店してからの経過時間)と注文数の関係を記録するテーブルである。売上情報データベース182は、このような注文された時間と注文数の相関テーブルを料理ごとに有する。なお、
図5(a),(b)に例示したテーブルは、ユーザごとのデータであってもよい。
【0061】
売上情報データベース182には
図5(b)に例示したようなデータが格納されているため、売上情報データベース182からは、入店からの経過時間に応じた注文頻度に係る情報が料理ごとに得られる。
図6に、入店からの経過時間に応じた注文頻度に係る情報を模式的に示す。
【0062】
図6に示すように、売上情報データベース182に基づくと、それぞれの料理が「入店からの経過時間が短く、比較的早期に注文されがちである」、あるいは、「おおむね多くのユーザが食事を終わりにする時間に注文されがちである」といった、各料理の注文傾向が把握される。店舗端末100のCPU11は、売上情報データベース182に記録されている売上と時間に関する各種相関に基づいて、料理ごとの注文傾向を判断する。なお、
図6には、2つの料理についての情報だけが示されているが、売上情報データベース182からは店舗が提供可能な料理すべての当該頻度情報が抽出できる。
【0063】
次に、
図7を参照して、注文情報データベース183の記憶内容やデータ構造について説明する。注文情報データベース183は、
図7に示すようなテーブルを有し、ユーザごとに入店からの経過時間と注文料理を記録している。注文情報データベース183は、RAM13上に構築されてもよい。
【0064】
CPU11は、注文情報データベース183を参照して、ユーザが注文した料理とその注文がなされた時間(入店からの経過時間)を取得することができる。注文情報データベース183は、ユーザが入店した時刻もユーザごとに記憶する。したがって、CPU11は、ユーザが注文した料理とその注文がなされた時刻も取得することができる。
【0065】
[システムの動作]
次に、上記料理情報提供システム1における料理情報提供の流れについて説明する。
図8は、料理情報提供システム1で実行される情報処理の一例に係るシーケンス図である。図示のように、店舗端末100は、ユーザが来店すると入店時刻を注文情報データベース183に記録する(ST10)。なお、ユーザ来店は、従業員が従業員端末300に来店を記録する操作を行うことにより店舗端末100にユーザ来店を通知するような仕組みによって、店舗端末100に把握される用に構成してもよい。
【0066】
店舗端末100は、所定のタイミングで表示情報を生成し、また、生成した表示情報をユーザ端末200に送信(出力)する(ST11,ST12,ST13)。他方で、ユーザ端末200は、店舗端末100から送信(出力)されてきた表示情報を、自端末の表示部で表示する(ST21,ST24,ST25)。また、ユーザ所望のタイミングで、ユーザ端末200は注文情報を店舗端末100に対して送信(出力)する(ST22,ST23)。
【0067】
なお、言うまでもないことであるが、
図8に示したシーケンスは、一例であり、ユーザが注文をするタイミングにより注文情報の出力(ST22,ST23)が
図8とは異なるタイミングで行われてもよい。ユーザ(来店客)の入店から退店までのあいだ、
図8に示すような、表示情報の生成出力とその表示(例えば、ST11とST21のペア)と、ユーザ端末200からの注文情報の出力(例えば、ST22,ST23)が繰り返される。
【0068】
料理情報提供システム1における料理情報提供に係る情報処理は、ユーザが退店したときに終了する。例えば、従業員端末300やユーザ端末200などから、「お客様のお帰り」を通知されると、店舗端末100はその時刻を注文情報データベース183に記録して処理を終了する。
【0069】
図9に、店舗端末100による表示情報の生成出力処理(ST11,ST12,ST13)の詳細な処理の流れが示されている。店舗端末100のCPU11は、まず、ST10で注文情報データベース183に記録されたユーザの入店時刻からの経過時間に基づいて、料理情報データベース181に記憶されている料理群の中から、おすすめ料理候補を1以上、統計的な方法により選択する(ST31)。
【0070】
CPU11が実行する統計的な方法は、例えば、売上情報データベース182から、入店からの経過時間をパラメータにして、その時間に注文される頻度が高い料理を抽出してもよい。売上情報データベース182は、
図6に模式的に示したような情報を料理ごとに出力することができる。CPU11は、売上情報データベース182を入店からの経過時間をパラメータにして検索することにより、1以上のおすすめ料理候補を抽出する。なお、この検索の際には、例えば、頻度情報に利益率などで重み付けをしておすすめ料理候補を抽出してもよい。これにより、利益率の高い料理を積極的におすすめすることができる。
【0071】
また、このST31のおすすめ料理候補の選択の際に、CPU11は、ユーザの入店からの経過時間に加えて、あるいはこれに代えて、ユーザの滞在時間帯をパラメータにしてもよい。飲食店では時間帯によって、よく注文される料理が異なる場合があるため、これにより、おすすめする料理もそれに合わせて変化させることができる。
【0072】
続いて、店舗端末100のCPU11は、選択されたおすすめ料理候補の中から、ユーザ端末200に表示させる表示情報に含ませるおすすめ料理を動的に決定する(ST32)。この動的な決定処理は、ユーザ入店後に注文された料理と、候補に挙げられているおすすめ料理候補との相関に基づいて、CPU11により判断される。
【0073】
図10は、上記注文済み料理とおすすめ料理候補との相関に基づく決定処理を説明するための模式図である。
図10中、左部分に示すように、ユーザからの注文(料理a1,2,・・・)は時系列に沿って、店舗端末100に入力される。ここで入力される注文に係る料理には、
図4に示したようなメタデータが紐付けされている。一方で、
図10中、右部分に示すように、おすすめ料理として挙げられている料理のそれぞれにも、
図4に示したようなメタデータが紐付けされている。
【0074】
CPU11は、
図10中、右部分に示されているおすすめ料理候補の一つ一つを、左部分に示されている過去に注文された料理と、それぞれに紐付けられたメタデータ同士の相関関係を検討することによって、重み付けする。メタデータ同士の相関関係の一例としては、
図10中に示したように、ある食材に係るメタデータと、おすすめ料理候補に紐付けられた食材に係る1つ以上のメタデータとの相関がある。
【0075】
例えば、食材がよく似ているという相関関係が得られる場合、CPU11は、おすすめ料理候補に係る料理b1の重み付けを下げる、というような処理を行う。これにより、似たような料理が連続しておすすめ料理として提示されることを抑制できる。例えば、前菜として鮮魚のカルパッチョを注文したユーザは、その後に刺身の盛り合わせをおすすめされても感度が鈍い、というような例があるが、本例の処理によれば、そのようなおすすめがなされるのを抑制することができる。
【0076】
上記注文済み料理とおすすめ料理候補との相関に基づく決定処理の一例としては、例えば、CPU11は、おすすめ料理候補に挙げられている料理のそれぞれに、注文済みの料理のそれぞれとの、メタデータ同士の相関関係を検討し、重み付けを与える。その上で、重み付けにしたがって、おすすめを決定する。乱数を使ってランダムに決定してもよい。その際に重み付けを考慮してランダムに決定してもよい。なお、CPU11は、おすすめ料理を複数決定してもよい。
【0077】
CPU11は、おすすめ料理を決定すると、次に、表示情報を生成する(ST33)。表示情報は、例えば、マークアップランゲージが使用されたページとして構成されてもよい。次に、CPU11は、生成した表示情報をユーザ端末200に出力(送信)する(ST34)。ユーザ端末200の表示装置は、受信した表示情報を画面に映し出す。
【0078】
以上が料理情報提供システム1の動作の流れである。
上記情報処理装置によれば、ユーザの入店後の注文に応じて動的に変化するおすすめ料理が、入店からの経過時間に基づいて判断される適切なタイミングで提案されるため、おすすめ料理の動的な提案が実現し、顧客満足度を向上させることができる。
上記情報処理装置によれば、おすすめ料理をユーザの入店後の注文に応じて動的に変化させる具体的方法を提供することができる。
【0079】
[おすすめ料理の提案のタイミング1]
次に、おすすめ料理情報を提供するタイミングについて説明する。おすすめ料理情報を提供するタイミングは、言い換えれば、S11,ST12,ST13の表示情報の生成出力がなされる所定のタイミングになる。
図11は、おすすめ料理情報を提供するタイミングについて説明するための図である。
【0080】
図11において、縦軸は時間軸を表し、矢印は、おすすめ料理情報が提供されるタイミングを示すものとする。本実施形態におけるおすすめ料理情報を提供するタイミングは、一例として
図11(a)に示すように、10分おきなどのように等間隔でおすすめ料理情報が提供されるように構成してもよい。
【0081】
あるいは、売上情報データベース182に記憶されている
図5(b)のようなデータに基づいて、前菜の注文が少なくなるタイミングなどを割り出し、そのタイミングにおすすめ料理情報が提供されるように構成してもよい(不図示)。あるいは、入店後、5分経過時、20分経過時、50分経過時、などのように、あらかじめ決められた所定のタイミングで、おすすめ料理情報が提供されるように構成してもよいし、ユーザからの注文が所定時間ない場合におすすめ料理情報が提供されるように構成してもよい(不図示)。
【0082】
さらに、
図11(b)に示すように、本料理情報提供システム1により提供されたおすすめ料理情報に対して、ユーザが好意的なレスポンスを返す、例えば、そのおすすめ料理を注文する、といったアクションがあった場合、店舗端末100のCPU11は、その後のおすすめ料理情報の提供を積極的に行うようにしてもよい。具体的には、
図11(b)に示すように、所定の間隔で提供していたおすすめ料理情報を、より短いスパンで提供するようにする。あるいは、頻繁におすすめ料理情報を更新してもよい。
【0083】
所定の間隔を置いておすすめ料理情報を提供するのではなく、あらかじめ決められた所定のタイミングで、おすすめ料理情報が提供されるように構成されている場合、そのあらかじめ決められた所定のタイミングを早めのタイミングにシフトさせるようにしてもよい。この場合、例えば、通常なら入店後20分経過時にメインディッシュのおすすめ料理情報を提供するところ、入店後15分経過時にそれを提供するようにする。
【0084】
おすすめ料理情報の提供をより頻繁に行うようにタイミング変更するトリガーとしては、上述のように、ユーザがおすすめ料理情報に対して好意的なレスポンスを返したことのほかに、ユーザの注文間隔の頻度でもよい。この場合、CPU11が、ユーザの注文間隔を、注文間隔データベース183を参照することにより把握しておき、注文間隔の広狭に応じて、おすすめ料理情報の提供の頻度を変更する。
【0085】
この場合例えば、CPU11は、料理の注文間隔が狭いユーザに対して頻繁におすすめ料理を提示するようにしてもよい。逆に、注文間隔が広いユーザに対しては頻繁なおすすめ料理の提示を抑制してもよい。あるいは、注文間隔が広いユーザに対しては、入店からの経過時間が所定の時間が経つ前であっても、前記所定の時間の後におすすめ料理候補として選択される料理の中からおすすめ料理候補が選択されるようにしてもよい。この場合、所定の時間としては、例えばデザートや食後の口直しをおすすめ料理として提示することを開始する時間とすることができる。
【0086】
これによれば、CPU11は注文間隔に基づいてユーザの空腹度合いを推し量ることができ、これに応じた頻度の変更を行うことで適切なおすすめ料理の提案が可能になる。
【0087】
その他のおすすめ料理情報を提供するタイミングとしては、入店からの経過時間に基づくと、食事の終了が予想される時間が近づいたタイミングで、CPU11が、注文情報データベース183を参照することにより注文された品が所定の金額等に到達したか否かを判定し、到達していないと判定される場合に、さらにおすすめ料理情報を提供するよう構成してもよい。例えば、「2時間呑み放題」のような居酒屋で、1時間30分経過した時点で上記情報処理を行う。
【0088】
このような構成によれば、ユーザ又はユーザグループが享受したサービスが、飲食店の提供可能なサービスの標準的な水準に未だ達していないような場合に、もう一品追加の料理の提案をすることができるので、顧客満足度を向上させることができる。
【0089】
さらに別の情報処理として、CPU11は、デザートやいわゆる「〆の料理」が、通常それらが注文される時間帯(「第1の時間帯」とする)よりも前に注文された場合、かならずしも入店からの経過時間に基づいておすすめ料理の提案をしなくてもよい。この場合、入店からの経過時間が第1の時間帯よりも前の所定の時間帯(「第2の時間帯」とする)に入っていなくても、その第2の時間帯に選択されるようなおすすめ料理候補から、おすすめ料理を決定する。
【0090】
これにより、第1の時間帯におすすめ料理候補として選択されるような料理が、第1の時間帯よりも前の時間において注文されたような場合に、第1の時間帯よりも前の時間帯(第2の時間帯)におすすめ料理候補として選択されるような料理を、第2の時間帯でなくてもおすすめ料理として決定し、提案される。
【0091】
そうすると、飲食店が本来、大きな満足を与えることができるはずの料理を享受する機会を逃さないように、ユーザに提案することができる。その結果として、顧客満足度を向上させることができる。例えば、「〆の料理」やデザートなどをユーザが比較的早期に注文した場合、ユーザは本来その店舗で楽しむことができる目玉料理を食べ逃してしまう可能性があった。上述のようなおすすめ料理の提案タイミングの制御によれば、そのような可能性を低減させることができ、顧客満足度の向上につながる。
【0092】
[おすすめ料理の提案のタイミング2]
おすすめ料理情報の提供を行うタイミングに関する情報処理については、さらに、以下に述べるように、
図9のST34(表示情報の出力)の処理を行うタイミングを調整することにより、料理の提供のタイミング(サーブタイミング)が重ならないようにしてもよい。
【0093】
図12は、本情報処理の手順の一例を示すフローチャートである。
図9と同じく店舗端末100のCPU11が実行する情報処理となる。ST41、ST42,ST43,ST45は
図9に示したステップと同じ処理である。
図12に示すように、CPU11は、ST45(表示情報の出力)の処理を行う直前に、表示情報の出力を遅らせるか否かを判断する(ST44)。この表示出力ディレイは、ST45を行うと、その時点でそのおすすめ料理(「第1の料理」とする)の注文をユーザから受けた場合、別の注文済みの料理(「第2の料理」とする)の提供と同時になる場合に、実行される(ST44,Yes)。
【0094】
図12に示したような処理を行うことにより、第1の料理と第2の料理の提供が同時にならないようになる。したがって、適切なタイミングでのおすすめ料理の提案が可能になる。
【0095】
[時間のかかる料理のおすすめ]
さらに、別の情報処理として、時間のかかる料理を安易におすすめ料理としない処理をしてもよい。調理時間は、
図4で示したようなメタデータにより料理ごとに設定されている。このような場合、CPU11は、
図9のST31の選択をする際、ユーザの入店からの経過時間に、メタデータにより特定される調理時間及び/又はサーブまでの時間を加えた時間が、所定の閾値を越えないような料理のみをおすすめ料理候補にする。あるいは逆に、ユーザの入店からの経過時間に、メタデータにより特定される調理時間及び/又はサーブまでの時間を加えた時間が、所定の閾値を越える料理は、おすすめ料理候補から除外する。
【0096】
上記情報処理によれば、時間のかかるような料理をおすすめするにあたって、入店からの経過時間が遅くなりすぎないような配慮がなされる。これにより、顧客満足度を向上させることができる。
【0097】
さらに、上述の処理をした上で、調理時間が上記所定の閾値を越える料理が注文されると、CPU11は、
図9のST31の選択をする際、注文された料理がユーザに提供されるまでの時間内に提供可能な料理を、優先的におすすめ料理候補としてもよい。
【0098】
優先的におすすめ料理候補とする処理の具体的な方法としては、例えば、CPU11が、料理情報データベース181に記憶されている料理群の中から、統計的な方法により1以上のおすすめ料理候補を選択する(
図9のST31)際に、選択に用いる料理ごとの重み付けを変更する。これにより、時間のかかる料理がユーザに提供されるまでの時間内に提供可能な料理が、通常ならば例えば40%の確率でおすすめ料理候補に選択されるところ、80%の確率で選択されるように変更できる。
【0099】
上記情報処理によれば、時間のかかる料理が注文された場合においては、ユーザを待たせている比較的長い時間の間に、提供可能な料理をユーザに提案することによって、顧客満足度を向上させることができる。
【0100】
[変形例]
上述の実施形態は種々の変形が可能である。例えば、上記実施形態においては、店舗端末100が実行した情報処理による表示情報が、ユーザ端末200に出力される例が記載されているが、従業員端末300に出力されるように構成してもよい。この実施形態の利用例としては、ホール係などの従業員が自分の携帯する従業員端末300を見て、来店客におすすめ料理を提案する。このようなハードウェア構成にすることで、来店客と従業員のコミュニケーションを促進することがきる。
【0101】
また、上記実施形態の一変形例においては、おすすめメニュー情報を提案する際に、提案する根拠となったメタデータをユーザに表示してもよい。これにより、過去に注文された料理と、おすすめメニューとの相関を店員が説明することなくユーザに認識させることができ、より納得感のある注文を促すことができる。
【0102】
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の範疇に含まれる。なお、実施形態に開示した構成はすべて組み合わせて実施することが可能である。
【0103】
また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する情報処理プログラムが、システムあるいは装置に直接あるいは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるネットワーク上のサーバも、本発明の範疇に含まれる。