A shift handover is the transfer of open work and live context from one team to the next. It is not a summary of the day. It is the mechanism by which obligations survive the departure of the person who took them on, and it is the single most reliable place to find the cause of a guest complaint that nobody can explain. Most of what goes wrong at a front desk was known, an hour earlier, by somebody who has now gone home, and a property management system either captures that or quietly loses it.
The pattern is always the same. A receptionist agrees something with a guest at half past two, the shift changes at three, and at seven o'clock a different receptionist is being told about an arrangement they have never heard of, by a guest who is now certain the hotel is disorganised. Nobody lied and nobody was careless. The information simply had no home outside one person's head, which is also why an unresolved guest conversation sitting in a guest messaging inbox is one of the few things that reliably does survive a shift change: it is attached to something.
This article covers what actually gets lost, why verbal handovers fail in ways you can predict, why the handover book stops working a few months after somebody buys it, what belongs in a handover and what is merely noise, how nights and departments differ, and what to expect from your systems.
The Handover Is a Seam, and Seams Are Where Things Tear
A hotel runs continuously and is staffed discontinuously. That mismatch produces two or three seams a day, and every seam is a point where continuity depends on a deliberate act rather than on presence.
Most operational thinking treats these moments as administrative. The rota says three o'clock, somebody arrives at three o'clock, and the assumption is that the desk simply continues. What actually happens is that a body of undocumented knowledge, built up over eight hours, walks out of the door while a second person starts from the state of the system plus whatever they were told in four minutes.
The gap between those two things is the handover problem, and it is worth being precise about its size. Over a shift a receptionist accumulates dozens of small facts: which guest sounded annoyed, which room has a shower that takes too long to warm up, which arrival called ahead about a late flight, which corporate booker wants to be told personally if the rate changes. Almost none of it is in the reservation record. Nearly all of it is the difference between a competent shift and a shift that feels chaotic to guests.
The instinct is to fix this with more talking. It is the wrong lever. The properties that hand over well are not the ones with the longest conversation at the seam; they are the ones where far less needed to be said, because it was already written where the next person would find it.
What Actually Gets Lost at Three O'Clock
The failures are not random. Across a lot of properties the same five categories account for nearly everything that goes wrong, and they are worth naming individually because each one needs a different fix.
The promise. Somebody said yes to something. A late checkout at no charge, breakfast included because of a problem the night before, a specific room because the guest asked nicely and it happened to be free. Promises made verbally are the single most damaging category, because the guest remembers them exactly and the hotel remembers them not at all. When the promise is denied on the next shift, the guest concludes not that a note was missed but that they were lied to.
The half-resolved complaint. A guest raised something, a partial fix was applied, and it was left in a state that requires a follow-up. The incoming shift meets a guest who is mid-conversation and has no idea a conversation is in progress. Asking the guest to explain again is what turns an ordinary problem into a review, which is the mechanism described in more detail in the piece on handling guest complaints.
The fault nobody logged. The lift is making a noise, room 214's air conditioning is loud, the card reader on the second floor is slow. Faults reported verbally at the desk are notorious for evaporating, because the receptionist intends to log them at a quieter moment and the quieter moment does not arrive.
The person to watch. A guest who is drinking heavily, a card that has been declined twice, a party of six in a double, somebody who has been asking oddly specific questions about the layout of the building. This category is uncomfortable to write down and important to hand over, and the discipline required is covered from the risk side in the risk management guide.
The money. A deposit taken in cash and not yet posted, a payment promised for later, a bill disputed and left open, a float that does not balance. Money at a seam is where small operational sloppiness turns into an accounting problem that somebody has to unpick a week later.
| What is lost | How it shows up later | Where it should have been recorded |
|---|---|---|
| A verbal promise | Guest insists on something the desk cannot see | On the reservation, before the guest walks away |
| A half-resolved complaint | Guest asked to repeat the story | On the reservation, with the next action named |
| An unlogged fault | Second guest reports the same thing | Against the room, as a maintenance item |
| A person to watch | Incident nobody saw coming | On the reservation, factually and without editorial |
| Loose money | Float short, or a balance nobody can explain | Posted before the shift ends, not after |
Look down that last column. Only one of the five belongs in a handover document at all. The rest belong on the record of the thing they concern, which is the whole argument of this article in one table.
Verbal Handovers Fail in Predictable Ways
Spoken handovers are not useless. They are fast, they allow questions, and they carry tone in a way that writing does not. But they fail in four specific ways, and knowing the failure modes tells you what to stop relying on them for.
Recency wins. A verbal handover is dominated by whatever happened in the last hour. The difficult guest at half past two gets three minutes; the promise made at nine in the morning has been mentally filed as dealt with and never comes up. Handovers systematically under-report the early part of the shift, which is exactly where the promises with the longest tail were made.
The busy seam. Shift changes are frequently scheduled at the worst possible moment. Three o'clock in a city hotel is the front edge of check-in. If the handover happens across a queue, it compresses to a sentence, and the sentence is usually a summary of mood rather than a list of obligations.
The confident summariser. Experienced staff hand over less, not more, because they have internalised what matters and trust their own judgement about what is worth saying. That judgement is usually right and occasionally expensive, and the person receiving the handover has no way to tell which kind of shift they have just been given.
No record afterwards. A verbal handover leaves nothing behind. If a question arises two days later about who knew what and when, the answer is a disagreement between two people who both believe they are right. That is not a minor inconvenience; it is what makes seam-related incidents so hard to learn from.
The conclusion is not to abolish the conversation. It is to demote it. The conversation should be the place where the incoming shift asks questions about a record that already exists, not the primary transmission channel.

The Handover Book, and Why It Stops Working by March
Almost every hotel has tried a handover book. A hardback diary by the printer, a shared document, a channel in a messaging app. It works beautifully for about six weeks and then quietly degrades, always along the same path.
First, it becomes a diary rather than a queue. People write what happened rather than what is outstanding. Entries accumulate that require nothing from anybody, and the ratio of signal to volume falls.
Second, nothing ever closes. A book records that a fault was reported. It has no mechanism to record that the fault was fixed, so a reader three days later cannot tell whether an item is live or historical without asking. Open and closed items sit next to each other looking identical.
Third, reading it becomes optional. Once the book contains more than a page a day, nobody reads back further than the current entry. An item written on Tuesday for a guest arriving Friday is functionally invisible by Wednesday afternoon.
Fourth, it is disconnected from the record. The note about room 214 is in the book; the person who next opens room 214 in the system sees nothing. Any information system where the storage location differs from the retrieval location will fail, and a handover book fails in exactly that way.
None of this means you should not have one. It means the book has one legitimate job: property-wide items with no natural home in a guest or room record. Scaffolding going up on Thursday. A contractor needing access to the plant room. The fire alarm test at eleven. Those genuinely have nowhere else to live, and there are few enough of them that the book stays readable.
Everything else has a home, and the discipline is to put it there instead.
Write It Where Somebody Will Go Looking for It
The single principle that fixes most handover problems is this: information should be stored on the object it concerns, not in a document about the shift.
A note about a guest goes on the guest. A note about a reservation goes on the reservation. A fault goes against the room. A task goes to a person with a state that can be closed. The test is simple and worth applying to every note your team writes: who is the next person to open this record, and will they see this when they do?
This matters because retrieval in a hotel is almost never chronological. Nobody arrives at the desk asking what happened yesterday afternoon. They arrive as a guest with a name, and the receptionist opens a reservation. If the relevant fact is in a document organised by time, it will not surface at the moment it is needed, no matter how carefully it was written.
Three practical consequences follow.
Write it immediately, not at the end. A note written when the promise is made takes fifteen seconds and is accurate. The same note written at the end of the shift takes longer, is less precise, and frequently does not happen at all because the shift ran late. This is the highest-leverage habit change available, and it is the one most resisted, because it feels like an interruption in the moment.
Write it as an obligation, not an observation. The useful form is what was agreed, what remains outstanding, and who does it next. A note reading “guest not happy about the room” transfers anxiety without transferring work. A note reading “moved to 305, offered breakfast for two on 7th, needs confirming with restaurant” transfers the actual job.
Attribute and timestamp everything. Not to apportion blame, but because a note without an author cannot be questioned. The follow-up question is always the same, which is what exactly did you promise, and it can only be asked if the record says who to ask.
What Belongs in a Handover, and What Is Just Noise
Handovers fail from too much content at least as often as from too little. If the incoming shift is given twenty items, they will act on four. Being ruthless about what qualifies is what makes the remainder survive.
The test is whether an item requires action or awareness from the next shift. If it requires neither, it is not a handover item, however interesting it was.
| Belongs in the handover | Does not |
|---|---|
| Promises made that are not yet in the system | Occupancy and revenue figures, which are in reports |
| Complaints in progress and who owns them | Complaints already closed to the guest's satisfaction |
| Rooms out of order or with reported faults | Routine cleaning status, which is on the board |
| Arrivals needing special handling, VIPs, groups | The full arrivals list, which the next shift will read anyway |
| Credit issues, disputed bills, declined cards | Ordinary payments taken without incident |
| Anything owed to a guest | General mood of the day |
| Incidents that may generate a follow-up call | Gossip about guests or colleagues |
| Live external factors: outages, weather, roadworks | Anything already visible on the dashboard |
The right-hand column deserves a moment. Much of what fills handovers is information the incoming shift will acquire in their first ten minutes by looking at their own screen. Repeating it feels thorough and actively harms the handover, because it buries the four things that were not going to be discovered any other way.
A useful discipline for a supervisor is to listen to a handover occasionally and count how many items were things the incoming shift could not have found out for themselves. In a healthy handover that number is most of them. In an unhealthy one it is two out of fifteen.
The Overlap Window Is Worth Paying For
A handover conducted with a coat already on is not a handover. If shifts are scheduled to end and begin at the same minute, the transfer happens either in the outgoing person's unpaid time or not at all, and staff will optimise for leaving.
Ten to fifteen minutes of paid overlap is enough for most independent properties, and it is the cheapest reliability improvement in the building. The cost is a few hours of wages a week, and the return is the class of failure that requires an apology and often a discount. If you have the rota flexibility, the wider trade-offs in shift design are worth reading alongside this, and they are covered in the staff scheduling guide.
Two structural points make the overlap work.
Do not schedule the seam at the peak. If check-in floods from three o'clock, move the shift change to half past two. The overlap should sit in a trough, not the crest. This is often resisted because the rota has always said three, and it is usually free to change.
Give it a fixed shape. The same order every day, so nothing is skipped when it is busy. Open items first, then arrivals of note, then rooms and faults, then money, then anything property-wide. A fixed sequence means an interrupted handover can resume where it stopped rather than starting again or, more commonly, stopping there.
The overlap is also where new staff learn the job, which is an argument for protecting it that has nothing to do with today's guests. A receptionist in their first month does not yet know which details matter, and the fastest way to teach that judgement is to have them stand through a handover given by somebody who does. Properties with high turnover tend to have poor handovers for exactly this reason: the habit is transmitted person to person rather than written down, so it thins out with every departure. Where turnover is unavoidable, writing the running order on a card taped inside the desk does more than a training session, and the broader case for structured onboarding at the desk is made in the piece on front desk operations.
There is one more habit worth building, and it costs nothing. The incoming shift should be reading the record before the conversation, not during it. Someone who has already looked at the arrivals, the open tasks and the notes asks sharper questions and needs less telling, which is what turns fifteen minutes into enough time.
The Night Shift Hands Over Differently
Nights are a special case in both directions, and treating them like any other seam causes a specific set of problems.
The evening-to-night handover passes into a shift that is often a single person with no colleague to consult, working the hours when the fewest decisions can be escalated. That person needs more context than a day receptionist, not less: who is still out, who is expected very late, which guest was upset earlier, what the plan is if the party in 118 does not quieten down. A thin handover into a solo night shift is how small situations become incidents.
The night-to-morning handover is different again, because the night shift holds two distinct things. There is the operational picture, which is the same category as any other handover. And there is the outcome of the audit, which is a financial matter: what balanced, what did not, what was left unposted for the morning to resolve. Confusing the two is common, and the practical result is that audit exceptions get mentioned verbally at seven in the morning and then forgotten by nine. The mechanics of what the audit itself should be closing are set out in the night audit playbook.
It is worth being explicit that a handover and an audit are not the same activity. The audit closes the business day and reconciles the numbers. The handover moves open work between people. A property can run a flawless audit and still hand over badly, and it usually will if the same fifteen minutes is expected to do both jobs.
One further point specific to nights. The night shift is the only shift that routinely observes the building rather than the guests: the door that was propped open, the corridor light that has failed, the smell in the basement corridor. That observation is genuinely valuable and it almost never gets recorded, because at four in the morning there is no obvious place to put it and by seven it feels too minor to mention. Giving nights a standing place to log building observations captures a stream of information no other shift can produce, and it pairs directly with the schedule described in the preventive maintenance guide.

