Crucial Data for IT Tickets

When you start designing a from scratch Ticketing system for your IT Department things a be a bit overwhelming. There are many programs out there that do the same thing but seem too busy, complex or just too expensive to implement.

Over the past year I have been working with contractors to deploy an in house ticketing system for our IT requests. For us third party options were too complex for a extremely small help desk to utilize, and ones that were free (i.e. Spiceworks) were too busy with unnecessary information for us. We went about creating the ticketing system however had little idea of what data we needed to capture in the system once it went live to users.

We started with the basics:

1. Issue
2. Due(Priority)
3. User
4. Category
5. Response Method

We found that users don't chose category's like we do so we hid that field for them and left the others. Due responses always defaulted to the slowest time (for us it was "within a week"), and the user field auto populated with the user who was logged into the web page. This could be changed but most users just wanted their name in there.

From their your case my differ, but its a good start to gathering data from your users via a ticketing system instead of phone calls and stop by's.

Test Your IT Monitoring Tools Regularly

Most IT Departments have active monitoring tools to make sure you are notified in the event that something goes wrong, right, or is starting to look sketchy (much like a bad NHL trade). These systems are put in place with the mindset of a set it and forget it mentality because hey, its supposed to alert us right? Well if you haven't heard it before I am saying it now. No. Is that a complete sentence? Probably not, but it gets my point across. Monitoring systems and devices are only as good as their trustworthiness and much like your gradual trusting of friendships must grow by testing the tools on a regular basis.

I will use our power monitoring/temperature monitoring device in our server closet as an example. In the event of a power failure, or A/C unit failure one of two things will happen. In the first scenario, the unit alerts us by calling my cell phone to notify me that power has been lost and the unit is running on backup power (this unit is a cellular one). In scenario two the device calls my cell and alerts me to a high temperature reading, possibly caused by a malfunction in the A/C unit. If I never test the unit by pulling the power plug then I have no faith the unit will successfully call me in the event of a power outage, and if its not regularly tested then I have no faith the battery is still holding a charge inside the unit and will stay alive long enough to make the call needed through our vendor.

Testing these units regularly should be on your IT calendar and should be as often as you or a colleague can test it. (For us, quarterly should be our testing cycle).

Having faith in these systems to work correctly when needed can help an Administrator sleep at night knowing a trustful partner is always watching and thankfully never needs sleep.