Who plans day three?

Look at the shape of a five night stay from where your software sits.

The booking. The confirmation. The pre-arrival message. The registration form, the passport, the signature, the arrival itself. Then, at the far end, the departure, the invoice, the review request. Both ends are crowded. There is a vendor for every one of those moments and most properties are paying two of them.

Now look at the middle. Tuesday, Wednesday, Thursday.

That is most of the stay. It is the part your guest will describe to other people when they get home. And almost nobody in this industry writes about it, let alone builds for it.

Who plans day three?

Day three has no owner. It is after the arrival flow has finished congratulating itself and well before anybody asks for a review. Nothing is scheduled to happen. Which is precisely why things happen.

On day three a guest wants four small things, and they are always the same four. What is on today. What time it starts. The code for something. One good dinner.

Those four questions arrive at your desk. By phone, in person, in a WhatsApp thread at 21:00, and again tomorrow morning from the guest in the next room. Your team answers them, correctly and patiently, several hundred times a season. That is not a software problem in the sense that software will make the questions stop being asked. It is a software problem in the sense that the answers already exist and nobody has put them where the guest is looking.

One list, kept three times

Here is the thing the middle of the stay actually produces, and it is much simpler than it looks.

A stay produces one list. What this guest has booked, on which day, at what time, and what they asked for alongside it. Two breakfasts on Tuesday. The boat at 09:00 on Thursday. A late checkout on the Sunday. Lactose intolerant.

Most properties keep that list three times over.

The guest has a version, somewhere between a confirmation email and their own memory. The front desk has a version, in the reservation screen. And the person running breakfast has a third version, written out by hand or printed yesterday afternoon, because neither of the other two is shaped like a service.

Three copies of one list is three chances to be wrong. And the paper one is always the most current, which tells you everything about how useful the first two were.

The interesting question for a software company is not how to make a nicer version of any one of those three. It is whether you can get away with keeping only one.

What the guest opens

The itinerary is the list, assembled per guest and per day. In the product the units are itinerary items, and an item is one of four things: an Experience, an Amenity, a Guidebook or a Calendar event. It sits on a specific day, a specific day and time, or across the whole stay.

The guest opens it on your own domain, from a link in whatever channel they already use. There is nothing to install.

It shows what is booked, what is on today and what is next, with the guidebook answers sitting underneath it: house rules, how the appliances work, the neighbourhood. Those are the answers reception repeats all day.

It adapts by guest, stay day and language. That is the whole of the personalisation, and we would rather say so plainly than let the word do work it has not earned. A Dutch family on night four and a Spanish couple on night one do not see the same screen, because the day and the language are different. Ordering, timing and language adapt. Nothing scores the guest. Nothing predicts. It runs across 100+ languages.

Do guests actually use hotel apps?

This is the fair objection and it deserves a real answer rather than a slide.

Guests do not use a hotel app that asks for a download, an account and a password, and then shows them a PDF of the breakfast times. That is not scepticism about guests. That is an accurate read of a bad trade: five days of use in exchange for a store search, an install and a deletion.

Usage comes from one thing only. Being the fastest route to something the guest wants in the next ten minutes. The door code. The breakfast time. Tonight's plan.

LabNul50 retired its 24/7 phone concierge on exactly that behaviour, and 25,000+ guest-opened doors is the evidence that a guest will open something when opening it is the shortest path to the thing they want. Nobody opened it out of loyalty. They opened it because the alternative was finding the number.

Where the list comes from, without anyone typing it

A list that somebody has to maintain by hand is a list that is wrong by Wednesday. So the itinerary is assembled rather than written.

From the guest's own orders. When a guest's order is confirmed, the items are created from it and carry the quantity ordered. Two breakfasts is two. A filled fridge of four beers, five colas and three bags of crisps is twelve. Anything priced per day spreads across the days of the stay; anything priced per night is dated the morning after, exactly the way the guest's own screen labels it. Four nights of breakfast is four items on four mornings, not one line stamped on the day you approved it. If a guest cancels, every item that order created is cancelled with it.

From your property system. Where your rate includes breakfast, dinner, half board or a package, those add-ons can land on the guest's itinerary straight from the system of record. You choose which ones sync and where they land: every morning, every night, or on the check-in day. Take the add-on off the rate and it comes off the itinerary. This is live today for Cloudbeds and StayNTouch, with a nightly pass that keeps upcoming reservations in step rather than only new ones.

From your own team. An operator adds an item by hand wherever one is needed, and every item carries a visibility: external or internal. External items are the guest's. Internal items are yours, never appear on the guest's screen, and are filtered out for the AI assistant as well, which applies the same rule rather than a second one.

Your booking stays in your property system. That remains the system of record. We read from it and write the guest's list.

The shift: one day, every room

The second view is the one your duty manager leaves open.

The day board is one day across the whole property. Every room with a guest in it is a row. Each row plots that reservation's timed items as blocks along the working day, with its day-wide items pinned beside them. Move forwards and backwards a day at a time and read the property as it will actually happen.

