JP5770140B2 - 美容サロン予約システム - Google Patents

Description

本発明は、美容サロン（美容室）等の利用の予約及びその管理を行うための情報処理システムの技術に関する。

美容サロン等の業界における利用の予約に関する現状及び課題として以下がある。

（１） 利用者（顧客）による美容室（店舗）の利用の予約のために、店舗で直接予約すること以外に、電話（コールセンタの予約受付サービス等）、店舗専用ＨＰ（ホームページ）、ネット上の予約サービスサイト、等の各種の予約の手段・媒体・方法など（以下「予約手段」と称する）が存在する。

例えば、上記電話による予約では、利用者が携帯電話などからコールセンタの予約受付サービス（美容室の予約受付業務を代行するサービス）等の番号へ電話し、オペレータ対応や自動音声応答などに従い、対象の店舗や日時などを指定して予約が可能である。また上記店舗専用ＨＰでの予約の場合、利用者が端末からＨＰ（予約ページ）にアクセスし、対象の日時などを指定・入力して予約可能である。また上記ネット上の予約サービスサイトの場合、当該サイト（Ｗｅｂページ）に候補として複数の美容室の情報が登録されており、利用者が端末からサイトにアクセスし、対象の店舗（地域）や日時などを指定して検索し、検索結果の中から指定して予約可能である。

各美容室は、自店舗での直接予約以外にも、上記のような所望の予約手段を契約などで使用し、利用者に対して予約を提供することができる。利用者は所望の予約手段を利用して予約を行うことができる。

（２） 上記予約の際には、複数の利用者の間や、美容室（店舗）側のリソース（時間、店員など）の間において、予約の重複が発生し得る。例えば同じ時間枠に複数の利用者（店舗側の許容度合いを超える人数）が予約を要求する場合（あるいはそれらの予約を確定させた場合）である。

美容室側は、予約の受付の業務では、店舗側の許容度合い（例えば同じ時間枠で二人までなら施術可能など）を超えるような予約の重複を避けるように、何らかの対処・調整などが必要である。重複する複数の予約の要求を調整する例としては、許容度合いを超える分の予約を断ることや、空いている他の時間枠を薦めることや、当該時間枠で臨時的に増員などして対処すること等が挙げられる。

また特に、重複する複数の予約の要求に対し、もし店舗側の許容度合いを超えるような予約を確定させてしまった場合、来店した利用者が予約した時間でサービス（施術）を受けることができないといった問題を引き起こす。これにより店舗のサービスレベル（顧客満足度）が大きく低下するリスクがあるので、極力避ける必要がある。

（３） 更に、美容室は、上記のような複数の予約手段を並列的に使用して利用者に対して複数の予約手段を提供することが可能である。美容室にとって、集客増加などのためには、なるべく多くの予約手段（その経路）を使用した予約を可能にしておく方が有利である。美容室が複数の予約手段を使用する場合、これらの予約手段の間で、上記のような予約の重複がより発生しやすくなる。そのため何らかの対処・調整などが必要となる。

しかしながら現状、複数の予約手段間における予約の重複を自動的に防止・調整などをする機能・システムは無い。そのため、美容室としては、複数の予約手段を使用する場合、予約の重複に関する対処・調整などのために、相応の人員・手間・コスト等が必要である。例えば美容室の通常のサービス業務を行う店員以外に、複数の予約手段に関する予約の集計・調整などの業務を担当する人員を雇って対応したり、あるいは通常業務と予約業務の両方を兼ねる店員などが生じている。

また逆に、美容室によっては、上記のような人件費などのコストや、サービスレベル低下のリスク等が考えられることから、上記複数の予約手段を使用した予約を利用者に提供することが導入しにくいという面もある。例えば下記のようなネット上の予約サービスサイト（集客ツール）なども数多く存在するが、美容室によっては、上記コストやリスク等の理由から、そのようなサービス（集客ツール）についても、使用（導入）しないか、するとしても数を絞るといった傾向がある。

（４） 上記予約手段の１つとしてネット上の予約サービスサイト（集客ツール）がある。例えばホットペッパービューティー（HOT PEPPER Beauty）（美容サロンの検索・予約サイト。ＵＲＬ：beauty.hotpepper.jp）や、オズモール（OZmall）（女性・ＯＬのための情報サイト。ＵＲＬ：www.ozmall.co.jp）などが挙げられる。いずれも美容サロンの利用の予約の機能を有すると共に、サイトに応じた機能（例えばクーポンやポイントのサービス）を提供している。

（５） 美容サロン等の予約システム（予約管理機能を持つ情報処理システム）に関する先行技術例としては、特開２００４−２９９５９号公報（特許文献１）などがある。特許文献１（「美容室等のデータ処理システム」等）では、課題として「予約のスムーズな受付、一括管理と店舗への通知ができるシステムの提供」等の記載がある。特許文献１では、複数の店舗（美容室）と複数の利用者との間に、予約の一括受付を行うシステムを設けた構成が記載されている。

特開２００４−２９９５９号公報

前述のように、美容サロン側は複数の予約手段を使用可能であり、利用者側は複数の予約手段を利用した予約が可能であるが、従来、それらの間で発生し得る予約の重複を自動的に防止・調整などを図る機能・システム等は提供されていない。そのためそれら全体の効果的な利用が実現できていない。例えば美容室側は、複数の予約手段を使用する場合、予約の重複の対処・調整に関するコストや、サービスレベル低下のリスク等の問題があり、効果的な集客などができていない。

