複数店舗のメニュー変更と売上集計を一元管理

静岡駅前と郊外店では、売れる時間帯も客単価も違います。それでもメニュー変更と売上集計を店ごとの表計算や連絡アプリに任せると、価格の直し忘れや集計のズレが起きやすい。NIR株式会社で店舗業務の相談を受ける私も、仕組みより先に『誰が、いつ、どこまで直したか分からない』状態を整えるところから入ります。

店ごとの表が増えるほど、同じ商品が別物になる

よくあるのは、本部が新価格を送ったのに、清水の店舗では古い表が残り、静岡駅近くの店舗だけ先に変更されているケースです。ランチ表、店内端末、注文用画面、厨房の控えを別々に直していると、一か所は抜けます。

売上側でも同じです。ある店は「生ビール」、別の店は「生中」、もう一店は商品番号だけ。名称が揃っていなければ、全店合計を出すたびに人が読み替えることになります。月末に数字を合わせる作業が増え、店長が数字を見る頃には次の月に入っている。これでは仕入れや人員配置の判断が後手に回ります。

多店舗管理の土台は、全商品に共通の商品番号を付けた「商品台帳」です。立派なシステムを入れても、ここが曖昧だと集計は整いません。私は導入前に、現在使っているメニュー表と売上データを店舗別に並べ、同じ商品と店独自の商品を切り分けます。

桜えびやしらすなど、仕入れ状況で提供を止める品は、削除ではなく一時停止にします。削除すると過去の売上まで追いにくくなるためです。税込・税別の扱い、値引き後の金額をどちらで記録するかも、この段階で固定します。

電話や口頭での変更依頼は速そうに見えて、後から確認できません。変更内容は本部または権限を持つ担当者が一か所へ登録し、確認者と反映日時を残します。店長は公開前の内容を確認し、問題があればその場で差し戻す流れです。

大型連休や静岡まつりの前後は、期間限定メニューと通常メニューが重なりがちです。開始日だけでなく終了日も先に入れておくと、出しっぱなしを防げます。現場が忙しい時間に更新作業をさせないことも大事です。

日付が変わってから閉店する店では、午前1時の会計を暦どおり翌日にするか、前日の営業分に含めるかで日報が変わります。駅前店と郊外店で締め時刻が違うなら、暦日ではなく店舗ごとの営業日を持たせます。ここを決めずに比較すると、週末の売上が別日に割れてしまいます。

集計には売上だけでなく、取消、返品、値引き理由も残します。たとえば客数は増えたのに粗い利益感が下がった場合、特定商品の値引きが多いのか、販売構成が変わったのかを確かめられるからです。店舗別、商品別、時間帯別へ同じ元データから切り替えられれば、店長ごとの手作業も減らせます。

原価データまでそろう店舗なら、売上高だけでなく商品ごとの粗利額も判断材料になります。ただし原価は仕入れで動くため、更新担当と見直し頻度を決めてから使うのが安全です。

全店を一晩で切り替える必要はありません。一般的な目安として、最初の一週間は現在の変更経路と締め作業を観察し、次に商品台帳を整えます。その後、一店舗で新旧の数字を照合。問題がなければ対象店を増やします。

確認したいのは、数字が合うかだけではありません。予約品の扱い、セット商品の内訳、まかないや廃棄、現金過不足など、その店特有の処理が抜けていないか。草薙の小型店と焼津方面の大型店で同じ操作を強いるより、共通ルールを保ちながら権限や画面を役割別にする方が現場に定着します。

導入効果は「便利になった」で終わらせず、価格変更にかかった時間、修正件数、月次集計の所要時間を切り替え前後で測ります。二か月ほど見れば、続ける設定と直す運用が見えてきます。期間は店舗数や既存データ量で変わるため、あくまで目安です。

NIR株式会社は静岡市駿河区を拠点に、飲食店向けのMenuOSを含む業務システムの開発と運用支援を行っています。既存の注文機器を全部入れ替える前提ではなく、今あるデータを生かせるか、どこを共通化すると負担が減るかを現場と一緒に確認します。

表計算の整理だけで足りる場合もありますし、店舗数や更新頻度によっては専用の管理画面が合う場合もあります。判断材料がまだ揃っていない段階でも、現在のメニュー表や日報を見ながら整理できます。システム導入・開発を無料で相談するから、店舗数と困っている作業をお聞かせください。