Written for the MSP owners rather than the end clients. If the same Intune tickets keep coming back up the queue, it is almost never the engineers. It is that the ticket arrives without the four facts that make it solvable.
Level 1 can close far more Intune work than most MSPs let it, and level 3 gets dragged into far more than it should, because the handover between them is verbal. The fix is boring and it works: decide which categories level 1 owns outright, and standardise what an escalation has to contain.
What level 1 can own with a written runbook
App not installing on one machine when it installs everywhere else. Device not syncing. User cannot enrol. A missing licence. Wrong group membership. Company Portal showing nothing. Every one of those has a fixed sequence, and none of them needs anybody senior. Give level 1 the sequence and the permission to run it and the queue gets shorter without hiring.
What genuinely needs level 3
App packaging and detection logic, because a wrong detection rule reports success while installing nothing. Autopilot and enrolment status page failures, because the useful information is in logs on a machine that has usually been reset. Conditional Access changes, because the blast radius is everyone. Anything involving certificates, platform SSO on macOS, or a migration from another management platform. These are not harder tickets, they are tickets where being wrong is expensive.
The four facts that stop a ticket coming back
The device name as Intune knows it, and its last check in time. Without these the next engineer starts by working out which machine.
The exact error, copied, not described. "Failed" is not an error. 0x87D1041C is an error, and it points somewhere specific.
What was already tried, including the things that did not work. Half of returned tickets are returned because somebody repeated a step that had already failed.
The logs, collected before the machine was touched. On Windows that means the Intune Management Extension logs from ProgramData, and an MDM diagnostics report. Once a device has been reset, the evidence is gone and the ticket becomes a guess.
Why this matters more than it sounds
A bounced ticket costs twice, and it costs the client's patience rather than yours. It also hides the real pattern. Ten tickets about apps not installing usually mean one packaging problem, but only if somebody sees all ten together. Escalations written the same way every time make that pattern visible. Escalations written from memory do not.
Write the runbook for the level 1 list, write the four facts into your escalation template, and review what still escalates after a month. That review is usually where the actual root cause is sitting.
If you would rather borrow the depth than build it, that is what Level 2 and 3 support for MSPs is for.