また特許文献１等の先行技術例は、異なる複数の予約手段の間での予約の重複を防止・調整などを図る技術ではないため、前述のような問題が残る。

以上を鑑み、本発明の主な目的は、美容サロン等の予約システムに関して、美容室（店舗）による複数の予約手段の使用の場合による人員・手間・コスト等を低減し、予約の重複によるサービスレベル低下のリスクを低減することができる技術を提供することである。

本発明のうち代表的な形態は、美容サロン等の利用の予約及びその管理を行うための情報処理システム（美容サロン予約システム）等であって、以下に示す構成を有することを特徴とする。本形態では、通信ネットワーク上（クラウド環境など）で、複数の美容室等の店舗と、複数の予約手段との間に、各美容室による１以上の予約手段を使用した予約の提供に関する、予約の統合管理（予約の重複の防止・調整などを含む）を行う機能（予約管理機能）を持つ予約システムを設ける。本予約システムでの予約管理機能の情報処理として、美容室（店舗）側の複数の予約手段を使用した予約の提供に関する取り纏めを行い、複数の予約手段の予約データの受付・集計、振り分け（予約重複チェック及びエラー処理などを含む）、予約結果（予約状況）データ提供、等を行う。

本形態の美容サロン予約システムは、例えば、通信ネットワーク上、複数の美容サロンの店舗の端末と、複数の予約手段との間に、コンピュータで構成される予約システムが接続される。予約手段は、利用者による店舗の利用の予約を受け付ける機能を有する情報処理システムである。予約システムは、複数の各々の店舗との通信インタフェース及びユーザインタフェースを提供する店舗側インタフェース部と、複数の各々の予約手段との通信インタフェース及びユーザインタフェースを提供する予約手段側インタフェース部と、複数の各々の店舗による１つ以上の予約手段を使用した予約の提供に関する統合管理を行う予約管理機能とを有する。予約システムは、予約管理機能として、店舗の端末からの操作に基づき、当該店舗ごとの設定情報を第１のＤＢに登録する第１の処理部と、予約手段からの操作に基づき、当該予約手段ごとの設定情報を第２のＤＢに登録する第２の処理部と、複数の各々の予約手段から予約データを入力する第３の処理部と、入力された予約データについて、第１及び第２のＤＢの情報に基づき、予約の重複をチェックして当該予約を確定させるか否かを判断して予約結果へ出力する第４の処理部と、予約結果のデータを該当する予約手段へ応答する第５の処理部と、予約結果のデータを、該当する店舗の端末へ送付する第６の処理部と、店舗の端末からの要求に応じて予約結果のデータを当該店舗の端末へ応答する第７の処理部と、を有する。

本発明のうち代表的な形態によれば、美容サロン等の予約システムに関して、美容室（店舗）による複数の予約手段の使用の場合による人員・手間・コスト等を低減し、予約の重複によるサービスレベル低下のリスクを低減することができる。

これにより、美容室（店舗）側は、複数の予約手段の使用による効果的な集客などを実現でき、利用者側は、複数の予約手段の利用可能による利便性などを実現できる。予約手段（予約サービスサイト等）は、使用（登録）してもらう美容室（店舗）の獲得・増加ができる。予約システムを運営・提供する事業者は、予約の統合管理のサービスの提供による利益などが得られる。

本発明の一実施の形態のシステム（予約システムを含む）の全体の構成を示す図である。 本発明の一実施の形態の予約システムの構成を示す図である。 本実施の形態のシステムでのデータ情報の構成例などを示す図である。 （ａ），（ｂ）は、本実施の形態のシステムでの美容室側の店舗管理システムの有無に応じた構成・処理例を示す図である。 実施の形態１の予約システムでの処理フローを示す図である。 実施の形態２の予約システムでの処理フローを示す図である。 （ａ）は実施の形態１での予約の具体例、（ｂ）は実施の形態２での予約の具体例を示す図である。 一実施の形態の予約システムでの表示画面例を示す図である。 従来システムでの予約の例を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。

本実施の形態の予約システム（美容サロン予約システム）は、従来システム（図９）に対し、図１〜図４等に示す構成を有し、図５〜図７等に示す処理を行い、例えば図８のような画面（ＧＵＩ）を提供する。本予約システム１では、対象とする美容サロン２で取り扱う特有のデータ構造（例えば施術情報を含む）やその予約の方式、及び異なる複数の予約手段３に対応した、予約の統合管理（予約管理機能１１）のサービスをクラウド環境で提供する構成である。特に予約システム１の予約管理機能１１（図３、予約振分部１０３等）は、複数の予約手段３の予約データで予約が重複する場合、ＤＢの内容によって処理を振り分け、店舗２側の設定情報に基づき、重複許容度の範囲内で予約を確定するように、予約の重複に関する自動的な防止・調整などを図る。

［システム構成］
図１において、本実施の形態のシステムの全体の構成例を示している。本システム全体は、クラウド環境（インターネット、データセンタ等）に構成される予約システム１（美容サロン予約システム）と、複数の美容サロン２（美容室、店舗）と、複数の予約手段３と、複数の利用者４（顧客）とを有し、これらが通信接続される構成である。

予約システム１は、サーバ１０、ＤＢ（データベース）５０、及びその他ネットワーク機器などの公知の要素で構成される。サーバ１０でのソフトウェアプログラム処理などにより、予約管理機能１１、店舗側ＩＦ１２、予約手段側ＩＦ１３などを提供する。予約システム１（サーバ１０）は、複数の物理サーバや仮想サーバ等で構成されてもよい。

