Building Hotel Software Is Mostly About People

The system assumed guests would be checked in when they arrived. That sounds reasonable. It isn’t what happens at a guest house at midnight.

When we looked at the records, 27 stays had been checked in a day after their booked date. We assumed they were late arrivals. Not one of them was. Every guest had been in the room on the night they booked. A guest arrives at 11pm, the night staff hand over a key, and the check-in gets typed up in the morning when things are quiet.

That’s a perfectly good way to run a front desk. But the system billed from the moment of typing, so every one of those stays came out a night short. The first day was worse: guests who were already staying when the system went live were entered that morning, and one stay of nearly three months was billed as a single night.

We could have sent a memo telling staff to check guests in on the spot. Instead we changed the system to fit the habit. A stay is now billed from the night it was booked for. If a guest really did arrive late, a manager says so and gives a reason. And front desk can record that a guest arrived on an earlier day, which shows on the guest’s history so nothing is hidden.

Every mistake staff make is a design brief. Read it before you write the memo.

Ten bills had the same payment on them twice, taken between seven seconds and two and a half minutes apart. The cause was a single moment of doubt. After a payment went through, the form stayed on screen, still filled in, with the button still live. Did it work? Better press it again.

Room charges were doubled the same way. The charge was only added at check-out, so during a stay the bill looked empty. An empty bill looks like a mistake, so staff fixed it by adding the charge by hand. Then check-out added it again.

Both are what happens when a screen leaves someone unsure. So now a payment that goes through is replaced by a receipt, with nothing left to press. Every save shows a confirmation, so no action passes silently. And while a guest is staying, their reservation shows what the stay will cost, so an empty bill no longer looks like a mistake.

A question we got from the desk was simply “I can’t cancel a reservation?” The button wasn’t broken. It was hidden, because only managers could cancel a stay that had already started, and nothing on screen said so. Hiding a button doesn’t remove the question. It just means nobody can answer it.

The rule we work to now: if someone can’t do something, the button stays visible, greyed out, with the reason next to it, for example “ask a manager.” People learn the rules of the hotel from the system itself, at the moment they need them.

The same goes for numbers. The home page once showed 63% occupancy while two guests were in the building, because guests who left early still counted until their booked departure date. We fixed the count, but we also fixed the confusion. Every figure on the home page now has a small “i” that explains exactly what it counts. Occupancy reads “7 of 11 rooms tonight”, so you can check it against the room board.

A hidden button is a question nobody can answer.

Different people look after different parts of a room. Front desk knows who is in it, housekeeping knows whether it’s clean, and management decides whether it can be sold. So the room board keeps those three things separate, and each person updates only their own part. Nobody overwrites anyone else’s work, and nobody sells a room that hasn’t been cleaned.

Discounts used to sit on the bill page, away from where front desk deals with the guest, but the owner wanted front desk handling discounts at the counter. So we moved them onto the reservation, where the desk already works, and managers get an email every time one is given. The desk can act, and the owner stays informed without having to be asked.

Every charge and payment also shows who posted it and exactly when. That isn’t there to catch people out. When something goes wrong, the question “who did this?” leads to a five-minute training conversation with the right person, not an argument at the end of the month.

You can’t hand a hotel a login and walk away. Staff change, shifts rotate, and the person on the desk at 2am didn’t attend the launch-day walkthrough. So the training is built into the system:

• A guided tour on everyone's first login.
  It walks through the whole flow on the real screens: setting up rooms, taking a booking field by field, checking in, checking out and settling the bill. It's tracked per person, not per device, so on a shared front-desk tablet every new member of staff gets it, not just whoever signed in first.
• A Getting Started page that knows where you are.
  Its checklist watches the system and ticks off what's actually been set up, so a new hotel can see what's left to do.
• Tours for each section.
  Guests, for example, has its own walkthrough: finding someone, avoiding duplicate records, and what a guest's history shows.
• Explanations where the question comes up.
  Greyed-out buttons give their reason, and figures explain what they count, so the answer is on the screen at the moment someone needs it.

And training doesn’t stop at launch. When the records show a habit forming, like next-morning check-ins or a charge being added by hand, we change the system to fit it, then walk the team through what changed and why. The data tells us who needs a refresher and what it should cover.