As part of my job with Maintainn, I am in charge of our Helpscout queue. Helpscout is where we deal with support tickets and interact with our customers. When you file a new ticket through your Maintainn Dashboard widget, it goes directly into our queue for review and response. Some tickets are reporting issues that one of our customers is seeing with their website, and some are outlining ideas of where they’d like to take their website and what type of development they’d like to see done. It varies every day, with every ticket.
Another way that the tickets vary is how much (or how little) information they provide. If there is not much there, it can make it more difficult to determine what the client has in mind and what needs to be done, and can prolong the dialogue (and put off the work!) as I try to figure out what they are really asking for.
A Ticket Without Enough Information
My site is not working. Help me!
Unless it’s very obviously broken, like a white screen or no styles are being loaded, then this type of opening ticket is not very helpful. I am not going to know how it is broken. I am going to either start from the very beginning of a general debug list or immediately respond back with questions about what you are experiencing. I will also be asking where I can see an example of what you are talking about, just so that I can get going on determining the issue(s).
A Slightly Improved Starting Point
Hello Maintainn Support! I have just finished writing up a new blog post and published it. When I went to see the result, the layout for the site was completely broken. Could you go see what is going on please?
This is a notably better opening ticket. It states what you were doing at the time you noticed there was something wrong with the website, and allows me to isolate my attention to certain locations of the website, specifically the post editor for the newly published blog post and its single post permalink. I will be able to track down what may be going on much faster with fewer questions.
An Ideal* Ticket
* there is no true ideal ticket, but we can get pretty close
Hello Maintainn Support! I have just finished writing up a new blog post and published it. When I went to see the result, the layout for the site was completely broken. For this post, I decided I wanted to create a gallery for the post based on an example I found online, and I think that may be part of the cause. Could you go see what is going on please?
Like the better example above, I still know where to check (in this case, the editor and the single post permalink), but it also isolates which part of the new post to check.
With that information, I can determine that an extra closing ‘div’ tag was somehow generated and inserted, and that broke the layout for the rest of the page. I am then able to remove the offending tag and update the post, and everything is back in working order.
What are you trying to say, Michael?
The more information you are able to provide upfront, the quicker things are going to go, so whenever possible, provide as much detail as you can. It’ll help speed up determining and isolating the issue, so that we can get it resolved or, if it’s not a simple fix, begin a discussion about options that available to amend the issue.
When does this not apply?
There are definitely going to be cases where the thoughts above are not applicable. Not every ticket I see is outlining an issue being experienced. Sometimes it’s simply a request to update some content on the site, and other times its going to be a customer letting us know of some information ahead of time so that we are prepared and kept in the loop. Are those always going to need explicit details in the ticket? No, but when in doubt, providing some more is better than not, especially for content update requests.
Do you have any other questions about what to include with a support ticket? Shoot ’em at us in the comments!
