How to Write the Perfect Ticket as an IT Pro

We're all hypocrites when it comes to ticketing systems. We go into tickets expecting them to be missing important information. But at the same time, we also expect something near perfection from those within the pipeline.

Regardless of what IT role you hold, your colleagues will have basic expectations of how to write the perfect tickets and notes. Here's how.

Properly Escalate Issues

With most medium-to-large companies, the IT departments are made up of several people or teams with different tiers of expertise and domains of responsibility. If you are a lower-level engineer, say helpdesk or a junior within a group, you'll regularly need to escalate tickets up to a specific group or higher-tiered engineer. In these circumstances, think of the rules that you lay out for your users. Give enough detail in the ticket, send screenshots, etc. These same rules apply when escalating tickets, but there are extra considerations. Namely, troubleshoot before you start escalating.

Example: Say that Sam, network engineer at Shire Inc., gets a ticket escalated up from Frodo on the helpdesk. The user's notes on the ticket were vague: "The network drops a lot on the 3rd floor."

Rule 1: Frodo better make the best effort that he can based on available time and expertise to work the issue. Go interview the user to get more info. Is the connection wireless or wired? Is one computer affected for the whole floor? And so on, with basic troubleshooting.

If the problem is limited to this one person and the rest of the floor is okay, it's probably an issue with their computer, not the network.

If Frodo escalates this to Sam, then he's going to kick it right back down. Desktop issues are Frodo's responsibility and this is clearly a desktop issue.

Maybe he slacks off, and doesn't interview the user at all, saying, "It's a network issue, escalate on up to Mr. Gamgee!"

Again, the ticket should be kicked back. He made no effort at all to triage the problem and that's what the helpdesk is supposed to do.

Or maybe Frodo finds everyone on the floor is complaining about connectivity. He tests the wifi and it's slow all over the place. Access to the network hardware is limited to network engineers and he's not allowed to touch it. Clearly, he's done his due diligence and it's time to escalate, but he adds no notes to the ticket about troubleshooting and a conclusion. Sam has nothing to go on and should send that ticket right back.

Notes for Future Reference

As we've seen, there are extra expectations for handling tickets and internal notes when pushing tickets up within IT, but there are other reasons for everyone to take good notes.

Sometimes simple notes are fine. For instance, "Wifi performance complaints on the 3rd floor, access point 3-B unresponsive, reboot AP, confirmed wifi performance normal."

More complex problems require more involved troubleshooting, research, and fixes. Those issues require thorough notes so that if the issue occurs again, someone could fix it much quicker following what you wrote. After all, why reinvent the wheel? This becomes invaluable if the issue causes an outage in any area of your infrastructure where time to restore service is critical.

Great notes are also necessary for long-term or intermittent issues. If a router or load balancer freaks out and takes down part of the network every other month, you can't waste time repeating the same troubleshooting steps. You want to know the actions someone took to fix it, even if that person (or people) are no longer with the company.

Perhaps, you can find a different fix and resolve that pesky problem for good. Maybe your team requires formal incident reports for these serious issues. You can either try to remember everything that happened in the fog of war for the long haul or have your great notes already written out from when you closed the ticket.

These notes are also important if you're working with a vendor's tech support so they can see the full history of the issue. You better believe they get just as frustrated with lousy tickets.

Take Your Own Medicine

It's human nature to be lazy. We can complain about our users all day and their "HELP, CALL ME!" tickets but that applies to you and your team as well. Hopefully, you can see the value that great tickets and notes provide both internally for your team and in working with outside help. By creating perfect tickets every single time, you're maximizing communication and putting forth the extra effort to provide the best support that you can!

Practice what you preach good notes, steps to reproduce, screenshots, log files, any scrap of info you think they could use, and send it all on over. Give the next tier what they need, get the problem sorted faster, and you become a hero.