Handing Over Sideways, Not Just Forwards
The word handover implies time: this shift to the next. In practice a large share of failures are lateral. The information does not need to reach tomorrow, it needs to reach housekeeping, or maintenance, or the restaurant, and it never leaves the desk.
The classic example is the guest who mentions at check-in that they are leaving at five in the morning and would like a bag of pastries. That is a kitchen instruction, a night shift instruction and a housekeeping instruction all at once, and if it lives only in the receptionist's memory it will fail in at least one of those places.
Three lateral routes account for most of the trouble.
Desk to housekeeping. Early arrivals, requested room changes, extra beds, do-not-disturb requests, guests who have asked not to be serviced. Housekeeping plans their sheets in the morning, so anything learned at the desk after that point needs an explicit route rather than an assumption. The room-status side of that conversation is the subject of the housekeeping checklist.
Desk to maintenance. The fault reported at the desk is the archetype. The important design decision is that the report should be raised against the room at the moment it is heard, by the person who heard it, and not collected on a list for somebody to transcribe later. Every transcription step is a place items die.
Desk to food and beverage. Allergies, celebrations, complimentary items promised at the desk, guests who have been told the kitchen closes later than it does. Promises made at reception that other departments have to honour are a recurring source of embarrassment, and they get worse the busier the desk is.
The common thread is that lateral information needs a destination, not a broadcast. A message in a group chat that concerns one department is read by nobody in particular. An item attached to the room, assigned to a person, with a state that can be closed, is read by exactly the right person at the moment they are doing that work.
There is a third direction that gets missed entirely, which is forwards past tomorrow. A guest calls on Tuesday to arrange something for their arrival on Friday. That is not a handover item for the next shift, because the next shift can do nothing with it, and it is exactly the kind of thing a book swallows: written on Tuesday's page, invisible by Thursday.
Large systems solve this with a dated action item routed to a department, which surfaces on the day it is due. If you do not have that mechanism, the workable substitute is to put it on the record that will definitely be opened on the relevant day, which for an arrival is the reservation itself, and for a room is the room. The rule of thumb is to ask what somebody will have open in front of them on the day this matters, and write it there. Anything future-dated that goes into a chronological log is a bet that a colleague will scroll backwards, and that bet loses.
The Money Seam
Whatever else is loose at a shift change, money should not be. It is the one category where a partial handover has consequences that survive weeks.
Three rules cover most of it.
Post before you leave. Anything taken during the shift should be on the folio before the shift ends. A cash deposit sitting in a drawer with a sticky note is a reconciliation problem the moment the person who took it goes off for two days. This is also the point where the boundary matters between a guest's own bill and the accounts that carry charges for people who are not staying, which is where the leaks described in the piece on house accounts begin.
Count the float with both people present. If there is a cash float, it is counted at the change of shift by the outgoing and incoming person together, and both agree the figure. A float counted alone means any discrepancy is discovered later, by which point it cannot be attributed to a shift and therefore cannot be investigated. The point is not suspicion. It is that an unattributed shortfall is unfixable, whereas an attributed one is usually explained within a day.
Hand over the exceptions explicitly. Disputed charges, cards declined, guests who promised to settle later, bills left open on departure. These need naming individually, because each is an obligation with a deadline. A guest who said they would come back to settle at six is a handover item until the money is in.
The reason to be strict here is not that hotels lose large sums at shift changes; mostly they do not. It is that money problems are the ones that surface a month later in a reconciliation, when nobody can remember the day, and resolving them consumes management time out of all proportion to the amount involved.
When Something Goes Wrong at the Seam
Occasionally a handover failure produces a real incident: a guest who was not warned about something, a room let to somebody who should not have had it, a medical or security situation where what was known and when becomes a serious question.
Two things matter afterwards.
The first is reconstruction. You need to be able to establish what was recorded, by whom and at what time, without relying on memory. A system that timestamps and attributes notes and changes gives you a timeline. A handover book gives you handwriting and an argument. If your property is in a jurisdiction where you may need to demonstrate that a report was made and acted on, this stops being an operational nicety.
The second is the response, and this is where most properties get it wrong. The instinct after a seam failure is to require more handover: a longer form, an extra checklist, a mandatory sign-off. That reliably makes the next handover worse, because it adds volume to a channel that was already over capacity. The better response is almost always to move the specific item that failed out of the handover entirely and give it a home in the record where it cannot be dropped.
If a promised late checkout was missed, the fix is not a line item on a handover form. The fix is that late checkouts get recorded on the reservation at the moment they are agreed. One is a rule people follow for three weeks, and the other is a change to where information lives.
What Your PMS Should Be Doing Here
Very little of this is solved by a feature called handover. It is solved by the ordinary parts of the system being good enough that the handover has less to carry. A few specific capabilities do most of the work, and they are worth checking in a demo.
Notes attached to the right object, timestamped and attributed. On the reservation, on the guest profile and on the room. Notes that cannot be traced to an author are worth much less than they appear, because the follow-up question can never be asked.
Tasks with an owner and a state. The distinction between a note and a task is that a task can be finished. Anything requiring action needs a state that changes, otherwise the next shift cannot tell live items from history, which is the exact failure of the paper book.
Faults raised against the room, not collected on a list. The receptionist who hears about the noisy air conditioning should be able to record it against that room immediately, with the option to take the room out of order if it is serious enough to stop selling it.
A visible history per room and per reservation. When something is disputed, the useful question is what has happened to this room, or this booking, in order. That should be a view, not an archaeology exercise.
Arrivals and departures that flag the exceptions. The incoming shift wants the four arrivals that need something, not a list of forty that they must read to find them.
Prostay is deliberate about this, and it is worth being straightforward about what it does and does not have. There is no handover module and no shift-close ceremony in the product. The position it takes instead is that a handover is a symptom: the more the system holds properly, the less has to be transferred by hand.
In practice that means diary notes on both the reservation and the guest profile, each showing when it was added and who last changed it, and archived rather than deleted so an old note can still be recovered when a guest refers back to something from a previous stay. It means an operational task drawer where a task carries a title, a description, a priority, an assigned person, an optional room or guest and a link to the reservation, moving through to do, in progress and done, so an incoming receptionist can filter to what is assigned to them rather than reading everything. Comments on the task keep the conversation with the work instead of in a chat thread.
On the housekeeping side, the board carries the room status, the front office status, do-not-disturb and make-up-room flags and occupancy discrepancies where the attendant found something different to what the system expected, with per-room notes and a history drawer that shows what has happened to that room over time. Guest service requests are raised against a room with a service level countdown and a status, assignable to an attendant, and maintenance work orders carry a priority, a due date and a team, with the option to place the room out of order at the moment the order is created. Scheduled room moves for the day sit on the dashboard as their own list with pending and completed counts, which is precisely the kind of item that used to live in somebody's memory until three o'clock.
For the questions that come up afterwards, each reservation has an activity log showing the date, time, user and what changed, and there is a property-wide user activity log that can be filtered by date, user and message. Housekeeping's overnight rollover moves occupied rooms back to dirty as part of the audit, with a manual run available and the last run displayed, so nobody is guessing whether the day changed.
What it does not do, and this is worth saying plainly rather than leaving a demo to discover: there is no Opera-style trace that routes a dated action item to a department queue, no cashier shift with a drawer count and a close, and no formal handover log. If those specific mechanisms are what you are shopping for, this is not the product that has them. What is here is the material a handover is made of, attached to the records it belongs to.
A Handover That Actually Holds
If you want to improve this next week rather than next quarter, the following sequence is roughly in order of return.
Move the shift change out of the busiest fifteen minutes of the day. Free, and it makes everything else possible.
Pay for ten minutes of overlap and require both people to be present for it. Not with a coat on.
Introduce one rule and enforce only that one: anything promised to a guest is recorded on the reservation before the guest walks away. If you change nothing else, change this. It removes the most damaging category of failure outright.
Give the handover a fixed running order and keep it to items requiring action. Open items, arrivals of note, rooms and faults, money, property-wide. Same order every day.
Move faults out of the conversation and onto the room, raised by whoever hears about them, at the moment they hear about it.
Count the float together, or stop having a float. Both are defensible; one person counting alone is not.
Demote the book to property-wide items only, and review it monthly to check it has not silently become a diary again.
Then, once a month, ask the question that tells you whether any of this is working: of the problems that reached a guest this month, how many were known to somebody on an earlier shift? Not to assign fault, but because that number is the honest measure of your seams, and it is the only handover metric worth tracking. When it falls, it is because information stopped depending on who happened to be standing at the desk, which is the whole of the job.




