売上を時間帯別に見る|1日の合計では人の配置は決まらない

1日の合計だけが届く本部の数字と、1時間ごとに切った売上の山と谷の対比

【結論】
1日の売上合計は、結果だけを伝えて、その結果がどこで作られたのかを伝えません。シフトは1時間の単位で組むのに、本部に返ってくる数字は1日1行——ここがずれている限り、人の配置も仕込みの量も、勘で決めるしかありません。TEAL BIは1件ずつの取引データを受け取るので、全店の売上・客数を1時間ごとに切って、前日ぶんを翌朝そろえます。ランチとディナーを分けて評価することも、雨が降った時間と売上の谷を重ねて見ることもできます。

【この記事でわかること】
・同じ日商でも、1日の形は店ごとに違うということ
・「静かでした」という報告を、時間の位置で特定する方法
・人を減らす話ではなく、動かす話であること
・雨や曜日が、時間帯によって効き方を変えること
・料金と、実際に本番稼働している連携先の一覧

シフトは時間で組むのに、数字は1日1行で返ってきます

シフトは1時間の単位で組むのに、返ってくる数字は1日1行

いまの状態

本部に届くのは、結果だけ

  • 8月20日(水)A店
  • 売上 312,000円
  • 客数 186人
  • → 1日のどこで作られたかは分からない
TEAL BI

1時間ごとに切って、翌朝そろう

  • 11時から22時まで、1時間ごと
  • 売上・客数・人件費を同じ日付で
  • 全店ぶんが1枚に並ぶ

判断は「今日1日」ではなく「今日の何時」で下ろされる。数字の粒度が、判断の粒度に届いていない。

図1:本部に届く数字の粒度(左)と、TEAL BI が返す粒度(右)。数値は作図用の例です。

店舗の打ち手は、ほとんどが時間の単位で決まります。何時から何人入れるか。仕込みをどこまで用意しておくか。ピークの前に休憩を回すか、後に回すか。どれも「今日1日」ではなく「今日の何時」で決める話です。

ところが、本部に上がってくる数字は1日1行です。売上がいくら、客数が何人、人件費がいくら。結果は分かりますが、その結果が1日のどこで作られたのかは分かりません。

この状態で判断しようとすると、足りないぶんを経験で埋めることになります。「金曜は忙しいから1人多め」「雨の日は暇だから減らす」。当たることもありますが、外れたときに何が違ったのかを確かめる方法がありません。次に活かせないので、毎回同じ勘に戻ります。

打ち手が時間の単位なら、数字も時間の単位で持っていないと噛み合いません。

同じ日商でも、1日の形は店ごとに違います

同じ日商でも、1日の形は店ごとに違う

A店

昼に山が1つ

  • 12〜13時に集中
  • 夜はほとんど動かない
B店

夜に山が1つ

  • 18〜20時に集中
  • 昼はほとんど動かない
C店

昼と夜に山が2つ

  • 山が2つ、間は谷
  • 必要な人数が1日で2回変わる

日商はどれも 312,000円。合計だけを並べるかぎり、この3店は「同じ日」として並びます。

図2:日商が同じ3店舗の、1時間ごとの売上。濃い棒は各店の山にあたる時間帯。数値は作図用の例です。

日商が同じ2つの店が、同じ商売をしているとは限りません。片方は昼に山が1つあり、もう片方は夜に山が1つある。3店目は昼と夜に山が2つあって、その間はほとんど客が入らない。合計だけを並べると、この3店は同じ数字として並びます。

必要な人数も、仕込みの量も、この3店では別々です。同じ日商に対して同じ基準で人を置いていると、山のある店では足りず、谷の長い店では余ります。どちらも数字の上には現れないまま、毎日続きます。

これは店舗の努力の差ではなく、立地と客層の差です。オフィス街の店と、駅前の店と、住宅地の店では、1日の形が最初から違います。合計だけを見ているかぎり、この違いは一度も表に出てきません。

時間で切ると、店ごとの形がそのまま見えます。比べるべきなのは合計ではなく、形のほうです。

「静かでした」を、時間の位置で特定する

売上が落ちた日に理由を聞くと、「今日は静かでした」という答えが返ってきます。嘘ではありませんが、これだけでは打ち手が決まりません。

同じ「前週比マイナス10%」でも、中身は3通りあります。1日を通してなだらかに少なかったのか。ピークの2時間だけがへこんだのか。ピークは変わらず、その前後の時間が消えたのか。

1つ目なら客数そのものの問題で、集客の話になります。2つ目は、その時間に何かが起きています——提供が追いつかなかった、席が回らなかった、近隣で別の催しがあった。3つ目は、営業時間や人の張り付け方の話です。同じ10%でも、打つ手はまったく別です。