予約管理機能１１は、複数の美容室２と複数の予約手段３との間で各美容室２による１つ以上の予約手段３を使用した予約の提供に関する統合管理を行う。ＤＢ５０は、ストレージ装置などを用いて、サーバ１０が管理・処理する各種のデータ情報（後述図２の５１，５２，６１，６２等）が格納される。

店舗側ＩＦ１２は、美容室（店舗）２側に対する通信ＩＦ（インタフェース）やＧＵＩ（グラフィカルユーザインタフェース）を提供する。通信ＩＦとしては、各種方式でクライアント・サーバ通信が可能であり、ＧＵＩとしては店舗２ごとのＷｅｂページ画面（例えば店舗２ごとに異なる機能のメニューを含んだ画面）などを提供する。

予約手段側ＩＦ１３は、予約手段３側に対する通信ＩＦやＧＵＩを提供する。通信ＩＦとしては、本予約システム１と連携する各予約手段３の通信方式に対応し、ＧＵＩとしては、予約手段３側の登録・設定などのためのＷｅｂページ画面などを提供する。予約手段側ＩＦ１３及び予約管理機能１１は、異なる方式の複数の各々の予約手段３と通信してそれら異なる形式のデータ情報を予約システム１で統合的に扱うためのＥＤＩの処理機能を含む。

複数の各々の美容サロン２（例：美容室Ａ，Ｂ，Ｃ）は、端末２０や店員などを有する。端末２０は各種のＰＣやタブレット等であり、店舗２に応じて後述の店舗管理システム（２１）を備える。

複数の各々の予約手段３（例：３１〜３４）は、少なくとも、利用者４による美容室２の利用の予約（仮予約）を受け付ける予約機能を有し、当該予約手段３ごとの機能（システム）に応じて、サーバ・ＤＢ・端末などで構成される。予約システム１と連携する予約手段３については適宜増減可能である。

電話（予約受付）３１は、コールセンタの予約受付サービス（契約した美容室２の予約受付業務を代行するサービス）等及びそれを構成する情報処理システムを示す。利用者４が携帯電話などの端末４０から電話し、オペレータ対応や自動音声応答などに従い予約可能である。

店舗専用ＨＰ３２は、店舗２ごとの専用ＨＰ、及びそれを構成するサーバ等のシステムを示す。利用者４は端末４０から店舗専用ＨＰ３２にアクセスし、その予約ページで、利用の対象となる日時（時間枠）などを指定して予約可能である。更に店舗２に応じて、店員（施術担当者）や施術などを指定して予約可能である。

予約サービスサイト（Ａ）３３は、第１の予約サービスサイト（Ａ）及びそれを構成する情報処理システムを示す。また予約サービスサイト（Ｂ）３４は、第２の予約サービスサイト（Ｂ）及びそれを構成する情報処理システムを示す。各サイト（３３，３４）は、少なくとも、美容室２の利用の予約に関する予約サービスを提供する。利用者４は端末４０から所望のサイト（３３，３４）にアクセスし、その予約サービスのページで、利用の対象となる店舗（地域）や日時などの条件で検索し、検索結果の中から指定して予約可能である。その他、当該サイト（３３，３４）に応じたサービス（例えばクーポンやポイントのサービス）が提供される。

［従来システム］
図９を用いて、従来システムにおける予約の重複などの例について補足説明する。各美容室２は、自店舗での直接の予約を可能とする以外に、図示の例のように利用者４に対する予約手段３を使用（提供）している。例えば美容室Ａは、電話（予約受付）３１を契約で使用している。美容室Ｂは、電話３１、店舗専用ＨＰ３２、予約サービスサイト（Ａ）３３、予約サービスサイト（Ｂ）３４を使用している。美容室Ｃは、予約サービスサイト（Ａ）３３を、美容室Ｄは、予約サービスサイト（Ｂ）３４を使用している。

例えばある利用者Ａが予約手段３として電話３１を利用して美容室Ｂの利用の予約（＃１）をする場合を示す。同様に利用者Ｂが店舗専用ＨＰ３２を利用した予約（＃２）を、利用者Ｃが予約サービスサイト（Ａ）３３を利用した予約（＃３）を、利用者Ｄが予約サービスサイト（Ｂ）３４を利用した予約（＃４）を、それぞれ行う場合を示す。これらの予約（＃１〜＃４）が、例えば美容室Ｂの同じ時間枠に対する予約の要求である場合、重複しているので、対処・調整などが必要である。

なお従来、店舗２内で予約台帳（紙）で予約管理を行う場合、あるいは後述の店舗管理システム（予約管理機能）を用いて予約管理を行う場合、その業務を行う店員は、当該店舗２で使用している予約手段３からの予約の情報を集計し、その情報を予約台帳、あるいは店舗管理システムの予約状況のＤＢなどに記入する。そして予約（要求）の重複がある場合は調整などを行っている。

［予約システム］
図２において、図１の予約システム１の構成例を示している。サーバ１０において、予約管理機能１１を構成する処理部として、登録部１０１、予約データ入力部１０２、予約振分部１０３、予約振分結果応答部１０４、予約結果送付部１０５、予約状況参照・更新部１０６、課金処理部１０７などを有する。ＤＢ５０に格納・管理されるデータ情報として、（店舗側）マスタＤＢ５１、（予約手段側）マスタＤＢ５２、予約データ６１、予約結果６２等を有する。

登録部１０１では、店舗側ＩＦ１２を介して、美容室（店舗）２側からの登録（ａ２）による設定情報（図３、３０１）などをマスタＤＢ５１に登録する。また、登録部１０１では、予約手段側ＩＦ１３を介して、予約手段３側からの登録（ａ１）による設定情報（図３、３０２）などをマスタＤＢ５２に登録する。各マスタＤＢ５１，５２のデータ情報は、１０２以下の予約管理機能１１の処理（詳しくは図５等で示す）の際に用いられる。

予約データ入力部１０２では、予約手段ＩＦ１３を介した通信により、各予約手段３での予約データ（予約情報）（ａ３）を入力（取得）し、予約データ６１として格納する。

予約振分部１０３では、予約データ６１（各予約手段３による予約情報）を参照し、予約確定（ＯＫ）であるか予約重複（ＮＧ）であるか等をチェックして、それに応じて処理を振り分け、予約結果６２に格納（出力）する。その際、予約振分部１０３は、マスタＤＢ５１の内容（予約設定情報など）や、予約結果６２の内容（その時の予約状況）を参照しながら処理を行う。

予約振分結果応答部１０４では、予約手段側ＩＦ１３を介した通信により、各予約手段３へ、上記１０３による予約振分結果（予約確定か否か等）のデータ（ａ４）を応答（送信）する。

予約結果送付部１０５では、各美容室２の端末２０（特に店舗管理システム２１が有る場合はそれに連携する）へ、予約結果６２のデータ（ａ５）を送付する（後述図４（ａ））。

予約状況参照・更新部１０６では、各美容室２の端末２０（特に店舗管理システム２１が無い場合）からの予約状況の参照／更新の要求（ａ６）に応じて、予約結果６２（予約状況）を参照／更新し、そのデータ情報を応答する（後述図４（ｂ））。

課金処理部１０７では、予約結果６２に基づき、例えば予約成立（実績）などに応じた課金計算処理を行い、美容室２等に対する課金情報を発行する。

［ＤＢ（データ情報）］
図３において、本予約システム１のＤＢ５０で管理・処理するデータ情報の例を説明する。まず、美容室（店舗）２毎に、店舗側ＩＦ１２，登録部１０１を介して（店舗側）マスタＤＢ５１へ初期設定などで登録（ａ２）する情報（３０１）として、（ａ）店舗情報、（ｂ）店員情報、（ｃ）施術情報、（ｄ）予約手段情報、（ｅ）予約設定情報などがある。

（ａ）店舗情報は、当該美容室２のＩＤ，名称，連絡先，通信アドレス，予約候補（対象）となる日時（時間枠），その他属性などの情報である。店舗２ごとの店舗管理システム２１の有無などを示す情報を管理してもよい。（ｂ）店員情報は、当該美容室２における施術（サービス）を提供する店員（スタッフ）のＩＤ，名称，出勤日時などの情報である。店舗２に応じて、予約時の指定候補となる店員の情報を含む。（ｃ）施術情報は、当該美容室２で提供する施術（サービス）の情報として、ＩＤ，名称，内容，時間，料金などである。例えばカット，カラー，パーマ，ネイル等、店舗２に応じて提供されるサービスに関する共通のメニューの情報がある。（ｄ）予約手段情報は、当該美容室２が使用し利用者４に対して提供する予約手段３を指定するＩＤ等の情報である。

（ｅ）予約設定情報は、当該店舗２における重複許容度や、予約手段３の優先度などがある。重複許容度は、同じ時間枠などに対する予約の重複の許可（ＯＫ）／不許可（ＮＧ）を設定する２値情報、あるいは、重複許容人数（Ｎとする）などの多値情報である（後述図８等）。例えば重複許容人数Ｎ＝２の場合は、同じ時間枠で２人までなら予約を許可することを示す（後述図７等）。なお重複許容度として重複許容人数（Ｎ）のみの管理としてもよい（例えばＮ＝０の場合は予約不可を示し、Ｎ＝１の場合は１人のみ予約可能すなわち重複不許可を示すことになる）。その他、店舗２毎の店舗管理システム２１の有無（すなわち連携／統合などの種別や処理方式）などの設定情報を管理してもよい。なお後述図８の画面では、上記３０１のような設定情報に対応した例を示す。

また、予約手段３毎に、予約手段側ＩＦ１３，登録部１０１を介して（予約手段側）マスタＤＢ５２へ初期設定などで登録（ａ１）する情報（３０２）として、（ａ）予約手段情報、（ｂ）予約設定情報などがある。（ａ）予約手段情報は、予約手段３のＩＤ，名称，種別，通信アドレスなどの情報である。（ｂ）予約設定情報は、例えば当該予約手段３での予約の方式などの情報である。

また、予約データ６１や予約結果６２の内容に含まれる、１件ごとの予約情報（３０３）の構成としては、（ａ）利用者情報、（ｂ）予約手段情報、（ｃ）予約対象情報などがある。（ａ）利用者情報は、当該予約（仮予約または確定予約）をしている利用者４を示すＩＤ等である。（ｂ）予約手段情報は、当該利用者４が予約に利用した予約手段３を示すＩＤ等である。（ｃ）予約対象情報は、予約対象（予約内容）となる店舗（美容室）２，日時（時間枠）などの情報である。更に店舗２に応じて、予約指定の店員（施術担当者）や施術を示すＩＤ等の情報が含まれる。

