An email has a clear request but no owner
Assumed example: reception emails maintenance about a room repair. The email describes the job, but no record says who accepted it. Check how requests are assigned before changing the intake form.
Illustrative excerpt. Not a client result.
Sample Systems Review: missed service requests.
A fictional hospitality example: requests arrive by email, text, phone and in person, but ownership and status are hard to track. The excerpt compares two options and proposes a small test with a person responsible for each step. Every scenario detail is invented; no client data or measured results are shown.
Systems Review / illustrative excerpt01 / What is happening now
The fictional starting point
Service requests arrive by email, text, phone, and verbal handoff. The person receiving a request passes it to whoever they think should handle it. Staff do not consistently record when work is finished, so requesters and managers have to ask for updates.
For this example, assume reception and maintenance can use an existing shared list, but have not agreed who keeps it current. This is a scenario assumption to verify in a real review, not a finding about a client.
First decisionPilot one shared request log with reception and maintenance. Make the duty manager responsible for naming one accountable person per request, and that person responsible for status and completion.
Test whether naming an owner and confirming the handoff prevents requests from being lost. Software can help route a request, but a person still needs to accept it.
02 / Current flow
How the request moves today
01Request arrives
Email, text, phone, or verbal request.
02Someone interprets it
The receiver decides what is needed and who should handle it.
03It is handed off
An employee or outside provider receives the request through an informal channel.
04Someone asks for status
The requester or manager asks for an update because open requests are not tracked in one place.
03 / Evidence to decision
Separate a tool problem from an ownership problem
These invented records show the comparison a reviewer could make. They are hypothetical inputs, not observations from an actual engagement.
A text repeats the same request
Assumed example: a manager texts about the same repair later in the shift. Staff cannot tell whether it is a new request or a status check. A shared reference would help link the two messages.
A verbal handoff leaves no status
Assumed example: the next shift hears that the repair is being handled, but cannot say who is doing it or what happens next. The handoff needs a rule for confirming those details, whatever software is used.
Taken together, these inputs point first to missing ownership and shared status. If real records instead showed prompt assignment but repeated missed notifications, the next test would be notification delivery and tool configuration.
04 / Options and tradeoffs
Two ways to test the same problem
Option A: use an existing shared list
Add a request reference, receipt time, category, owner, assignment time, status and next action. Staff enter requests from every channel into the same log.
This tests the handoff without a software purchase or migration. The tradeoff is manual entry and reconciliation; a list may become hard to maintain if volume, permissions or routing needs are more complex than assumed.
Option B: configure a request-management tool
Use structured intake, assignment and notifications in a dedicated tool. Check whether an existing licensed product can do this before buying another.
This may reduce manual tracking, but adds configuration, training and possible cost. It still needs agreed owners. Choose it sooner if the existing list cannot provide the access controls or request history the work needs.
For this fictional scenario, start with Option A because it isolates the ownership problem with less change. Reconsider if the pilot exposes a specific tool limitation.
05 / Owned next action
Test the shared log with reception and maintenance
First record a seven-day baseline, then pilot the shared log for 14 days with reception and maintenance. These illustrative windows cover weekday and weekend handoffs, with a second week to check whether the process holds after the first corrections. Extend them if request volume is too low to compare; they are not a standard KGS timeline or a promise of improvement.
Operations manager
Before the pilot, approve the request categories, scope and owner for each category. Keep urgent safety issues on the existing urgent-response route; this log does not replace it.
Reception
Record each in-scope request when it arrives, including phone and verbal requests. Link repeat contacts to the original reference rather than counting them as new work.
Duty manager
Name one accountable person for each request and record when they accept it. Reconcile the log with intake channels at every shift handoff; have the receiving person confirm ownership.
Assigned owner
Record the current status and next action. Mark completion only when the agreed work is done, with a brief completion note.
Operations manager
At the end of each week, review gaps and tracking effort with reception and maintenance. At day 14, decide whether to continue, revise the process or test Option B.
06 / Baseline and checks
Record the starting point and compare the test
Use the same definitions during the baseline and pilot. During the baseline, tally current handling without introducing new assignment rules; mark missing timestamps as unknown rather than estimating them. The duty manager reconciles the email and text records plus reception's phone and verbal tally at each handoff. Keep only the operational details needed for comparison; the example does not require guest names or sensitive records. No baseline values are supplied here.
Requests recorded
Compare unique in-scope requests found during reconciliation with those in the log. Keep missing entries visible in the count; do not assume the log is complete.
Time to assign a request
Record receipt and assignment timestamps. Compare the median and longest waits for similar request categories; count requests still unassigned separately.
Status at handoff
Count open requests with an owner, current status and next action at each shift change. Record which detail is missing so the team can correct the rule.
Status-chasing and tracking effort
Reception tallies contacts made only to get status. Staff record time spent chasing status and maintaining the log. Compare contacts and total tracking time per request, within similar categories, so the seven-day baseline and 14-day pilot remain comparable.
07 / Decision rule
What would change the recommendation?
Expand only when ownership holds
In this example, do not expand the pilot while any in-scope request remains unassigned at a shift handoff. That strict check addresses the specific failure being tested: work losing its owner between shifts. It is not a response-time guarantee.
If ownership holds, compare assignment delays, status-chasing and tracking effort with the baseline before expanding. Check changes in request volume and category mix before attributing an improvement to the pilot.
Change the process or tool when the evidence calls for it
If requests are recorded but still lack an owner, revise assignment and handoff rules first. If ownership is clear but manual entry causes omissions or excessive work, test Option B against that specific limitation.
Automate routine notifications only after the handoff works. Consider AI for sorting or drafting later, using realistic test cases and a named human fallback. A different result should lead to a different recommendation.
A request needs an owner and a way to check it.
A fictional hospitality example. Roles and checks would be agreed for the actual work.
- 01
Request
Proposed rolePerson receiving the requestRecord it in the agreed queue.
CheckIs the request captured?
- 02
Owner
Proposed roleNamed employee or vendorKeep ownership and the next action visible.
CheckDoes it have a clear owner?
- 03
Check
Proposed roleAgreed person checking completionRecord whether the agreed completion criteria are met.
CheckIs completion recorded?
Recommendations to test before implementation. No client result or measured improvement is claimed.
A review of your business starts with your own records.
If you need to investigate a recurring problem before choosing a project, talk to us about a Systems Review.