What's your approach to this help desk procedure issue?

[JavaJones]

I've recently been discussing small-to-mid-size business IT procedures with a few colleagues and have come up against some interesting differences in our perspectives. One issue in particular seemed worth getting wider feedback about.

In any business that reaches a size large enough to have dedicated IT resources (whether in-house or contracted), there is usually the concept of a "help desk", generally the first point of contact for user issues. Methods of contact often include phone, email, and form input (Intranet or Internet). Help desk staff usually make use of some kind of ticket/issue tracking system to help them document, assign, and keep users informed on issue handling. Some companies allow or even encourage direct access to the help desk systems used for issue tracking (obviously with limitations for user-level vs. technician level access), others prefer to keep the issue tracking system entirely proprietary to the IT/help desk staff, with all communications made directly by a help desk representative through email, phone, or in-person.

Another key differentiator is that many companies, especially in my experience web-based or web-oriented ones, either allow you to directly input your issue into a form and immediately generate a help desk ticket, or they immediately generate an issue/case number from any incoming email (my ISP Sonic.net is a good example of this). Others prefer to only ever generate help desk tickets manually, with a help desk rep soliciting required information from the user either via phone or email.

So my questions are:

• In your experience is auto-generation of tickets common (e.g. via email), and do you personally prefer that or not?
• In your experience do help desk departments often provide direct access to ticket creation via form?
• Do they allow access to viewing/interacting with the trouble ticket system and user's open tickets via web?
• How do you feel about this level of access for individual users?

I'm happy to share my own perspective of course but I hope to get a sample of yours first.

- Oshyan

[Stoic Joker]

So my questions are:

• In your experience is auto-generation of tickets common (e.g. via email), and do you personally prefer that or not?

-JavaJones (April 13, 2011, 06:23 PM)

That seems to be driven more by the size of the company than anything else. When the number of support people/clients go past a certain point ... The ticket system is required.

However it depends on the issue being reported. Our ISP had a ticketing system I just found out about a few months back. Previously I would call in issues, sit on hold, and then get someone (who had to be told the story again). Now I create a ticket online, play a few rounds of phone tag, and then get to explain the ticket's issue description to someone. ...So neither is really "faster" IMO.

• In your experience do help desk departments often provide direct access to ticket creation via form?

-JavaJones (April 13, 2011, 06:23 PM)

The bigger the company, the more common abstraction becomes (the human touch/contact thing takes time). So anytime they can put something in front of you other than a body...Is a $aving$

• Do they allow access to viewing/interacting with the trouble ticket system and user's open tickets via web?

-JavaJones (April 13, 2011, 06:23 PM)

^^Not to sound like a broken record^But...^^ We have the potential to use a externally accessible customer access ticketing system. As there is one included in the Kaseya network management system we use. I just prefer not to, as I feel the I get more/better info from direct interaction with the client.

We have over 4,000 clients, we do not have a phone tree. People call and talk to people ... It's one of the things (part of the service) we pride ourselves on.

• How do you feel about this level of access for individual users?

-JavaJones (April 13, 2011, 06:23 PM)

After a certain point/size it is a necessary evil.

[JavaJones]

Thanks for the response, exactly the kind of perspective I was looking for.

