Key points
- One case owner retains responsibility for guest communication.
- The catalogue identifies the delivery team and useful information.
- A follow-up joins the existing request unless the need has changed.
Separate case ownership from delivery
The employee receiving a request first confirms what the guest needs. They create or retrieve the case and route the work to the appropriate team. The case owner remains responsible for the next guest update even when another department carries out the task.
This distinction prevents “message forwarded” from being mistaken for “request accepted.” It adds a practical routing rule to centralised hotel task management. In a small team, one person may perform both roles. The record should still make it clear who will provide the response, especially if that person finishes their shift before the request is complete.
A starting catalogue to adapt
The matrix below proposes five request families. Department responsibilities and service hours vary by property. Include the actual overnight coverage and a deputy for periods when the usual owner is unavailable. Confirm the catalogue with each delivery team before staff use it to make commitments at the desk.
| Request | Suggested delivery team | Useful information | Expected confirmation |
|---|---|---|---|
| Extra linen | Housekeeping or runner | Type, quantity, authorised location | Handover or agreed placement |
| Loan equipment | Equipment custodian | Suitable model, availability, duration | Verified setup or handover |
| Room fault | Maintenance | Observation, access, affected use | Competent update and guest informed |
| Local information | Front desk or concierge | Need and stated constraints | Answer provided with limits explained |
| Unlisted request | Duty manager | Desired result and deadline | Decision or alternative communicated |
For personal information, use the data minimisation principle explained by the ICO: collect what the purpose requires. A linen delivery record can describe the task without narrating the guest’s personal circumstances.
Move a request through the workflow
- Restate the desired outcome, distinguishing a preference, a constraint and stated urgency.
- Check for an existing case covering the same stay and need.
- Assign the delivery team and obtain acceptance, or use the agreed escalation route.
- Give the guest a realistic response or a time for the next update without promising unverified availability.
- Obtain evidence appropriate to the task and communicate the result.
Acceptance identifies who is handling the work. It does not prove delivery. Likewise, “waiting for guest” should explain the missing information and the case owner’s next action. Otherwise, that state can become a place where requests simply stop moving. If the request crosses shifts, explicitly transfer ownership of the next update.
Handle follow-ups and unavailable services
When a guest calls again, find the existing reference before creating another case. Add the follow-up and any new information. If the requirement changes, amend the task or create a clearly linked addition. Tell the original delivery team when an action is cancelled: changing the front desk record alone may leave a colleague continuing the work.
If the requested service is unavailable, the case owner explains the limit and offers an authorised alternative. Record whether the guest accepts, declines or wants time to decide. An offer is not acceptance, and a communicated refusal should not be recorded as successful delivery. This distinction keeps the service record useful for later review.
Two complete illustrative cases
Room 206 requests two pillows. Front desk opens R-206, confirms the available type and assigns a runner. The guest calls before delivery. Front desk attaches the call to R-206 and checks progress. The runner confirms handing over two pillows, and the owner closes the request using the agreed confirmation rule. No second delivery is created.
Another guest requests an adapter when no available stock remains. The custodian confirms this. Front desk offers an authorised alternative and explains its limitations. The guest declines. The case closes as “request unfulfilled, alternative declined, guest informed.” This accurate result can inform a catalogue review without inflating the number of requests described as resolved.
Improve the catalogue through exceptions
Review misrouted requests, unanswered follow-ups and frequently declined alternatives. Look for a missing instruction: unclear availability, a team without a deputy or an ambiguous closure condition. Add a useful rule after the responsible department approves it. The objective is clearer future decisions, not an ever-growing list of categories that employees struggle to choose between while serving a guest.
Frequently asked questions
Must an urgent request wait for data entry?
A situation requiring immediate action follows the hotel’s emergency process first. The designated person completes the record afterwards. The ordinary request matrix does not replace an alert or the property’s safety instructions.
Should guests confirm every delivery?
Choose proportionate evidence: an observed handover, an expressly agreed placement or guest feedback where necessary. Avoid asking for several confirmations for one simple task. Define the appropriate criteria for each request family.
