Hotel Shift Handover: Stop Losing Guest Requests at 3pm and 11pm

Requests get lost between shifts because ownership is implicit: the day team knows, the evening team assumes, and nobody tells the guest. The fix is one owner at every minute, an explicit transfer when the shift changes, and a shared list of open requests that both teams read at every change. That is the whole system, and it belongs in our guide to the best hotel AI concierge platforms only because the list is a lot easier to keep when the requests arrive in writing.

The example everyone recognizes is the crib. A family asks for one at 2pm. The day attendant hears it, intends to bring it after the next room, and clocks out at 3pm. The evening team never heard. At 9pm, with a tired toddler and no bed for them, the parent asks again, and this time the tone is different. I have been that parent, standing in a hallway doing the math on how long a child can sleep on two chairs pushed together. Nobody forgot the crib. It was handed over to nobody.

Why do guest requests disappear at shift change?

Because the logbook records events, not obligations, and the verbal handover is lossy. "Corner room wanted a crib" in a logbook is a fact about 2pm. It is not an instruction to anyone at 3:05pm. And the two minute conversation at the time clock carries whatever was top of mind, which is the AC complaint, not the crib.

Thin and new teams make it worse. In the AHLA and Hireology 2025 survey of 282 hoteliers, 65% reported staffing shortages, housekeeping was the most critical opening at 38% of hotels and maintenance at 13%, and 71% had unfilled openings, averaging six to seven per property ^[1]. A handover between a veteran going home and a second-week hire arriving is not a conversation between equals. The veteran knows what "the usual" means. The new hire nods.

The tooling compounds it. Access Hospitality's 2026 research found hotels use an average of five systems, with staff spending 78 minutes a day switching between them ^[2]. A request that lives in a radio call, a logbook line, a text to the supervisor and a column on a spreadsheet has four partial records and no owner. The sprawl is the failure, not a symptom of it.

What does a dropped request cost?

It becomes a problem in the guest's memory, and problems are expensive. In J.D. Power's 2025 study of 39,219 guests, about 12% of stays involved a problem such as a housekeeping issue, noise or a check-in dispute, and when one occurred satisfaction fell 217 points on a 1,000 point scale, from 677 to 460 ^[3]. A crib that arrives at 9:30pm after being asked for twice is in that 12%.

It also costs the next booking. In Oracle Hospitality and Skift's 2022 survey of 5,266 travelers, 34% named staff shortages and slow service as their top reason not to rebook a hotel, and 23% called lack of daily room cleaning a problem ^[4]. Across industries, Zendesk's 2025 research found 63% of consumers willing to switch to a competitor after one bad experience ^[5]; that is not hotel-specific, but I doubt hotel guests are more forgiving than the average.

The dropped request also wrecks your numbers. If you are setting response-time targets, a request that crossed a shift and died is a seven hour resolve time, and it will sit at the top of your 90th percentile until the handover is fixed.

The reviews that mention slow response times are often describing exactly this: not a slow team, but a request that spent most of its life owned by nobody.

What are the four rules of a handover that works?

One: every request has exactly one owner at every minute, including the minute of shift change. Not a department. A person. Two: ownership moves by explicit transfer, named and acknowledged, never by assumption. "Housekeeping knows" is not a transfer. "Dana, you have 214's crib, promised by 3:30" followed by "got it" is. Three: the guest is updated whenever the expected time changes, by a named person, before the old time passes. Four: anything that will take more than one shift gets a daily note and a daily guest touchpoint.

These rules work best when requests arrive typed and routed, which is the point of routing requests to the right team from the start: a request that already has a type, a priority and an owner is a request the handover can see.

The list has to survive the shift change intact, which is harder than it sounds when the list is a logbook. ResortConcierge AI keeps requests that keep their owner and status across shifts in one queue, so the 11pm team opens the same list the 3pm team left, with the age of each item showing, rather than a page in a logbook.

What should the handover include?