時間帯で切ると、この3つは一目で区別がつきます。店長に聞きに行くときも「昨日どうでした?」ではなく「19時台だけ落ちていますが、何かありましたか」と聞けます。責めるためではなく、原因を特定するためです。聞かれたほうも、そのほうが記憶がはっきり出てきます。

人を減らす話ではありません。動かす話です

時間帯の話をすると、人件費を削る話だと受け取られることがあります。実際に効くのは、減らすことよりも動かすことです。

谷の時間に3人いて、山の時間にも3人しかいない——この状態は、人が多すぎるのではなく、置き場所がずれているだけです。谷から1人を山へ動かせば、総労働時間は変わらないまま、ピークの提供速度が変わります。削減ではないので、現場の反発も起きにくい打ち手です。

開店・閉店の時刻も同じです。閉店前の1時間にほとんど客が入っていないなら、その時間は仕込みや清掃に回したほうがいい。逆に、閉店間際に断っている客がいるなら、そこは伸ばす余地です。どちらも、時間で切った実績がないと判断できません。

勤怠システムを合わせて連携すると、シフトと実打刻の時間が同じ画面に乗ります。売上の山と、人がいた時間を重ねると、ずれている場所がそのまま出てきます(人件費を金額ではなく労働時間で管理する)。

雨も曜日も、時間帯によって効き方が違います

「雨だったので暇でした」という説明は、日単位で見ているかぎり確かめようがありません。1日じゅう降っていたのか、夕方だけ降ったのかで、影響を受ける時間はまったく違うからです。

TEAL BIは気象データを時間帯別で取り込んでいます(下の連携一覧の「外部データ」)。売上の谷と、雨が降った時間を重ねて見れば、本当に天気の影響だったのか、それとも別の理由だったのかが分かります。同じ雨でも、ランチ帯に降ったのか、退勤時間に降ったのかで、効く店と効かない店が分かれます。

曜日も同じです。金曜と土曜は日商が近くても、金曜は夜に偏り、土曜は昼から入る——という形の差があります。前年の同じ曜日と重ねるときも、合計より形で比べたほうが、違いがはっきり出ます。

売上の予算は、ランチとディナーを分けて持つこともできます。夜が弱いのか昼が弱いのかで、打ち手も、動く担当者も変わります。

なぜ多くの本部で、時間帯が見られていないのか

理由は単純で、本部に上がってくるのが1日1行の報告だからです。店舗から送られてくるのが日計の数字であるかぎり、あとから時間帯に戻すことはできません。合計は明細から作れますが、明細は合計から作れないためです。

TEAL BIが受け取っているのは、集計結果ではなく1件ずつの取引データです。何時に会計されたかが1件ごとに残っているので、時間帯で切るのは後からでもできます。見たい切り口を、先に決めておく必要がありません。

POSレジの管理画面でも時間帯別のグラフが見られる製品はあります。ただ、そこで見られるのは1店ずつです。全店を横に並べて、同じ時間軸で比べるところは本部側でやるしかありません。メーカーが混在していればなおさらです。

なお、POS側の生データには保存期間があります。時間帯で見られるのは、明細が残っている期間までです(POSの過去データは保存期間で消える)。

数字が届くのは、翌日の朝です

数字が届くのは、翌日の朝

閉店まで

店舗はいつも通り

レジを締めるだけ。書き出しも転記も提出もありません

夜間

取引データを自動で取得

合計ではなく、1件ずつのデータを受け取ります

翌朝

全店が1時間ごとにそろう

前営業日までを確定した数字として並べます

当日の途中経過ではなく、前営業日までを確定した数字としてそろえます。

店舗に増える作業はありません。書き出し・転記・提出は、どの工程にも入っていません。

図3:前日ぶんが翌朝そろうまで。店舗側の操作は発生しません。

取得は夜間に自動で行われます。翌朝には、前日のどの時間帯に山があったのかまで見られる状態になっています。日計の1行だけでなく、時間帯まで割れた形で届きます。

「前日ぶん」に統一していることは、時間帯別で見るときにとくに効きます。当日の途中経過だとまだ来ていない時間帯が空欄のまま並ぶので、山がどこにあるのかを読み違えます。1日が閉じてから見る形にそろえています。

1日1行では見えなかったものが、何に変わるのか

昨日の山と谷が、1時間ごとに並ぶ

前日ぶんの売上と客数が、1時間ごとに切られた状態で並びます。前週の同じ曜日や前年と重ねられるので、どの時間が落ちたのか、どの時間に余地があるのかが、その日のうちに分かります。

全店が1枚に並ぶ

前日ぶんの売上・客数・客単価が、店舗別に並びます。そこから店舗ごとに、曜日別・時間帯別へ降りられます。前年・2年前との対比も同じ画面です。

担当の4〜5店だけが並ぶ

