Writing Ticket Notes and Escalating
How to write clear ticket notes, set priority, and hand a ticket to someone else without making them start over.
Any help desk ticketing systemabout 3 min read
Symptoms
Use this runbook when:
- You're not sure what to write in a ticket, or how much detail is enough.
- You're deciding whether to keep working on something or pass it on.
- A ticket has been reopened and you can't tell what was already tried.
Before you start
Good notes make the next person's job easier, and that next person is often you in three weeks. The rule of thumb is: write it so a colleague could take over without calling the user again.
Steps
Write a useful ticket
- Title: short and specific. "Laptop will not connect to office Wi-Fi" is better than "Wi-Fi problem".
- Record the basics: who is affected, which device (name or asset tag), where, and when it began.
- Capture the symptom in the user's words, plus exact error messages or codes (copy or screenshot them).
- Ask what changed (update, new device, password change, power cut).
- Find the scope: one user or many? One device or all? One program or everything?
Set the priority
Use your organisation's definitions. A common simple guide is:
| Priority | Typical meaning |
|---|---|
| Critical | Whole site or business-critical system down, security incident |
| High | A person or team can't work and has no workaround |
| Medium | Work is slowed or there's a workaround |
| Low | Request or minor annoyance; no business impact |
The impact (how many people, how badly) and urgency (how soon it matters) both count. Don't be afraid to raise the priority if new facts appear, and write why.
Keep notes as you work
Add a short note after each step: what you checked, what you found, what you changed. Include the time. Avoid "fixed" without saying what was done. Never record passwords or other secrets.
Escalate cleanly
Escalate when you've hit the limit of your access or experience, when the SLA is at risk, when many users are affected, or when it's a security matter. Escalating isn't failure; waiting too long to escalate is the problem. Before you escalate:
- Write down everything you tried and the results.
- State clearly what you need: "please check the DHCP scope", "need admin rights to unlock the account".
- Tell the user what happens next and roughly when (don't promise a fix time you don't control).
- Keep the ticket assigned to yourself or update the owner, so it doesn't get lost.
Close properly
- Confirm with the user that the problem is fixed (and note that they did).
- Write the resolution: cause (if known), fix, and any follow-up. Resolution text is what future technicians search, so make it specific.
- Link related tickets and, if it's a repeat problem, suggest a permanent fix.
Escalate when
- You've spent a long time on a ticket with no progress, and the SLA is close.
- The ticket involves security, data loss, or a service many people depend on.
- You need access or approval you don't have.
- The user is a VIP or the issue is unusually sensitive. Follow the local policy.
Ticket note template
General-purpose note (copy and adapt):
Summary: <one sentence>
Reported by / contact: <name, how to reach, preferred time>
Device / system: <name, asset tag, OS, location>
Scope and impact: <who, how many, workaround? Y/N>
Symptoms / exact error:
Timeline: first noticed <when>; recent changes <what>
Checked and found:
1. <check> -> <result>
2. <check> -> <result>
Actions taken: <what you changed and when>
Current status: Open / Waiting on user / Escalated / Resolved
Next step (owner, date):
Resolution (when closing): cause / fix / user confirmed Y/N
Escalation hand-off note:
Escalating to: <team / person> | Reason: <limit of access / SLA / scope / security>
What I need from you:
What I already tried (so you don't repeat it):
Business impact and deadline:
User informed: Y/N (what I told them)