What is "actionable information" for problem reporting?

Examples of inactionable information

When looking at a field problem, we are often fed with inactionable information, meaning that we are told the fact that a field problem has occurred, but there isn't an action we can do about it.

Let us give a few examples of inactionable information:

• "Your software crashes very often! How to stop the crash and make it work normally?"
• "It looks sometimes audio is not recorded correctly, and happens randomly. How can I fix it?"
• "I'm experiencing Out Of Memory error and crash! Please fix it ASAP!"
• "I'm using an IP camera with your software and I can't see video!"

The information given in these examples, though describing customer unsatisfaction vividly, does not provide us a clue for anything that is actionable. We are pretty much blind on these issues in the same way you are. For us to be able to help you, you need to at least provide some "actionable information".

Guidelines

Following are some guidelines for this kind of information:

1. It should contain a list of possible causes for us to have a direction, in order to further investigate.
2. It should provide some clues that allow us to try to recreate the exact problem in the lab.
3. You can directly suggest what actions we can do about the issue.
4. You can tell us what you have done to the system that you are not sure that is correct. Sometimes you might have inadvertently tripped by some internal system conflict.

Two sides of the story

A good piece of actionable information will have two sides of the story, the good and the bad. By analyzing and comparing the good and the bad often reveals some important clues among the unknowns.

A common error made by many users is that they only report problems, but forget to report what was before the problem or what is aside the problem. Let us give a few examples:

• A system can be running fine for 6 months and suddenly stopped working. Then the user just reports the system stopped working without mentioning it's been running 6 months fine. By analyzing what was done right before the system stopped working could reveal vital clues of any possible actions.
• A user could have installed 3 systems, and out of the 3, 2 is fine, and 1 has problem. Then the user just reports the 1 that has problem without mentioning the other 2 is fine. By comparing the three systems could reveal vital clues of any possible actions.

Resource issue

Please be noted, that even when actionable information is provided, it doesn't necessarily mean the problem will be solved. It merely present a possibility that the problem could be solved through some actions, meaning that without it, it's not possible to do any actions, let alone solving any problems.

When actionable information is provided, there is still a matter of "how much resources" are involved, in order to perform that action. Consequently, if the information provided is too vague, it could take impossible or unreasonable amount of resources to perform the action against the problem you reported. This is where you explain to our sales department how to justify the effort we put into resolving your issue. The more business information you provide, the more quickly we can decide how to schedule the task. For more information about task scheduling, please review: What are the task scheduling issue?

See also

• Why can't you use TeamViewer to assist me remotely?