Everyday IT · Escalation

Escalation should move the investigation forward, not restart it.

The next engineer should not have to rediscover the scope, repeat every comparison test, or guess why you stopped.Hand off the evidence, the risk, and the exact question that remains.

Build the handoffWhen to Escalate

The escalation packet

A strong handoff can be short if it contains the right information.

01

State the symptom and scope

What is failing, who is affected, where it occurs, whether it is reproducible, and whether the impact is one user, one device, one site, or shared infrastructure.

02

State what is already proven

Record known-good comparisons, browser-vs-client results, direct-path tests, service state, relevant logs, permissions, timestamps, or other evidence that narrowed the layer.

03

State what changed and what did not

List targeted actions already taken and their results. Also note important things intentionally not changed because of risk, scope, ownership, or missing authorization.

04

State the next question

Do not end with “please investigate.” Name the unresolved layer or decision: firewall route, Conditional Access policy, storage health, inheritance design, server availability, vendor behavior, or another specific next question.

Failed tests are useful evidence

Do not erase the path that ruled things out.

Comparison

Include the meaningful difference

If the same user works on another device or another user works on the affected device, include that result because it narrows the next engineer's starting point.

Reachability

Include exact layer results

Examples: portal reachable but authentication rejected, VPN connected but UNC failed, browser mailbox healthy but desktop Outlook failed, or Windows detected no scanner over the dock path.

Change result

Include what did not fix it

A targeted change that produced no improvement is useful when it was justified and documented. It prevents unnecessary repetition.

Intermittent

Include time and trigger patterns

Record whether the issue follows an application launch, user sign-in, location, time of day, reboot, password change, or another repeatable trigger.

Protect the next engineer from hidden risk

Escalation is often triggered because the blast radius changed.

Data

Say what could be lost or overwritten

Call out unsynced files, unique local data, restore risk, failing storage, retention concerns, or any step that could alter historical content.

Privilege

Say what level of access is required

Identify when the next step requires firewall administration, Global Administrator, Domain Admin, production server access, or another privileged boundary.

Dependency

Say which shared service is involved

Document the suspected domain controller, DNS, firewall, mail flow, storage, hypervisor, backup, security, or vendor dependency instead of handing over only the end-user symptom.

Rollback

Preserve the known-good state

If configuration was changed, include the prior state, export, screenshot, ACL capture, or other rollback reference when available.

A concise escalation can still be complete

The goal is signal, not a wall of ticket history.

Summary

What is broken and how broad is it?

One or two sentences that make the user impact and scope clear.

Evidence

What narrowed the layer?

List the few tests and findings that materially changed the investigation.

Actions

What has already been done?

Include targeted remediation, outcome, and current system state.

Ask

What exactly needs the next engineer?

End with the unresolved decision, access boundary, or infrastructure question that caused the escalation.

Escalate the investigation, not just the ticket.

A good handoff preserves the work already done and gives the next engineer a smaller problem than the one you started with.

Related Guides

Make the handoff reproducible.

Confirm the scope

State who, what, where, and when is affected before handing off the ticket. Scope the problem