見せる範囲は役職で分けます。店長は自分の店だけ、エリアマネージャーは担当の4〜5店だけ。時間帯の話は、担当している店の中でしか手が打てません。全店の中の順位より、自分の店のどの時間が薄いかのほうが役に立ちます。見せ分けで料金は変わりません。

売上・人件費・仕入が、同じ日付で並ぶ

勤怠を合わせて連携すると、同じ時間帯に何人が立っていたかが並びます。売上の山と人の山がずれている時間は、ここで見つかります。予算値を登録しておけば、日次の予実と当月の着地見込みも同じ画面に出ます。

実際に本番稼働している連携先

時間帯まで割って見るには、1件ずつの取引データが毎日入っている必要があります。ですので連携先も、「本番稼働中」=いま毎日データが流れているものと、そうでないものを分けて出します。

区分連携先状況
POSレジ東芝テック/スマレジ/USENレジ/NECモバイルPOS/ポスタス(POS+)本番稼働中
ローズシステム/寺岡精工/funfo/Chompy(モバイルオーダー)本番稼働中
ステアリテール(FoodFrontia Pro)/グローリー/リブオン(宅配Evolution)/ダイニー接続対応中
仕入インフォマート本番稼働中
メニューPlus(レシピ)接続対応中
勤怠・人事ジョブカン/King of Time/タッチオンタイム/SmartHR本番稼働中
予約・口コミGoogleビジネスプロフィール/TableCheck/Instagram
※Instagramは一部の企業様で稼働中です
本番稼働中
外部データ気象データ(全国・時間帯別)本番稼働中
上記以外ネットワーク未接続の店舗を含むCSVアップロードで統合対象に含められます

どれくらい作業が減るのか

直営12店舗での実測値

106時間削減した集計作業
20万円人件費換算
12店舗実測した直営店の数

106時間は、担当者1人の月間労働時間のおよそ3分の2にあたります。

図4:TEAL 直営12店舗で実測した、集計作業の削減量。

直営12店舗の飲食企業では、店舗と本部のエクセル作業が1か月で106時間・金額にして20万円ぶん減りました。日計を集めるだけで終わっていた時間が、時間帯まで見て手を打つ時間に変わります。

106時間は担当者1人の月間労働時間のおよそ3分の2にあたります。時間帯別の分析は、やる価値が分かっていても手が空かないので後回しになります。空いた時間が最初に向かう先は、たいていここです。

よくある誤解

この節で扱う3つの誤解

ピークの時間は、店長が体で分かっています

分かっているのは自店だけ。全店を並べて比べる形にはなっていません

うちは日商が読めているので、時間帯までは要りません

日商が読めても、人をどの時間に置くかは決まりません

見る画面が増えると、店長が見なくなります

増えるのは画面ではなく粒度。見る場所は1つのままです

図5:以下の3節で扱う誤解と、その答え。

「ピークの時間は、店長が体で分かっています」

分かっていると思います。ただ、それは1人の頭の中にあるもので、店ごとにばらついていて、本部からは確かめられません。エリアマネージャーが4〜5店を見るときは、4〜5人ぶんの記憶を突き合わせる作業になります。

数字で出ているものは、引き継ぎができます。店長が代わっても、その店の形は残ります。人が入れ替わったときに最初に失われるのが、この種の情報です。

「うちは日商が読めているので、時間帯までは要りません」

日商が読めていることと、その日商を最小の人数で作れていることは別です。合計が予算どおりでも、山と谷に同じだけ人が置かれていれば、余っている時間と足りない時間が同じ日に同時に発生しています。

時間帯を見る目的は、売上を増やすことだけではありません。同じ売上を、どう作ったかを見る。そちらのほうが、実務ではすぐ効きます。

「見る画面が増えると、店長が見なくなります」

増やす前提ではありません。店長が毎日見るのは自分の店の1枚だけで、そこに昨日の山と谷が出ています。全店を横に並べた画面を見るのは、本部とエリアマネージャーです。

見る頻度も役割ごとで構いません。店長は毎日、エリアマネージャーは週に何度か、本部は会議の前に——という使い分けで運用されている企業が多いです。全員が毎日見る前提で設計する必要はありません。

料金と、導入までの流れ

TEAL BIの料金は1店舗あたり月額8,000円(税抜)だけです。初期費用・導入費用・連携費用はいただいていません。この記事で挙げた時間帯別の集計も、この料金に含まれます。オプション料金という考え方をしていません。

導入の流れは、いまお使いのPOSレジと勤怠システムの構成をお聞きするところから始まります。すでに接続実績のあるものであれば、やり取りは短く済み、約1週間で稼働を開始できます。掲載していないものが混ざっている場合も多くは連携可能で、その際はメーカー様との打ち合わせのうえ新規の連携開発を行います。期間の目安は1か月程度です。いずれの場合も月額8,000円のままで、連携のための費用はいただきません。

