損失管理とレジリスク
手動割引が1回だけなら問題ではありません。同じPINで1シフトに20回の割引があり、他の全員が3回なら、意味があります。
損失管理は2つの層で構成されます。1つ目は危険操作ジャーナルで、「何があったか」という問いに答えます。2つ目は6つのルールで、オーナーの「何を見るべきか」という問いに答えます。
危険操作ジャーナル#
レジは現在のキャッシャーに紐づけてリスクのある操作のイベントフィードを記録します(PINによる素早い切り替えも考慮され、デバイスにログインしている人だけではありません):
| イベント | 記録されるタイミング |
|---|---|
| 手動割引/価格変更 | キャッシャーが手動で価格を下げたか割引を適用した |
| 注文のキャンセル | 領収書が完全に無効化された |
| キッチン送信後のアイテム削除 | 調理中の料理の取り消し |
| 領収書による返金 | 返金が処理された |
| 販売なしのドロワー開放 | 領収書外でドロワーが開かれた |
| 発行済み領収書の再印刷 | 再印刷 — ゲストの領収書をすり替える古典的な手口 |
| プリチェック後のゲスト請求書の修正 | ゲストがすでに合計を見た後にゲスト請求書が変更された(印刷済みプリチェックを無効化するテーブル統合も含む) |
| シフト締め時のレジ差異 | 実際の金額が期待値と一致しなかった |
キャッシャーと操作タイプでフィルタできるフィード自体は「統計」セクションの**「危険操作」**タブにあります — 来店状況とサマリーを参照。ここでは重複して掲載しません。
ジャーナルには2つ目のサーバー側の柱があります。 危険操作はレジが記録するだけでなく、サーバーが独自に導出します — 注文自体がどう変化したかから:キッチンに送信済みのアイテムの削除、手動割引、価格変更、クローズ済み注文の再オープン、支払い後のキャンセル、返金、プリチェック後の修正。この記録はレジでは回避できません。ブラウザではなく、注文を受け付ける側で行われるためです。
2つの柱から別のルールが生まれます — 「ジャーナル差異」:操作がレジのジャーナルにありサーバー側にない場合(またはその逆)、詳しく確認する理由があります — アプリがオフラインで動作していた、ジャーナルが届かなかった、またはキャッシャーが記録を回避しようとした可能性があります。このような差異は他のアラートとともに「監視中」タブの「レジリスク」に表示されます。
6つのルール#
ルールはサーバー側でジャーナルと会計データに基づいて計算されます。観察ウィンドウは1週間で、「シフト」は店舗の暦日で近似されます。
| ルール | 発動するタイミング |
|---|---|
| キャンセル連発 | 1人のキャッシャーが1シフトに「たまたま」では済まない数のキャンセル/取り消しを蓄積した(デフォルト — 8回、フルシフトで約1時間に1回) |
| 割引連発 | キャッシャーの1シフトの手動割引合計が、ウィンドウ内のアカウント全キャッシャーの中央値の3倍(×3)を超えた |
| レジ差異 | シフト締め時の不足/過剰がオーナーのしきい値を超えた、または差異の中央値の3倍(×3)を超えた |
| 消費が基準超過 | 棚卸サイクルで実際の消費が理論値(レシピカードによる)をN %以上超えた(デフォルト — 5 %)— 「差はどこへ消えたか」 |
| 仕入価格の急騰 | 商品がその価格の中央値より高く受け入れられた(デフォルト — 15 %以上) |
| ジャーナル差異 | 操作がレジのジャーナルにありサーバー側にない(またはその逆)— 上記セクション参照 |
金額しきい値が自己調整される理由。 定数は機能しません。アカウントごとに通貨が異なり、客単価の規模も異なります。そのため金額ルールは、同じアカウントの全キャッシャーの中央値とキャッシャーを比較し、その3倍を超えた場合にのみ発動します。
仕入価格の中央値は30日と90日のウィンドウで計算され、1つの納品書が1つのサンプルポイントです(納品を5行に分割したサプライヤーが中央値を正直な場合より5倍ずらすことはありません)。3件未満の納品ではサンプルにならず、ルールは沈黙します。同じ中央値が受領行に直接**「中央値比 +N %」**バッジを表示します — 在庫を参照。
各アラートにはレベル(高/中)、リスク額、イベント数、期間があります。再計算しても重複は生まれません。同じ日の同じ偏りは同じアラートです。
どこで確認し、どう設定するか#
「レジリスク」ブロック — 「ワークチャット」→「対応が必要」→ 「監視中」タブに、他の案件とともにあります。パネルに独立した「要注意」セクションはもうありません。古いアドレスもここに誘導されます。「対応する」ボタンはイベントフィードに移動します。
しきい値は**「統計」セクションのヘッダーにある歯車 ⚙️** から開きます。項目は「アラートしきい値」:自動的に「危険操作」タブに切り替え、折りたたまれたしきい値ブロックを展開します(この項目はオーナーとマネージャーに表示されます)。手動でも到達できます — 「危険操作」タブ → しきい値ブロック。設定できる項目:
- 1シフトの手動割引合計 — 基準を引き上げます:しきい値と中央値超過の両方の条件が必要です(割引の基準は相対的でプロモーションに依存します);
- 1シフトのキャンセル連発 — カウントしきい値;
- レジ差異 — 中央値を置き換えます:ここではオーナーが絶対金額での許容度を知っています;
- 理論消費を超える損失、%;
- 仕入価格の中央値超過、%。
空のしきい値 = 「しきい値なし」:ルールは中央値(金額ルール)または保守的なデフォルト値から動作します。
オーナーへのメール — サブスクリプションによる。 デフォルトではアラートは計算され管理画面に表示されますが、メールは誰も受け取りません。メールのトグルは同じ設定にあり、意図はこうです:1回の実行につき1通の新規アラートのサマリーであり、1件ごとに1通ではありません — キャンセル連発は通常まとめて届きます。
危険な操作のビデオクリップ#
Cenaly Hardware Bridgeを介してレジデバイスにカメラが接続されている場合、イベントに短いビデオクリップを添付できます。操作の前と後の数秒間です。
店舗ごとに設定します(各レジでホールもアングルも異なります)。設定はハードウェアのセクションで行います:
- 有効化(デフォルトは無効 — レジエリアの映像は個人データであり、顧客に黙って有効化することはできません);
- ブリッジのデバイス一覧から選択するレジエリアのカメラ;
- イベントの前後何秒をクリップに含めるか — デフォルトは30と30、5〜120秒の範囲で指定可能;
- 店舗ごとの1日あたりのクリップ上限 — デフォルトは40、1〜200の範囲で指定可能;
- クリップの保存期間 — デフォルトは30日、1〜365の範囲で指定可能。
ジャーナルはカメラなしでも完全に機能します — ビデオは追加機能であり、必須条件ではありません。
PIN承認#
危険な操作は上司の確認でクローズできます。レジ担当者が操作をリクエストし、マネージャーが自分のPINを入力すると、ジャーナルに操作と承認者の両方が記録されます。
割引、返金、訂正のロール別上限は、オーナーが従業員とシフトセクションで設定します。レジはそれに基づいて、その操作にPIN承認が必要かどうかを判断します。
ゲートはインターフェースだけにあるわけではありません。 領収書がサーバーに送信されると、レジ担当者の上限が再解決されます — アプリが送信した内容ではなく、実際の役職に基づきます。上限を超える割引の領収書は、上司の確認なしでは受け付けられません。また、承認者は実際に承認する権限を持っている必要があります。「リクエストから」の名前とロールはサーバーは考慮しません。
発行済み領収書の再印刷もPINの下で行われ、ジャーナルに記録されます。
関連セクション#
- 勤怠とサマリー — 「危険な操作」フィード本体と「注ぎ」タブ
- 要対応 — ワークチャットの「監視中」タブで、「レジリスク」ブロックがある場所
- レジ(POS) — PINロール、プレチェック、返金
- 現金シフト — 現金照合とZレポート、差異が生じる元
- 在庫 — 棚卸し、ロス、入荷時の「中央値比 +N %」バッジ
- 従業員とシフト — ロール別の割引、返金、訂正の上限
よくある質問#
これは従業員の監視ですか?#
これは対話のツールであり、罰則ではありません。ルールは人を責めません — ある人の操作数が全体像から急に外れていることを示すだけです。その先を判断するのは管理者です。
割引が非常に大きかったのに、なぜルールが発動しなかったのですか?#
金額ルールは1回の操作ではなく、シフトあたりの金額を全レジ担当者の中央値と比較します。大きな割引が店舗全体で常態なら、中央値は高くなります。絶対額を捉えたい場合は、明示的なしきい値を設定してください。
同じケースでアラートが何度も届きますか?#
いいえ。アラートの識別子はルール、店舗、レジ担当者、期間から構成されます — 再計算しても同じアラートになり、そのメールは1回だけ送信されます。
メールだけ有効にして、ビデオを有効にしないことはできますか?#
はい、これらは独立した設定です。メールはルールのしきい値で、ビデオはハードウェアセクションの店舗設定で行います。
「支出が基準超過」が発動したらどうすればよいですか?#
技術カード上の理論消費量と棚卸しの実績を比較してください。多くの場合、原因は不正確な技術カード、未処理の廃棄・損耗の書き消し、または目分量の盛り付けです。分析は在庫セクションの「ロス」タブで行います。