Automate Your Restaurant 86 List Across POS Channels 2026

Key Takeaways

• An 86'd item that stays live on a delivery app for even 20 minutes can trigger dozens of bad orders, comped meals, and 1-star reviews simultaneously.

• Manual 86-list updates across a POS, website, third-party apps, and kitchen display system typically take 8–15 minutes per incident and require a manager's attention.

• A real-time automation layer can propagate a single "86" tap in your POS to every connected channel in under 60 seconds.

• Restaurants running multi-channel automation see measurable reductions in comped dishes, delivery refund fees, and negative guest reviews tied to out-of-stock orders.

• This guide walks through a step-by-step workflow recipe for wiring together your POS, online ordering platform, and delivery integrations using automation middleware.

The kitchen runs out of the short rib at 7:15 PM on a Saturday. Your line cook shouts "86 short rib." Your manager radios the front of house, pulls up the POS, finds the modifier, disables it, then opens a laptop to update your Toast online ordering page, logs into GrubHub's merchant portal, texts the Olo admin link to herself, and spends the next 12 minutes clicking through menus while the dinner rush swallows the floor.

Meanwhile, three delivery orders for the short rib land in the kitchen. The cooks make substitutions, you comp two dishes and discount the third, and a guest posts a photo of a "lamb chop" that was definitely not a lamb chop.

This is the 86-list problem. It is not a communication problem. It is a synchronization problem—and synchronization is exactly what automation solves.

What is an 86 list? In restaurant operations, an 86 list is a real-time record of menu items that are unavailable—out of ingredient stock, out of prep capacity, or pulled for quality. The term dates to diner slang for "we're out of it." The operational challenge is propagating that status instantly across every channel where guests can order.

TL;DR: Automating your 86 list means a single update in your POS (or inventory system) triggers webhook-based calls that disable the item across Toast, Olo, ChowNow, and your website menu in under 60 seconds—no manager intervention required after the initial 86.

Who This Guide Is For

This workflow recipe is designed for:

• Independent restaurants and small chains (2–20 locations) running Toast, Square, or Clover as their POS with at least one third-party delivery integration (Olo, ChowNow, DoorDash, GrubHub, Uber Eats).

• Operations managers who lose time during service propagating 86s manually across platforms.

• Restaurant groups scaling past a single location where one manager can no longer touch every system during a rush.

Red flags: Skip this guide if you operate a single location, paper ticket kitchen, and take zero online or delivery orders—there's nothing to synchronize. Also skip if you're on a fully managed POS bundle that already handles cross-channel sync (some enterprise Toast or Lightspeed enterprise contracts include this), as adding a second automation layer may create conflicts.

Why Manual 86-List Management Breaks Under Scale

According to the National Restaurant Association 2025 State of the Industry, U.S. restaurant industry sales are forecast to exceed $1.1 trillion, and off-premises (delivery + takeout) orders now represent a substantial share of total revenue for most full-service and quick-service concepts.

Average labor cost per full-service restaurant: roughly 30–35% of revenue, according to the Toast 2024 Restaurant Industry Report—with managers often citing off-system administrative tasks as a growing share of non-revenue labor.

The math on a manual 86 failure is easy to run:

Multiply by 3–5 incidents per week across a busy independent and you are looking at $4,500–$14,800 per year in avoidable losses—before counting the brand cost of repeated complaints. According to the BLS Occupational Outlook Handbook, food service managers earn a median annual wage well above $60,000—which means manager time spent on manual 86 propagation is expensive, not just inconvenient.

Quick-service restaurants face an even sharper problem. QSR locations process hundreds of orders per store per day, according to the Technomic 2024 Industry Pulse, which means an 86'd item staying live for 15 minutes can generate 10–20 erroneous orders before staff catch it.

The 86-List Automation Architecture

A modern restaurant 86-list automation connects four layers:

1. Trigger layer — the POS or inventory system where staff signal the 86 (a button tap, a voice command, or a threshold breach in an inventory app like MarketMan).

2. Event bus — a webhook or API call emitted when the trigger fires, captured by automation middleware.

3. Propagation layer — parallel API calls to every connected ordering channel (Olo, ChowNow, your website CMS, DoorDash Merchant API, GrubHub for Restaurants).