You narrow it with hospitality words rather than software words: arrivals, stayovers, departures, each carrying a count of how many rows match, all three on by default so the board is complete until you deliberately narrow it. Narrow further by item status, by item type, or by whether internal items are showing. The filtering happens on the board you already have open, so nothing reloads. Click a row at a time of day and you are adding an item at that time, with the time already filled in.

Two details worth knowing because they are the ones that break on everyone else's version. The day type is derived in each room's own time zone, so a late-evening arrival lands on the correct board day instead of yesterday's. And a same-day booking counts as both an arrival and a departure, so it survives either filter rather than falling between them.

What it is not: it is not a task manager and it does not assign work to anybody. It shows the stay. Who does what is a different piece of product and a different conversation.

The floor: one item, every guest

The third view is the one that replaces the paper.

A manifest is the list of everyone who has booked one particular thing on one particular day. The industry already has a word for it, so we use the industry's word rather than inventing one.

Choose breakfast, choose tomorrow, and you have it: every guest who ordered it, their room, how many covers, what they asked for alongside, and any note they left. Orders and covers are both on it, because eighteen orders can be thirty-six covers and the kitchen needs the second number, not the first. The options are broken down at the top, so a service knows how many of each before it starts.

Tick each row off as it goes out. The ticks are shared, so two people working the same service see the same list, and each tick records who made it and when. New orders for that day appear as guests place them. Cancellations drop off. At the end of the day it closes and keeps the ticks it ended with.

And when the floor would rather have paper, print it as an A4 sheet with a tick box per row.

Three views, one dataset

Here is the part that is a data model property rather than a feature, which is why it is the part worth arguing about.

These are not three products with three databases. The day board is one day across every room, grouped by reservation. A manifest is the same day and the same query, rotated ninety degrees: one item, across every guest. The guest's screen is the same data a third time, filtered to one reservation and to the items marked external.

A manifest in particular is a definition rather than a snapshot. It stores only which item, which day, and how it is sorted. Its rows are resolved live every time somebody opens it, and they are never stored. That is why orders placed after you created it appear on it and cancellations drop off it without anything being regenerated. Nothing regenerates because nothing was ever generated.

Change the underlying item and all three views are already correct, because there is nothing to export, nothing to sync and nothing to update. The printed sheet at the back of house is produced from the same row the guest is reading on their phone.

The limitations, said out loud

Four of them, because you would find all four out in the second week anyway and it is better that you hear them now.

Live means a refresh every fifteen seconds. A manifest polls; it is not pushed. We are not going to call it real time. For a breakfast service, fifteen seconds is the right answer, and a push version is a later decision rather than a secret.

A printed sheet is a snapshot of the moment you printed it. Orders placed afterwards are not on it. The sheet says so on itself rather than letting somebody discover it at service.

The AI reads the itinerary. It does not write to it. A guest can ask what is planned tomorrow, what time the boat tour starts, what they saved, or whether the spa booking is confirmed, and the answer comes from the real list, including an explicit "nothing planned yet" when there is nothing, so it does not invent a day. It will not add, remove, reschedule or save anything on a guest's behalf. That is a decision we have not taken yet, not a feature we are being coy about.

Day boundaries are not identical across the three views. The guest's screen and the day board resolve a day in the room's own time zone, because that is the day the guest is living in. A manifest resolves it in your workspace time zone, because one manifest can span several rooms. If you run a single property you will never notice. If you run several across borders, now you know which is which.

There are also things deliberately not built yet: no tick-everything button, no CSV export, no manifest templates or recurrence, and no capacity limit on a service. Each was considered and left out of the first version.

The recommendations cannot be bought

One more thing, and it is an editorial decision rather than a technical one.

The local recommendations sitting beside the itinerary are the ones you picked. We take no commission on them, there is no paid placement in that list, and there is no mechanism by which a restaurant can buy its way onto your guest's screen. There is not going to be one.

That is a commercial argument, not a moral one. A list that can be bought carries no information in its ordering, so it is worth nothing to a guest. And when a guest comes back from somewhere disappointing, they do not blame the feed. They blame the property that sent them. You absorb the reputational cost of a recommendation you did not make and were not paid for.

You are the one who knows which of the two places on that square is the good one. That knowledge is the product, and it is yours.

Everyone owns the arrival

Both ends of the stay are crowded because both ends are easy to see. A booking is an event. An arrival is an event. A review request is a task with a date on it.

The middle is not an event. It is three days of small, repeated, answerable questions, and it is where your reputation is actually made.

One list. The guest reads it, the shift works it, the floor ticks it off. Nobody retypes anything.

What sits on top of that list, and what you do with the moments it opens up, is next.

See the itinerary, the day board and manifests, or read how the frame around them was built in The Guided Stay. HolidayHero runs on top of the property system you already have, across 3,500+ properties from single villas to OVO Network's 250+ chalets. Pricing is published, from €6.50 per unit per month with no setup fee.