Wider impact
The symptom affects many users, several services, or a tenant-wide configuration.
“What if it’s bigger than a ticket?”
A boundary is useful when the next owner receives usable context.
The desk should not force a migration, investigation, redesign, or vendor dependency through an everyday ticket. It should preserve facts, name the boundary, and make the next decision understandable.
Signals that work changed shape
One signal can be enough to pause routine support.
Design rather than restore
The desired outcome changes architecture, policy, governance, or a standard working method.
Material risk
The request involves privileged access, suspicious activity, retention, legal need, or a security decision.
External dependency
The next action sits with a provider, business-app vendor, hardware owner, network, or another administrator.
State what was observed.
Affected users, app, device, exact wording, time, recent change, and safe checks already completed.
Name why desk work stops.
Project scale, security risk, business authorization, infrastructure, vendor dependency, or another owner.
Identify responsibility.
Who must scope, approve, investigate, coordinate, or provide missing evidence—and what they need next.
Handoff record
Carry forward what the next owner would otherwise ask again.
This structure demonstrates the expected information, not a fabricated customer record or proof of a past result.
- Observed
- What the user experienced, where, and when.
- Checked
- Safe steps already taken and their result.
- Impact
- Who and which work are affected.
- Boundary
- Why everyday user support no longer fits.
- Decision
- The approval, scope, risk, evidence, or ownership needed next.
- Destination
- The accountable role or vendor—not an invented named individual.
Representative destinations
Name the responsibility, not merely “tier two.”
| Finding | Likely responsibility | Context to carry |
|---|---|---|
| Unexpected MFA or suspicious sign-in | Authorized security or tenant administrator | User, time, wording, device, observed activity, and actions taken—never credentials. |
| Tenant-wide service or policy impact | Tenant owner, service administrator, or vendor | Affected services and users, start time, known changes, and available service evidence. |
| Migration or redesign request | Project owner and technical lead | Desired outcome, current state, dependencies, stakeholders, risk, and acceptance criteria. |
| Network, hardware, or business-app cause | Responsible MSP, vendor, or equipment owner | Device, location, connection, affected apps, comparison tests, and business impact. |