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

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.

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

  • 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.

  • 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.

  • 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.

  • 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.

Thwack - Symbolize TM, R, and C