Chris's Wiki :: blog/sysadmin/OptionalTicketing Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/OptionalTicketing?atomcommentsDWiki2009-04-18T06:01:30ZRecent comments in Chris's Wiki :: blog/sysadmin/OptionalTicketing.By Chris Siebenmann on /blog/sysadmin/OptionalTicketingtag:CSpace:blog/sysadmin/OptionalTicketing:6d820d87e48f640442c0de4a5e2acbce708a543cChris Siebenmann<div class="wikitext"><p>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, <a href="https://utcc.utoronto.ca/~cks/space/blog/sysadmin/UserSysadminBenefit">UserSysadminBenefit</a>.)</p>
</div>2009-04-18T06:01:30ZFrom 88.97.233.154 on /blog/sysadmin/OptionalTicketingtag:CSpace:blog/sysadmin/OptionalTicketing:c403e46d97ded1eb0b859183c19e228948497bcbFrom 88.97.233.154<div class="wikitext"><p>"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."</p>
<p>I disagree. It aides /you/ in providing /them/ a better service. By way of clarity, tracking, escalation and fast response times.</p>
<p>You needn't stipulate that they fill out or even see obscure ticketing details such as priorities or components. Just the fleshy bits.</p>
</div>2009-04-15T14:12:44ZFrom 99.236.188.163 on /blog/sysadmin/OptionalTicketingtag:CSpace:blog/sysadmin/OptionalTicketing:99bc09d6c14bc9f99e259d82ed62ab7c777f06abFrom 99.236.188.163<div class="wikitext"><p>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. </p>
<p>So they talked to a staff member nominated as their point of contact, who did the necessary magic to put it into RT.</p>
<p>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.</p>
<p>MikeP</p>
</div>2009-04-14T19:14:08ZFrom 80.34.171.71 on /blog/sysadmin/OptionalTicketingtag:CSpace:blog/sysadmin/OptionalTicketing:4d574d80d4d27ab15dbea999eb9b7e7894416db8From 80.34.171.71<div class="wikitext"><p>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.</p>
<p>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</p>
</div>2009-04-14T09:17:01ZBy rdump on /blog/sysadmin/OptionalTicketingtag:CSpace:blog/sysadmin/OptionalTicketing:99bb4e27a07d102438e24e02a67010f88c739474rdump<div class="wikitext"><p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Of course, I have to use it to report problems too. And as a user, I truly fear the ticket system.</p>
<p>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.</p>
<p>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.</p>
<p>Am I crazy yet? But of course.</p>
<p><sigh></p>
</div>2009-04-13T21:39:58ZFrom 71.250.234.178 on /blog/sysadmin/OptionalTicketingtag:CSpace:blog/sysadmin/OptionalTicketing:1eca05491b72f03215c8aaa50322b62b40f8a4b3From 71.250.234.178<div class="wikitext"><p>My trouble ticket service IS our developers' bugzilla installation. There are just different targets for my users to contact me. </p>
<p>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". </p>
<p>I also have a todo list in my franklin covey planner, and the first entry every day is "check bugzilla".</p>
<p>Matt Simmons<br>
<a href="http://standalone-sysadmin.blogspot.com">http://standalone-sysadmin.blogspot.com</a></p>
</div>2009-04-13T15:58:38Z