なお図３で、ａ３は、予約手段３での仮予約（未確定）の予約データを示し、ａ４は、予約振分結果の応答として、確定予約または仮予約取り消し等のデータを示す。ａ３の予約データの入力に対し、予約振分部１０３の処理では、予約重複チェック等が行われ、同じ時間枠などに対して予約（仮予約）が重複する場合は、マスタＤＢ５１等の内容（上記予約設定情報など）に応じて処理を振り分ける。即ち、重複許容度（重複許容人数Ｎなど）の範囲内であれば予約が確定（許可）され、範囲外であれば仮予約の取り消し（不許可）となる。この結果がａ４として応答される。ａ４の応答を受けた予約手段３は、自分の管理する予約状況のＤＢ等に対してａ４の内容を反映する。

［店舗管理システムの有無］
図４（ａ）は、店舗２側に店舗管理システム２１（予約管理機能を含む）が有る場合の構成・処理例を示す。この場合、予約システム１（予約結果送付部１０５など）と店舗２側の店舗管理システム２１とで連携して予約管理を行う形態となる。

店舗管理システム２１は、例えば美容室２の端末２０にインストールされるパッケージソフトウェア等で構成される。この店舗管理システム２１は、少なくとも当該店舗２内の予約管理機能を含み、予約状況７１のデータ情報を含むＤＢを管理する。店舗管理システム２１の予約管理機能は、当該店舗２での予約状況・スケジュール等を予約状況７１のＤＢに管理する。

店舗管理システム２１は、その他の機能、例えばレジ・販売管理、店員管理（出勤管理など）、施術管理（カタログ機能など）、顧客管理（個人情報及び施術履歴管理など）、販促管理（メール配信など）、店舗専用ＨＰ管理機能、等を備えてもよい。なお上記店舗管理システム２１のその他の各機能については、予約システム１側に統合した形態としてもよい。即ちサーバ１０で各機能をＷｅｂサービスとして提供し、店舗２は端末２０から所望の機能（メニュー）を選択して利用可能である。

図４（ａ）で、サーバ１０の予約結果送付部１０５は、予約結果６２のデータを更新に伴い即時に該当の店舗２の端末２０の店舗管理システム２１へ送付する（ａ１）。店舗管理システム２１は、送付されたデータ（ａ１）を自身の予約状況７１のＤＢへ反映（更新）する。当該店舗２の店員は、端末２０で店舗管理システム２１による画面を参照し、随時、予約状況７１を確認することができる（ａ２）。また、当該店舗２で直接（店内や電話など）の予約が入った場合は、当該店舗管理システム２１の予約状況７１に反映（更新）される（ａ２）。更に、このように店舗管理システム２１側の予約状況７１の更新の場合は、サーバ１０側へその更新情報を送信して、予約結果６２（予約状況を示す）を更新させるようにしてもよい。

予約結果６２及び予約状況７１に対応するＤＢ（テーブル等）には、図示する４０１のような予約状況（スケジュール）の情報が含まれている。４０１の予約状況（スケジュール）は、時間枠ごとに予約情報（図３の３０３と対応する）が格納（記入）されるイメージを示している（実際のデータ形式は任意でよい）。時間枠のうち、白枠は空き（予約無し）、斜線枠は予約有りを示す。なお４０１は、業務予定のスケジュール情報としても捉えることができる。なお勿論、上記予約結果（予約状況）６２のデータ情報をもとに別途スケジュール情報を構成し管理しても構わない。

図４（ｂ）は、店舗２側に店舗管理システム２１（予約管理機能を含む）が無い場合の構成・処理例を示す。この場合、予約システム１内に当該店舗２の予約管理機能を統合した形態となる。

店舗２の店員は、予約状況を参照（確認）したい場合は、端末２０のＷｅｂブラウザ２２等からサーバ１０にアクセスし要求する（ｂ１）。この際、店舗側ＩＦ１２では予約状況の参照などのメニューを含む画面を提供し、店員は画面で予約状況の参照（確認）などを選択する。要求（ｂ１）を受けて、予約状況参照・更新部１０６では、予約結果６２のデータ（４０２）を参照し、それを表示する画面（Ｗｅｂページ）のデータを構成し、当該店舗２の端末２０へ応答（送信）する。これにより店員は画面で予約状況の参照（確認）などができる。予約結果６２（予約状況）は、４０１と同様に、４０２のような予約状況（スケジュール）のデータ情報を含んでいる。

また、店舗２側で直接の予約が発生した場合には、上記同様に端末２０からサーバ１０にアクセスし、予約状況参照・更新部１０６の処理により、予約結果６２のデータに対してその予約分を反映（更新）する（ｂ２）。

上記図４（ａ），（ｂ）のように、本予約システム１は、店舗２ごとの店舗管理システム２１の有無に応じた対応（サービス）が可能であり、それらは並存可能である。店舗２は既存の店舗管理システム２１を使用し続けることもできるし、店舗２内には設けずにクラウド上に統合することもできる。

以下、上記実施の形態の構成に基づくより詳しい実施の形態１，２を説明する（基本構成は同様である）。

