Your ticketing system should be optional

April 13, 2009

There's a fair bit of enthusiasm for ticketing systems in the sysadmin world, and it's not hard to see why. But I'm going to be a contrarian here: while ticketing systems are all well and good, you should absolutely not require users to use them in order to interact with you.

The problem with ticketing systems is that they're like bug trackers; they're internal systems that are almost always filled with fields and procedures that exist for your needs. Your users should not have to fill in these fields and jump through those procedural hoops, because they don't give your users any benefit; they just help you.

This doesn't mean that you shouldn't have a ticketing system; it just means that you should take freeform problem reports by email or whatever, and put them in the ticketing system yourself. And if some users want to file their own tickets, it may make sense to make it available to them.

(It follows that the more complicated your ticketing system is, especially in the number of fields you have to fill in to make an initial report, the worst it is for users. Unless they are unusually interested in how your run the systems, they probably have no idea what the right answers are for all of those questions that they're being asked.)


Comments on this page:

From 71.250.234.178 at 2009-04-13 11:58:38:

My trouble ticket service IS our developers' bugzilla installation. There are just different targets for my users to contact me.

Typically, they'll say something like "Hey, I've got this weird thing going on", and I'll say "alright, I'll look at it, just make sure to put it in bugzilla so I don't forget".

I also have a todo list in my franklin covey planner, and the first entry every day is "check bugzilla".

Matt Simmons
http://standalone-sysadmin.blogspot.com

By rdump at 2009-04-13 17:39:58:

This is one portion of my job where it really helps to be able to have three contrary world views in place at once. Otherwise, I'd go crazy.

We have a ticket system that we're told in no uncertain terms to send all requests towards. We have the best of motives for this.

We want to use it to get the users' problems resolved as instantly as possible. In most cases, this is best served by having the ticket dispatchers recognize and solve common problems, with procedures for escalating the uncommon problems to the proper places.

In reality, the system is so designed that it hinders figuring out what's going on. First, it doesn't fit on my screen. It's not just a typically too common too-wide web page. It's aggressively wide, to the point that I'm always missing things. Second, the scripting it uses has bugs that exploit memory leaks in at least three browsers. On the bright side, the crashes that result have taught me to backup my tab sets. Third, the conversation about the problem in the ticket is carried on in three separate sections of the page, with at least one of the sections (seemingly) in reverse chronological order. We miss things regularly. Most of our time dealing with this system involves trying to figure out what should have happened with the misdirected tickets.

Of course, I have to use it to report problems too. And as a user, I truly fear the ticket system.

It has a whole passel of confusing fields in it. Some are mandatory. Others are optional. And still others I will -never- be able to understand. My resulting worries about how to help ensure the right menu items are selected and the right ever-changing fields are filled in to make it easy for the front line folks to get the ticket to the right place are answered with... closed tickets. Indeed, the only rational response for most requests is to close them unresolved.

In the end, like most overly complex ticket systems, it's where problems go to be ignored, and die unresolved. We don't seem to have a choice.

Am I crazy yet? But of course.

<sigh>

From 80.34.171.71 at 2009-04-14 05:17:01:

I think you are judging a way of working (ticket driven) by some wrong implementation, at least if exposed to end users, like for example Bugzilla. A ticketing system helps you know in every moment what to do (my short time memory tends to fail quite often :P) and from a BOFH point of view helps in getting only the real problems to your attention.

And speaking of Buzilla, I've been using it for years now with end users and in first place they're scared but in the long run they learn and simply ignore all those esoteric fields. Nonetheless a simpler ticketing system could do better than Bugzilla

From 99.236.188.163 at 2009-04-14 15:14:08:

At previous_job, our users had made it quite clear they absolutely did not want to have to interact with our RT system any more than necessary. And I don't blame them - faculty members have better things to do with their time than to figure out what priority should be assigned to their request.

So they talked to a staff member nominated as their point of contact, who did the necessary magic to put it into RT.

I would argue that not only is this a better way to handle the difficulties of end-user / trouble tracking systems, it's the only way.

MikeP

From 88.97.233.154 at 2009-04-15 10:12:44:

"Your users should not have to fill in these fields and jump through those procedural hoops, because they don't give your users any benefit; they just help you."

I disagree. It aides /you/ in providing /them/ a better service. By way of clarity, tracking, escalation and fast response times.

You needn't stipulate that they fill out or even see obscure ticketing details such as priorities or components. Just the fleshy bits.

By cks at 2009-04-18 02:01:30:

Fundamentally, I don't think that 'help us provide better service' is something that users will perceive as a benefit in most cases, because from the user perspective we should already be providing great service to start with. (I put more words on this in a new entry, UserSysadminBenefit.)

Written on 13 April 2009.
« A hairshirt too far: on always avoiding CSS
How I went wrong in thinking about /boot mirroring »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Apr 13 01:48:42 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.