Seba BlancoI help independent hotels sell more effectively and operate smarter by combining hotel technology with sales and marketing.
Table of Contents
- Why "hotel software" doesn't cover this
- The architecture: three layers, one job each
- What each team sees on its phone
- Housekeeping
- Maintenance
- The lessons (the part worth copying)
- Offline has to be honest
- Let the forms read the source of truth
- Find out what your PMS API really answers before you design anything
- Test by really cutting the network
- Built around your hotel, not the other way round
- How to start at your hotel
Do not index
Do not index
In a small hotel, reception, housekeeping and maintenance work from the same bookings, but rarely from the same information. Reception has the PMS. Housekeeping and maintenance get a paper sheet, a message, or nothing at all.
The apps in this article bring the PMS to the two teams that never see it. Before each shift, every team finds on its phone the work it has to do that day: which units turn over, who arrives, which services have a set time. What the team logs in the field travels back to the office, even from corners of the property where the signal comes and goes. Each department starts the day organised, and nobody has to chase the front desk for answers.
We built this for one small property we work with: a handful of rooms and cabins in a remote rural area. The method matters more than the case, so the method is what this article is about.
Why "hotel software" doesn't cover this
Most PMSs are built around the front desk. That makes sense: reservations, rates, payments and check-in are where the money is. But a screen designed for a receptionist is the wrong tool for someone carrying a stack of towels.
Housekeeping doesn't need the reservation. It needs to know, unit by unit, whether today is a turnover, a departure, an arrival or a stayover. Maintenance needs even less: only the things with a clock attached, like the hot tub that must be ready at a set hour or the transfer that leaves in the afternoon.
Larger properties handle this with add-on modules or dedicated housekeeping platforms. For a property with a handful of units, those tools tend to be too heavy, too expensive, or dependent on a constant connection. In our case the data was also spread across several places, so nobody had one reliable picture of the day.
The problem was never a missing feature. It was information in the wrong shape, sent to the wrong device, over a connection nobody could count on.
The architecture: three layers, one job each
We kept the design to three pieces. The reasons for the split matter more than the tools.
1. The phone. Each app is a PWA, a progressive web app. Staff install it from the browser, with no app store involved, and it sits on the home screen with its own icon like any other app. The phone stores no passwords or keys, and it never talks directly to the PMS or to Notion.
2. A cloud intermediary. A small program running on Cloudflare Workers sits in the middle, and it is the only place where the keys live. It receives what the phones send and writes it to Notion. Every early morning, before the shift starts, it reads the PMS and builds the day's report in Notion.
3. Notion. This is the source of truth, and it is what management looks at.
Why not let the phone talk to the PMS directly? Because then a lost or borrowed phone becomes a lost key. And because Notion, not the PMS, is where the hotel can correct things by hand. Keep that second point in mind; it comes back below.
What each team sees on its phone
Housekeeping
Staff sign in by picking their name from a closed list. No passwords: on a small team, a forgotten password costs more than it protects.
Cleaning protocols can be read with no signal at all. Each room or cabin has its own checklist, with photos and a field for items guests left behind. Photos are compressed on the phone before sending, from roughly 4 MB down to about 200 KB. On a weak connection, that is the difference between a photo that uploads and one that never does. The same app also handles requests for days off.
At the centre of the app is the daily report, built automatically from the PMS. For each unit it says whether there is a turnover (one guest leaves and another arrives the same day), a departure, an arrival, or a stay that continues. It also checks for overbookings.
One detail sounds technical but is really operational: the phone reads that report from Notion, not from the PMS. If the manager corrects something by hand, the correction holds. If the PMS goes down, the team still has its worksheet. And the fields the hotel fills in manually, such as who is responsible for a unit or how the beds should be made up, are never overwritten by the automatic update.
Maintenance
The maintenance app has three tabs:
- Today: only what is urgent and the services with a set time that day (hot tub, transfers), including anything left over from yesterday.
- Everything else, grouped by area of the property and folded away until someone opens it.
- Shopping list for the weekly trip to town.
The team changes each task's status from the phone. The whole row is tappable, because in the supermarket this app gets used with one hand.
The design principle we arrived at: the home screen is a traffic light, not an inventory. We reworked that screen three times in a single day, and every revision went the same way, toward fewer things on the first screen.
The lessons (the part worth copying)
Offline has to be honest
Anything staff enter without signal goes into a queue on the phone and is sent automatically when the signal returns. The app says "Sent" only when the record has actually arrived. Otherwise it says "Saved, will send automatically." It never pretends.
That sounds minor. It isn't. The first time someone sees "Sent" on a record that never arrived, they go back to paper, and they are right to.
Let the forms read the source of truth
The forms are drawn by reading Notion live. If the manager adds a cabin or changes who is on the team in Notion, the app updates itself. No programmer, no new version. For a small hotel without a developer on call, that matters more than any feature.
Find out what your PMS API really answers before you design anything
This was the most expensive lesson. The PMS API at this property could answer exactly one question: "who arrives on day X?" It could not answer "who leaves today?" or "who is staying tonight?"
To rebuild a full picture of the day, the intermediary sweeps the arrivals of the last three weeks and works out from them who is in the house. It works. We would still rather have known on day one. Ask your PMS provider for the API documentation, or ask whoever builds the tool to test it, before anyone draws a single screen.
Test by really cutting the network
We built the code with Claude working as a coding agent. Before every change, automated tests ran that genuinely cut the network and checked what the app did. Those tests found bugs nobody in the field would ever have spotted. Out there, they would simply have looked like "the app is acting up again," and people would have quietly stopped trusting it.
The lesson isn't about AI. When a tool gets built quickly, the discipline has to live in the tests.
Built around your hotel, not the other way round
The best part of this approach is that nothing in it is fixed. The three layers stay the same; what changes is what each team sees on its phone, and that is decided by the hotel, not by a software vendor.
A property with a spa could give therapists their day's bookings. A lodge with boats or horses could give the guides tomorrow's departures. A hotel with a busy breakfast could give the kitchen the number of guests in house each morning. Same method, different screens.
And it is simpler than it sounds. You don't need to be a programmer. The day-to-day changes, like a new cabin, a new staff member or a new checklist item, are made in Notion, and the app picks them up on its own. New screens are described in plain language to an AI coding agent, which writes the code. What you do need is to know your operation well and to test carefully before the team relies on it. Any hotelier who knows how their own shifts really run already has the hardest part.
How to start at your hotel
You don't need to begin with code. Begin with these questions, in this order:
- What does each team need to see on the phone? Not what the PMS shows. Walk a shift with housekeeping and with maintenance, and write down the questions they ask out loud.
- What does your PMS API actually answer? Get the documentation or a test account. Check whether it gives you departures and in-house guests, or only arrivals.
- Where does your source of truth live? Somewhere management can see and correct by hand, where those corrections survive the next automatic update. For us, that was Notion.
- What happens with no signal? Decide what must work offline (protocols, checklists, photos) and how the app will tell staff, truthfully, what has been sent and what hasn't.
Answer those four and you already have most of the design.
If you want to see where your own operation stands, we put together a short self-diagnosis for hotel operations: hotelmarketingpoint.com/hotel-operations.
Written by
Seba Blanco
I help independent hotels sell more effectively and operate smarter by combining hotel technology with sales and marketing.