4. Confirmation layer — a Slack or SMS alert to the manager confirming the item is disabled across all channels, plus a timestamp log for each.

US Tech Automations builds this architecture as an agentic workflow that sits between your POS and every ordering channel, handling authentication, retry logic, and failure alerting—so your staff never has to touch a second screen.

Step-by-Step Workflow Recipe

Here is the full 11-step recipe for wiring a real-time 86-list automation:

1. Identify your POS webhook endpoint. Toast, Clover, and Square all offer menu-item availability webhooks or API endpoints. Pull your API credentials from the developer portal and document the exact payload structure for a menu-item status change.

2. Map every channel that serves your menu. List every place a guest can order: your POS (dine-in), Toast Online Ordering, Olo (if applicable), ChowNow, DoorDash, GrubHub, Uber Eats, your website (if it has an embedded ordering widget). This becomes your propagation target list.

3. Confirm API availability for each channel. DoorDash, GrubHub, and Uber Eats all offer merchant APIs with item availability endpoints. Olo has a robust availability API. ChowNow offers menu sync via partner integrations. Confirm you have access credentials for each.

4. Set up automation middleware. Choose a workflow automation platform (e.g., the agentic workflow layer at US Tech Automations) that can receive a webhook from your POS, parse the menu-item ID and new status, and fan out calls to multiple APIs simultaneously.

5. Create a menu-item ID mapping table. Each platform uses its own internal item IDs. Build a lookup table (a Google Sheet, database row, or JSON config file) that maps your POS item ID to the corresponding ID in each delivery channel. This table is the core of your automation.

6. Build the trigger handler. Configure the middleware to listen for a POS webhook payload indicating item availability = false (or equivalent). Parse the item ID, look it up in your mapping table, and pass the channel-specific IDs downstream.

7. Build parallel channel-update steps. For each channel in your target list, create a step that calls the channel's item-availability API with the correct item ID and status. Run these in parallel—do not chain them sequentially, as you want all channels to update within the same 60-second window.

8. Add retry and failure logic. If a channel API returns an error, the step should retry up to 3 times with exponential backoff. If all retries fail, the step should alert the manager via Slack or SMS with the specific channel and item that failed.

9. Build the confirmation notification. After all parallel steps complete, send a single Slack or SMS message to the manager: "Short rib 86'd successfully across Toast Online, Olo, GrubHub, DoorDash, Uber Eats (6:17 PM). ChowNow: retry pending."

10. Test in staging. Run the automation against your test menu item (most platforms provide sandbox environments). Confirm the item disappears from each channel within 60 seconds of the trigger.

11. Deploy and train staff. Publish the workflow to production. Brief kitchen and floor staff that a single "86" action in the POS is now sufficient—no follow-up calls, no second logins, no manager notifications required.

Common Mistakes to Avoid

Running this workflow across hundreds of restaurant setups surfaces the same failure patterns repeatedly:

• Skipping the ID mapping table. Operators assume their POS item name matches the delivery platform's item name. It almost never does. Build the mapping table before building the workflow.

• Treating 86s as fire-and-forget. An API call can fail silently. Always build confirmation + failure alerting into the workflow, or you will discover a failure via a comped dish, not a log.

• Forgetting to build the "un-86" step. The item comes back in stock the next morning. Your automation needs a corresponding "re-enable" step that fires when you restore availability in the POS, or you will have items permanently 86'd on delivery channels.

• Letting channel credentials expire. Delivery platform tokens rotate. Build a credential health check into your monthly maintenance routine, or the workflow fails silently the night your auth token expires.

Platform Comparison: Native Sync vs. Automation Middleware

Not all restaurants need a custom middleware layer. Here is an honest comparison of the main approaches:

Toast excels if your entire ordering stack lives inside the Toast ecosystem—you get near-instant sync with zero setup. Olo similarly handles its own channel set natively and is the right call for concepts fully on the Olo platform. According to Technomic 2024 Industry Pulse, digital and third-party ordering channels now represent a growing share of full-service restaurant revenue, making cross-channel consistency a competitive requirement rather than a convenience. According to Deloitte's 2024 Consumer Industry Insights, consumers who receive an out-of-stock order through a delivery app are significantly less likely to reorder from that restaurant within 90 days.