いま使っている集計を止める必要はありません。並行して動かし、両方の数字が一致することを確認してから切り替えていただけます。

画面と機能をひととおりご覧になりたい場合は、サービス紹介資料(全10ページ)をご請求ください。フォームのご入力後、その場でダウンロードいただけます。

よくあるご質問

Q. どのくらいの細かさで見られますか?

1時間ごとに見られます。店舗別・曜日別に切って、前年や前週と重ねて比べられます。実務としては、まず店舗別で外れている店を見つけ、その店を曜日と時間帯で絞る、という順で使うのが有効です。

Q. いつ見られますか?当日の途中経過も見られますか?

前日ぶんが翌朝そろいます。当日の途中経過は、店舗の締め処理が済んでいないぶん時間帯によって数字が動くため、本部・エリアマネージャー・店長が同じ数字を見られるよう「前日ぶん」で統一しています。

Q. 売上以外も時間帯で出ますか?

客数と客単価が同じ時間軸で並びます。勤怠システムを合わせて連携いただくと、シフト時間と実打刻時間の予実を、店舗別・曜日別・時間帯別に日次で追えます。

Q. ランチとディナーで分けて見られますか?

分けられます。売上の予算を、ランチとディナーで分けて登録することもできます。夜が弱いのか昼が弱いのかで打ち手が変わるため、分けて持っている企業が多いです。

Q. 時間帯別に見るために、レジの打ち方を変える必要はありますか?

ありません。取引データにはもともと時刻が入っているので、打ち方を変えていただく必要はありません。取得は夜間に自動で行われます。ネットワークにつながっていない店舗だけ、CSVのアップロードで同じ表に含めます。

Q. POSの管理画面でも時間帯別のグラフは見られますが、何が違いますか?

見られるのが1店ずつか、全店を同じ時間軸で横に並べられるか、という違いです。メーカーが違う店どうしでも同じ基準で並びます。売上・人件費・仕入が同じ日付で並ぶのも、本部側にデータを集めているためです。

Q. 過去のデータは、いつまで残りますか?

TEAL側に蓄積するため、POSの保存期間が過ぎても本部の数字は消えません。導入前の期間も、POSに残っているぶんはさかのぼって取り込めます。この費用はいただいていません。

TEAL BIについて

TEAL BIは、(株)ラックバッググループが提供する飲食企業向けの経営データ統合ダッシュボードです。複数メーカーのPOSレジ・勤怠・仕入の各データを自動連携し、統一フォーマットに変換したうえで、店舗別・日次でFL比率・確定原価率・人件費の着地見込みを可視化します。複数の飲食企業で本番稼働しています。グループ代表自身が20年以上にわたって飲食店経営の現場に携わってきた経験から立ち上げた事業で、現場の経営者が本当に必要とする数字が実装されているのが特徴です。

いま何店舗でどのPOSをお使いか、勤怠システムは何をお使いか。この2つをお聞かせいただければ、稼働開始までの流れと期間の目安をお返しします。時間帯別に見て何を決めたいのかも、あわせて教えてください。

あわせてお読みください:
「最近、お客さんの層が変わった」と言われて、確かめられますか:レジの客層ボタンを、店をまたいで足せる形にそろえます

人件費を金額ではなく労働時間で管理する:シフトと実打刻の日次予実
店長からの報告待ちをやめる:本部と店舗が同じ数字を毎日見る
売上速報のエクセル作成をやめる:多店舗飲食の本部集計を自動化
POSの過去データは保存期間で消える:乗り換え時のデータ移行と前年対比
その数字、店長会議で使えますか:POS混在のままで毎日確定する本部集計

執筆:斉田 教継((株)ラックバッググループ / (株)ティールテクノロジーズ 代表取締役)
20年以上にわたり飲食企業の経営に携わる。(株)ラックバッググループが提供する飲食企業向けデータ統合ダッシュボード「TEAL BI」の事業を主導する。一般社団法人オープン・フードサービス・システム・コンソーシアム データ標準化分科会長として、業界共通POS標準フォーマット基盤の構築を主導。

投稿者プロフィール

斉田 教継株式会社ラックバッググループ 株式会社ティールテクノロジーズ 代表取締役
斉田 教継(さいだ のりつぐ)
株式会社ティールテクノロジーズ 代表取締役
株式会社ラックバッググループ 代表取締役
20年以上にわたり飲食企業の経営に携わる。現在は飲食企業向けデータ統合ダッシュボード「TEAL BI」を運営する。一般社団法人オープン・フードサービス・システム・コンソーシアム データ標準化分科会長として、業界共通POS標準フォーマット基盤の構築を主導。