How knowledge base automation works for technical support for MOS.ru users
Today I want to talk about technical support, or rather about the subtleties that ensure its work. We have recently completed a project on organizing a knowledge base that helps to carry out its work for the technical support of the official portal of the Mayor of Moscow, the My Moscow application and other electronic services of the Moscow Government. The automation results indicate that a similar approach may be useful for other projects, and in this post I will talk about the distribution of roles and processes in the created information system. Those interested will find under the cut a detailed story about how the STP (technical support service) knowledge base of services for Muscovites MOS.ru works. And I will be glad to any feedback, opinions and, of course, suggestions on how you can further improve the work of maintaining such a knowledge base.
Technical support is good. It makes everyone angry (and me too) when it is impossible to get an answer from the employees of any service. It seems that they left to look for the answer in the file – the same as in the picture above. But in reality, the problem is usually a lack of free hands. Each additional technical support engineer requires an additional salary. And companies, for obvious reasons, are constantly striving to optimize the number of operators, use artificial intelligence, and somehow bypass the stage of long-term training for employees of such departments.
One of the fairly effective methods of such optimization, in which the user service does not suffer, is the formation of a knowledge base (KB), which is necessarily up-to-date, convenient and constantly self-improving. With this approach, one can hope to improve the quality of service and increase the efficiency of technical support and contact centers. This is the base we created for the mos.ru portal and the My Moscow application. Considering that today the tried and tested scheme solves the tasks assigned to it, it is possible that some practices will be useful for organizing your STP.
The database must have a structure
To avoid confusion when working with knowledge base, all articles are divided into blocks depending on the direction in which the user’s question comes.
The articles in block A (for the Answers.Mail and Yandex.Que services) are created to process general and specific questions related to information on the mos.ru portal, obtaining government services and documents, and the activities of the OIV. For example, the answer to the question “How to obtain Russian citizenship?” will be found just in block A.
Articles in block B are created for questions coming directly to the STP. They are related to the operation of the services of the mos.ru portal, the content on the portal, the activities of the OIV, the operation of the My Moscow mobile application, and the receipt of government services and documents. For example, a typical question in this block is: “What should I do if I cannot log in to the application?”.
Thus, we maintain one database, but the information in it is not boiled in “one pot”, but is clearly divided. The General Inquiry Officer will not receive technical answers and vice versa.
Sections make it easy to find
Practice has shown that division by subject (classifier) is a very useful thing. For a convenient distribution of questions and the subsequent finding of articles on them, we use numerical values for each section. For example, knowledge about fines for personal transport is coded 2.143.1.n, where n is the ordinal number of the article in this section (1, 2, 3, etc.).
It is most convenient to customize knowledge base classifiers in accordance with the already accepted classification of questions in the STP. Thus, any service can connect to the system, set convenient classification trees for its system, which greatly facilitates the search for articles.
In order for technical support to work better, in addition to the classifier of the name and number in each article, four types of answers were provided, which differ in some features, mainly stylistic:
Official… Used by STP staff responding by email. The most complete answer that answers the question posed, provides workarounds, and links to instructions and contact information.
Verbal. Used by STP staff answering the phone. Agree, it is very inconvenient to pronounce a link in a voice, therefore, for a verbal response, “voice navigation” is used – go there, click there. All redundant information (in comparison with the official answer) is cut off.
Chat. The shortest answer, containing the most concise information and links to instructions. In this case, the main thing is that the user gets an answer to his question.
Bot (automatic response). This is almost exactly the same answer as for the chat, but it is not used by the operator, but by the robot answering the first questions of users. To determine the topic, the bot uses model questions – this is another field that it was decided to add to the information system. In number model questions those user requests (real or hypothetical) that can be asked without knowing the whole internal cuisine are received. The more such questions, the more a specially trained algorithm has to find the corresponding article by number, title or keywords.
Article statuses or system life cycle
In the process of work, we made sure that it is useful for articles to have several statuses that allow you to hide underprepared knowledge, archive obsolete ones, and also affect the ability to edit. Here are some useful examples of statuses:
In preparation – this is the status of “article birth”. It is not visible to the staff of the STP and it can be edited, supplemented, in fact, you can mold anything you want out of it.
Checked by the Coordinator – the next step in creation, the article is still not visible and can be changed. But only the Coordinator can translate it further (or back). The status is suitable for more mature articles.
On approval – this status is not much different from the previous one from the point of view of users, but the person in charge can already approve the article, and it will fall into the active part of the knowledge base.
Actual / Published – the article is seen by STP operators, and changes can only be made by transferring to the status “In preparation”
Obsolete / archived – the article is not visible and cannot be changed. She will not appear in even searches. It can be returned for preparation if the person in charge decides to update the information.
How do articles appear in the database?
In order to supplement the knowledge base, it is necessary to start the process of adding new articles. There may be different reasons and different scenarios for this. But on the mos.ru project, we have defined two main triggers for creating articles:
New functionality has been added or there have been changes that users are likely to have questions about.
For example, when the launch of a car raffle was expected after vaccination, by the time of release, answers were prepared and entered in the database, which allowed call center and STP operators to successfully answer questions on the first day of the raffle (and even a little earlier). If the operators had compiled them themselves, it could take more than an hour to process one call. The use of AIS UZ has reduced the processing time to a few minutes.
Here, too, many typical situations arise. With the beginning of the school year, we began to receive requests from parents about problems with displaying children in the MES electronic diary. An analysis of incoming requests showed that most parents do not fully understand the process of adding a child to the system (this is done through the school), therefore knowledgedescribing the application process and information required by the STP to solve the problem (if any).
Thus, it was possible to close more than 40% of requests at once, as well as to establish communication STP / User and speed up the process of processing requests on a given topic.
Employee roles in the system
To avoid chaos in the knowledge base, creating, editing, deleting and publishing articles should depend on the user’s role. On our project, there were 4 such roles (although, probably, there may be other options. If yours is different, tell us in the comments):
Operator – can only create articles (fill in all fields);
Editor – can create articles, make changes to the prepared knowledge and transfer to the Coordinator;
Coordinator – can do much more: change article statuses, make changes, and so on. The only thing he cannot do is publish the article. This is done …
Approver – he can do EVERYTHING. Ave!
The schemes of work are as follows:
Simplified (Editor and Approver)
Advanced (Operator, Editor, Coordinator, Approver)
Maintaining the relevance of information in the knowledge base
When working with any knowledge base, it is important to understand that it is imperative to monitor the relevance. If this is not done, then the whole meaning of the project is lost.
If we talk about the project, on the subject of which we are considering all this today, then the relevance of knowledge was even more important, since it was necessary to answer on behalf of the Mayor and the Moscow Government (at least in the opinion of users). And therefore, any discrepancy in the information in the answer is fraught with not only fair anger of the user, but also legal consequences.
How to prevent the loss of relevance of knowledge? To do this, we carry out several routine maintenance to prevent errors:
Quarterly. Every three months, the entire knowledge base is checked, each article. To carry out a large amount of work, senior specialists, operators, and so on are involved.
Weekly. Mos.ru editors send changes in instructions for a week. Our specialist checks the articles available on the topic.
By events. For any release of a new functionality (or update of an existing one), knowledge is checked on the corresponding functionality.
Daily. STP operators monitor what they answer and what answers the system offers them. In case of discrepancy, they can correct the information on their own and report it to the Coordinator. After verification, the edited information is published.
Interaction with other STP
Sometimes access to the knowledge base is needed by several STPs. This means that operators need to be given appropriate access. And different employees should see all the blocks at once or only “their” ones.
But such an organization of work has its pros and cons. For example, in order to maintain a common base, it is necessary to adhere to a single format and style of presentation of articles. Verification of knowledge takes additional resources, but it becomes possible to form a truly unified database.
Another interesting point is that sometimes out-of-date information is lost in the process of working on an article for a large number of people. But colleagues from adjacent STFs find “stuck” articles, bumping into them in the search. Such mutual assistance turned out to be very useful, and to speed up the updating process, we introduced a system for routing calls across our knowledge base blocks. Thanks to this, the operator-colleague or his boss can inform us about an error in the article or about not completed developments, simply by writing to e-mail. We, in turn, can do the same.
Work continues
In general, work with knowledge bases and their automation tools probably never ends. All the time something needs to be corrected, supplemented and improved. But the scheme that I talked about in this post already allows you to optimize the work of technical support. And further work on the automation of processes should help to unify the knowledge base for the entire DIT of the Moscow Government, and also help to form the best practices for working with user requests.
It will be great if you share your experience and interesting situations in working with knowledge bases and technical support services in your own or someone else’s company (for example, at the customer’s). Maybe our know-how will help you, and ours will help us to make work with knowledge even more effective.
