Do you own a restaurant or lounge? — live product tour
Tables, orders, the kitchen screen, and the cash - plus everything underneath a service: the menu, stock, staff and their rota. The same live business runs on the portal, on the till, in the waiter's pocket and on the diner's own phone, and all of them see the same table at the same moment. And when the internet cannot be relied on, Cabbash Offline runs the whole floor on a phone or a Windows PC, and sends every table to the back office when it closes.
Android 8 or later. Open the downloaded file on the phone or tablet, and allow installs from your browser when Android asks — it isn't from the Play Store.
Android 8 or later. Open the downloaded file on the phone or tablet, and allow installs from your browser when Android asks — it isn't from the Play Store.
Windows 10 or 11, 64-bit. If Windows says it protected your PC, choose More info, then Run anyway.
Close the night and the report is already sent - the same document a hotel's owner gets, in a restaurant's language. It opens by telling you in plain English how the night went, what your guests will have felt, and the one or two things worth doing differently tomorrow. Then the figures behind it: how the money arrived, how the kitchen performed against your own service targets, the categories that carried the night, the five best dishes, every server's take, and every table. Built from the figures the close itself committed to, so it cannot disagree with the till.
/CashierPortal/EndOfDayReport
Owner
The actual PDF an owner receives. Four figures across the top, then the night written up: £6,174 across 79 tables, 544 items, and the two things worth doing tomorrow.
/CashierPortal/EndOfDayReport
Owner
Page two: 96 orders against a 5 minute pick-up and 20 minute service target - what was on time, what was late, how long each stage really took, and the slowest tables of the night.
/CashierPortal/EndOfDayReport
Owner
Page three: every category, every department, every server, then table by table.
The same split on screen - taken from the close's own figures, so the page and the report always agree.
Card and transfer takings against the accounts they were paid into, ready to check off a statement. A split sale credits each account with only its own part, so the cash half stays with the till instead of being banked twice.
Set one address or several on the business itself. Blank means nothing is sent.
Where the day actually happens: a cashier working real tables with the locked ones called out in red, the kitchen screen refreshing itself as orders land, and the end-of-day close that will not let you finish while a table is still open.
A full menu - three hundred and fifty dishes across seven courses - with the order building on the left.
Cash, card, transfer, split, or straight onto a hotel room - with the amount tendered, the change, and the table's whole audit trail.
A cashier's own view - every open table at their terminals, locked ones in red.
A real pass mid-service: a dozen tickets on the restaurant till, each with the waiter who sent it, the time it landed, and the note they typed. Live-refreshing, with a sound alert on new orders and voids.
Per-terminal close-out with a seven-day history - blocked while tables are still open.
Every table keeps a complete record of its own life, and any member of the floor staff can open it from the tile. Not a summary written afterwards - each event is recorded as it happens, by the person who did it, to the second. When a manager asks what happened to table nine, the answer is a page, not a conversation.
Every open table as a tile - item count, what it is worth, when it opened - each with a view button onto its history. A tile with nothing on it carries a bin as well; none of these is empty.
One table's whole life, oldest first: opened at 21:50, four items received, sent to the kitchen with every line named, then another seven fifteen minutes later.
One table passing through three sets of hands. The waiter opens it and sends the order, split across the Bar and Kitchen printers on the one line. The kitchen accepts it and then marks it ready - both stamped to the kitchen, not to the waiter, with the seconds between them there to read. A cashier voids a line at the end, under their own name. Three people, one page.
A cashier removes a pitcher at 22:10 and the trail says who and what. Below it the day turns over, and a three-hour gap is called out rather than left to be worked out.
Two different pieces of paper, printed at two different moments, and the difference between them matters. The bill is what a table is given when it asks what it owes - no receipt number, and marked an estimate on its face, because nothing has been settled yet. The receipt is only issued once the money is in, and carries the number the sale will be found by ever afterwards.
/Waiter/PrintBill
Waiter
What the table is handed when it asks what it owes - the total so far, marked as an estimate, with nothing closed and nothing paid.
/Waiter/Receipt
Cashier
Issued only once the money is in: seven lines, £116.00 paid, the waiter and the cashier both named, and a receipt number the sale can be found by.
CabbashMobile
Laid out for 80mm paper and sent to whatever printer the till already uses - including a Bluetooth one that has been paired. From the phone there is no driver to install; from a computer, see Printing From A Computer below.
CabbashMobile
The same receipt printed from a computer through the ordinary Windows print - laid out for the 72mm printable width inside an 80mm roll, and cut by the printer's own driver.
A receipt printed from the phone goes straight to the printer - the app speaks the printer's own language and needs nothing installed. A computer is different, and it is worth being plain about it: a browser cannot talk to a till printer directly, so it prints the way Windows prints everything else. Install the printer's own driver, pick it when you print, and the receipt comes out laid out for the roll and cut at the end. No extra software of ours, no service running in the background - the ordinary Windows print you already know.
An order placed on the phone prints itself, at the station that has to cook it. The bar's drinks come out at the bar, the grill's food at the grill, each on its own slip, each cut from the next - nobody carries a docket across the floor and nobody presses Print. Give a product department the address of the printer standing next to it, switch the setting on, and that is the whole configuration.
Nine departments, each pointed at the printer that stands beside it. Categories belong to a department, so a product inherits where it prints.
Off by default. On, and each order goes to its department's printer; anything without one still prints at the till.
The same kitchen screen on a phone: each ticket split into kitchen and bar items, with the waiter, the time and the table's note.
/Kitchen
Signing in checks every station printer. One is switched off, and the till says so before the first order is taken.
No pretending. It names the station, says why, and offers Retry - and the order is saved either way.
What a Store Admin sees when they open the portal: live sales, open tables right now, stock positions, and the last few end-of-day closes - and underneath it the whole menu configuration that service runs on.
Live view for one store - open tables now, revenue, stock and recent end-of-day closes.
Every physical till, its online status, printer and paper.
Menu categories grouped by department, with drink flags and terminal assignment.
The full catalogue - cost, allergens, per-terminal pricing, reorder point and food cost %.
Ingredient-level stock by weight, kept separate from the sellable catalogue.
The oldest problem in a dining room is catching someone's eye. A diner taps one button on their own phone and every waiter's device buzzes - not a chime that blends into a busy floor, but a distinct double pulse they learn by feel. It reaches them whether the app is open, in their pocket, or closed altogether, and the call is written down before any of that is attempted, so a manager can see who asked and when even if a phone was flat.
One button on the table's own QR page. No app, no account, no catching anyone's eye.
/CustomerOrdering
The real thing, on a waiter's phone: Table Call, Table 19 needs assistance - arriving over the till screen while they are mid-sale, with its own double-pulse vibration.
/CustomerOrdering
The same call in the portal's notification bell, for whoever is not on the floor - table number and time, kept whether or not a phone ever received the push.
The diner browses the catalogue the till is using - change a price and the next scan shows it.
/CustomerOrdering/Menu
One QR code per table, printed once. A diner scans it with their own phone and lands straight on the live menu - no app to install, no account, no waiting to be noticed. They browse the same catalogue the till is using, and can call a waiter over without flagging anyone down. Nothing about it is a separate menu that has to be kept in step: change a price or mark something off, and the next diner to scan sees it.
Print once - diners scan with their own phone, no app to install.
What a diner sees after scanning: the restaurant's own photo, Call Service, the menu, About Us and the WiFi.
/CustomerOrdering
The same categories and products the till uses, browsable from a phone.
/CustomerOrdering/Menu
CabbashMobile (Android and iOS) carries the same multi-terminal login, the same live table state, and the same checkout logic as the portal - limited by the role the staff member logs in with, and synced in real time with the till.
Pick the till you are working today - live online status per terminal.
A waiter's live table list, matching the portal in real time.
Search, scan or browse - the running total updates as you go.
The same app, a different role - a cashier closes tables, never opens them.
Once the order is in, Complete Sale hands straight off into payment.
Cash, card, transfer, split, post bill or complimentary - VAT and service live.
Switch a restaurant to Standalone offline and its whole floor runs on Cabbash Offline, on a phone or a Windows PC: tables are opened, ordered, sent to the kitchen, billed, paid and closed on the device, internet or not. Each table goes up to Cabbash in one piece when it closes - with its dockets, its voids and every step of its history - and while it is open, the portal still knows it is there.
Window 4: two mains and two beers, the newest on top, with the menu - photos and all - beside it.
Number, name and how many are sitting down - or switch to a takeaway for collection or delivery.
Docket K-000105 for Window 4 with the kitchen's note; the bar gets its own slip for the drinks.
Both tables, their totals and who is serving them - the same list on a phone or a PC.
Cabbash Offline
The Situation Room lists the tables open on Cabbash Offline - waiter, when opened, items and total - long before they close.
Cabbash Offline is the till on an Android phone, and it is built the other way round from a web page: every sale is written to the phone first and sent to Cabbash afterwards. The internet dropping out stops nothing - the cashier keeps scanning, the customer pays, the receipt prints - and when the line comes back every sale goes up on its own, in the order it was taken, without anyone pressing anything.
On a phone-sized screen the basket scrolls and nothing else does: the totals and every button, down to Complete Sale, stay where the thumb expects them.
Cabbash Offline
The line has gone and the till says so across the top - and the £4.55 sale is completed anyway, saved on the till and sent to Cabbash when the line is back.
Five drinks, £20 handed over, £9.85 change - every line and the total to the penny, with the till, the cashier and the time.
Each person's own report before they go home: sales, payments by type, voids and complimentaries, and how many sales are still waiting to be sent.
The same Cabbash Offline, installed on a Windows PC - a touchscreen POS terminal at the counter, or the laptop already in the shop. It is not a second product with its own rules: it is the phone app, built for Windows, so the way it sells, holds its sales and sends them to Cabbash is exactly the same. Every PC is a till in its own right - no server in the back room and no network between the tills to set up.
The Drinks aisle beside the basket, the newest line on top, and the totals and buttons that never scroll away.
Business code, then PIN - from the number keys or the screen. One copy of the till per PC.
The USB receipt printer installed in Windows, or the network printer Store Setup names - and Windows' own offline flag shown, so nobody waits for a receipt that is not coming.
Cash, card, transfer or split. £20 handed over for £10.15, and the change shown as it is typed.
Every printed code is a way in, and now each one is counted: how many people opened the menu or the shop from a printed code, how many guests opened their stay from a room, how many pressed Call A Waiter. A business sees its own; a company sees every business side by side.
End of Day can run on its own, per terminal, at a time the business sets. It waits for the floor to be genuinely quiet, clears away empty tables, and closes the till - and when it cannot, it says so on a ticket instead of failing silently.
Where the automated close reports anything it could not finish - alongside faults staff raise themselves.
What the close will post, before it posts it - takings by tender against what the till recorded.
Any previous close, reopened read-only - the same figures, months later.
The same day split by where the money came from - kitchen, bar, and anything else you define.
Every table in the period with what it took - the seven tabs across the top are the same close asked seven different ways.
The same money grouped by what was sold rather than who sold it.
Every line sold, with quantity and value - searchable, and sortable on any column.
What each member of staff put through the till in that close.
When the money actually arrived - the shape of the day rather than its total.
Not a summary bolted onto a till, but a real double-entry ledger. Every sale, every payment and every expense posts a journal as it happens, so the accounts are not something anyone assembles at month end - they are already there. A restaurant gets the same books a hotel does, on the same screens, because money does not behave differently across a counter.
Revenue, expenses, net profit and cash collected - with the trend and where the revenue came from.
Built from the postings, not typed up separately.
What was taken, broken down by where it came from.
What actually moved, against what was merely billed.
Yours to shape - grouped by type, with the mappings that decide where each payment lands.
Every posting the day made, in the order it made them.
The check that the books balance, on demand rather than at month end.
Assets, liabilities and equity, from the same postings.
The till's own story, told back to you. Not a port of the hotel's room-and-guest reports - these are the questions a restaurant actually asks at the end of a shift: what sold, who sold it, how it was paid for, and what was given away rather than charged for.
Every report in one place, grouped by what it answers.
Every sale closed at a terminal in the period, with its totals and discounts.
Who took what, by value and number of sales, with each one's share.
Cash, card, transfer, split and post bill - each as a share of the day.
What came off a bill, who took it off, and when.
Every waiter and cashier against what they sold - value, number of sales, and each share of the period.
What came off bills, who authorised it, and how much of the period it accounts for.
Warehouses are created for you - one main warehouse per store, and a sub-warehouse per terminal - and stock moves between them through real purchase orders, request orders and damage write-offs. Low stock is watched per warehouse, so a product that is fine overall but out at one till is still flagged.
One main warehouse plus an automatic sub-warehouse per terminal.
Products below their own reorder threshold at a specific warehouse.
Ordering stock in - collected, moved and paid, which auto-creates a real expense.
Moving stock from the main warehouse out to a terminal's own sub-warehouse.
Breakages and write-offs against a terminal's stock, each with a compulsory note.
Every purchase order records the price actually paid for each item that day, so a price history builds itself per item. What it cost last time, what it costs now, and whether it has crept up - no spreadsheet, just a by-product of ordering stock the normal way.
Each item's last price against its latest, the change flagged in red when it rose, a trend line beside it.
Every purchase of an item, oldest first, and how the price moved each time.
CabbashMobile
Store Admin
The report's price tracking section. Every purchase order line is checked against what that item last cost and anything over 5% is named in red, so a quiet section is itself the answer.
Set a threshold and any item whose price jumps more than that over its last purchase is flagged, in red, right on the End of Day report that already goes out when the day is closed. A supplier nudging a price up quietly does not stay quiet.
Most systems can tell you what a dish sells for. This one tells you what it actually cost, and whether the kitchen used what the recipe says it should have. Every kilo that arrives, gets cooked, gets binned or gets counted is written down, so at the end of the month the difference between what should be on the shelf and what is on the shelf is a number you can look at rather than a feeling.
Every ingredient, what it is worth, and which ones are at their reorder level.
Food cost and gross profit for each dish on the menu, the expensive ones at the top.
Open a dish and see each ingredient: what it cost to buy, its yield, and what the usable portion really cost.
Opening, delivered, cooked, wasted, counted, closing - per ingredient, and it adds up.
Expected against counted, line by line, with what the difference was worth.
Recorded against a reason as it happens, and totalled by reason for the period.
Record a batch of sauce and the ingredients come off, the sauce goes on.
Each ingredient with its unit, what it is bought in, its yield and what it is worth.
The unit it is held in, the unit it is bought in and how many that holds, its yield, and its reorder level.
Every count with what it corrected. Only one can be open at a time, so no two ever claim the same variance.
Every change to every balance, what caused it, who did it, and the balance afterwards.
Set the reasons stock gets written off against. Retired, never deleted, so old records keep their label.
A freezer drifting warm, a generator that will not catch, a drain backing up during service. Each one gets raised with a severity, sent to the firm that fixes that sort of thing, and then updated every time anything happens until somebody writes down what fixed it. Months later, when the same fault comes back - and it does - the whole story is still there.
Open faults by severity and how long each has waited, closed ones below with how long they took.
Open a ticket and every update is there in order, with the box to add the next one.
Who you call for what, with the contact who answers.
Your own list, so the book can be read by what keeps breaking.
When a printer stops mid-service nobody has time to work out whether it is the printer, the network or the till. Technical Support is a role for the person you call, and it gives them something no other role has: a phone screen showing what actually went wrong today, and a tool that finds every printer on site and prints a test page to any one of them. They are not a till user with extra buttons - they sell nothing, and the sales screens are not theirs to reach.
Network printers found by sweeping the network, Bluetooth printers the phone is paired with - each with its address, its state, and a test print.
/Support/Printers
A test print that failed, and said so. A Bluetooth printer cannot be asked how it is, so the test is what answers - here the printer was switched off.
/Support/Printers
Promotions the till can apply, with dates that decide when they run. A code is created once with a percentage and a window, and it appears on the till for exactly those days - nobody has to remember to switch it on in the morning or off at the end of the month.
Promotions with their own dates - running, scheduled or finished, at a glance.
Codes and offers with their own dates and limits, applied at the till rather than argued about.
Customers carry a card with a barcode. Points earn on what they actually pay and are spent as money off a later sale, at rates the business sets itself. It is a real balance with a real ledger behind it - every point earned, spent or adjusted is recorded, so a balance can always be explained.
Who is on the scheme, what they hold, and what the business owes them.
Every point earned and spent, per member, with the sale that moved it.
A section runs on somebody. Name them Head of Department and they get a login of their own - one screen, their own department's End of Day, and nothing else in the product. It is a reading post, not a management one: no till, no money moved, no settings.
Each product department carries who runs it, picked from the staff who actually hold the role - so the name on the screen always ties to an account that can sign in.
The week's closes, and nothing else in the sidebar. With totals switched off the money columns are gone too - what is left is which terminal closed, when, and who closed it.
Open a close and the breakdown is theirs alone - the departments they head, the items and the counts, and any voids that came off their section.
Running costs and staff discipline sit alongside the sales side of the business, with one grouped view of every user, terminal by terminal. Scheduling and clock-ins each have their own section.
Day-to-day running costs, categorised by expense type.
Staff discipline records - type, staff member, manager, outcome.
Staff grouped by terminal, with role, PIN login and portal access status.
A company that runs several stores gets its own layer above them: what it pays for the suite, how each store performed today, every user across the whole business, and a group-wide sales rollup that drills back down into any one of them.
What the company pays, total headcount, store breakdown, and today's takings per store.
Every admin and staff member across the company's stores.
Group-wide sales rollup with a date range, drillable into each business.
Nobody here runs payroll. It belongs to the company above this business - the group employs the staff and the group pays them - so head office opens one list covering every business at once and runs it from there. What this business contributes is the part it already produces: the hours. Every clock-in and clock-out on the staff app is the record the run reads from, so nobody is paid from anybody's memory of who worked when.
Every member of staff the group employs, across all its businesses, on one list - with the business each belongs to.
Expected against actual, the hours pulled from real shifts, and the variance called out before anything is paid.
A completed run: the period, who ran it, when, and a payslip line for each person.
Every shift starts and ends here. From the login screen a staff member taps Attendance Tracker - no sign-in, no till session - keys in the business code and their PIN, and meets the same clock they use on their own phone: one big button that takes a photo to prove it is really them, then logs the time. It is the record payroll trusts, and the same screen shows each person their own hours and history - nobody else's.
The same keypad as staff login, but it opens the clock rather than a till session.
/Attendance
The big camera button, green when you are off the clock - a photo confirms it is you.
/Attendance
The front camera opens for one shot before the time is logged - the record payroll relies on.
/Attendance
Red once you are in, with the time you started and today's hours below.
/Attendance
Days and hours this week and month, a 14-day chart and every recent shift - each person's own, never a colleague's.
/Attendance
A manager plans the week ahead a shift at a time - or the same shift for several people at once. A shift stays a draft until it is published, and once it is, it becomes what the clock checks against: nobody can clock in for a day they are not rostered on. Real clock-ins are then matched back to the plan, so who turned up - and who was late - is a screen, not a guess.
The week's schedule, one row per staff member, draft until it is published.
Pick any number of people from the staff multi-select and the same shift is added for each.
Delete just one person's row, or the entire shift for everyone on it at once.
Real clock-in/out matched against the rota - On Time, Late, Left Early or No Show.
Front desk staff work a night shift; a manager reads the same screen in daylight. Both themes are designed, not one inverted into the other, and the choice sticks. The whole interface is translated too - English and Nigerian Pidgin, across every page - and switching language keeps you exactly where you were rather than dropping you back at a dashboard. The screens below are the hotel property, because that is the business this portal runs - the top bar carrying both controls is the same one on every kind of Cabbash business.
The dashboard at night - real occupancy, real charts, designed for the dark rather than inverted.
The busiest screen in the building, on the theme a night shift will actually use.
Two languages in the top bar of every page - switching keeps your place.
The same product in Pidgin - the interface, not just a few labels.
Cabbash also runs company and hotel and supermarket & retail businesses, each with its own product.