Diagnostic quality
How do you diagnose a support ticket properly?
By reproducing the fault before explaining it. A diagnosis is the account of what you did to narrow the problem down, and what that ruled out. It is scored on the narrowing rather than on arriving at the right word. A correct guess and a correct diagnosis read very differently on the page.
- Reproduced and correctly diagnosed the issue
- 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.
Naming a cause without any step that would have ruled out the alternatives.
Asking the customer to try things at random - clear the cache, log out and in - in the hope that one works.
Stopping at the first explanation that fits the symptom, when two or three fit it equally well.
What a strong one looks like
What the grader is actually looking for
The same ticket, done in the way that scores.
Reproducing it first, or saying plainly that it could not be reproduced and what was tried.
Establishing scope early: one user or the whole organisation, one record or every record, since when.
Naming what was ruled out and how, so somebody picking the ticket up does not repeat the work.
Questions
Asked about this one
What if the fault cannot be reproduced?
Say so, and say what was tried. An honest account of a fault that would not reproduce beats a confident diagnosis with nothing behind it. It is also what the next person needs most.
Is asking the customer questions a sign of weak diagnosis?
The opposite, when the questions narrow something. Asking whether it affects one user or everybody rules out half the possible causes in one message. Asking them to try things at random does not.
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.