＜実施の形態１−処理＞
図５は、実施の形態１の予約システム１の処理（第１処理フロー）を示す。実施の形態１（第１処理フロー）は、図２のように各予約手段３に対して予約振分結果の応答（ａ４）を返す場合の詳しい形態を示す。図３のように各予約手段３から入力する予約データ（ａ３）の内容が仮予約の情報のときに、サーバ１０（１０３）での処理に基づき、各予約手段３への予約振分結果の応答（ａ４）として、確定予約などの情報をリアルタイムで返して各予約手段３内に反映させる方式である。以下S101等はサーバ１０での処理ステップを示す。なお予め登録部１０１を通じて各マスタＤＢ５１，５２に情報が設定されているとする。

（S101） 予約データ入力部１０２は、リアルタイムで順に、複数の各々の予約手段３からの予約データ（ａ３）を取得（入力）し、予約データ６１として格納する。１０２は、予約手段３での予約発生に伴いリアルタイムに予約データを取得する。あるいは所定タイミングごとにまとめて複数の予約手段３の予約データ（ａ３）を取得（入力）してもよい。

（S102） 予約振分部１０３は、S101で入力された予約データ６１（複数の予約情報）を参照し、予約振り分け処理（予約重複チェック、エラー処理などを含む）を行う（図３）。１０３は、ＤＢ５０の予約設定情報などに基づき、予約情報（３０３）の１件ごとに、その利用者４による登録日時の早い順に、当該予約（仮予約）を確定（ＯＫ）としてよいかどうか、予約重複（ＮＧ）かどうかを判断し、処理を振り分ける。なおここ（S102）ではまず重複許可／不許可の２値で判断し振り分ける処理例とする。１０３はこの結果を一旦予約結果６２（あるいは一時的な記憶領域）に格納する。

（S103） 更に予約振分部１０３は、S102の結果について、上記予約重複（ＮＧ）の場合は、より詳しく判断・調整する。１０３は、当該予約情報（１件）につき、店舗２の予約設定情報における対象の時間枠の重複許容人数（Ｎ）を参照し、その人数（Ｎ）以内である場合は、当該予約を許可（ＯＫ）、即ち確定とし、その人数（Ｎ）を超える場合は、当該予約を不許可（ＮＧ）、即ち仮予約を取り消しとする。そして１０３は結果を予約結果６２へ格納する。なおS102，S103を１つにまとめて処理するようにしてもよい。

（S104） 予約振分結果応答部１０４は、S102,S103の予約振分結果（予約結果６２）のデータ（予約確定／仮予約取り消し等）を、対応する予約手段３に対して応答（送信）する（ａ４）。S101〜S104の流れはリアルタイム処理である。

次に、サーバ１０（１１）は、店舗２側の店舗管理システム２１の有無に応じて以下の処理を行う。２１が有りの場合はS105、２１が無しの場合はS106へ移る。

（S105） 予約結果送付部１０５は、S104の予約結果６２のデータ（予約情報）を、更新に伴い即時に、該当（予約対象）の店舗２の店舗管理システム２１へ送付する（図４、ａ１）。当該店舗２の店舗管理システム２１は、送付された予約結果６２のデータ（予約情報）を、自身の予約状況７１のＤＢへ反映して最新の状態にする。

（S106） 予約状況参照・更新部１０６は、店舗２側からの予約状況の参照／更新の要求（図４、ｂ１）を受けた場合は、予約結果６２のデータ（予約情報）を参照／更新し、その結果を当該店舗２へ応答する。以上、予約情報ごとに同様の処理の繰り返しである。

［具体例（１）］
図７（ａ）は、実施の形態１の第１処理フローの場合の予約の具体例を示す。ある美容室Ｂの予約対象（空き状態）の時間枠（Ｔ）に関して、利用者４（Ａ〜Ｄ）による登録（要求）の順で予約（予約情報）＃１〜＃４が発生したとする。それぞれの予約情報＃１〜＃４の予約手段は３１，３２，３３，３４とする（図９対応）。また当該店舗（Ｂ）での当該時間枠（Ｔ）に関する、重複許容人数Ｎの設定値が２（同じ時間枠で２人までなら重複の予約を許可する設定）とする。第１処理フローの場合、前述のように登録順（入力順）にリアルタイムで判定処理する。よって、Ｎ＝２により、予約＃１，＃２までは予約結果がＯＫ（許可）となり、＃３，＃４はＮＧ（不許可）となる。

＜実施の形態２−処理＞
図６は、実施の形態２の予約システム１の処理（第２処理フロー）を示す。実施の形態２（第２処理フロー）は、図２のような各予約手段３に対する予約振分結果の応答（ａ４）を返さない場合の形態を示す。図３のように各予約手段３から入力する予約データ（ａ３）の内容を、仮予約ではなく確定予約として取り扱う。サーバ１０でのバッチ処理で予約重複チェック等を行う。また実施の形態２では、複数の予約手段３の優先度の設定を用いて処理を行う。

予め、店舗２は、図３の予約設定情報で、使用する複数の予約手段３に関する優先度を設定する。例えば図９の例のように美容室Ｂが４つの予約手段３（３１〜３４）を使用する場合に、所望の優先順を設定する（後述図７（ｂ））。

（S201） 予約データ入力部１０２は、所定タイミング（所定日時や所定間隔など）で同期的に複数の予約手段３の予約データ（ａ３）を取得・入力し、予約データ６１として格納する。なお予約手段３に応じて新規の予約データが無い場合も含む。

