Reference · built on requestOperator by FibricHospitality & guests

86 Watch

Watches menu item availability, count sheets, and expected covers, and proposes what to 86, what to change on the menu, and what to buy.

Request accessPricing ↗

About

The kitchen runs out of the fish mid-service and the servers find out from the guest. 86 Watch reads item availability from your point of sale, the counts your team keeps, and the covers you expect tonight from reservations and in-house guests. When the count on hand will not cover the covers booked, it says so before service.

It proposes the 86 flag on the item, the menu change where a substitute exists, and a purchase list for the buyer. Each is approved by the chef or the manager on duty, and each leaves a record of the count and the covers that justified it.

This is a reference listing. It documents what Fibric would read from 86 Watch and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Menu item availability in Toast through the stock API and the stock webhook, and unavailable items in Simphony through /api/v1/menus/items/unavailable
  • Item availability in Lightspeed Restaurant K-Series through /o/op/1/itemAvailability
  • Sales by item from closed checks, so the operator knows how fast each item moves on a comparable night
  • Count sheets in Google Sheets or Airtable: item, unit, quantity on hand, and the time of the count
  • Expected covers from the reservation book you export to a sheet, and in-house guest counts from the property management system for breakfast
  • Purchase orders already placed, where your purchasing system exposes them, so an item on its way is not bought twice

Proposed actions

  • Target capability: propose marking an item out of stock through the Toast stock API, or unavailable in your point of sale, for approval
  • Target capability: propose returning an item to the menu when a count or a delivery shows it is back
  • Target capability: propose a menu substitution for tonight, with the item it replaces and the reason
  • Target capability: propose a purchase list for the buyer: items, quantities, and the covers and counts behind each line
  • Target capability: propose a pre-shift note listing the items at risk of running out, by service period

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • 86 the special before the guest hears it

    The count sheet shows fewer portions than tonight's booked covers usually order. The operator proposes the out-of-stock flag in Toast for the chef's approval, with the count and the comparable nights beside it.

    With Toast, Google Sheets

  • Cover the breakfast rush

    In-house guests in Mews put breakfast covers above a normal Sunday. The operator proposes a purchase list for eggs and bread from the Airtable count, and a note to the morning cook.

    With Mews, Airtable

  • Put the item back

    Simphony shows an item unavailable while the count sheet shows a delivery received. The operator proposes making it available again and records who approved it.

    With Oracle MICROS Simphony, Airtable

Requirements

  • A point-of-sale connector that exposes item availability and closed checks: Toast, Oracle MICROS Simphony, or Lightspeed Restaurant
  • A count sheet the operator can read, in Google Sheets or Airtable, with a consistent item name or code per row
  • A source of expected covers: a reservation export in a sheet, or in-house guest counts from the property management system
  • Par levels per item, or enough count history for the operator to propose them to you
Authentication
86 Watch authenticates as nothing on its own. It reads the point of sale, count sheets, and reservations through the connectors you have connected, and proposes availability changes through the point-of-sale connector.

Limits

  • Counts are only as recent as the last entry. Between counts it works from sales, and it says which.
  • It proposes a purchase list. The buyer places the order with the supplier; no order leaves the property on its own.
  • Where the point of sale exposes availability as read only, the 86 is proposed to the manager to set by hand.
  • It does not know about a delivery until someone records it or the purchasing system does.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request 86 Watch ↗

Questions and answers

What does the chef approve?
Each 86, each return to menu, each substitution, and each purchase list. The proposal shows the item, the count, the covers booked, and how fast the item sold on comparable nights. The chef approves, changes the quantity, or dismisses.
What record does an 86 leave?
A receipt with the count and the covers that justified it, who approved it, the change made in the point of sale, and when the item came back. The purchase list keeps the same evidence, so the buyer can defend the order.
Does it change the menu on its own?
No. It reads availability, counts, and covers and proposes changes. An item is marked out of stock only after approval, through the point-of-sale connector, once. Purchase lists are handed to a buyer, never sent to a supplier.
Ask about 86 Watch

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy