前日にいくら売れたか、手数料を引いて本当に利益が出ているメニューはどれか、食材原価が不自然に高い店舗はどこかを、毎朝知ることができます。
飲食店・カフェ · 10 / 13
飲食店向けPOS・注文システム
店頭、テーブルのQR、デリバリーアプリの注文を1つの画面にまとめます。厨房は実際の注文順を見られ、経営者はどのメニューが利益を出しているかを毎日把握できます。
飲食店・カフェ 「店頭はあるメーカーのPOS、デリバリーはさらに3つのアプリです。閉店後は4か所の売上を足し合わせて、それでもどのメニューが儲かっているのか分かりません」
よくある課題
今の飲食店は、店頭、電話注文、いくつものデリバリーアプリと、複数のチャネルで同時に売っています。アプリごとに専用のタブレットがあり、厨房の前に並んでいます。昼には注文が一斉に入り、スタッフは何台もの画面を読んで厨房に大声で伝えます。閉店後、経営者は全チャネルの売上をExcelに集計し、アプリごとに違う手数料を差し引きます。
そうして出てくるのは売上の合計だけです。よく売れるメニューが食材費と手数料を引いて実際にいくら利益を出しているのかは誰にも分からず、昼に切れた食材は、厨房が「もう作れない」と言ったときに初めて分かります。
解決の方法
私たちが作るPOSでは、すべての注文が1つの画面に集まります。店頭ではカウンターで入力し、テーブルの顧客はQRを読み取って自分で注文と支払いを済ませます。LINE MAN、Grab、foodpanda(いずれもタイのデリバリーアプリ)の注文は、各社のAPIを通じて同じ注文一覧に入ります。厨房は専用の画面で注文を時間順に見て受付と完了をタップし、システムがライダーやホールスタッフに知らせます。
売れたメニューは、設定したレシピどおりに食材の在庫を引き落とします。そのため、食材費とそのチャネルの手数料を引いたあと、各メニューが実際にいくら利益を出しているかが分かります。経営者には毎朝LINEでレポートが届きます。前日の売上、利益の大きかったメニュー、よく売れた時間帯、週末までに切れそうな食材に加えて、マネージャーが確定するだけの発注書の下書きも付いています。
支払い済みの注文のキャンセル、決められた範囲外の値引き、食材の発注には、引き続きマネージャーの承認が必要です。インターネットが止まっても、店頭のPOSは注文を受けてレシートを印刷でき、接続が戻ると自動で同期します。
仕組みの流れ
- 店頭とテーブルQRの注文
- LINE MAN、Grab、foodpanda
- レシピと食材原価
- 全チャネルの支払い
- すべての注文を1つの一覧に
- レシピどおりに在庫を引き落とし
- 手数料を引いた利益をメニュー別に計算
- 食材の発注書を下書き
- 厨房の画面
- 経営者へ毎朝LINEでレポート
- 会計システム
- 発注はマネージャーが確定
導入前と導入後
導入で得られるもの
- 01
店頭の注文、テーブルのQR注文、デリバリーアプリの注文を1つの画面で受けるPOS
- 02
リアルタイムで注文が並ぶ厨房の画面と、売れたメニューに応じた食材在庫の自動引き落とし
- 03
売上、メニュー別の利益、よく売れる時間帯を毎日経営者に届けるレポート
- 04
前週の売上をもとに食材の在庫切れが近いことを知らせ、マネージャーが確定するだけの発注書を下書きする機能
- 05
全チャネルの売上を会計システムへ自動で送り、デリバリーアプリごとの手数料も分けて記録する連携
立場ごとのメリット
デリバリーアプリとは各社の公式APIで接続し、今あるプリンターとキャッシュドロワーをそのまま使います。オフラインでも動き、売上は二重入力なしで会計システムへ送ります。
店頭のスタッフは何台もの画面を読まなくてよくなり、厨房は1つの画面で実際の注文順を確認できます。マネージャーも閉店後に売上を集計する必要がなくなります。
向いている業種
お使いのシステムと連携
開発プロセス
- 1
ヒアリング
要件・ユーザー・成功指標を定義し、着手前に範囲と価格を確定。
- 2
設計
UXとアーキテクチャを設計。プロトタイプ承認後に開発へ。
- 3
開発
AIで加速したスプリント。毎週デモ、シニアがレビュー。
- 4
テスト
合意した範囲に対してQA・セキュリティ・性能を検証。
- 5
公開・保守
本番リリース、チームトレーニング、月次保守プラン。