（S202） 予約振分部１０３は、S201で入力された予約データ６１（複数件の予約情報）を参照し、予約振分処理（予約重複チェック、エラー処理など）を行う。予約対象が同じ店舗２の時間枠となる予約情報ごとにチェック・判断する。ここでは１回のタイミングで入力した複数件の予約情報の登録日時は同じ扱いとする。１０３は、該当店舗２の予約設定情報における予約手段の優先度を参照し、これらの複数の予約情報を、優先度の順で、予約確定（ＯＫ）か予約重複（ＮＧ）かを判断して処理を振り分け、結果を格納する。

（S203） 更に予約振分部１０３は、S202の結果について、前記S103と同様に、重複許容人数（Ｎ）に照らして、予約許可（ＯＫ）／不許可（ＮＧ）を判断し、予約結果６２へ格納する。以上S201〜S203は所定タイミングごとのバッチ処理である。

次に、実施の形態２では、前記S104のような予約手段３への応答は返さずに、以下、サーバ１０（１１）は、実施の形態１と同様に、店舗２側の店舗管理システム２１の有無に応じて処理を行う。

（S204） 予約結果送付部１０５は、S203の予約結果６２のデータ（予約情報）を、即時に、該当（予約対象）の店舗２の店舗管理システム２１へ送付する。当該店舗２の店舗管理システム２１は、送付された予約結果６２のデータ（予約情報）を、自身の予約状況７１のＤＢへ反映して最新の状態にする。

（S205） 予約状況参照・更新部１０６は、店舗２側からの予約状況の参照／更新の要求を受けた場合は、予約結果６２のデータ（予約情報）を参照／更新し、その結果を当該店舗２へ応答する。以上、予約情報ごとに同様の処理の繰り返しである。

［具体例（２）］
図７（ｂ）は、実施の形態２の第２処理フローの場合の予約の具体例を示す。ある美容室Ｂの予約対象（空き状態）の時間枠（Ｔ）に関して、図７（ａ）と同様の予約情報＃１〜＃４が発生したとする。重複許容人数Ｎ＝２とする。また当該店舗（Ｂ）での予約手段３の使用に関する優先度の設定が｛３３，３４，３１，３２｝の優先順であるとする。第２処理フローの場合、前述のように所定タイミングの入力データ毎に、優先度に従って判定処理する。優先度に基づき、予約＃３，＃４を優先して予約結果がＯＫ（許可）となり、予約＃１，＃２がＮＧ（不許可）となる。

＜実施の形態３＞
他の実施の形態（実施の形態３）の予約システム１の構成・処理例は以下である。実施の形態３では、基本構成は実施の形態２と同様とし、各予約手段３に対し予約振分結果の応答は返さない構成とする。サーバ１０（１１）では、複数の予約手段３による入力の予約情報について予約重複チェック等を同様に行い、サーバ１０から該当の各店舗２（店舗管理システム２１の有無に拠らない）へ予約結果６２のデータ（予約情報）を即時に送付して、店舗２側（例えばディスプレイ）で即時に表示させ保存させる。これにより店舗２では、店員は、複数の予約手段３による予約情報（予約重複チェック済み）を即時に確認することができる。店員は、その予約情報を見て、予約が重複しているかどうか、当該予約を確定するかどうかをその都度判断する。そして、店舗２の店員から該当の予約した利用者４へ、予約確定かどうか等を連絡して調整する。

［画面例］
図８は、本実施の形態（図１〜図３等）の予約システム１において店舗２側が設定情報（３０１）を登録（ａ２）する場合に提供する画面例を示す。図８の画面のように、店舗２、店員（スタッフ）、施術（サービス）などの情報を設定可能である。詳細ボタンで詳細情報を設定可能である。また使用する予約手段３の情報を設定可能である。例えば予約システム１が用意するリストから所望の予約手段３を選択して設定可能である。また予約設定情報として、前述の重複許容度における許可（ＯＫ）または不許可（ＮＧ）や、重複許容人数（Ｎ）などを選択して設定可能である。また前述の予約手段３の優先度を設定可能である。優先度は例えば「無し」が設定可能であり、また使用する予約手段の欄で設定されている順に設定可能としてもよい。

［効果等］
以上説明したように、本実施の形態によれば、クラウド環境の予約システム１で予約の統合管理のサービスを提供することで、各美容室（店舗）２による１つ以上の予約手段３を使用した予約の提供に関する人員・手間・コスト等を低減し、予約の重複によるサービスレベル低下のリスクを低減することができる。これにより、美容室（店舗）２側は、複数の予約手段３の使用による集客効果を実現でき、利用者４側は、複数の予約手段３の利用可能による利便性などを実現できる。予約手段３（例えば予約サービスサイト（Ａ）３３）は、使用（登録）してもらう美容室（店舗）２の獲得・増加ができる。予約システム１を運営・提供する事業者は、予約の統合管理のサービスの提供による利益など（例えば予約の成立に応じた課金や、予約システム１と連携する店舗管理システム２１の拡販など）が得られる。

また特に前記図４のように店舗２側の店舗管理システム２１の有無に応じて連携や統合のサービスが可能でありそれらが並存可能である。予約システム１の事業者は、連携の場合は、店舗２に対して、予約システム１のサービス提供と共にそれと連携する店舗管理システム２１の提供も可能である。また特に多店舗展開している美容サロン等の場合は、予約システム１でそれら複数の店舗２に関して予約の統合管理をすることにより、多店舗での情報共有が可能である。また特に各美容室２は予約システム１のサービスへの登録（加入）・設定がＧＵＩを通じて容易にできるので、複数の各予約手段３の試用や導入、解除などがしやすい。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本発明は、美容サロンやネイル・エステ等の複合サロン等を含む、予約を管理するサービス業などに利用可能である。

