How to Write a Support Ticket That Gets a Prompt Response

These tips—based on years of experience on both ends of the support ticket—can help you get precisely what you need from software customer support.

In this post, I’ll offer some suggestions for improving the performance of your support tickets—so you can get the response you need as quickly as possible.

I’ll draw from 15 years of experience on the support side, primarily responding to tickets for the SaaS www.advocati.net that lawyers would open, plus my experience answering some C# Corner forum tickets.

On top of that, I am an active product user, and I regularly engage with support teams. For instance, I’ve been using Progress products for 10 years, and part of the reason I continue to use Telerik and Kendo UI products is that the Progress support team is exceptional. Even if the ticket is a user error and not the fault of the product, the support team helps get me pointed in the right direction.

With experience on both sides—as a ticket submitter and a ticket responder—I’ll share the most important lessons I’ve learned for a better and faster resolution anytime you’re opening a support ticket. No matter how incredible the support team is, we can get even faster answers if we help them help us.

Bing image

Put Yourself in Someone Else’s Shoes

This is my first tip. After I write something for support, I clear my mind and try to think like the person on the other side of the issue. And I ask myself:

• Is it clear enough to understand the issue?
• Can they solve the problem now that the code is complete and they have a big picture?
• Is there anything I am missing from the scene that could be important?

Be Clear About What You’d Like to Achieve

Sometimes, what we desire our code to do or what resolution we need to our problem is clear. Remember that the thing we need is evident in our mind, but it might not be so obvious to someone trying to help. Spell it out for clarity.

Sending the Solution

If there is a specific change the team could make to the software to benefit not just you but all users, suggest it! This will allow them to understand the problem from a different perspective.

I recently asked the support team to increase the maximum attachment size from 30 MB to 100 MB, which would allow you to clear the bin and obj folders as node_modules and send your entire solution zipped. Before the 100 MB limit, I submitted partitioned zip files in multiple tickets.

Don’t be afraid to send your source code as long as there is a confidentiality agreement in place (there is one with Progress software) so you know it will be appropriately handled. Some projects require a specific environment, such as database dependencies and/or VPNs, so the project will not run when the support team looks at it. However, the support team will better understand the overall picture when they can see more context.

Sending Some Files or Pieces of Code

This works great to show what you’re experiencing. Remember to leave checkpoints in the code like notations:

// Here not to that
// It should return XYZ
// How do I get the value from ItemX
// Problem [description]
// Start point here

These checkpoints will guide the support team in understanding your point of view better.

The Best Way to Have a Call with Support

Some products allow you to talk directly with the support team on a call. I have sometimes used support calls with Telerik DevCraft Ultimate.

The thing I recommend is to understand that the main point of a support call is not to solve the problem at that moment but to provide a clearer background of the issue, especially when it isn’t replicating on the support environment side.

Support teams usually have limited time to check out our problem. So when receiving the call, pay attention to this:

• Prepare your environment and run the application before the call.
• Have your code open in your IDE.
• Set a breakpoint that might be an excellent place to check the code.

This will help you make the best use of your call time, providing the best chance of prompt resolution.

When the Problem Can’t Be Solved

When no solution is yet available, or if we’re requesting a new behavior, most companies will have some sort of backlog for these. Progress creates a ticket in the Feedback Portal that allows other users to vote on the most desirable updates. The vote-winning suggestions will often be implemented in future release updates.

You can also suggest new features and argue for their importance. This is what happened to me with the RadOpenFileDialog. It replaced the default Microsoft FileDialog from WinForms, but the Telerik component’s keyboard behavior was incompatible with Microsoft, which I thought may confuse some end users. This was so important that the Progress team updated it in the next release, demonstrating Progress’s strong commitment to its customers.

If the support team informs you that your issue is a bug, you may be eligible to receive points for finding it. For instance, Telerik Points can earn you a discount on your next renewal.

Need More Insight?

For additional content, you can visit my C# Corner blog, where I have published some tips for posting in the forums.

If you are fluent in Portuguese and would like to converse with me, I’m available on my LinkedIn profile to assist you.