Smart TV app
Best for: Good for pilots if the app can auto-launch and stay awake.
Watch: Consumer TV operating systems can update, sleep, or lose app state.
Use this checklist before buying hardware, designing slides, or sending staff into Friday rush with screens they cannot update.
Start here
Running the menu from a USB drive and realizing every special requires touching the screen.
Using a browser slideshow that only refreshes when someone reloads the TV.
Buying consumer TVs without thinking about heat, brightness, runtime, or warranty.
Treating combos, slices, and sold-out toppings like static artwork instead of operational data.
Putting promos on the same slide all day instead of dayparting lunch, dinner, and late-night offers.
Using a player with no offline fallback, screenshot capture, or health signal.
Scaling from one screen to three screens without naming, assigning, and monitoring each display.
Best for: Good for pilots if the app can auto-launch and stay awake.
Watch: Consumer TV operating systems can update, sleep, or lose app state.
Best for: Best TVMenus direction for reliable local playback and native device control.
Watch: Use managed pairing and local cache; avoid fragile browser-only playback.
Best for: Affordable for first-screen tests and simple menus.
Watch: Confirm CMS support, kiosk behavior, offline caching, and long-run stability.
Best for: Best for high-traffic counters, bright rooms, and long daily runtime.
Watch: Costs more up front, but reduces replacement and warranty risk.
Define lunch and dinner menus before opening.
Reserve one promo slot for high-margin combos.
Create a sold-out workflow for toppings, slices, and limited-time items.
Keep one fallback slide cached locally in case Wi-Fi drops.
Check every assigned TV before the first rush window.
Use one clean menu with a narrow promo rail. Rotate only if customers have time to read it.
Split core menu from combos/promos. Put high-margin add-ons where customers decide.
Use menu, bundles, and promo/sold-out status as separate surfaces so rush-hour choices stay clear.
Upside: Cheap and familiar.
Risk: Manual updates, no scheduling, no remote health, and poor scaling.
Upside: Remote publishing and basic playlists.
Risk: Often designed for any screen, not pizza rush workflows or player reliability.
Upside: Built around Sites, Areas, Menus, Devices, manifests, pairing, telemetry, and screenshots.
Risk: Still proving the QSR/pizza wedge, so early pilots shape the product.