Hotel guest request management: log, assign and close each one

Guest request management is one shared log in which every request, whether it arrives by phone, at the desk, by message, through the guest app or in a corridor, gets a named owner, a promised time the hotel sets, a status and a check back with the guest before it is closed.

A guest asks for an extra pillow at 21:40 on the way to dinner. The receptionist nods, the phone rings, the shift ends. At 23:00 the guest is still waiting, and nobody in the building knows a promise was made. Every hotel has a version of this story, and the fix is not more effort at the desk. It is a single log, a named owner for each row, a promised time the hotel chooses, and a check back with the guest before the row is closed. After reading this you will be able to set up that log, set target times for each request type, run a real shift handover and hold a weekly review that removes the causes of the requests themselves.

Where do guest requests get lost?#

Requests rarely get lost at the moment they are made; they get lost at the handover, when the person who heard the request stops being the person responsible for it. The moment of asking is usually fine: the guest has the full attention of a staff member. What follows is where hotels lose the thread.

Requests arrive through five channels: the phone to the desk, the guest standing at the desk, written messages such as business messaging, booking-site messages and email, the hotel's own guest app, and the corridor, poolside or lift where staff are asked directly. The corridor request is the most fragile, because it never reaches a screen or a notebook and the staff member is usually on the way to another task. If your log only captures what arrives at the desk, you are logging a fraction of your promises.

A request phrased as a comment is still a request. "The shower drains slowly" or "the corridor light flickers" must be converted into a logged entry, and that is a training habit rather than a form. The related trap is "someone is dealing with it": two people each assume the other owns it, and neither confirms to the guest. Shift change is the biggest single leak of all, because the outgoing shift knows the promise and the incoming shift knows the room number at best. Language loses detail too: a request taken in a language the next shift cannot read arrives as a summary, so record the guest's own words plus a one-line summary in the hotel's working language. A fuller approach to this is part of designing the guest journey stage by stage.

What should a guest request log contain?#

One log, one row per request, with enough fields that a person who was not there can pick it up and finish it without asking anyone. The test of a good log is not its length but its independence: any trained person, on any shift, should be able to act on any row.

A few rules make these fields work. Use a clear stand-in such as "day guest, pool" when there is no room. The promised time is what the guest was actually told, not what the hotel hopes. The status comes from a fixed short list: open, in progress, waiting on a part or supplier, done, closed, cannot be met; free-text status is where logs die. Without a closure note the log cannot be reviewed, only trusted. And access matters as much as content: front office, housekeeping and guest relations must read the same list, because a request that lives in one department's notebook is not logged, it is remembered. Where requests arrive in several languages, the summary field is where a language plan for your guest mix pays off.

How do you set a target time for each request type?#

The hotel sets its own target times, type by type, writes them down, and treats a missed target as an escalation trigger rather than a failure to hide. Targets are not a marketing claim; they are an internal promise that the staff can either keep or renegotiate with the guest.

Group requests into a small number of types: safety and access (lock, key, water, electricity), comfort (temperature, noise, bedding, towels), cleanliness, technical (television, Wi-Fi, plumbing), food and beverage, information and booking help, and transport. Give each type two times: the response time, by which someone acknowledges and starts, and the completion time, by which the guest has an answer.

The times above are illustrative only, for a fictional 120-room city hotel; each hotel sets its own and labels them as its own. Set them from what the hotel can actually do at 03:00, not at 11:00, because a target that only works in daytime teaches staff to ignore targets. Publish the table where both shifts see it and load it into the log as the default, so the promised time is not invented at the desk under pressure.

Turkish regulation gives the direction rather than a number: hygiene, cleaning and maintenance must be kept up regularly and faults must be fixed as quickly as possible, under Article 17 of the Turizm Tesislerinin Niteliklerine İlişkin Yönetmelik (opens in a new tab) (mevzuat.gov.tr, 2026). Confirm your own obligations and any sector-specific duties with your legal adviser. Review your targets against the log each quarter: if a type misses its target most weeks, either the target or the staffing is wrong, and both are fixable.

What happens when a promised time passes?#

A missed promised time triggers a named escalation, and the guest hears about the delay before having to ask about it. The worst version of a late request is a silent one, where the guest has to chase the hotel for something the hotel promised.