１…予約システム（美容サロン予約システム）、２…美容サロン（店舗）、３…予約手段、４…利用者、１０…サーバ、１１…予約管理機能、１２…店舗側ＩＦ、１３…予約手段側ＩＦ、２０…端末、２１…店舗管理システム、２２…Ｗｅｂブラウザ、３１…電話、３２…店舗専用ＨＰ、３３…予約サービスサイト（Ａ）、３４…予約サービスサイト（Ｂ）、４０…端末、５０…ＤＢ、５１…（店舗側）マスタＤＢ、５２…（予約手段側）マスタＤＢ、６１…予約データ、６２…予約結果、７１…予約状況、１０１…登録部、１０２…予約データ入力部、１０３…予約振分部、１０４…予約振分結果応答部、１０５…予約結果送付部、１０６…予約状況参照・更新部、１０７…課金処理部。

Claims (8)

1. 美容サロン予約システムであって、
   通信ネットワーク上、複数の美容サロンの店舗の端末と、複数の予約手段との間に、コンピュータで構成される予約システムが接続され、
   前記予約手段は、利用者による店舗の利用の予約を受け付ける機能を有する情報処理システムであり、
   前記予約システムは、
   前記複数の各々の店舗との通信インタフェース及びユーザインタフェースを提供する店舗側インタフェース部と、
   前記複数の各々の予約手段との通信インタフェース及びユーザインタフェースを提供する予約手段側インタフェース部と、
   前記複数の各々の店舗による１つ以上の予約手段を使用した予約の提供に関する統合管理を行う予約管理機能と、を有し、
   前記予約システムは、前記予約管理機能として、
   前記店舗の端末からの操作に基づき、当該店舗ごとの設定情報を第１のＤＢに登録する第１の処理部と、
   前記予約手段からの操作に基づき、当該予約手段ごとの設定情報を第２のＤＢに登録する第２の処理部と、
   前記複数の各々の予約手段から予約データを入力する第３の処理部と、
   前記入力された予約データについて、前記第１及び第２のＤＢの情報に基づき、予約の重複をチェックして当該予約を確定させるか否かを判断して予約結果へ出力する第４の処理部と、
   前記予約結果のデータを該当する予約手段へ応答する第５の処理部と、
   前記予約結果のデータを該当する店舗の端末へ送付する第６の処理部と、を有すること、を特徴とする美容サロン予約システム。
2. 請求項１記載の美容サロン予約システムにおいて、
   前記予約システムは、前記予約管理機能として、
   前記店舗の端末からの要求に応じて前記予約結果のデータを当該店舗の端末へ応答する第７の処理部を有すること、を特徴とする美容サロン予約システム。
3. 請求項１記載の美容サロン予約システムにおいて、
   前記店舗の端末は、当該店舗内の予約状況を管理する機能を含む店舗管理システムを有し、
   前記第６の処理部は、前記予約結果のデータを、即時に、該当する店舗の端末の店舗管理システムへ送付し、
   前記店舗管理システムは、前記送付された予約結果のデータを前記店舗内の予約状況に反映すること、を特徴とする美容サロン予約システム。
4. 請求項２記載の美容サロン予約システムにおいて、
   前記第７の処理部は、前記店舗側での直接の予約の発生の場合に、前記店舗の端末からの予約の情報を受け、前記予約結果のデータに反映して更新し、当該店舗の端末へ応答すること、を特徴とする美容サロン予約システム。
5. 請求項１記載の美容サロン予約システムにおいて、
   前記第１の処理部は、前記第１のＤＢに格納される前記店舗ごとの予約設定情報として、同じ時間枠での予約の重複を許容する度合いを示す重複許容度を設定可能とし、
   前記第４の処理部は、前記入力された予約データについて、前記店舗ごとの予約設定情報の重複許容度に基づき、予約の重複をチェックして当該予約を確定させるか否かを判断すること、を特徴とする美容サロン予約システム。
6. 請求項１記載の美容サロン予約システムにおいて、
   前記第３の処理部は、前記複数の各々の予約手段からの予約データとして仮予約の予約情報を入力し、
   前記第４の処理部は、前記仮予約の予約情報について、当該仮予約を確定させるか取り消すかを判断して予約結果へ出力し、
   前記第５の処理部は、前記予約結果のデータとして、前記確定または取り消しの情報を前記予約手段へ応答し、
   前記予約手段は、前記予約システムからの応答の情報を当該予約手段での予約状況に反映すること、を特徴とする美容サロン予約システム。
7. 請求項１記載の美容サロン予約システムにおいて、
   前記第１の処理部は、前記第１のＤＢに格納される前記店舗ごとの予約設定情報として、当該店舗が使用する複数の予約手段における優先度を設定可能とし、
   前記第４の処理部は、前記入力された予約データについて、前記店舗ごとの予約設定情報の優先度に基づき、予約の重複をチェックして当該予約を確定させるか否かを判断し予約結果へ出力すること、を特徴とする美容サロン予約システム。
8. 請求項１記載の美容サロン予約システムにおいて、
   前記予約システムは、前記予約結果のデータを参照し、予約の成立に応じて店舗に対する課金計算処理を行う課金処理部を有すること、を特徴とする美容サロン予約システム。

Images