The situation
Fictional planning example. These are sample decisions, not customer results or a demonstration of a live configuration.
A fictional MSP receives a call from someone reporting that several colleagues cannot use email. The caller can describe symptoms but cannot confirm the root cause. The first on-call engineer does not answer.
Sample intake record
Use the distinction between reported information and confirmed outcomes when reviewing your own process.
| Field | Sample entry | How to use it |
|---|---|---|
| Reported impact | Several colleagues cannot send or receive email. | Caller-reported scope; do not assume every user is affected. |
| Start time | Caller says it began about ten minutes ago. | Approximate report, not a measured outage duration. |
| Site and callback | Collect the site identifier and approved callback details. | Follow the organization’s identification process; do not collect passwords or access codes. |
| Symptoms | Sending and receiving appear affected. | Describe observable behavior without diagnosing the cause. |
| Priority | Apply the MSP’s approved impact and urgency rules. | Do not declare a priority or SLA from this example alone. |
Walk through the decisions
- Confirm the intake boundary. Collect the caller’s issue, affected scope and available contact information. Keep observations separate from technical conclusions.
- Apply approved triage rules. Use the MSP’s categories and escalation criteria. If impact is unclear, retain that uncertainty for review instead of filling in an assumed severity.
- Prepare the handoff. Use the configured ticket or record destination and confirm the expected delivery behavior during setup. A spoken promise is not evidence that a ticket was created.
- Use the unavailable-engineer path. When the first on-call recipient cannot answer, follow the approved backup or escalation route. Tell the caller what next step is being taken without promising restoration.
Example handoff note
Reported issue: email send/receive failure for several colleagues; site scope unconfirmed. Start time: approximately ten minutes before the call. Root cause: unknown. Primary on-call attempt: unanswered. Next step: approved backup recipient reviews the intake; ticket delivery must be checked through the agreed workflow.
When the routine path does not fit
- The caller asks for a password reset: Use the approved identity and account-action process. Intake does not justify bypassing authentication.
- Only one user is affected after clarification: Update the reported scope and reapply the organization’s priority rules; preserve the correction.
- The backup recipient is also unavailable: Use the documented escalation owner or message process. Do not continue retrying an undefined list of people.
Use this with your team
Which facts determine urgency? Who checks ticket delivery? What is the fallback after an unanswered escalation? What response can staff approve without promising an SLA outcome?
Replace the fictional choices with your approved process before configuring service. This page does not collect or send your answers.