Showing results for 
Search instead for 
Did you mean: 

Do trouble tickets via email create more problems than they solve?

Level 11

The core application to any HelpDesk workflow is the ticketing system. It helps all levels to track issues/requests and documents what has been discovered about the particular issue. There are some ticketing systems that are really complex with lots of features. As more and more features are added, complexity is added as well.

I was recently speaking with someone who stated that they had emailed into their IT ticket system with a list of items that needed addressing. They knew they were supposed to open a single ticket for each issue separately. A few days later the IT staff worked on one of the issues, then closed the ticket and marked it as resolved. Only one of the issues on the ticket was resolved with the rest of them never being addressed.

Since ticket creation via email is so easy, some users may create more tickets than they normally would. Perhaps instead of doing the research in a knowledge base or on a company intranet, users just send in the email to ask IT. I personally have done this because it was easy.

The email ticket creation feature is a convenient feature of a ticketing system. Users can easily send in one request or issue at a time to create a ticket. Users don’t have to stay on a phone trying to explain the issue while someone transcribes it into a ticket for them. However, with every feature there are down sides too. Users will inevitably email multiple items in at once and IT staff will overlook them. The email system or integration will go down. Users will create tickets via email with very generic requests like ‘Internet is slow’.

Does a feature like ticket creation via email improve user experience? Does the benefit to enable such a feature outweigh the cost to set it up and maintain it? Can you train users to only send in one issue per ticket.


I can't say I've seen the multiple issues in one email problem myself but we find that a lot of times when users create tickets through emails, they don't really know what they are asking for or they don't know how to use the correct terminology and our helpdesk people have to call them and clarify before anything can be done.

It's time consuming for the helpdesk and really not a convenience for the end user at that point.

Level 17

The only way to train users, is to guide them. Even then, some have their own expectations and won't take the guidance you may be trying to give.

Either to a resolution or how to properly document or request something to make sure it gets done as needed/wanted.

Regardless of how the ticket comes in, there must be more information if you get a vague request. So someone will have to call... Service Desk / Ticket Pusher(team lead from SD/HD) / Ticket Pusher from Next Dept. / Tech providing service or Fix ...... and so on.  SO at what instance do you choose to kill the gears by throwing a cog in. Every attempt to call and get more information is an attempt to create the perfect environment for the tech to show up provide the perfect most instantaneous service/fix and keep the user happy. If the user isn't compliant then you spend time aggravating them and yourself only to not have any relevant information for your tech providing service. The hope is, and if you have good one's; the tech shows up with all tools in hand and can fix anything quickly. But reality is sometimes the request is convoluted or misunderstood - so different help/service is needed. Or maybe a reprogramming. either way... if you can't match the information first you send the tech into an unknowing situation and the user may still end up not too happy. Tricky thing training your users can be, even in just using the service desk.

My favorite - they get an email when a service request is closed. The USER must mark this complete. So they click it, opens the email and THEY HIT SEND.... then we see a new ticket, new # and all; with the subject : RE: Ticket #123456 NOT COMPLETED ... ... ... smh, they reviewed it before telling us it was complete.

So, as the world turns; we provide the service that ensures our customers the best days of OUR lives.

Level 13

Whether auto-created from an email or created by a help-desk person receiving an email, I've seen numerous instances where the ticket contains something that the user thought was important (but really wasn't) and nothing that is truly relevant.  In both cases I think the root issue is that there is no interview process to glean what the issue is and collect the required data.

Unfortunately, even when a help-desk person is creating a ticket via voice there are too many instances where there is no effective interview process collecting the data and the results are the same.

Level 11

Emailing in lends itself to not only laziness from the end user, but the end user it typically ignorant of what information may be needed to begin work on the issue. As for calling into the Helpdesk, that really depends on the agent taking the call. I have seen everything from those that create and punt to agents that truly try to help resolve the issue for the user.

Also, some Helpdesk policies may not allow for proper time to interview the user, via phone, to get the information needed. This is especially true when agents are measured on length of the calls. But that is another issue in itself.

Level 11

In a TAC presentation this week at Cisco's Geekfest, they had a bullet point that you should only open one issue per case. Cisco's end users are typically ones that are technical and already in IT. They should already _know_ to open one issue per case, however their web site ticket creation makes it very easy to put multiple issues in a single case.

If you get a ticket with multiple issues, do you open separate tickets on the user's behalf for the other issues and use that opportunity to re-enforce the one issue per ticket?

I have had to work on issues that I was the third or fourth person that had worked with the user on the issue. It's no fun to get one of those cases. I would keep the case and pull in other teams as necessary.

Level 17

Documentation is the key - either manage all in one ticket - and that is the crux of your one ticket per case... but what is a case. One per call or email/ticket opened. One per Node. TAC case is going to be different from a case or ticket created from a service desk call. The different scenario may dictate the difference.... and back to the point of documentation - if you document then whoever gets the ticket next can actually help. If the case gets split, each ticket should be created with reference back to the first ticket in each new one - and a list of all sub tickets within the master. A (1 of 5) is always a good addition to the title. And if your Service Management application can manage the parent/child tickets it makes it all that much easier.

I think Cisco's assessment of 1 ticket per case is an over simplification of the matter. Any given situation of a support case should be subsequent to the idea's of common sense and proper documentation. Anything short of this is a failure in proper service to the customer.

Level 11

Some support organizations are motivated to create more tickets because each ticket equates to additional revenue.

About the Author
I am a network and UC engineer for a mainly Cisco reseller. I have worked in the networking industry for about 14 years and started as a network administrator for a small CLEC (carrier) where I did it all in IT and worked on the carrier network. After the CLEC, I went to work for a large healthcare organization in the Houston area and stayed with them for about three and a half years. Now I work for a reseller in the professional services part of the organization. I am currently studying for the CCIE in Routing and Switching lab. You can find me on the Twitter @twidfeki or I blog on Packet Pushers and