SCENARIO ── RYOKAN BREAKFAST CASE
朝食の予約と実際の来場記録から、利用人数と混雑時間を予測する開発案です。厨房とホールの担当者が料理の準備量と配置人数を確認します。客室10〜30室の宿で、約3ヶ月の導入を想定します。
OVERVIEW
朝食付きの予約人数と実際の来場人数・時刻を比較するシステムです。予約の変更・早朝出発・当日の追加を記録し、翌朝の準備量を決める材料にします。
炊飯のように追加に時間がかかる品目と、営業中に補充できる品目を分けて管理します。利用中の予約管理ソフトから取得できる項目を確認し、小規模な宿でも続けられる入力方法を決めます。
CHALLENGE
APPROACH
予約台帳から朝食の有無・人数構成・連泊日数・団体予約・チェックイン時刻を確認します。朝食会場では部屋番号・来場人数・時刻を記録します。記録がない宿は紙の一覧から始め、1ヶ月で入力負担を確認します。予測は「38人中32〜35人」のように範囲で示し、変更理由も記録します。
15分ごとの来場予測を使い、炊き上がり時刻・先に準備する料理・ホールの配置人数を担当者が決めます。事前に量を決める炊飯・出汁と、来場状況に合わせて追加する焼き物・小鉢を区別します。アレルギー対応食や子ども用の食事は予約内容を個別に確認し、必要な数量を確保します。
CONSULTATION
予約台帳から確認できる内容と、厨房・ホールで記録する項目を一緒に整理します。
準備量や混雑時間のうち、困っている仕事に必要な機能から検討できます。
SCREENS
前夜にフロントのパソコンで予約と予測を確認し、朝は食堂のタブレットで来場を記録する画面例です。旅館名・部屋番号・人数は想定例で、実在の宿や実績ではありません。
前夜にフロントで確認する画面です。朝食付きの宿泊者数と実際に来場すると予測した人数を並べ、15分ごとの来場人数も表示します。団体・連泊・家族連れなどの区分ごとに、予測の根拠を添えます。
予測人数から米・味噌汁・鮭の準備量を計算します。営業前に量を決める品目と、来場状況を見て追加できる品目を分け、担当者が予約人数と提供内容を確認して数量を確定します。
担当者が当日の部屋番号・来場人数・時刻を記録し、予測人数とまだ来場していない部屋を確認します。追加炊飯や小鉢への切り替えは、調理時間と締切を確認して判断します。
実際の人数が予測の範囲に収まった朝・外れた朝を並べ、外れた朝には理由メモを残す画面。団体の出発予定や食事の変更など、その日の状況を記録します。特定の客層が必ず同じ行動をするとは扱わず、実際の予約・来場記録から傾向を確認します。ご飯の余りの推移も同じ画面で追えます。
OUTCOME
担当者の見込みとAIの予測を並べ、実際の人数と比べられるようにします。仕込み量や人員配置を見直す際に使います。
担当者の見込みも残して、AIの予測や実際の人数と比較します。最終的な仕込み量は宿の担当者が決めます。
一律に多めに用意していた数量を、品目ごとに見直します。余りを完全になくすことはできませんが、不足を避けたい品目は、朝食の予約内容に合わせて数量を確保します。
来場予測から座席の割り当て・焼き物の調理開始時刻・応援スタッフの配置を前夜に検討できます。
PROCESS
開発期間は約3ヶ月を想定しています。予約情報と記録の状態を確認して日程を決め、オンラインと宿への訪問を組み合わせて進めます。月ごとに操作できる画面をお渡しし、フロントと厨房の担当者が実際の名簿で確認します。
前夜の予約確認、朝の炊飯・調理・料理の補充、残ったご飯の記録までを確認します。手書き台帳・Excel・予約管理システムから取得できる項目を調べ、取り込み方法を決めます。この月から来場人数と時刻を記録し、予測に使う実績をためます。最初は紙の一覧を使う方法も検討します。
1ヶ月分の来場記録と過去の予約台帳で予測を試作し、開発に使った日とは別の日の記録で予測と実績を比較します。記録が不足する場合は予約数と集計の確認から始めます。予測人数・準備量・当日の来場記録の画面を作り、厨房で使う升・切れなどへの換算方法を担当者と確認します。
従来の準備量を維持しながらAIの予測と実際の来場を2週間比較します。差が大きかった日の理由を確認し、端末の置き場所や入力方法を調整します。提供に支障のない範囲で準備量を見直し、来場記録を継続する手順を引き継ぎます。
FAQ
RELATED
予約台帳から確認できる内容と、厨房・ホールで記録する項目を一緒に整理します。
準備量や混雑時間のうち、困っている仕事に必要な機能から検討できます。