Documentation
What should a support resolution note contain?
Enough for somebody who has never seen the ticket to understand what broke, what was done and how to recognise it next time. The test is not whether it is tidy. It is whether the next person facing the same fault is faster because this note exists.
- Documented the incident and its resolution clearly
- One of the 11 dimensions every ticket here is graded against
What a weak answer looks like
The ways this is usually lost
Named failures rather than general warnings, because a warning nobody can recognise in their own work changes nothing.
"Fixed", "resolved", "sorted for the customer" - closures that record that something happened and nothing about what.
A note that only makes sense if you already watched the ticket.
The customer-facing reply pasted in as the record, which leaves out everything the engineer actually did.
What a strong one looks like
What the grader is actually looking for
The same ticket, done in the way that scores.
The symptom as reported, the cause as established, and the change that was made.
What was ruled out along the way, which is often the more useful half.
Anything that would let somebody recognise this fault quickly: the error string, the affected area, what makes it distinctive.
Questions
Asked about this one
Who is a resolution note written for?
The next engineer, including you in six months. A customer has already had the explanation in the reply; the note exists so the knowledge survives the ticket being closed.
How long should it be?
As long as it takes to name the symptom, the cause and the change. Most useful notes are a short paragraph. Length is not the measure - a long note that never names the mechanism scores worse than three precise lines.
See this scored on a real ticket: work one free, read a worked ticket, or see what a graded record shows. Every guide is listed on the guides index, and if something here is wrong or unclear, tell us.