We switched to QR-based bottle counts at 4 p.m. pre-shift and cut 86s from 6 a week to 2, but the team says it bogs down the bar during peak. How are you keeping counts tight without dinging ticket times — do you cap updates after a set hour, or is there a better workflow that protects service quality?
Cap the scanning once the rush starts and go exception-only… We do a “4 p.m. QR sweep” pre-shift, then during peak the barback scans only empties and the POS handles recipe depletion; we reconcile variance at close and spot-check high-variance SKUs at first cut. If you don’t have a barback, run 2-minute scan bursts on the quarter-hour and ignore the rest during service.
, QR during peak slows us too — building on @eleanorVee, we switched high-movers to a POS “count-by-crack” button so when a bottle’s opened it logs instantly, and we only QR the back bar at 4 p.m. and at close. We also pre-stage a two-par speed rail and treat a mid-rush swap as one “rail swap” event rather than 12 scans, which kept 86s near your 2/week without dinging ticket times. Would a crack button plus rail-swap logging cover your peaks?
Quick tweak that helped us: we run 90‑second micro-scans at:15 and:45 only on a ‘hot list’ auto-sorted by theoretical usage since 4 p.m., and outside those windows it’s visual-only so tickets don’t stall. Does your system support a one‑tap “likely to 86 in 90 min” view to build that hot list, @s_lin78? If staffing’s tight, tag sub‑30% bottles with a red band pre‑rush so they get swapped/logged in the next window — pit stop, not a full tune‑up.