Ticket Triage 101

Throughout my career... or rather my life, I've been fascinated with puzzles.

I love the whodunnits and whatdunnits, often spending my free time eliminating variables to find the solution. Naturally this is what my career is all about. Triaging and figuring out the whatdunnits. Here is what I found to be super helpful in helping identify the problem without spending hours with your head spinning

Identifying the problem

??Stop. ??Listen. ???Communicate.

Often in IT we often assume we know exactly what the error means but as the tech gets more complex we get caught in the weeds when IT doesn't do what we want it to. This is why it is so important to Stop, Listen and Communicate with the user. Listening to what they did and how it happened can answer the following questions

1. Who: Identify the user or affected party. Obtain relevant details such as their name, contact information, and any relevant affiliations (e.g., department, team, or project).
2. What: Clearly articulate the issue or request. Encourage users to provide specific details, including error messages, symptoms, or desired outcomes.
3. When: Determine the timeline. When did the issue occur? Is it ongoing or a one-time occurrence? Time-sensitive matters require immediate attention.
4. Where: Context matters. Gather information about the affected system, location, or environment. This helps narrow down potential causes and solutions.
5. How Many: Quantify the impact. How many users are affected? Is this an isolated incident or widespread?

What's that saying? A picture is worth a thousand words. In the IT industry a screenshare is worth a thousand emails. Spending 15 mins on a screenshare can give us so much info that a user might not be able to give without us guiding them or asking a million questions causing a very irate duo

Eliminate the variables.

Most of the time what is reported as a general issue is something that is specific, so for example if someone reports all of everything is down but they are the only user or department affected it could be module that is down, or a finance module is struggling.

The way to find this out is ask the questions that could help narrow it down.

If the user reports one or you are present to check for one, they can point you in the right direction as to why a failure occurred. For example, Windows blue screens of death provide a relevant error code that will give you a good sense of what caused a failure.

Can the user provide screenshots, video, or other supporting information that can help assist in the troubleshooting process?

With this information we can document and look into this further confident that we have all the information. We are then able to expedite the resolution process and ensure that escalations reach the appropriate channels promptly.