Stop running your hotel out of WhatsApp.

Lede

Walk into almost any independent hotel and ask where the work happens. You will be shown a front desk, a housekeeping office, a maintenance workshop. Then ask where the decisions happen, and someone will take out a phone.

The tool nobody chose

No general manager sat down and decided to run their property out of a group chat. It arrived the way weather arrives. Somebody needed to tell the night porter about a late arrival, the night porter was not at a desk, and the message went to a phone. It worked. So the next one did too, and then there was a group for housekeeping, and a group for the duty managers, and a group with the owner in it that nobody posts in unless something has gone properly wrong.

By the time anyone notices, the group chat is the operating system of the building. It holds the arrivals, the complaints, the leak on the third floor, the photograph of the broken kettle, the argument about the staff van, and — somewhere in the middle of that — the only surviving record of a promise made to a guest at eleven at night.

Why it wins

It is worth being honest about why chat beat every purpose-built system the industry has sold to hotels. Chat requires no training. It runs on a device every member of staff already owns and already looks at. It reaches the person who has no desk, no email address and no shift overlapping with yours. It costs nothing. It is faster than any form.

Those are not small advantages. They are the reason a housekeeping supervisor will photograph a stained mattress and send it to a group before the door has closed behind her, rather than walk to a terminal and fill in a maintenance ticket. If your replacement for the group chat is slower than the group chat, the group chat wins, and it will keep winning, quietly, in parallel, while you pay for the thing that was supposed to replace it.

So the argument here is not that chat is bad. It is that chat is the wrong system of record, and that most hotels have accidentally made it one.

What a message cannot be

A message has a sender, a timestamp and some text. That is the whole of it. What it does not have is the thing operations actually runs on: state.

A task has an owner. A message has a reader, which is not the same, because everyone in the group has read it and therefore nobody has it. A task has a due time. A message has a moment of arrival, after which it starts sinking. A task can be reassigned when the person who had it goes home. A message cannot be handed to anyone; it can only be quoted at them.

This is why the group chat produces a very specific kind of failure, and it is almost never a dramatic one. Nothing explodes. A thing simply does not happen, and afterwards nobody can say whose it was. The supervisor is certain she raised it. She did. The message is right there. The engineer is certain he never saw it, and he is probably telling the truth, because it arrived while he was under a sink and by the time he came out it had been pushed off the screen by a debate about parking.

The second thing a message cannot be is countable. You cannot ask a chat how many rooms went out of order this month, which department is holding the oldest open item, or whether the same complaint has now arrived from several different guests about the same corner of the building. The information is all in there. It is just not in a shape that can answer a question.

The handover in the scroll

Watch what happens at shift change in a hotel run out of chat.

Karim finishes at three. Lena starts at three. What Karim knows is more than fits in the walk from the back office to the desk: which rooms are out, which arrival is a rebooked complaint from last month, which guest was promised a technician before dinner and by whom. What actually gets transferred depends on whether the two of them overlap, whether the lobby is busy, and whether Karim remembers.

The rest is supposed to be in the scroll. In practice, nobody scrolls. Reading back through a working day of a busy group to reconstruct the state of a building is a research task, and Lena has a queue in front of her. So she starts the shift with the state she was told plus whatever she can see, and she rediscovers the rest during the evening, one surprise at a time. At twenty past seven a guest asks her where the technician is, and she has to reconstruct a conversation she was never part of, in front of the person it was promised to.

That rediscovery is the real cost of running a hotel out of chat, and it does not appear on any invoice. It is paid in the first hour of every shift, forever.

The procedure that lives in someone's head

There is a third failure, slower than the others. A new housekeeper asks how to handle a guest's medication left in a room. Someone in the group answers from memory. The answer is good, because the person answering is experienced.

Next month a different person asks the same question and gets a slightly different answer from someone else, also from memory, also experienced. Neither answer is written down anywhere, because it was already answered — look, it is in the chat. Except that the chat is not searchable in any way that helps, and the two answers now coexist, and the property has quietly acquired two procedures for one situation.

When the experienced person leaves, both answers leave with them, and the group chat retains the words without retaining the reason. That is not a knowledge base. It is a transcript of a knowledge base that used to exist inside somebody.

What replaces it

Not another chat app. If the pitch is “the same thing, but ours”, there is no reason for anyone to move, and they won't.

What replaces it is a small change in what happens to a message after it is sent. The message stays fast. What changes is that it stops being the end of the process and becomes the start of one.

• A guest message lands in an inbox where it is triaged, attached to that guest's history, and answered by a person working from a drafted reply rather than from memory.
• A staff message that names a problem becomes a task with an owner, a due time and a checklist, and it is still a task tomorrow whether or not anyone scrolled.
• The procedure someone would have typed from memory is retrieved from the department's knowledge base with a citation, so the next person gets the same answer and can see where it came from.
• The shift ends with a briefing assembled from what actually changed, rather than from what the outgoing manager happens to recall.

None of that requires anyone to stop using chat. Staff should talk to each other constantly; it is a hotel. It requires only that the chat stop being the place where the building's state is stored, because the chat was never built to store it and has been doing the job as a favour.

The test is simple. If the person who runs your evening shift called in sick tonight, could their replacement start work without phoning them?

In a hotel run out of a group chat, the answer is no, and everyone knows it, which is why the phone call always happens. That call is the system working as designed. It is just a poor design.