Use a simple escalation ladder by lateness. First, the owner tells the supervisor. Second, the supervisor chooses between a new time, a concrete alternative or an honest no. Third, the guest is told either way. Telling the guest before the deadline is best of all: "we said 22:00, the part arrives at 09:00, here is what we can do tonight" is a kept promise replaced by a better one.

Shift handover is a ritual, not a glance: the incoming shift reads the open list aloud, item by item, and each item is accepted by name. "The night team knows" is not a handover and does not move the owner. Sort the open list by promised time, not by arrival, so the oldest promise sits at the top of the screen at every hour. Two closing rules protect the record: nothing is closed by a person who did not do the work, and nothing is closed without a closure note.

How do you close the loop with the guest?#

Close the loop by telling the guest what was done and asking whether it is now right; a finished task is not a closed request. The pillow may have been delivered, but if the guest was in the shower and never heard the knock, the promise is still open in the only memory that matters, the guest's.

Ask a specific question: "is the water hot now?" rather than "is everything fine?", which invites a polite yes and hides the failure. Check back soon after completion, while the guest still connects the answer to the request, and again at departure if the request was significant. When the request cannot be met, say so early, give the reason in one line and offer a concrete alternative; a clear no with an alternative is better than a silent maybe.

Record what the guest said, not only that they were informed, because the reply is the evidence that the loop closed. If the guest is out, leave a written note or a message in the guest app and mark the row "closed, guest not yet reached" rather than "done". And when a request ends in dissatisfaction, it is no longer a request: it becomes a complaint and moves to the recovery routine, with the log row as its history. For that step, use a recovery routine for guest complaints at the front desk, and if messages are answered partly by software, be clear about when to hand a guest message over to staff.

How should you handle sensitive requests?#

Allergies, medical needs, accessibility requirements and religious or cultural needs are requests that carry personal data, so the log records only what the service needs and only the people who need it can see it. This is both an operational habit and a legal duty.

Apply minimum necessary: write "severe nut allergy, kitchen informed" rather than a medical history. The kitchen needs the fact, not the diagnosis. Give access on a need-to-know basis: the kitchen and the assigned room attendant, not a corridor whiteboard, a group chat or a shared screen in the lobby. Agree a retention rule for how long such a note stays in the log, and who removes it after departure when there is no continuing reason to keep it. Separate preference from health data: a high floor or a quiet room is a preference worth carrying to the next stay, while a medical detail is not carried forward automatically.

Staff also need a named person to escalate to when a request is outside their authority, such as arranging a doctor or an accessible transfer. The rules here are legal as well as operational: Turkish personal data law (KVKK, kişisel verilerin korunması kanunu) applies to what you write in the log. Describe the duty in general terms to your team and confirm access, retention and consent questions with your legal adviser.

What does a weekly review of requests turn up?#

A weekly review turns repeated requests into a maintenance list, a stock list and a training list, which is cheaper than answering the same request every week. Thirty minutes with the log, held at the same time each week, is enough.

Count requests by type and by room or area: a cluster in one corridor or on one floor is a building problem, not a guest problem. Then separate the three causes of repetition. "We did not have it" is stock. "We did not know" is information, signage or training. "It was broken" is maintenance. Each has a different owner and a different fix.

Information gaps are the cheapest win: if guests keep asking for the Wi-Fi password, the pool hours or the transfer price, the fix is a sign, a card or a line in the guest app, not a faster answer. A repeated cleanliness or welcome request points at the standard or the shift briefing, not at one person, so fix the briefing. Feed the maintenance items into the fault-fixing duty described above: faults must be fixed as quickly as possible under Article 17, and a list with dates is how a hotel shows it did. Keep the meeting to 30 minutes and end with named actions and dates, otherwise the review becomes a second place where requests go to die.

What to do next#

Start on Monday with one log and five fields: guest and room, the request in the guest's words, time received, one named owner and the promised time. Read the open list aloud at every shift change for two weeks, then hold the first weekly review. The pieces fit together in one direction: a single log makes the handover possible, the handover makes the promise keepable, the check-back closes it, and the review removes the reason the request existed.