Prevent it: make life easier for the client and yourself at the same time

So, in the previous article we started working with messages in the product, which allows you to quickly and accurately find out which errors and warnings the user most often sees. That, in particular, allows you to catch and fix problems that are difficult to reproduce on command, such as timeouts or abuse of the Cancel button. In the same article we will talk about how to convey to the user a solution to the problem before he turns to technical support - good, for this we need very little: the existing registry of messages, the knowledge base and one small change in the GUI.

Point one: we are updating the message registry

Participants: analyst, the main knowledge base.

Suppose that we have built the register of messages the previous time, and now all our APP_ERR and APP_WARN are arranged in fine rows in Excel. To each of the messages we generate a link of the form yourdomain.com/app_err_1 and on. Then we catch the person responsible for the knowledge base and ask what he can offer us. As the practice of our company has shown, approximately 70% of messages are closed by already existing articles written on the materials of requests for technical support. We will have to think about the rest, but, as a rule, for each warning or error there is finally something to say.

So, one more column is added to the list of messages with brief descriptions of the context and our new links: links to relevant articles.
')

Point two: implementation

Participants: analyst, product programmer, the main web server.

Time to start up both sets of links. The one of them, which is yourdomain.com/app_err_1, is inserted into the actual messages from the product - under the words “Read more”, for example, or “Help me fix the problem”. The second set - real links to articles - will work as a redirect for the first one, under which there are no real pages on the server.

Why do we do it

It is unlikely that someone from the users will decide to have fun reading the articles from the knowledge base just to take a winter evening with something. As a rule, technical documentation goes into action when something has already happened or is already incomprehensible. By providing a link to the article directly in the context of what happened, we help the person to understand what is happening without much effort and search first for the knowledge base, and then for the knowledge base. Moreover, choosing an article for each specific message, we can direct the user to the optimal solution from the existing ones.

Why do we do it like this

A system with two links and a redirect between them completely relieves us from being tied to a GUI — to builds, releases, localizations, and other slow things. It is much easier to have a set of static links in the interface, under which any desired article is dynamically attached.

The same system is great for emergency notification. If something went wrong in the program, and the million users in the world every day receive an error number 125 from you, with one command on the web server you put a fresh article with a repair instruction under yourdomain.com/app_err_125, and tech support sighs with relief. When the problem is exhausted, another command on the web server returns the link to its usual main article.

And further

The use of such a system implies a rather close observation of the articles involved in it: since they automatically turn into the most visited, it would be better to keep them in good shape, update, polish and in every possible way polish. But the same system helps to do this. Almost all programs for technical support allow you to associate articles from the knowledge base with applications from users. After reviewing the applications associated with a particular article, you can understand how and why in this situation the user came to technical support in general: did not notice the link? could not apply the solution described? didn't it work? - and take action immediately.

Thus, at the cost of a small one-time effort, all participants in the process, from programmers to users, can save a lot of time, money and nerves, and also draw many useful conclusions for themselves.