Prevent this: 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 what errors and warnings the user most often sees. Which, in particular, allows you to catch and fix problems that are difficult to reproduce on a command, such as timeouts or abuse of the Cancel button. In the same article, we will talk about how to convey to the user also a solution to the problem before he contacts technical support - good, for this we need very little: the existing message registry, knowledge base and one small change in the GUI.

Point one: we are finalizing the message registry

Participants: analyst, chief knowledge base.

Suppose that we built the message registry the previous time, and now all of our APP_ERR and APP_WARN are arranged in orderly rows in Excel. For each of the messages we generate a link of the form yourdomain.com/app_err_1 and beyond. 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 existing articles written on the basis of technical support calls. You will have to think about the rest, but, as a rule, there is something to say for each warning or error.

So, another column is added to the list of posts with brief descriptions of the context and our brand new links: links to relevant articles.

Point Two: Implementation

Participants: analyst, product programmer, head of the web server.

Time to put both sets of links into action. 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, under which there are no real pages on the server.

Why are we doing this

It is unlikely that any of the users will decide to have fun reading articles from the knowledge base just to take something on a winter evening. As a rule, technical documentation comes into play when something has already happened or is already incomprehensible. Providing a link to the article directly in the context of what happened, we help a person understand what is happening without unnecessary efforts 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 of binding to the GUI - to assemblies, releases, localizations, and other slow things. It is much easier to have a set of static links in the interface, under which any necessary article is dynamically attached.

The same system is great for emergency notifications. If something in the program went wrong, and a million users in the world receive error number 125 daily from you, with one command on the web server you put a fresh article with repair instructions for yourdomain.com/app_err_125, and technical support sighs with relief. When the problem has exhausted itself, another command on the web server returns its familiar main article to the link.

And further

The use of such a system implies a rather close monitoring 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 put gloss in every possible way. But the same system helps to do this. Almost all technical support programs allow you to associate articles from knowledge bases 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 tech support at all: didn’t notice the link? could not apply the described solution? didn't it work? - and take action right there.

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, as well as make many useful conclusions for themselves.