"Support," as much in this word ...

So, I continue the series of articles “from a sabbatical”, this time we will consider such “terrible” things as “product support”, “technical support”, “support service”, etc.

This article will not address the issues of team management, deployment of the application administration system and details of the work of the support department heads. The article is rather a kind of introduction to the issue of "support for IT products"

Where it all begins

So, traditionally, let's start with the basics. Let's try to answer the question:

What is a support service and what is it for?

Although the question sounds simple, the answer to it is not so easy to give. And the reason for this is far from the complexity of this area of ​​activity. The reason is that there is a small feature here - “support service”, as well as “support” in general, are not universal concepts. Their values ​​are very dependent on the specific situation we are considering. And in order to show this, I will give one very schematic example.
')
Suppose we have a bus manufacturer company in which there are “development and production” departments and a “maintenance service” department, which provides warranty service for the sold buses. There is also a second company - a consumer, who bought one of the buses to carry their employees along a certain route inside the campus / office area. So, in this particular example, we get the following picture:

The consumer company has:

• users are bus passengers
• "Support service" is the dispatcher, or reference, and the conductors in the bus itself,

which allow passengers to solve the arising difficulties.

And in the company - the manufacturer, we have:

• developers is a “development and production” department
• and also, “customer support” - in this case, this is already the “maintenance” department

It is obvious that an attempt to completely transfer the approaches to the organization of the work of the “support service”, adopted in one type of company, to a company of another type is, at a minimum, not a smart job, and often harmful.

But this is clearly seen in the example of buses, but, for some reason, it is not at all obvious in the case of IT.
Let's try to figure out a little more.

Formally, support services and software maintenance are located at the intersection of ITSM and CRM. And, as is usually the case, a few nannies have a child without supervision. At the same time, with the organization of the work of administrators, the issuance and maintenance of IT equipment - difficulties often do not arise. It turns out a certain paradox, it seems, both here and here - the IT sphere, and here and here quite competent employees and managers, but in one case everything basically works quite acceptable to itself, and in the other - how it goes. What is the difference? Why can we provide support for hardware, operating systems, web services, but at the same time with the support of business platforms such as accounting systems, data analysis systems, workflow, business process management, and others - often there are difficulties? What could be the snag?

Let us take another example, a little more approximate to our subject. So, we have a company that uses some kind of "standard" configuration of the accounting system (no matter what). Since the configuration is standard, the company does not have a staff of developers to make corrections and changes to the system used. It is quite obvious that users have all sorts of problems and questions with the use of this system. Users, these are people who are somewhat distant from IT (salespeople, accountants, bosses, etc.) and delve into the details of how it actually works inside, it’s not easy, and there’s just no time.

At this point, let's stop a little more. So, we have a pure company - a consumer. That is, the company itself does not produce the product that it uses, but buys it on the side. In this case, if there is no “support service”, then the end users themselves try to solve the problems that arise. As a result, a lot of time, nerves are lost, miracles begin with data, etc. In general, everything is as usual.

And the head of the newly organized “support service” asks himself two main questions:

- What is the purpose of the "help desk"? Who do they work for?
- What should be the ideal employee of this service?

With the answers should not be. This service is created to take over the work with the manufacturer / supplier and save the end users from unnecessary technical manipulations. That is, the customer (consumer) of the results of the "support service" are end users.

We are going further, but how to evaluate the work of the staff of this service? The speed of solving the problem? Rather not, than yes, because they can not, and should not climb inside the configuration or platform of the accounting system. Therefore, we exaggerate a little, and it turns out that their tasks are also quite obvious - to make sure that:

• when performing recommended and / or available actions, the system does not function as expected;
• the famous "tambourine dances" do not help;
• the problem description has been translated from the users language to the terms used by the system used;
• all necessary information is collected and transferred to the manufacturer / supplier as soon as possible;
• the user was able to solve their problems in a different way, if possible.

The last point is unfortunately still rare, but it is highly desirable in real life.

So, for the moment, we are generally moving in the right direction. About this we are told books from ITIL, many read articles, and the logic also confirms this. And in fact, there is no revelation here. But they will be next.

So, our manager everything turned out well, everyone is happy, and already the company - the manufacturer of this accounting system itself, invited him / her to set up their "support service". And here miracles begin. At the new location, he / she again asks the same questions as before:

- What is the purpose of the "help desk"? Who do they work for?
- What should be the ideal employee of this service?

And in this case, the answers will already be very different from what we saw earlier. So, we are dealing with a company - manufacturer. That is, the company has a staff of developers who come up with and implement their ideas in a certain product, which is used by other companies. And it turns out that in the absence of a "support service", it is the developers who are forced to distract from their main work and engage in trivial (in their opinion) problems, at a time when "the universe needs an ideal accounting system." In other words, in this case, the customer of the “support services” services is no longer users, but developers. And they no longer need to demand that an employee of the department collect something and give it to them; it is already necessary that this service be able to solve most of the problems on its own . Do you understand the difference?

