Do you own a hotel? — live product tour
A complete property management system with a real Claude assistant inside it - front desk, reservations, guest folios, housekeeping, the daily audit, a real double-entry ledger and the reporting built on it - and a guest-facing side where people check themselves in, read their own bill and check out from their own phone. The screens below are the running product, captured from a live property with rooms occupied and money on the books.
For the front-desk PC that writes key cards. It works once a hotel manager pairs the PC.
You do not have to log in to know how the property did. Every morning the day just gone arrives as a PDF, addressed to whoever you name - rooms sold and the rate they went at, what the restaurant and bar added, what was taken and how, what is still owed. It is built from the ledger the system posts as it works, not typed up by anyone afterwards, so there is nothing between the takings and the page.
/Hotel/HotelSetup/GenerateReportPdf
Owner
The actual PDF - occupancy, revenue, payments and what is outstanding, on the property's own letterhead.
/Hotel/HotelSetup/GenerateReportPdf
Owner
Further in: the post bills, VAT and service charge, the room board as it stood, and every room cleaned and by whom.
Name one address or several. Blank means the report is simply not sent.
One screen for the shift: who is in-house, what each guest owes, which rooms are free tonight, and who is due to leave. Balances are colour-coded everywhere they appear - green means the guest is in credit, red means they owe the hotel - so a receptionist never has to read a minus sign to work out which way the money points.
The shift's working screen - arrivals, in-house guests, departures and live balances in one place.
Every room's current state, grouped by floor and room type.
The full guest list with folio balance, room, and stay dates.
Today's checkouts, each with its folio state and a Close Folio action where one is needed.
Booking is the part of a hotel system that cannot be allowed to be approximately right. Every path that can commit a room - a new booking, a future reservation, extending a stay, moving a guest - takes a compare-and-swap lock on the room or room type, re-reads the live state, and re-validates before it writes. Two clerks selling the same room at the same instant produces one booking and one clear refusal, never two bookings.
Guest details, dates, room type and deposit - availability validated as you go.
Arrivals and stays for the current day, ready to check in.
Forward bookings ordered by arrival date - the closest first.
Rate per night, capacity, and the rooms behind each type.
Overdue departures, unassigned arrivals and anything else needing a decision today.
The whole property as one grid: every room down the side, every date across the top, and each stay drawn as a bar across the nights it occupies. It is the screen that answers the two questions a front desk asks all day - what is free, and who owes us - without opening a single booking. Bars are coloured by money, not by status, so a manager reading it from the doorway can see the property's exposure at a glance.
The property as a grid - every room down the side, the nights across the top, each stay coloured by what the guest owes.
Further down the same grid - stays grouped by room type across the date range.
Every room against every night, colour-coded - a month of the property on one screen.
Every charge, payment, refund and adjustment lands on a guest folio and is posted as a double-entry journal at the same moment. There is no separate reconciliation step where the two can disagree. A folio that reaches exactly zero on the last room's checkout closes itself; one in credit or in arrears stays open and says so.
The cashier's desk - takings, payment types and the day's movements.
Refunds owed and refunds paid, dated per guest.
The chargeable extras that can be posted to a folio.
Negotiated rates and billing arrangements for corporate accounts.
Bar, restaurant and shop sales, postable straight to a room.
The one piece of paper a guest actually takes away, and for most of them the only part of the system they will ever see. It is a proper invoice: the property's own letterhead and logo, a booking reference, the stay itemised night by night, every bar and restaurant visit opened up line by line, every payment with the method it was taken by, and one figure at the bottom that says plainly which way the money points. Printed from the folio itself, so it cannot disagree with the ledger.
/Hotel/HotelReservation/PrintBill
Guest
An executive king, the first of two nights: the room, two room-service orders and a bar tab each on its own dated line, a £100.00 deposit credited, and £122.80 still to pay.
/Hotel/HotelReservation/PrintBill
Guest
The same document when the money is square: a one-night riverside suite stay, paid by transfer, and the box at the foot says Settled in full rather than showing a balance.
/Hotel/HotelReservation/PrintBill
Guest
A guest in credit is told what they are owed, never handed a bill with a minus sign on it.
Once a day the system rolls the property forward on its own: it posts the night's room charges to every occupied folio, flags stays that ran past their departure date, and closes the trading day. It is state-based rather than clock-based - if the server happened to be restarting at the moment it was due, it catches up rather than silently skipping a day.
The audit's own screen - what ran, when, and what it posted.
Every operational action, by user, with a before-and-after note.
What the audit posted, by revenue head, for the day it closed.
Rooms move through clean, dirty, inspected and out-of-service states, and the booking engine respects them: a dirty room cannot be checked into. Faults in the building go to the maintenance book, which every business type keeps.
Room-by-room cleaning state, with today's departures flagged.
The property's rooms, their types, floors and current status.
This is a real accounting system, not a sales report with an accounting tab. Every movement at the front desk - a deposit, a room charge, an extra, a payment, a refund, an adjustment, a write-off, a transfer - posts a double-entry journal at the moment it happens, against a chart of accounts the property controls. The trial balance, the profit and loss and the balance sheet are all generated from those postings, so none of them can drift from what the desk actually did. There is no nightly export to a separate package, and no reconciliation step where the two versions of the truth disagree.
The property's financial position in one screen.
The property's own accounts, which every posting lands in.
Which ledger account each payment, credit and debit type posts to.
The double-entry postings themselves - hundreds of them, raised by the front desk without anyone typing a journal.
Generated from the postings, not assembled separately.
Revenue and cost for any period, straight off the ledger.
Assets, liabilities and equity, from the same postings.
What is owed, by whom, and for how long.
Money taken before the stay it pays for, tracked against it.
Import a statement and match it line by line against what the system recorded.
Cash positions and movements across the property's accounts.
Close a period and its figures are fixed - reopening one is a deliberate, audited act.
The measures a hotel is actually run on, computed from what happened rather than estimated from bookings. Occupancy counts assigned room-nights against the rooms the property really has, and a guest who left early stops counting on the day they left. Around that sit the questions an owner asks: which channel is worth its commission, which market segment pays best, how far ahead people book, and how this month compares with the last one and with the same month last year.
The owner's view - performance without the operational noise.
The same day from the desk's side - occupancy, arrivals, departures and room status.
Every payment taken over a date range, totalled.
Room-nights sold against rooms available, counted from assigned rooms only.
What each room and each type actually earned over the period.
This period against the same period last year.
The shape of the trend, month by month.
What each booking channel delivered.
What those channels cost, booking by booking.
Where the business is coming from.
Revenue against cost for the period.
Built and emailed to managers automatically every afternoon.
Every member of staff against what they actually did - check-ins, checkouts, folio postings and revenue handled, ranked.
The same people measured by throughput rather than money - who cleared how much work, and when.
Revenue against cost per department, so a busy month and a good month can be told apart.
Check a guest in and the key card is encoded from the same screen - no second system, no re-typing a room number into the lock vendor's own software. Cabbash ships Lock Writer, a small Windows application that sits on the front-desk PC beside the USB card encoder. The browser hands the check-in to it directly; the receptionist puts a card in the encoder and writes it. It has to be a desktop application rather than part of the website because the lock vendors' own SDKs are 32-bit Windows libraries driving that USB encoder - there is no cloud or mobile API in either of the two integrated so far, so nothing running in a browser or on a phone can physically write a card.
Each checked-in room on the booking carries Write key card, which hands the room and its dates straight to Lock Writer on the front-desk PC.
First run on a new front-desk PC - it reads which hotel it belongs to and connects itself.
Every room's own lock number, in the vendor's own format, alongside its type and status.
One setting per property - and the one Lock Writer reads to decide which vendor's SDK to drive.
A guest scans one code in the lobby or the room and gets the whole of their stay on their own phone - no app to install, no account, no password. They can check themselves in, read their bill line by line as it builds, check themselves out, and rate the stay. Every page is the live folio: the same numbers the front desk is looking at, at the same moment.
What a guest sees after scanning the property's code: Call Reception first, then everything for the stay - no app, no login.
/HotelGuest/{property}
The guest enters their own details before they get to the desk.
/HotelGuest/CheckIn
The guest's own telephone number is the whole login - there is no account to create.
The live folio, itemised - and a real guest in credit, labelled as such rather than shown as a negative.
/HotelGuest/ShowBill
Phone or room number, and only once the balance is settled - the front desk sees it at once.
Five stars and an optional comment, asked where the guest already is.
/HotelGuest/Rate
/Hotel/HotelReservation/Details
Guest
The reservation as the guest receives it: confirmation number, arrival and departure with the property's check-in and check-out times, the rooms, the deposit and the balance.
Every booking is confirmed to the guest by email the moment it is saved - nobody at the desk writes a word of it. Each step after that sends its own: check-in, a deposit or top-up taken, a stay extended, checkout. Each one goes out in the property's own name, and each ends with the official check-in and check-out times and the property's own small print. One switch in Setup turns guest email on or off for the whole hotel, and a booking is never held up waiting on a mail server.
The property gives Cabbash a mailbox address, and booking emails arriving there are read automatically and listed for the front desk. A classifier reads each message first: bounces and automated notices are never imported at all, and anything it cannot place waits on a second tab rather than being thrown away - so the inbox stays a list of bookings, and a real enquiry is never silently lost.
Booking emails pulled from the property's own mailbox, classified and listed.
The same inbox in dark mode: what still needs attention, and why each message was counted as a reservation.
Help is built into the portal and answers the question a new manager actually has: where is this screen, what does this figure mean, why did the system just refuse that. Most questions are answered instantly from answers written for this product. When that is not enough, one press asks a real Claude model. And when even that does not settle it, the question goes to the Cabbash team - a person answers, and the answer comes back to you.
One box and a plain question in plain words.
A live answer about balance colours and when a folio closes itself - written, formatted, and correct.
The same conversation on the dark theme - the assistant is part of the product, not bolted beside it.
Cabbash Bookings is a public website where guests find a hotel, choose a room and pay for it in full - and the booking lands in that hotel's reservations as it is made. Nothing is typed in twice and nothing is held without payment.
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.
A hall is a second business running inside the hotel, and it is booked, held, charged and settled on its own terms. A wedding, a conference or a function is taken as an enquiry, held against a real venue with a real capacity, and turned into money that lands in the general ledger the same night - not in a diary somebody keeps separately and reconciles later.
Four functions over the next five weeks and £15,025.00 of business in the header. A wedding, a conference and a dinner confirmed, a 70th birthday still an enquiry - and the conference billed to Harland & Pike LLP rather than to the man who booked it.
Each hall set up once with its seated capacity and its hourly and daily rate, then booked as often as it sells. Capacity is not decoration - it is what the booking form checks a headcount against.
One wedding: the ballroom for the day, a wedding breakfast and drinks reception for 90, a DJ, and a £2,500.00 deposit against £7,545.00 of charges - £5,045.00 still owed. The line under the balance is the whole point: charges post to Events & Banqueting Revenue, and a deposit taken before the day is held in Customer Deposits until it is applied.
The property's other revenue and cost lines: repeat guests and their history, and the stores side - suppliers, purchase orders, and stock held against the hotel's own warehouses.
Repeat guests, their stay history and their spend.
The property's supplier list and their terms.
Ordering stock in, receiving it, and paying for it.
What is held, where, and what it is worth.
The front-office POS: a leisure-club day pass and a spa treatment charged to Riverside Suite 203, straight onto the guest's running folio.
A guest at the pool or the bar does not reach for a wallet - the front desk charges the sale straight to their room, and it lands on the folio they settle at checkout. Which outlets may do this is a switch Head Office throws once for the whole company, and the tax on each service is worked out and posted with it, to the right ledger account, without anyone typing a journal.
Each outlet the property runs - the laundry, the coffee bar, the lounge - is its own till, reached with a four-digit business code and a PIN on the same glass a phone would use. Staff sign in, sell against that outlet's own short menu, and either take payment there or send the bill to a room.
An outlet till signed in to the laundry - wash and dry-clean, priced and ready to ring up.
/Account/StaffLogin
The keypad every till shares: a business code, then the operator's PIN.
/Account/StaffLogin
Every purchase order records the price you 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. Nobody keeps a spreadsheet; it falls out of ordering stock the normal way.
The unit cost is typed in per line on each purchase order - that is what builds the history.
Each item's last price against its latest, the change flagged, a trend line beside it.
Every purchase of an item, oldest first, and the step between each price.
/Hotel/HotelSetup/GenerateReportPdf
Owner
The alert section as it prints on the daily report - item, old and new price, the rise - in red.
You do not have to go looking. Set a threshold and any item whose price jumps more than that over its last purchase is flagged, in red, on the morning Day Audit that already lands in the owner's inbox. A supplier slipping 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
Everything the property runs on is configurable per property - rooms and rates, payment and credit types, departments, the reservation mailbox, the address the daily report is emailed to, and the check-in window that drives the overdue-departure gate.
Property details, times, currency and the addresses the system emails.
Every room, its type, its floor and its lock number - the list everything else is built on.
Rate, occupancy and description per type, which is what the booking screens price from.
Which tenders the property accepts, and the ledger account each one posts to.
Everything that can land on a folio besides the room, priced and mapped to a revenue head.
Check-in time, early check-in window, currency and tax - set once, honoured everywhere.
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 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 restaurant & lounge and supermarket & retail businesses, each with its own product.