How can I support support better?

Question

With the best will in the world, whatever software that you (and I) write will have some kind of flaw.

What can I do as a developer to simplify the work of the support department (first line, up to the third line and development) for diagnosing, circumventing and resolving problems that the user encounters.

Notes

• I expect answers that are mostly technical in nature, but I expect other answers to exist.
• "Do not issue errors in your software" is a good answer, but I already know that.

Answer 1

Specifications:

• In the error dialog for the desktop application, add a button that opens both the email and attaches the stack and trace, including system properties.
• On the error screen in webapp, tell the timestamp, including nano-seconds and the error code, pid, etc., so that you can look for server logs.
• Allow dynamic changes to log levels at run time. Having a server reboot is a pain for this.
• Record as much information as possible about the environment in which you are running (possibly at startup).

Non-technical:

• Provide a section of known issues in the documentation. If this is a web page, then this corresponds to the trigger list of errors from your error tracker.
• Depending on your audience, you will find some kind of interface for tracking issues.
• Again, depending on the audience, provide a forum for users to help each other.
• Usability solves problems before they become a problem. Reasonable, not scary error messages often allow the user to find a solution to their problem.

process:

• Keep track of your magazines. For a server-side product, regular log reviews will be a good early warning sign of upcoming issues. Make sure support knows when you think there are problems.
• allow time to write tools for the support department. They can start as debugging tools for developers, become a window into the internal state of an application for support, and even become tools for future releases.
• Allow developers time for support listen to customers on the support phone, go to the site, etc. Make sure developers are not allowed to promise anything. Deal with the developer after this - there may be ideas.
• where necessary, provide user training. Impedance mismatch may cause the user to perceive software problems rather than the mental model of the user software.

Answer 2

• Record as much information as possible about the environment in which you are running (possibly at startup).

• Give exceptions to meaningful names and messages. They can only appear in the stack trace, but it is still incredibly useful.

• Take time to write tools for the support group. They will almost certainly have needs beyond your users or developers.

• Sit with a support group during the afternoon to see what they should do. Watch for any repetitive tasks - they may not even consciously notice a repetition.

• Meet with a support group regularly - make sure they never get offended by you.

Answer 3

If you have at least part of your application running on your server, make sure you keep track of error logs.

When we first implemented the daily script, which greps for ERROR / Exception / FATAL and sends the results by email, I was surprised how many problems (mostly tiny) we had not noticed before.

This will help in the fact that you notice some problems on your own before they report support for the team.

Answer 4

Make sure your application can be deployed with automatic updates. One of the main problems of the support group is upgrading clients to the latest and best so that they can use bug fixes, new features, etc. If the upgrade process is seamless, stress can be relieved of the support group.

Answer 5

• Provide a mechanism to capture what the user was doing when the problem occurred, the ability to log or trace, which can help provide you and your colleagues with data (which exception was selected, stack trace, program status, user did, etc.), so you can recreate the problem.

• If you haven’t yet included automatic developer testing in your product development, think about it.

Answer 6

Like a combination of jamesh answers, we do it for web applications

• Check the "Report an error" link so that users can report errors even if they do not generate error screens.
• This link opens a small dialog box, which, in turn, sends the processor via Ajax to the server.
• The processor associates the sending with the script message and its PID so that we can find the correct log files (we organize our script / pid), and then sends an email to our error tracking system.

Answer 7

Provide a document about problems with information Conduct training on the program so that they know how it should work Provide simple short lines of the log that they will understand or create error codes with the corresponding document that describes the error

Answer 8

Some thoughts:

• Do your best to immediately confirm user input.
• Check for errors or exceptions as early as possible. It’s easier to track and fix the problem immediately after it occurs, before it generates “ricochet” effects.

• If possible, describe how to fix the problem in the error message. The user is not interested in what went wrong, only how to continue working:

  BAD: Floating point exception in vogon.c line 42
  BETTER: Enter a dollar amount greater than 0.

• If you cannot offer a fix, tell the user what to do (or not do) before contacting technical support, for example: "Click" Help ">" About the program to find the version / license number ", or" Please leave this error message on the screen. "
• Talk to your support staff. Ask about common problems and pets. Ask them to answer this question!
• If you have a website in the support section, provide a hyperlink or URL in the error message.
• Indicates whether an error occurs due to a temporary or permanent condition, so the user will know whether to try again.
• Put your mobile number on each error message and identify yourself as a developer.

Well, the last element is probably impractical, but doesn't it encourage better coding techniques?

Answer 9

Have a mindset to improve things. Whenever you correct something, ask:

• How to avoid a similar problem in the future?

Then try to find a way to solve this problem.