When NOT to use US Tech Automations: If you operate a single location with all ordering through Toast Online Ordering only, the native sync is free and sufficient. Similarly, if you're on a fully managed enterprise contract with Olo that includes cross-channel availability management, adding USTA middleware creates redundancy without benefit. The automation layer earns its cost when you have three or more ordering channels that don't natively share availability data.

Benchmarks: What to Expect After Automation

According to the National Restaurant Association 2025 State of the Industry, operator expectations around technology adoption have shifted sharply toward real-time visibility and cross-platform integration as table stakes for competitive multi-channel operations. Based on restaurant automation implementations across multi-channel concepts:

Frequently Asked Questions

Does this work if my POS doesn't have a webhook API?

Many older or budget POS systems lack webhook support. In that case, you have two options: poll the POS's availability endpoint on a short interval (every 30–60 seconds) or use a tablet-based 86 app that does have webhook support and sits alongside the POS as the trigger layer. Toast, Square, and Clover all support webhooks as of 2025.

How do I keep the menu-item ID mapping table current when I add new items?

Build a lightweight onboarding step into your new-item workflow: whenever a new menu item is created in the POS, a secondary automation step creates the corresponding entry in the mapping table and notifies the operator to add the delivery-channel IDs. This keeps the table from drifting over time.

Can this automation handle modifier-level 86s (e.g., 86 the shrimp modifier but not the whole dish)?

Yes, but it requires the delivery channels to support modifier-level availability APIs. Most major platforms (DoorDash, Uber Eats, GrubHub) do support modifier group availability as of 2025. You will need to extend your mapping table to include modifier IDs, and the automation workflow needs corresponding modifier-update steps.

What happens if the automation fails mid-propagation—some channels updated, some didn't?

The failure alerting step should fire immediately, listing exactly which channels succeeded and which failed. Your manager then knows to manually update only the failed channels. This is far faster than the pre-automation state (where all channels required manual updates) and prevents the most costly failure mode (all channels showing available when the item is 86'd).

How long does the initial setup take?

For a restaurant with a well-documented POS API and two to three delivery channels, initial setup typically takes 2–4 hours of technical configuration plus a 1-hour testing session. The main time investment is building and validating the menu-item ID mapping table. Restaurants with five or more channels or complex modifier structures should budget 6–8 hours for initial configuration.

Does this workflow handle temporary 86s vs. permanent item removals differently?

Best practice is to use the same automation for both, but add a field to your trigger: "temporary" vs. "permanent." For temporary 86s, the system also schedules a re-enable check (e.g., at the start of the next service period). For permanent removals, the workflow archives the item from the mapping table after confirming deletion across all channels.

Related Resources

For restaurants already managing inventory in MarketMan, the sync workflow extends naturally to purchase-order automation. See how teams connect inventory depletion triggers to supplier ordering in automate restaurant inventory ordering marketman us foods quickbooks 2026.

If you're running weekly financial reviews alongside operational automation, the P&L workflow at 5 steps to automate weekly p and l review 2026 pairs naturally with this setup.

For teams managing no-show recovery alongside availability issues, why restaurants teams opentable no show recovery to sms 2026 covers the complementary guest-recovery automation.

Glossary

86: Restaurant slang for an item that is no longer available for service. Origin disputed; commonly traced to diner codes of the 1930s–40s.

Webhook: An HTTP callback that fires automatically when an event occurs in a system (e.g., item status changes in a POS), delivering data to a listening URL in real time.

Propagation latency: The elapsed time between the trigger event (86 fired in POS) and the moment the item is unavailable to the guest across all channels.

Middleware: Software that sits between two or more systems, translating events and API calls so the systems can communicate without direct integration.

Retry logic: Automated re-attempts of a failed API call, typically with increasing delays (exponential backoff) to avoid overwhelming the target system during an outage.

Menu-item ID mapping: A lookup table that translates a single internal item identifier (POS ID) into the corresponding identifiers used by each delivery and ordering platform.

Take the Next Step

If your team is losing service time and revenue to manual 86-list updates, the workflow above can be implemented and tested in a single afternoon. Start by documenting your channel list and pulling your POS API credentials—those two steps take 30 minutes and immediately reveal whether you need full middleware or a simpler native sync.

For restaurants ready to automate the full channel-sync layer, see pricing at US Tech Automations to review workflow tiers built for multi-channel restaurant operations.