You cannot access the failing service. What goes in the handover?
Give the owner enough evidence to act without pretending you found the root cause.
The question
Bellmere is a fictional healthcare group with clinics, offices and a supply warehouse. The ticket, policy and technical evidence below are original practice material, not an employer’s actual interview question.
- Impact
- Four staff at one office cannot open the shared document application. Other offices have not yet been checked.
- Timing
- At 14:06 and 14:11, the same read-only request returned an application error. The first report arrived at 14:04; the actual start time is unknown.
- Checks
- The affected users can reach the login page and sign in. The current application guide was checked. A permitted fresh-session test failed in the same way.
- Access boundary
- The service desk cannot inspect service-side logs or restart the service. The document-platform team owns those actions.
- Data rule
- A diagnostic export contains user names, session tokens and document titles. The approved secure ticket channel permits a redacted error excerpt and request correlation ID. Never include session tokens.
- AI summary
- Root cause: the shared document database crashed at 14:04. Restart the database.
“Write the escalation and tell the user what will happen next.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Separate observations from inference
What would you do here? Open the move you’d make.
State the observed error and unknown scope
The strong move. A useful handover states the evidence boundary.
Keep the AI root cause but label it probable
Tempting, but it misses something. The packet has no evidence of a database crash. A probability label does not supply it.
See how a strong candidate says it
“The first report was at 14:04. Two tests returned an application error after successful login. We have not checked other offices or service-side logs, so a database crash and global outage are not established.”
Why it works: A useful handover states the evidence boundary.
Step 2: Prepare a reproducible record
What would you do here? Open the move you’d make.
Send only the error screenshot and an urgent subject
Tempting, but it misses something. That makes the owner ask again for context already available.
Include scope, timestamps, behavior and completed checks
The strong move. The next owner needs expected versus actual behavior and attempted checks.
See how a strong candidate says it
“I would include the affected office, four users, expected document access, actual error, 14:06 and 14:11 tests, and the failed fresh-session check. I would request the missing application version rather than invent it.”
Why it works: The next owner needs expected versus actual behavior and attempted checks.
Step 3: Keep sensitive fields out
What would you do here? Open the move you’d make.
Attach the full export so the owner has everything
Tempting, but it misses something. That includes session tokens and unnecessary sensitive content against the supplied rule.
Send the permitted redacted evidence
The strong move. A technical escalation does not remove the data-sharing rule.
See how a strong candidate says it
“I would use the approved secure channel and include only the redacted error excerpt and correlation ID. The export’s tokens and document titles do not belong in this handover.”
Why it works: A technical escalation does not remove the data-sharing rule.
Step 4: Name the owner and next update
What would you do here? Open the move you’d make.
Confirm receipt and keep the update commitment
The strong move. An escalation is a change in technical ownership, not the end of user communication.
Close as transferred once the ticket is reassigned
Tempting, but it misses something. A queue assignment alone does not confirm ownership or keep the affected users informed.
See how a strong candidate says it
“The document-platform team will investigate the service-side evidence. I will send this record, confirm the receiving owner, and update the users at 14:30. I will not promise a restart or repair time.”
Why it works: An escalation is a change in technical ownership, not the end of user communication.
The answer, in short
- Decision
- Escalate a redacted, reproducible evidence record to the document-platform owner.
- Because
- The service desk has reached its access boundary and has no evidence for the AI’s database-crash claim.
- What would change it
- New owner evidence or checks at other offices may change the scope and diagnosis. They do not retrospectively make the guessed cause a verified fact.
Common traps
- Converting a first-report time into an outage start time.
- Sending secrets with a diagnostic export.
Check your answer
- Did you avoid the unverified database-crash claim?
- Did you preserve the two actual test times and unknown start time?
- Did you redact tokens and unnecessary document details?
- Did you confirm the next owner and keep the user update?
Last reviewed Nov 10, 2026