📜 ⬆️ ⬇️

Tips for working with the ticket system

-

The previous article about the organization of the work of our technical support service has been the subject of lively discussion. Many readers have expressed doubts that effective communication between support engineers and users can be carried out exclusively through the ticket system. Our practice shows that this is quite possible under certain conditions. To prevent new customers from having doubts and making communication even more efficient and productive, we decided to publish a set of tips for working with the ticket system.

As we have already written , the main channel of interaction between customers and technical support service engineers is a ticket system . With it, clients can:

Its undoubted advantages are as follows:

Our support engineers deal with dozens of tickets every day. And a quick solution to a problem depends a lot on how these tickets are composed. At what points in the preparation of the ticket should pay special attention?

The first thing that technical support engineers see is the ticket header. It should be brief, succinct, and should reflect the essence of the problem being described as much as possible. If the ticket is about server malfunctions, then in the header it is desirable to indicate its number.
Here are some examples of correct and incorrect headers:
IncorrectlyCorrectly
PROBLEMS WITH SERVER !!!!Network availability issues with the csXXXX server
Short and accurate headlines will help later and you better navigate your own tickets and find the right one among them.
')
The more precisely, in more detail and more logical the problem is described, the faster our specialists will be able to solve it. It is desirable that the description was supported by specific examples. If, for example, you write about problems with network accessibility, then attach to the ticket replies to ping requests and trace data (they can be obtained using both standard traceroute / tracert utilities and the more specialized utility MTR).

Quite often one has to come across descriptions of this kind:
Good evening.
My server is not working again. What happened?

This kind of wording can give technical support staff a lot of trouble: they may take a long time to figure out exactly what happened to you.

A good description should be made differently. For example:
Good morning,
Yesterday, on the cloud server, I changed the IP address from (...) to (...). I checked all the settings several times - everything seems to be right, but for some reason the new address does not work.
(The description also includes the results of the ping request).

If you suspect a problem with a hard disk, also try to provide a detailed description of the problem. Sometimes our support engineers receive applications like:
I lost my hard drive.

Such a request can hardly be called clear: it is not at all clear on what grounds the conclusion about the “death” of the hard disk was made. Statements of this kind are best supported by examples:
On the dedicated server csXXXX suspected malfunction of the hard disk. SMART table data: (....)

SMART (self-monitoring, analysis and reporting technology) is a technology that allows you to assess the status of a hard disk using internal self-diagnostic equipment, as well as predict the time of its failure. You can read more about SMART-tables and their interpretations, for example, here (in Russian), as well as here (in English).

If you assume that there are memory problems on your server, try attaching the conclusions of memory diagnostics utilities that will help determine which memory strip is faulty.

If you have any problems working with our control panel or with settings (for example, monitoring settings, firewall, cloud storage), we recommend attaching screenshots of settings pages to the ticket - this will help you diagnose and correct errors faster.

All actions that are performed with the server (including sudden reboots and other unforeseen moments) are reflected in the system logs. Excerpts from the system logs can also be (and in some cases even necessary) attached to tickets. Even if you can not decipher the system logs, our specialists will help and give specific recommendations to solve the problem. On Linux systems, logs are usually stored in the / var / log directory, on Windows, in the% windir% \ logs \ cbs \ cbs.log directory.

Some errors occur only when working with certain browsers. In this case, you need to specify the version of the browser used and attach the appropriate screenshot.

Avoid too short descriptions: technical support staff will be forced to ask you additional questions, and finding out the details will take a lot of time, which could be spent directly on fixing problems.

Another important rule is formulated as follows: One problem - one ticket. Create a separate ticket for each of your faults - this will help to better coordinate the work of support engineers and speed up the consideration of the problem. In addition, following this rule will also help you to quickly search by ticket.

If a problem that you have already reported and which has been solved, suddenly manifested itself again, do not create a new ticket, but write about it in the one that was dedicated to this problem earlier.

Close the ticket only when the problem is finally solved. Even if you didn’t write anything, closing the ticket for technical support engineers is a signal telling you that nothing else bothers you.

Source: https://habr.com/ru/post/193634/


All Articles