Table Buddy
Table Buddy runs a restaurant's point of sale, kitchen display, stock, cash and reports on one set of books, for dine-in, takeout, counter and delivery. Take the order on the POS and Table Buddy follows it the rest of the way: a ticket on the kitchen display, the recipe's stock off the shelf, the payment into the right drawer or account, and card money tracked until it reaches the bank.
| For | Restaurants taking dine-in, takeout, counter and delivery orders |
|---|---|
| Status | In preview: free, with every module included |
| Site | table.workflowcorp.com |
| Sign in | A Table Buddy account. One login can belong to several restaurants and switch between them, and each keeps its own menu, staff, money, currency and time zone |
| API | REST over HTTPS, with keys scoped to the job |
How a service runs
One dine-in order, start to finish. Each step happens on the screen of the person doing it, and each leaves a record the next step reads.
- Take the order. On the point of sale, the server opens a table, adds the round and presses Send. The ticket goes to the kitchen and the recipe's stock comes off the books, not a moment before.
- Cook it. The ticket lands on the kitchen display with a running clock. Start, ready, served: the order moves on the floor as the pass moves it.
- Take the money. The bill is priced once and can be split across cash and card. Each payment posts to its money account as it is taken, and any tip is kept apart for the staff.
- Count the drawer. Cash waits in the cashier's own drawer until the close, when it is counted against what the drawer should hold and any difference is booked.
- Settle to the bank. Card payouts are recorded net of their fees and counted drawers are deposited. The daily closing report has the day on one sheet.
An order's stage is read from its kitchen tickets and never set by hand, and an order is completed only once it has been served and paid.
What it covers
Point of sale. Dine-in on a table, takeout, counter and delivery from the same screen. Lines stay a draft until you press Send, and each send becomes its own kitchen ticket, so a table's second round never reprints the first. Discount, service charge and tax, added on top or included in the price, come from one calculation on the POS and on the server, so the total on screen is the total charged.
Kitchen display. Tickets by stage, oldest first: to start, cooking, and ready at the pass. Each ticket's clock turns amber past its slowest dish's prep time and red ten minutes after that. Filter to one station and each ticket shows only that station's lines.
Tables and guests. A live floor by area, a bookings book one day at a time, and customer records that fill themselves in as orders are taken.
Stock and purchasing. Sending a round takes every ingredient in its recipe off the books; void a line before the kitchen starts and the stock comes back. Every material has a stock card showing each delivery, each order that used it, each count and each spoil. A count sets on-hand to what is on the shelf and records the difference as a line of its own. Deliveries add their stock and re-weight the average cost, and suppliers carry their invoices and payments.
Cash, banks and settlements. Each cashier opens their own drawer with a counted float, and the POS will not take cash without one. Card and gateway payments wait in a clearing account until the payout lands, net of its fee, so pending settlement is a figure rather than a guess. No balance is ever typed in: each one is the opening balance plus every movement since.
Staff and access. Ready-made roles (Manager, Cashier, Waiter, Kitchen, Store keeper and Accountant), or roles of your own built permission by permission. Nobody can hand out a permission they do not hold. Refunding is a permission of its own, and a tip is the staff's, never the restaurant's income.
Reports. Sales, products, stock, purchasing, money and tips, settlements and the daily close, each on screen, as CSV and in print, built from the same figures. Voids, cancellations, discounts, refunds, drawer counts, settlements and access changes go into an activity log that says who did it and when.
What you need
A current web browser on a tablet, laptop or desktop. The POS runs in the browser, so it needs a connection. Bills, kitchen tickets and reports print from the browser to any printer it can reach.
Table Buddy records card payments rather than charging them: your card terminal or payment gateway takes the card, and Table Buddy records the approved payment and follows the money to the bank.
Getting started
Create an account and open a sample restaurant that is already trading, visible only to you. Then set up your own from a starter menu, with add-ons, recipes, tables, stock items and suppliers, or start empty. There is no card and no checkout.
Billing
Table Buddy is free while it is in preview, with every module included, and commercial plans have not been published yet. See the pricing page.
The preview terms ask one thing worth knowing before you rely on it: its reports are built from what is recorded in it, so while it is in preview, check its figures against your own records (your cash count, your bank statement, your card payouts) before you use them for tax returns or payroll.
Getting help
The preview terms say to ask whoever set up your Table Buddy account, who can take your question to Workflow Corporation.
For developers
Menu, tables, orders, stock and reports over HTTPS, with API keys you scope to the job. An order placed through the API goes through the same order engine as the POS: once it is sent, it makes the same kitchen ticket and the same stock movements. Every POST carries an idempotency key, so a retry after a dropped connection acts once. The reference is on the Table Buddy docs page. See also Building on our products.