A problem that does not make it into the handover does not stop existing. It just becomes the problem of someone who does not yet know it exists.
I say this as a principle, not as a story. In hotel work I have seen unclosed issues, technical problems, requests that needed follow-up, or operational differences that had to pass to the next shift. But I do not have a single case documented clearly enough to say: this piece of information was missing from the handover, and that is exactly what caused this consequence. And I do not want to stitch several cases together into a story I am not sure of.
The principle is enough for me. You can have two shifts that are very good on their own. The first shift may have done everything right. The second may have people who are just as capable. But between them there is a point where the organisation can lose its memory.
That point is called the handover.
From a loose note to the current state
The change I can name with certainty in the way I work is the move towards a more structured handover.
Instead of leaving the information as a loose note, or as a list of things with no clear link between them, I have organised it by categories of work:
What is the state of the hotel?
What happened during the shift?
What has been resolved?
What is still open?
Who has to follow it up?
This way of working has also found its way into the SOPs and the structures I later built for the handover.
For me the main improvement is exactly this: not leaving the next shift with the burden of rebuilding the story on its own. It should receive the current state.
What a night handover contains
Without going into concrete content, the handover I use or have structured around night work includes categories such as:
- the overall operational state of the hotel;
- the main movements of the day and those that affect the next shift;
- reservations or statuses that need attention;
- unclosed administrative or financial matters;
- guest problems or requests that need to be continued;
- technical issues;
- information for housekeeping when there is something relevant for the next shift;
- open tasks and follow-ups;
- notes the next shift needs so it does not start work without context.
In my reports, I do not want problems that need follow-up to appear simply as a story of what happened. It has to be clear that something is still open.
Because "reported" and "resolved" are not the same thing.
A document that is used, not just proof
The information has to be clear enough that the other person does not need to interpret what I meant.
A note like "problem with the room" is not a good handover. It has to be clear what kind of problem it is, what state it is in, and whether there is still something to follow up, without adding unnecessary information.
I do not have an absolute personal rule that I always do every handover verbally as well, so I will not present that as a fact. But one thing is clear from the way I have built the reporting: the document should not just be proof that the handover happened. It has to be usable by the person who receives it.
Two moments that mirror each other
At the end of the shift my focus moves from "what do I need to do?" to "what does the person after me need to know?"
I check what has been left open, what was resolved during the night, and which issues must not get lost when the shift changes. I care especially that an unclosed problem does not look like a finished one just because my shift is ending.
When I take over the shift from someone else, I do the opposite. I try to build, as quickly as possible, a picture of the current state: what I am inheriting, what is normal, what has deviated and which points need attention.
For me these two moments almost mirror each other. When I hand over the shift, I have to reduce the uncertainty for the other person. When I take over the shift, I have to uncover the uncertainty that has been left behind.
What a tool does and what it does not
The handover tool I built follows almost the same logic.
The figures and the operational state give a snapshot of the moment. Open points separate what has happened from what still needs action. The owner matters, because a task without an owner is very close to a task nobody will do. The time or deadline separates information you simply need to know from something you need to act on. The notes keep the context that does not fit into a number or a status. Security also exists as a category, but I will not go into its content or procedure here.
One thing no tool fully replaces is the human context. A system can record that a point is open, who has to follow it up and by when. But it cannot by itself guarantee that the person taking over the shift has understood why it matters.
That is why, for me, a handover is not just a transfer of information. It is a transfer of responsibility. And this is exactly where many organisations go wrong.
If the information does not cross the line between two shifts, the good work of the first shift no longer belongs to the organisation. It stays only in the head of the person who has just gone home.