It turns out that with a similar name, and it seems that, as a single function, the departments have completely different requirements for their work. That is, we have two poles, two pure and completely opposite approaches to organizing the work of the “support service”. Unfortunately, very few people see this difference, and of those who see, it is often ignored.

After all, the same ITIL does not indicate this difference, and the vast majority of interpretations are based precisely on the approach for consumer companies. For this reason, I prefer the “helpdesk” option for manufacturing companies to call “technical support” to distinguish it from “customer support service”, “software maintenance department” and other “service desk” in consumer companies.
Summarizing, we get the following picture:

	Customer Service	Technical support service
Customer (consumer of department services)	End users	Development / Testing Department
Employee Tasks	understand the problem; ensure that when performing the recommended and / or available actions, the system does not function as expected; make sure that the known methods of solving such problems / problems do not help; translate the description of the problem from the users language, into the language used by the system; make sure that all the necessary information has been collected and transferred to the manufacturer as soon as possible; to ensure that the user is able to solve their problems as soon as possible, even in a different way, if possible.	understand the problem; identify the conditions of appearance / reproduction of the problem; find possible solutions to the problem without making changes to the system and / or with minimal involvement of developers; to verify whether known / found solutions to such problems / problems are satisfactory; translate the problem description into the language of system developers / architects; make sure that the design / architects understood the described problem correctly.
Employee Requirements	know the subject area well and speak the same language with users; well know the terminology and functionality of the system; be psychologically stable and friendly; do not be afraid to ask questions; be able to explain;	well know the terminology and functionality of the system; it is desirable to have an idea about the domain / business of customers; have experience and knowledge in software development and speak the same language with developers; do not be afraid to ask questions; be able to explain; have the desire and perseverance to get to the bottom of the problem;

Obviously, in real life, we have to use some kind of compromise and mixing of these two opposites, but, nevertheless, knowing these “ingredients”, the manager can already prepare his own recipe that most closely matches the conditions of a particular organization, build the relevant processes and prepare an SLA which will be in the interests of all interested parties (including the support / maintenance department).

What usually come

Well, as a bonus, a small list of unsuccessful approaches to the organization of the support service.

1. Using chat bots . Recently, this trend is gaining momentum and it seems to many that this is a great way to save on the number of employees. At the same time, no one even thinks about the purpose for which people turn to the support and maintenance department. So, chat bots and other search capabilities are strictly necessary when the user cannot (with a poorly structured or complex and complicated organization of the so-called “knowledge base”) or does not want (due to excessive employment or laziness) to search for information independently. In other words, only if the user does not understand or can not find the necessary information in the online documentation quickly enough, then an advanced search tool or chat bot will help him in this. Chat-bot should not touch any non-standard or technical problems. Unfortunately, very few people understand this. Of course, there is a great desire to force users, finally, to use the documentation and articles posted on the relevant portal, and not to contact the department staff on already-written and simple questions. However, this is solved more easily and simply by administrative methods, and not by an attempt to worsen everything. And the second point, connecting the help desk to the help “for every sneeze” to users is not the most commercially viable solution. On the one hand, the company assumes responsibility for the solutions provided, and on the other hand, it is not compensated either. In other words, such an approach takes away bread from the implementation departments of the / professional service.
   
   
2. Savings on employees . The division of employees by qualifications into support levels, and a set of “the most stupid” (that is, the cheapest) at the first lines of support, is very popular. Although initially it was meant that the division into levels of support is functional and not qualifying in nature. It turns out as a variant of the previous item with chat bots. Managing staff is simply not able to properly organize the interaction of department employees with users, and is trying to solve problems head on - by recruiting more employees for the price that is available. As a result, the quality of service simply falls, and, to the complete surprise of managers, the burden on "qualified" employees only increases.
   I am already silent about the special training of support staff.
   
   
