When is a request really done?
When hotels talk about "lost requests", they usually mean work that never happened. In practice, many failures happen around the work rather than in it. The air conditioning was fixed, but nobody told the guest. The towels were delivered, but nobody knows who handled it. The guest asks again, and the front desk can only find out by phoning around.
So start by agreeing on one definition with your team. A request is done when all three of these are true:
- The work is done. The service was delivered or the problem fixed, or, if it couldn't be, the guest was offered a realistic alternative.
- The guest knows. The guest received a closing message, in their own language, that refers to what they asked for.
- There's a record. When the request arrived, who it went to, who completed it and when it closed are kept somewhere you can look back at.
This definition works whether or not you use software. At shift handover, in complaint reviews and in "was it done or not?" debates between departments, it gives everyone the same test.
The five steps of a request trail
Every request follows the same path from the guest's message to closure. Each step needs very little information recorded. The real risk is that the information lives only on one person's phone, or in a chat history nobody will ever scroll back through.
| Step | What to record | Where it typically breaks |
|---|---|---|
| 1. Receive | Time received, room number, the guest's own words | The message stays on one employee's phone; when they go off shift, the request disappears with them. |
| 2. Classify | Information question, service request, complaint, or safety/medical issue? | A complaint is handled like a routine service request, and guest relations never hears about it. |
| 3. Assign an owner | The name of the person who took it (not just the department) | The job goes to "maintenance", but nobody in maintenance knows who has it. |
| 4. Complete | Time completed and who completed it | The work gets done but nobody reports it, so the request either looks open forever or quietly drops off. |
| 5. Tell the guest | Time the closing message was sent | The guest only finds out when they ask again. |
Notice what these failures have in common: none of them comes from a careless team. Each one comes from a missing step, the one that should pass information to the next person or to a manager.
Which messages should become tracked requests?
Not every guest message is a job. A guest asking when breakfast starts needs a correct answer; a guest asking for an extra pillow needs someone to do something. Sorting messages into four types makes it clear what your team has to track.
| Type | Example | What it needs |
|---|---|---|
| Information question | "What time does the spa close?" | A correct, quick answer. No separate job record. |
| Service request | "Could I have two more towels, please?" | A job with an owner, a completion and a short closing message to the guest. |
| Complaint | "There's been no hot water since last night." | Tracked like a service request, with guest relations informed as well. While the guest is still in house, there's time to put it right. |
| Safety or medical | "My child fell and hit his head." | A person, immediately: the relevant team and the duty manager if needed. Never an automated reply. |
One message can contain several requests: "The AC isn't working, and can we check out late tomorrow?" Those are two jobs, one for maintenance and one for the front desk. If they share a single record, closing one can make the other look closed too. Keep the rule simple: one request, one record.
Ownership rules: a person, not a department
A request sent to housekeeping hasn't necessarily been picked up by anyone. Tracking only works if, at any moment, each request belongs to exactly one person. Four rules help:
- Write the routing down in advance. Which request types go to which department, and who covers out of hours? If there's no maintenance on the night shift, who gets the broken AC? Decide before the request arrives, not when it does.
- One owner per request. Even when a job goes to a department, the person who takes it owns it. If two people move at once, the first to take it owns it and the other steps back.
- Hand over open work in writing. At the end of a shift, unfinished requests and their owners are passed to the next shift in writing. "The morning team will deal with it" is not a handover.
- Name an out-of-hours fallback. When a department isn't working, requests need a named person, or the front desk, to land with.
Keeping open work visible
An open request only gets noticed when someone looks at it. Two habits stop most waiting work from slipping through:
- Reminders. A request that hasn't moved for a while is brought back to the owning team. Set the interval to fit how you work: the point isn't to promise the guest a time, it's to put forgotten work back in front of the team.
- An open-work check at the start of each shift. The department lead reviews open requests at the start of every shift. Anything left over from the previous shift gets a confirmed owner and status.
Once these habits are in place, managers don't need to follow every request; they only need to look at the exceptions.
The closing message to the guest
The closing message is the last step, and the one that shows the request was taken seriously. A good one is short and covers three things: what the guest asked for, what was done and, if needed, what happens next. Sending it in the language the guest wrote in makes it read like a reply rather than a template.
Closing-message examples
Illustrative examples; adapt them to your hotel's tone of voice.
- Service request
- “Hello, your two extra towels have been left in your room. If there's anything else you need, just message us here.”
- Fault
- “Hello, the air conditioning in room 412 has been checked and is working again. If the problem comes back, please message us straight away.”
- Request that can't be met in full
- “Hello, we've looked at your late check-out request for tomorrow. As the hotel is full, we can extend your check-out to 2 pm. Shall we confirm that for you?”
Avoid two mistakes: not replying at all, and replying to every request with the same stock sentence. The second suggests nobody actually read the request, and leaves the guest unsure whether they were understood.
Illustrative scenario: a broken AC in room 412
Illustrative scenario
One request, end to end
- 9:40 pm The guest writes on WhatsApp: "The AC in my room isn't working and it's very hot." The message is treated as a service request; the room number and the guest's words are recorded.
- 9:41 pm Under the routing rules, the job goes to the night-shift maintenance technician, who receives it with the room number and the request.
- 9:42 pm The guest gets a short holding reply saying maintenance has the request.
- 10:05 pm The technician fixes the unit and reports the job complete. The completion time and who completed it are recorded.
- 10:06 pm The guest receives a closing message in their own language saying the AC is working again.
- Next morning The front office manager sees the night's opened and closed requests in one list and confirms nothing was left to a verbal handover.
Times, room number and messages are chosen to show the flow. They are not a real hotel's data or results.
Where to start measuring
You don't need a complex dashboard to improve request tracking. In the first month, it's enough to be able to answer four questions:
- How many requests did each department receive?
- How many were completed, and how many are still open?
- How long does it usually take from request to completion? This is your own starting point, not a target.
- Which requests did a guest have to ask about twice?
The last question is especially useful. When a guest writes "Any news?", the problem is usually one of the tracking steps rather than the work itself. Reviewing those cases once a week shows whether the gap is in routing, ownership or the closing message.
Eight questions to ask when evaluating a request-tracking system
If you're evaluating software, ask to follow one real request from your own hotel end to end in the demo. These questions let you compare any product on the same terms.
Evaluation checklist
- Where do staff receive and complete work: in a separate app, a web console, or a messaging app they already use?
- How is completion recorded, and can you see who completed the job?
- Does the guest get a closing message automatically, in their own language?
- Are two requests in the same conversation tracked as two separate jobs?
- Can you set routing rules for out-of-hours cover and shift changes?
- Is there a reminder for waiting work, and who does it go to?
- Can a manager see open and closed requests by department and by period?
- How is access to guest and staff data controlled, and what does the vendor provide for your data-protection obligations (GDPR, KVKK or your local law)?
There's no single right answer. A separate app that staff must install can take longer to adopt in hotels with many seasonal staff; a separate operations system is a natural choice for hotels that already run one. Decide based on how your hotel works today and how your team is structured.
With Whispr
How Whispr applies this process
Whispr is a platform for intelligent hotel operations and guest relations, and it applies this process as follows. Every service request, complaint or safety issue in a guest conversation becomes its own operational case and reaches the right department under the hotel's routing rules. The employee receives the job in their own WhatsApp and completes it by replying to the notification. If the team works in a Telegram operations group, the job closes with the group's Done button.
When the work is complete, the guest is told in their own language, and waiting requests trigger a reminder to the team. Messages involving safety or health are handed to your staff straight away. Managers see who reported, received and completed each job, along with volumes and response times by department. For details, see Hotel Operations, Reporting, Guest Messaging and Front Office.
Frequently asked questions
Our team works in WhatsApp groups. Isn't that enough?
For a small team with few requests, groups can work, but without ownership and closing rules, requests get lost easily. We look at where groups struggle, and what you can change today, in our guide to staff WhatsApp groups.
Does the same process apply to teams using Telegram?
Yes. The process doesn't depend on the channel: request, owner, completion, closing message and record. In Whispr, Telegram operations groups complete a job with the Done button.
Do we need a PMS connection to track requests?
No. The core rules of request tracking work without any connection. A PMS/HMS connection links the guest's room and stay details to each request, so your team doesn't have to ask for them again.