[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ticket systems

Dan MacNeil wrote:
I'm curious as to how people use ticket systems and their bad experiences with ticket systems. "How" and "why" are more useful right now than "what". I'm not especially interested in "request-tracker rocks!" or "No! otrs rocks more!"

Despite your request, you seem to have attracted those kinds of replies. My comments below are written from the perspective of managing an IT helpdesk in some largish organisations, so maybe not all of the comments are applicable but perhaps they provide food for thought.

- All calls must be logged. That must be bought into by the top of the organisation.

- Have a non-technical person/people answering the telephone. That removes the temptation to do the "quick fix" over the phone and not log it (because that's too much effort).

- For "quick fix" calls the ability to enter and resolve the ticket in one action is helpful

- Start simple. Many ticketing systems are very customised and complex, but most of the complexity isn't used in my experience. One example: if you're going to categorise calls into, say, "network", "systems" and "applications", define how you are going to USE that information before you set up such a system. Not how you might use it, but how you will.

I've heard people say that it is nice to have system created tickets, (naigos reports webserver down) or to have master tickets. (10 people complain about webserver down, close master ticket and close linked tickets)

I agree. With automatic logging, eg from Nagios, ensure before you enable it that the vast majority of mails from Nagios are "action" mails rather than "information" mails otherwise you'll end up with noise in the ticketing system and, more importantly, loss of faith in it by those who use it.

I've worked places where people game the system. A good evaluation comes from closing lots of tickets, so people are motivated to close tickets rather than solve problems. There are also some disincentives to put hard-to-solve problems in the ticket system....

Again I agree. Cheap evaluations like this do not work. The requirements are 1) every incident is logged and 2) there is enough information in the resolution of a ticket to enable another person to resolve a similar problem in the future. For evaluation purposes, maybe we pick ten tickets at random over the past six months (or whatever the review period is) and discuss how they meet those criteria.

Finally, define your requirements of a ticket system before selecting which one to use (you may, or may not, be surprised how often this is done the other way round).

I hope some of that was helpful (well, I hope all of it was, but I'll settle for some).

Keith Edmunds

|  Tiger Computing Ltd  |  Helping businesses make the most of Linux  |
|  "The Linux Company"  |    http://www.TheLinuxConsultancy.co.uk     |

Reply to: