| Dec 21, 2009
While performing regular reviews of Telerik support communication, I come upon the following question which appears to be asked every so often:
'What support channel should I be using for my development questions?'
As this is something that may bother each of us at some point, I decided to uncover the veil and provide some direction as well as a short list of pros and cons of each option.
The two main routes you can take to get assistance from the Telerik Support Staff are pretty well-known: posting an inquiry in the Telerik public forum or creating a support ticket. It is up to you to decide which of these two paths to choose and that is why I would like to underline that the purpose of the next paragraphs is to provide general guidelines instead of influencing directly your choice.
The forum posts have 72 hours response time and this is the place where you can get answers from the Telerik Support Staff as well as from Telerik community members. The discussions there are public and can be browsed/searched by other site visitors. In addition, you can use the support search facilities on telerik.com to find answers to your questions quickly and without the need to wait until someone responds to them.
Although around 95% of the forum posts are handled by Telerikers, the response time in the forums is not 100% guaranteed. General instructions about how to use the Telerik forums can be found here.
*Note: People answering questions in the forums (with replies marked as answers) can earn Telerik points or MVP tokens which can be used for future discounts when upgrading/purchasing our controls or gain Telerik MVP status respectively. This stimulates developers to help each-other and thus becomes a 'natural extension' of the Telerik support service.
On the other hand, the support tickets are the private channel which you can use to communicate with Telerik (for support-related questions). The response time in them depends on the support package you received with your purchase. Furthermore, the support tickets are considered with higher priority over the forum threads and allow code file attachments as opposed to the forums which permit image attachments only.
There are also several mandatory fields you have to fill in when creating a support ticket (after choosing a particular Telerik product) and specifying those correctly can be very important for replicating your case and tracking down a particular issue. They are present in 'Step1: Software you are using' on the Support Tickets-> Write Support Ticket page. Another important part of your message is the description itself - it should provide all the necessary details and outline your main configuration settings. Including code snippets, screenshots, videos, stack trace of exceptions or stand-alone sample project can speed up the resolution (their effectiveness may vary depending on the actual case). Those are entered in 'Step2: Describe your question' on the same page specified above.
Below are some extra 'in-house' tips I would like to share that are quite useful and turn out to be real time-savers in our daily support communication:
- Do not include Telerik controls assemblies in sample projects attached to tickets - instead select the exact version of the respective dlls from the dropdown when starting the support thread. This will spare 5 to 6MB being uploaded/downloaded afterwards. For instance, see how to check the exact version of Telerik.Web.UI.dll here.
- Screenshots - avoid using .bmp format, instead convert the images to .png or .jpeg to reduce their size
- Do not reply to automated emails which notify that your support ticket/forum post has been answered. Post replies in support tickets/forum threads only. Use merely those two support channels for technical questions (instead of writing to email@example.com or firstname.lastname@example.org) - thus your support history can be easily tracked and your questions will reach the relevant support personnel faster.
- You may share video content using Jing to avoid uploading videos in a support ticket.
- Strip down as much custom code from sample projects as possible and remove any unnecessary/unrelated dependencies. In case you work under DotNetNuke, Sharepoint or other custom environment, check whether there are any differences in the code execution inside and outside of that environment. When you are not able to share the data source due to some reason (db policies, NDA, etc.), consider generating a dummy/sample data source for testing purposes. This, for example, can be manually generated asp DataTable in case your control is data-bound.
Once again, I stress on the fact that it is your decision whether you will use the private support system or the public forums to share this information and get an answer/feedback from us. Of course, the fastest means to find answers/solutions is to dive into the vast support resources available on our site following the tips from these sources:
I hope you will find all those helpful.