宿泊サイトの子供料金設定
記事のネタに書こうと、事前確認にいくつかの（店舗の直予約の）サイトを見てみたけど、やっぱりというか整理されていないところが多いなと。。。
しばらく、宿泊業界で社内SEとしてやってきました。
印象としては、業種としては最古からある基本的なサービス業ですが、他業種（小売りなど）と比較しても、システム的な業界フォーマットが出来ておらず、それぞれ（の店舗・企業）が試行錯誤のまま、今の現状になっていると思います。
システム的な業界フォーマットというのは、
店舗管理にはPMS（ホテル管理システム）というものはありますが、
OTA（じゃらんや楽天トラベルといった総合予約サイト）やAGT（各種旅行代理店）とのシステム連携、
日次の売上実績や現金管理のためのPOSや会計システム連携、
宿泊人数に合わせた在庫管理や備品の受発注管理連携、
レベニューマネージメントや実績分析のためのBIツール連携、
こういったものをトータルに提案できるベンダーもコンサルもなく（あるかもしれないけど。口先営業だけでない本物はお目にかかれなかった。）、それぞれのベンダーの担当分野のサービスを集め、連携部分は、最終的には店舗責任の人海戦術ということです。
このシステム連携のフォーマットを、システム的制約・業務フローまで考えてうまく整理して設定しているグループ企業と、店舗もしくは担当者任せで管理できていないところがある思われます。
管理できてないところはどうなるかというと、値決め設定が曖昧だったり、無駄な手作業が発生していたり、グループ企業でも横串の分析ができていないことになります（PMSも統一されていない可能性が高い）。
で、本題の子供区分の話。
大人は、人数だけの管理（あってもアメニティーを分けるため男女の性別）ですが、子供は、食事の有無（子供メニューの選択）、布団／添い寝と、管理する項目が増えます。
食事の有無やメニューは食材に影響しますし、布団の有無はベット数や和室の布団の数（定員数）に影響します。
なので、子供区分はかなり煩雑なものだったりします。
業界的なフォーマットがないといいましたが、PMSやOTAには、TravelXMLというデータフォーマットがあり、他システム連携できるところは、これに準拠としているところがほとんどです。
※TravelXMLについては、話が長くなると思うのでいつか。
TravelXMLでは、子供区分はA/B/C/Dの4区分に収められます。
だから、OTAもそれに縛られるのですが、それぞれの予約サイトが子供区分に特徴を付けようと項目を増やした結果、一部参考までに、下記のようになっています。
| 子供区分（TravelXML） | じゃらん | 楽天トラベル |
| A | 小学生 | 小学生（高学年） |
| 小学生（低学年） | ||
| B | 幼児（食事・布団あり） | 幼児（食事・布団あり） |
| 幼児（食事あり） | 幼児（食事あり） | |
| C | 幼児（布団あり） | 幼児（布団あり） |
| D | 幼児（食事・布団なし） | 幼児（食事・布団なし） |
他のOTAも大体このパターンのどれかになっていると思います。
これによって何があるかというと、『幼児（食事・布団あり）』と『 幼児（食事あり）』に区別がないという点。また、各店舗のホームページ上の予約サイトの子供区分が、OTAとも全く違う独自区分の場合、店舗で予約担当者が目検で確認し、PMSを手作業で変更していると思います。
『店舗責任の人海戦術』の箇所です。
そもそも、料金帯はシステム的に制限されるべきものではありませんが、『TravelXML』で子供区分を自由に増やせるようになることは当分ないと思いますので、これが標準仕様になります。
これを理解した上で、『店舗責任の人海戦術』による作業量やPMS入力ミスによるクレーム対応、これらも天秤にして、独自料金帯を採用していればよいですが、価格決定と予約管理で担当が分かれている場合、予約サイト管理のところで歪みが出ます。
予約サイトで、子供人数の入力項目がそもそもなかったり、中途半端に区分に当てはまらない年齢帯があったり、OTAと区分や宿泊金額が違っていたりする場合、直接電話で確認するお客様より、選択肢から外してしまうご家族が多いのではないかと思うのですが、どうでしょうか？