The open requests list, sorted by age and priority. Every promise made to a guest, with its time. Anything waiting on a part or a vendor. Rooms with a known issue the incoming team should expect to hear about. That is it. The logbook stays, but it holds events and context; the request list holds things that still have to happen, and the two should never be the same document.

The board above is illustrative, and its seven columns are the template: room, request, promised time, priority, owner, status, next guest update. The last column is the one most properties leave out and the one that separates a handover that protects the guest from one that only protects the team.

How do you run the five-minute stand-up?

Standing, at the list, at 3pm and 11pm (or whatever your change times are; those two are the dangerous ones at most resorts because they are when the building is busiest and quietest, respectively). The script has three moves per item.

1. Read it: room, request, promised time, where it stands.
2. Name the new owner, out loud, and hear them acknowledge.
3. Confirm the next guest update: who sends it and when.

Then the exceptions: parts on order, vendors due, rooms to watch. Five minutes if the list was kept live during the shift. Twenty minutes if the handover is reconstructing the shift from memory, which is the signal that the list is being written at handover rather than as things happen.

When the incoming shift is one person, which is the 11pm reality at many independents, that person owns everything open and the list is their work order. The outgoing team's job is to make sure nothing on it needs knowledge that just left the building. This is also where AI for housekeeping requests quietly earns its keep: a request that came in through chat has the guest's words attached, so the one-person night team can read what was asked instead of what someone remembered.

How do you hand over maintenance issues that take days?

Separate the repair from the guest. The repair belongs to engineering and gets a daily note: what was tried, what part is on order, which vendor is due, what the next step is. The day engineer writes it before leaving, so the knowledge of why the compressor keeps tripping does not go home at 3pm.

The guest belongs to a named person who is not necessarily the engineer. That person sends one message a day with an honest new time, and offers a room move the moment the fix slips past a second night. Do not make the guest choose between a room move and a repair estimate they cannot evaluate; offer the move and let them decline it.

Multi-day items also interact with checkout. A late checkout request on a room with an open maintenance issue needs housekeeping and engineering to agree, and the housekeeping handshake behind late checkout is its own small system that the open requests list makes visible. When a request is reassigned, ResortConcierge keeps the guest's conversation attached through guest management, so the new owner reads what was promised without asking the guest to say it a third time.

What should the guest hear when a fix crosses a shift?

A name, a new time, and an apology that does not over-promise. Illustrative, for the crib:

Bad version, 9:05pm, after the guest asked again: "So sorry about that, we'll get one up to you right away." No name, no time, and "right away" is a promise the night team may not be able to keep.

Good version, 3:20pm, before the old time passed: "Hi, this is Dana from housekeeping. The crib for 214 is running later than I said, and it will be in your room by 4pm. Sorry for the wait." Named, timed, sent before the guest had to ask. If 4pm then slips, another message, same shape, from whoever owns it now.

The step most handovers skip is the message itself, because it feels like admitting a delay. It is admitting a delay. The guest already knows about the delay; what they do not know is whether anyone else does. ResortConcierge sends that update through notifications on the channel the guest used, which is a small thing until you are the parent in the hallway.

What is the simplest version for a 40 room property?

A shared sheet with the seven columns above, open on every phone, and the two stand-ups. That is the entire system, and it will fix most of the crib problem by itself, because the act of writing "owner" in a column forces the question nobody was asking.

Graduate to a tool when the sheet has more than about 20 open rows a day, or when the "next guest update" column keeps going blank because nobody wants to type a message by hand. Those are the two signs the sheet is holding you back rather than holding the line. One capability note: PMS connectors for room status are planned, not shipped, on ResortConcierge, and there is no integration with housekeeping or engineering software, so the queue is the record for requests, not a mirror of another system.

Start with the 3pm stand-up tomorrow. Print the seven columns, fill them from today's logbook, and read the list out loud with the evening team. You will find at least one crib on it. That is the point.