Personally I think a mix of auto and manual ticket creation makes sense. Auto creation from emails works fine, manual from phone. But I prefer a good web portal over both so that users can enter ticket details into a form, you can enforce fields to get useful info, and they can use the same portal to get status updates on-demand or reply (with email updates being sent to the user automatically when the ticket updates so they don't have to keep checking the site of course).

What I encountered in my discussions which surprised me was that some people viewed the users having some access to the ticket system as a "bad thing". Beyond simply preferring a different approach or feeling that the human touch was better, they actually felt that giving users that access was a problem, either a security risk, or likely to generate a lot of erroneous tickets, or something. That has not been my experience, though I'll grant that auto ticket creation by email does sometimes create erroneous or duplicate tickets, and often the info in the ticket needs to be completed by a tech anyway.

Thanks again. Anyone else with a perspective on this?

- Oshyan

[mouser]

what stoic said.

When the number of support people/clients go past a certain point ... The ticket system is required.

I tend to approach all of these kinds of issues with the same philosophy, that there is almost always an overhead mental cost to be paid in complexity, and that when you only have one or two people handling support, the more minimalist the approach the better.  If you are a sole developer, you might be attracted to the formality and logic of having a ticketing system for example.  But as logical as it might seem, there's a good chance that the additional layer of complexity is just not worth it and is more of a pain and distraction than anything.

However, as soon as you start adding more people to your organization.. in fact as soon as you have a company where any given request for help might be handled by two different people, then a formal ticket system starts becoming worth it.

[Ath]

Have a look at Auspex, it has a ticket system (RedMine), but only about half of the issues are logged, and the other half is reported in a forumthread or discovered by the developer, and often never put into RedMine

Isn't that just what mouser and stoic are trying to say?

Small team: Small tools
Big team: Big tools
(There probably are a few more flavors )

[JavaJones]

I agree. Nobody in the conversations I had was arguing against ticket systems as a whole, rather some felt that the system should just never be exposed to users and tickets should *never* be "auto" generated. They always wanted to be the ones creating tickets, entering data, etc.

One of the other unspoken issues with this is the overhead involved in adding back-and-forth communications details to your ticket system (unless you move to ticket system based communications once a ticket is opened). In other words let's say you receive a help request by email, you reply to the user to get more details, they respond and you open a ticket with the full info gathered so far. Now, do you move to ticket updates through the ticket system, or do you keep going via email? If the latter, then you should really be recording the pertinent info in the email back and forth into the help desk system. With all communications going through the system, that's never an issue.

In the end it's all about what works for people in their respective environments, of course. Different strokes for different folks.

- Oshyan

[40hz]

How do you feel about this level of access for individual users?

-JavaJones (April 13, 2011, 06:23 PM)

I think it's a great idea that seldom works well in the real world.

IMO most client generated ticket systems are mainly put in place for public relations purposes rather than for practical reasons. They're often nothing more than a fancy in-box. In most places, a client generated ticket does little more than act as a call tag for a technician.

It's then given to a helpdesk technician for triage. The tech needs to:

• contact the client
• get the client's story
• extract additional or missing information about the problem
• tentatively identify and classify what the real problem is
• edit the original ticket so that it's actually usable by support staff
• assign the request a priority code
• formally place it in the support queue

In short, someone still needs to talk to the client first before they can correctly enter the support request on the system. So it's generally immaterial, from a support perspective, whether the original ticket was client-generated or not. All support requests need to be reviewed.

[JavaJones]

Yes, that's a very good point indeed 40hz, and I agree. I do still prefer the option of auto-generated tickets and have found that in a good number of cases I don't actually need to change too much about the original ticket, only add additional info. But it does vary widely between organizations and the typers of users and problems they have.

One additional factor we haven't discussed is the perspective that some expressed to me which was that one person would generally be the "ticket manager" and be transferring tickets into the system from phone and email requests. This to me is perhaps the least sensible part of it, assuming you have multiple techs, because one person can become a bottleneck. But in the case of very small departments of only say 2 or 3 people, maybe it makes sense? That's certainly what was being presented to me at least. I'm still not sure I buy it. It seems to me it's preferable in that case that emails automatically generate tickets that everyone can self-assign and follow-up on. But sometimes I guess that level of control may be useful.

- Oshyan

[40hz]

I do still prefer the option of auto-generated tickets and have found that in a good number of cases I don't actually need to change too much about the original ticket, only add additional info.

-JavaJones (April 14, 2011, 03:42 PM)

If you have savvy users who understand much of the tech they're using, having them generate their own support tickets should work out very well. If that's the case with where you are - go for it!

I've never been that lucky.

[JavaJones]

Hehe, it's been a mix. Certain kinds of tickets and/or certain users, yes. Others, not so much. In general I find it a win to auto-generate, but definitely see how it might not be in other situations.

- Oshyan

[elvisbrown]

I built our help desk system from scratch based on know what we as a company wanted. I've worked there for almost 10 years so I have a fair idea. A user can phone our help desk or they can send an email. We usually find that they email if it is not urgent and phone when it is. From the phone calls most of them are classed as "completed on first contact" in other words the techie solved the problem on the phone.

Creating calls from emails works well and we us it extensively from our automated overnight processes. When they go wrong they send a coded email to the help desk to the email and that gets turned into an assignment that is automatically assigned to the right person. We have done this by implementing a system of "filters" that recognises pre-determined phrases in the emails. It works incredibly well and saves us hours of techie time by sparing them from trying to find out who to assign it to. By the way we are geographically dispersed.

As for access, only IT staff can create the calls but anyone can see them, the system is entirely open and we have nothing to hide. We want visibility about how long things take to fix and what are the things that consume the most time. For example we changed our email anti-spam system just on the basis of how many calls we had about blocked emails.

We did consider a web portal so users can click on options to either arrive at a solution themselves or at least create a meaningful call on the first go. In the end we found that that wasn't a problem that needed solving.

We use this system for everything that is IT related even assigning calls to external companies that we contract various services from.

If I was doing this exercise again I'd do it the same way as we get no complaints about the system itself. By allowing users to see their own calls they can see the progress themselves. My advice to anyone else would be to make it as open as possible and to not miss out on what you can achieve by automating the email process to create calls automatically.

Good Luck

[frogmanalien]

I actually work on a Helpdesk, and have been in the process of implementing a new software system to manage our support calls (we're using a hosted SAAS service of which there are plenty out there- including some great free/open source ones) so hopefully my experiences might be of use! (plus it's my first post  )
A ticketing system is really useful for tracking issues and making sure they don't disappear off of someone's radar- plus you can spot patterns as they occur, so you know when there's something "bigger going on" and responsibility can be shared easier (rather than everyone just forwarding emails around).
In terms of information capture-  Email "scraping" is great for saving time- but it's actually a lot of hard work to process emails to create tickets and prevent duplication- nothing's worse than creating a new ticket when it's actually a follow up. The solution we use for our Helpdesk actually uses a third-party piece of software called Email2Db (www.email2db.com) which adds a bit of intelligence to the puzzle, but it's still not perfect (largely because email and it's users aren't perfect either!).
I think forms are the BEST way as it gives you a chance, without too much effort, to ask important questions - I can't begin to count the number of times where if one extra bit of information was added to an email it would save hours- but because the person calling or emailing isn't asked that *particular* question, they never think about it. That said, I find people are unkeen to fill in forms (based on my experience at least) - and you either end up compromising on required bits of information to make sure that people use it. What we tend to say is that if you fill your form in better, we respond quicker (and it's true- as we know who best to give the call to).
Finally, there's no reason not to do a bit of everything- that way people who work mostly with email and are comfortable with email can log calls that, people who prefer a bit of hand holding and the personal touch can call in, and the technical guys who understand the benefits of providing information will use a web form!
Hope that helps!

[steeladept]

I can tell you what we do at our (large) company if that helps.  The user has a toll-free number to call in to the help desk, a web form, or an email box.  All 3 go to the first level help desk.  Assuming the help desk can't fix the issue outright (they have some rights to fix certain regularly occurring simple fix items); they then generate a ticket based on the information.  If that isn't enough information, they call the user back to get the additional information needed.  Once that occurs, the desk-side support group (or networking or whatever other group is appropriate) takes the ticket and works on it from there.  It isn't a perfect system, but it works pretty good and meets the balance of user convenience, IT support convenience, issue tracking, and information gathering that the company expects out of the system.

[JavaJones]

Thanks for all the continued input. From what I can see, in general auto-generation is quite reasonable and commonly used, which was the main point of contention I had with some of the people I originally discussed the issue with. For them, there seemed to be an almost religious (or dogmatic, at least) belief that auto-generating tickets was always a bad thing and that a "real live person" should always be the first line of contact. While I'm not seriously invested in any particular approach, I am glad at least to see that my perspective is not particularly unusual or "non-standard". In the end what works for a given department may not work for others, every company has somewhat unique needs. Being open to all options and using a clear evaluation of needs and potential solutions is the obvious way to arrive at the best solution; I just find often people get blinded by what they've been taught or told is the "standard" or "best practice" without looking at alternatives or how technology and methodology evolves over time.

Thanks again everyone!

- Oshyan

[40hz]

For them, there seemed to be an almost religious (or dogmatic, at least) belief that auto-generating tickets was always a bad thing and that a "real live person" should always be the first line of contact.

-JavaJones (May 10, 2011, 02:32 PM)

That mindset is usually the result of them experiencing a help desk that didn't stay on top of user-generated requests. So for them the only reliable way of having someone respond in a timely manner was by getting a "body" on the phone.

If a user generated ticket system is handled properly, people soon learn to trust it. Once that happens, the support tech will sometimes have to play phone tag with a client rather than the other way around. Also don't be surprised if you start seeing requests that say: "No need to call. Just e-mail me and tell me what I need to do." Having a library of pre-written 'solutions' is worth it's weight in gold once that starts happening. Mouser's form letter gizmo could also work quite nicely for that.

One good thing a user initiated ticket system gives you is a bulletproof timestamp of when the request came in. That's good to have when some executive's administrative assistant dropped the ball on something and is looking for someone to put part of the blame on. Automatically having a system do some CYA is a wonderful thing.

Of course, it cuts both ways. If your helpdesk is in the habit of making people wait or losing requests it will all come out on the weekly management reports.

[JavaJones]

Good observations 40hz. I think you're right, if auto-generated ticketing is handled badly (or helpdesk as a whole is handled badly) then it can definitely sour both the IT staff and the users on that kind of approach. But of course any approach if handled badly will make people prefer something else, hehe. Ultimately it was the fierce adherence to one particular approach without really acknowledging the potential merits of other methods that bothered me. I'm glad to see there are as many ways to approach this as there are IT departments, all legitimate and *potentially* (though not necessarily) ideal for their particular circumstances.

- Oshyan

[40hz]

One if the biggest barriers I've encountered when trying to implement organizational or technology changes is the issue of culpability. Usually those who are most resistant to proposed changes are those who fear getting their tails kicked (or losing their job) once the change takes place - because the proposed change will expose their errors, laziness, or failure to get a jump on something.

One thing I've found helpful is to get a written statement from the highest levels of management guaranteeing there will be no repercussions visited on anyone for past mistakes or oversights - provided they get with the current program and see to it that workable changes and improvements are made.

----------

from: Uncle Ebwart's Rainy Day Fun-Book of Modern Business Management and Other Craft Projects


40hz's Merciful Motivational Maxim:

      A little amnesty goes a long way!

Corollary: Everybody fights back when their livelihood or reputation is at stake.