Stop running housekeeping from a WhatsApp group

In many hotels a guest request travels like this: the guest calls reception, reception writes it in a staff WhatsApp group.

Someone maybe answers, and nobody knows if it was done.

It feels fast, because typing into a group is fast. But nothing in that chain has an owner, a clock or a status. The manager's only way to find out whether the towels arrived is to scroll, and scrolling stops working the day the group has thirty people in it.

This is not an argument against WhatsApp. It is an argument against running work in a conversation. A group chat is a stream of messages; a request is a piece of work with a beginning, an owner and an end. Different shapes.

Worth knowing, because it comes up: the Cloud API does now support groups. Meta's documentation states that "The Groups API is now open to all businesses with an Official Business Account (OBA)", with a maximum of 8 participants, one Cloud API business per group, and no availability for WhatsApp Business app numbers (Groups, Meta for Developers, read 28 September 2026). So the platform is not the obstacle, and we have written separately on what the API allows for group chats with guests. But a group capped at eight is not where you dispatch work for a thirty-person operation, and an uncapped one would still be a conversation rather than a system.

A better flow

1. The guest writes "the plug in my room isn't working" or "can we get extra towels?"
2. The assistant recognises the guest, room included, from the property system, and answers anything simple, like the WiFi password or pool hours, on its own.
3. Anything that needs a person becomes a ticket, labelled by team: housekeeping, maintenance, reception.
4. The on-duty staff member gets a WhatsApp alert on their own phone, during their team's hours.
5. They mark it done, and reception sees it closed.
6. If nobody handles it within a set time, reception gets a visible alert.

Bonus: when a guest checks out in the property system, housekeeping can be alerted that the room is ready to clean. Nobody walks the corridor to find out.

Step 2 is the one that does the quiet work. A large share of what arrives at reception is not a request at all. It is a question with a fixed answer. Every one of those that never becomes a ticket is a person not interrupted.

What changes

• Accountability: every request has an owner and a status. "I thought someone else had picked it up" stops being a possible answer.
• Speed: requests go straight to the right person, not to a group of 30. Notifications that always concern you get read. Notifications that concern you one time in twenty get ignored, and no amount of shouting in the group fixes that.
• Visibility: managers see what was asked, how long it took, and what keeps coming back. The third one is the valuable one. A country hotel that counts its tickets for a month usually finds the same handful of rooms, the same two fittings and the same one question generating a third of the traffic. Those are fixable at source.

Two timing details on WhatsApp

Replies are easy while the conversation is live: "When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts", and "When the window closes, you can only send pre-approved template messages" (Send messages, Meta for Developers, read 28 September 2026).

So a same-shift "done, the towels are on their way" is an ordinary message. But a job reported at 22:00 and fixed at midday the next day is outside the window by the time you close it. You do want the guest to hear that it was fixed, because that is the difference between a complaint and a service story. That needs an approved template. Templates "must have a status of `APPROVED` before they can be sent" (Message templates, Meta for Developers, read 28 September 2026), so write the two or three you will need before you go live.

The same applies to staff alerts sent over WhatsApp: they are business-initiated messages, and Meta requires opt-in before a business messages someone (Get opt-in for WhatsApp, Meta for Developers, read 28 September 2026). Ask your team, record the answer, and give people a way to come off the list when they leave the role.

What to prepare

1. Teams and their duty phones. Not names. Roles. People change shift; the role does not.
2. Hours for each team, and who covers the rest. Maintenance at 03:00 goes to the night manager, not into a queue nobody is watching.
3. The time limit before a request escalates. Pick a number per team and write it down. Ten minutes for reception and two hours for maintenance is a perfectly good starting pair; the point is that it is decided, not felt.
4. A second screen at reception, next to the property system. If the open tickets are not visible from where the front desk stands, they will not be watched.

Two more:

• A rule for what the assistant never answers alone. Anything involving money, safety or a complaint goes to a person immediately.
• A weekly five minutes on the numbers. Open tickets, average time to close, repeat causes. Five minutes, every week, beats a report nobody reads.

What to expect in week one

Volume goes up before it goes down. Guests who would have said nothing will now ask, because asking got easy. That is a good sign, not a problem, and it settles. Staff will also keep using the old group for a fortnight out of habit. Close it, or it stays.

Takeaway

A staff group chat is a conversation, not a system. Guests notice the difference.

The same test applies to the rest of the stack, starting with the spa system you choose.