A Resto-Bar POS Has to Survive a Saturday Night
Casual dining is where a POS gets tested: drinks and food leaving the same order for different stations, bills staying open across courses, a group splitting the check, and a full house at 8pm. This is the part of the market our kitchen routing was built for.
Four things that separate a resto-bar from a counter
Two stations, one order
Fried chicken goes to the kitchen, a pitcher of iced tea goes to the bar. If both print on one ticket at one station, someone is carrying food across the room because the drinks are ready first.
Open bills that survive a second round
Guests order drinks, then food, then another round. Parked orders hold the bill against the table with its elapsed time and item count, so staff do not re-key an order or lose one between rounds.
Split bills without the argument
Groups pay separately. Split payments and part-cash part-wallet tenders are handled at checkout with change computed per tender instead of on the back of a napkin.
Discounts that are computed, not estimated
The 20% Senior Citizen and PWD discount and its associated VAT exemption under RA 9994 and RA 10754 are applied under the rules, with ID capture and the discount recorded per transaction — so it appears in your reporting, not just on the receipt.
From table to settled bill
The same order moves through every step. Nothing is retyped between the floor and the kitchen.
- 01
Seat and order
Staff take the order at the table or the counter, against a table label.
- 02
Route
Food lines fire to the kitchen station, drinks to the bar, per category.
- 03
Hold
The bill stays parked against the table while more rounds are added.
- 04
Settle
Split payments, mixed tenders, and Senior/PWD discounts applied with ID capture.
- 05
Close
Daily sales, VAT, discounts and tender types, plus a counted-cash closure.
Controls that matter when the room is full
Most shrinkage and most arguments happen in the gap between what was ordered and what was rung up. These are the controls WSI POS gives you in that gap.
- Voids, refunds and discounts routed through a manager approval PIN, so those actions leave a trail with a name on them
- Per-staff accounts and roles, so a kitchen account never reaches the back office
- Cash closure with opening float, Pay In / Pay Out / Safe Drop and counted-cash variance
- End-of-day reading consolidating gross sales, VAT, discounts and tender types
- Order and kitchen tickets carrying table number and modifiers onto the line
What is not in the product yet
Course and seat numbering is not in the product yet
Tickets carry the table and the items. Sequenced course firing (starters now, mains after) and seat-level splitting are not built. If you run a multi-course service where timing between courses matters, tell us during scoping — we would rather say this up front than have you discover it on a Saturday night.
No consolidated multi-branch console today
Each branch runs its own counter, kitchen display and local database, which is why one branch's outage does not stop another. A group-level console with centralised publishing and reporting is on the roadmap, not in the product.
Related reading: POS for milk tea shops · cloud POS versus local-first · how pricing works
Walk us through your floor
Tell us how food and drink leave your kitchen and we will show the routing on the actual product, not in a screenshot.