3. Using the phone as the main way to call for support . In general, it is rather strange to see that often when organizing support / support departments, preference is given to creating call-centers. If we are talking about IT systems support, then one phone call requires about as many resources as handling 2-3 incidents filed through a portal, forum or email. Calls are sometimes necessary and important, but far from always such an expensive (for a department) type of communication is rational and convenient from the point of view of organizing user support and / or customers. Even if you do not go into details of monitoring the quality of the product and / or services, organizing comfortable communication with users / customers, even the issues of availability and dissemination of experience and knowledge within the team, with telephone communications, require additional efforts and costs.
   
   
4. Using support services as a secretariat . In other words, when the first line of support plays the role of a sort of dispatch department and directs users to the right employees, depending on the issues and problems encountered. In fact, it is a disturbing "bell" that in the company "something went wrong." The support service, although it is an integral part of CRM (Customer Relationship Management), is a customer relationship management system, but it is part of it, not its replacement. Therefore, when the customer contacts the support service with the problem that he has expired the license for the product, this means that the abbreviation CRM is in the company for a tick, and the relevant departments (in this case, the sales department) do anything except their direct work. And therefore support / support staff will work as “communicators” between the customer on the one hand and the commercial department, the licensing department, and fulfillment by the department on the other.
   
   
5. Imitation of “personal” accompaniment , when support department employees sign only with a name, for example, “Maria”, “Ivan”, etc. I, of course, understand that abroad are ordinary phenomena and, on the one hand, hints at “warm friendly relations”, and on the other, it hurts the pride of Western users (the servants had no names), but even there it only makes sense very rare cases. In the practice of IT support, this creates only difficulties. The simplest situation: in the department four people are named “Alexey” (real case), while due to circumstances in the office only one of them is present (the second is on vacation, the third is ill, the fourth is on a business trip) and a problem arises in one of incidents, which was serviced by a certain "Alexey". As expected, the one in the office has no idea what is at stake. What should the supervisor / leader or the head of a department do if the customer refers to some verbal recommendations received from “Alexey”?
   
   On the other hand, when a certain “Fyodor” addresses you, it is far from always comfortable, because you do not know this person, no one imagined him to breed “familiarity” and generally, how can you be sure that “Fyodor” Is this his real name?
   Therefore, always, with any response of the company in the signature must be at least the name of the person who sent the message. Even if this letter / message comes from the team as a whole. In addition, if the appeal began to be processed by one employee, then he conducts work on this particular incident to the end, without constant switching of participants from the company. A change is allowed only when necessary (for example, ill, or overloaded with more important requests, or the work is “picked up” by the staff of the “technical support”) and the new responsible officer must always introduce himself and indicate whether he will work on the application until the end, or only temporarily handles it. In general, all this is very strange and it seems that many managers simply do not own the basics of administrative work.
   
   
6. Creation of “Customer Success”, “Technical Enablement” and other “Fulfillment” departments . Again, this is a recent fashion, mainly due to the enthusiasm of Agile for its methods of conducting development, and is an attempt to establish feedback, which is called head-on. Unfortunately, in reality this is usually an indication that having failed in the organization of normal work as implementation departments, training, maintenance / user support in particular, and CRM implementation methods in general, people began to sculpt alongside somehow already working departments, a new backup service. Alas, quite often with the same success.
   
   
7. Cargo-cult ITIL / ITSM . In fact, this is the biggest problem in organizing the work of support services. Framework artifacts require a sufficiently in-depth analysis before their introduction and a clear understanding of what we are doing, for what, why and how. For example, let's take the CMDB - the database of configuration / settings and the history of their changes. Consider a simple question: what information / attributes and their changes do we need if we support a certain business platform (for example, an accounting system)? There is a temptation to add everything that is possible there, but for companies of the “1C” level, with tens of thousands of customers, this will turn the system into a repository of unnecessary parts for anyone.
   
   But most often the creation of CMDB is simply ignored, storing information in separate files, letters, and even on pieces of paper. The difficulty is that the selection criteria for configuration / changeable parameters are not given in the ITIL manuals (for example, in the third book, ITIL Service Transition). There is only a classification and some examples taken for administrative work. Therefore, everything depends on the qualifications, experience and insight of the ITIL implementation architect.
   
   I hope this has shed some light on the fact that “knowledge of ITIL / ITSM” in itself does not guarantee anything and requires first of all an understanding that there is support, why it is needed in this particular case and what is a sign of the success of its work.
   
   
8. "Curves" KPI . This item is “out of competition”, as are all metrics of efficiency in general. The fact that they are needed is now understood by everyone. But the questions: “for what?” And “which ones?” Are already “backfilling questions” for the overwhelming number of managers. The same is true in the case of evaluating the performance of the support / maintenance departments. The simplest example: how to evaluate the usefulness of a single employee in a department? The number of incidents processed? If so, does this mean that 100 problems solved in a week are better than 10? In real life - does not mean. These 10 incidents can be so complex and important, and that one hundred - just the easiest, that comparing head-to-head numbers - is simply meaningless. Unfortunately, few people remember that the essence of KPI is the numerical characteristic for routine, repetitive and single-type work / processes. Therefore, in the numbers to display the contribution of support staff is not so easy as it seems at first glance, and it will be expressed by some kind of integral metric.
   
   In addition, the analysis of the work of support services allows us to assess the quality of work of external service providers and / or development department. This part of activity analysis is often ignored altogether.
   

I have it all. Your comments and reasoned comments are highly appreciated.

Good luck and success to all.



Sources of images:

1. “Frozen” dog - from here
2. "Severe" dog from here
3. Call Center: from here
4. Bus service from here