Case study about communication with a “heavy” client

Sometimes a technical support engineer faces a difficult choice: apply the dialogue model “We are for a high service culture!” Or “Press the button - you get the result”?

... breaking a wing of cotton

We lay in the clouds, like in crypts.

We poets are rarely holy

We poets are often blind.

(Oleg Ladyzhensky)

Working in Technical Support is not only funny stories about self-leaping time and GPS unicorns, and even not only detective puzzles in the style of Hercule Poirot.



Technical Support is, first of all, communication, and communication means people, and among our clients there are very different characters:

• The German, working from a cafe opposite his office in Berlin, has truly Nordic exposure, perfect peace of mind, a carefully verified network, an extensive fleet of servers and cognitive abilities to configure and maintain all this on A +. Applications from him usually cause the same reaction as the last dumpling on a plate in a large company and an out of time light.
• The Briton, over the past 5 years has changed two companies, but not the style of work with support. They either run away from his cases, like from a bubonic plague, or pre-anticipate all the “charm” of working with this person, because he can take control away from a remote session without warning (to check his mail, sometimes personal), put pressure on engineers and management for the smallest nonsense and, finally, just as suddenly close the application with the comment "DUPLICATE".
• An Indian with a polysyllabic and unpronounceable surname, refuting all myths about Indian IT: polite, calm, competent, reading documentation, listening to the advice of an engineer and always doing everything himself, the owner of a chic turban (yes, we found it on Facebook) and an ideal Oxford pronunciation.

Each engineer can recall five such "named" clients, even without much thought. We frighten some of our newcomers with some (“if you behave badly in your lab - a woman will come and! ..”), we boast about some (“but I already have 5 applications with N. closed!”). And more often than not, we even remember and understand that positive and negative examples are just our perception, and it follows from our communication with clients and clients with us.



And this communication is very different.



Once we already wrote about the "demons" that prevent engineers from working with clients , and now I want to show how this happens with a living example.



Here is a good example of two years ago: the client’s reaction to the “traditional” steps of Troubleshoot by the engineer and the engineer on the client’s communication style.

Fragmentation Case

So, the case: a very experienced and technically savvy client opens an application with technical support and asks a direct question, providing many details to describe the situation.



I took the liberty of remaking the correspondence into a dialogue, preserving the stylistic features.



Client (K): - Good afternoon, sir. My name is Marco Santino, we used your best practices and installed the latest technology that you recommended, but we see that the system’s performance becomes critically low due to high fragmentation. Please tell me is this normal?



Engineer (I): - Hello, Marco! My name is Ignat and I will help. Does it always show up? Have you tried to defragment?



(K): - Dear Ignat! Yes, it always appears. We tried to defragment, but, alas, it takes too much time with a complete system downtime, and therefore it is not possible.



(I): - Listen, but something I can’t find this best practices. Where did you find him? And, maybe, nevertheless do defragmentation, huh?



(K): - Dear Ignat! Understanding that you do not take our problem seriously and having difficulty restraining ourselves from a direct, rather than politically correct, answer, we will nevertheless try to answer you. We do not have your experience (we have only been in IT since 1960), and we are very grateful to you for your work and efforts in our enlightenment. Best Practices was handed over to us by your Product Managers for dinner in Barcelona, ​​and I sent you a link to them. Ivan, we ask you directly: is this situation normal? If you are not interested in talking with us, please find someone who can help us.



(I): - Marco, I haven’t found these best practices. I need logs, and I will transfer the problem to another engineer. I’ll tell you what: if you see fragmentation and do not defragment, it’s stupid and irresponsible. And in general, how did you manage to confuse the noble name “Ignat” and call me Ivan?



(K): - That's enough! I tell you, Ignat, not a brother, not a matchmaker, so that you call me by name, so please, please contact me Mr. Santino! If you can’t find a document, can’t cope with such a simple task, then either quit the company or ask the author who transmitted this document to us! As for the logs, we can’t pass them to you without special coordination, since we work with secret documents. Your indignation at my mistake shows your ignorance and your bad manners. I am very sorry for you. And the last one: if we say that we “tried to defragment” and this is “impossible”, then we tried and this is impossible. Ignat, I beg you, stop suffering from nonsense and get involved in your work - either give us an answer or find the one who will give it to us!



After that, the application was transferred to a higher level, where she died - the client didn’t provide the logs, full-scale testing did nothing and the problem simply could not be confirmed.



Question: what could an engineer do to avoid a passion and escalation of the conflict?



(Try to answer this question yourself before reading further).



Lyric technical retreat

For fans of solving puzzles and answers to the question “who is the killer?”: The problem turned out to be much more serious: ReFS fragmentation not only affected disk operations, but in some cases increased CPU and RAM consumption up to ten times, and not only for Veeam clients - All ReFS users could suffer.



It took Microsoft more than a year, with the support of many vendors, to finally fix this error (in which we see our merit as well - many copies were broken about supporting this giant at all levels).



I, answering the question “what could be done?”, I want to ask another, eternal question: “Who is to blame?”



Out of professional solidarity, I really want to say: “The customer is to blame,” and begin to shield the engineer. As a leader who constantly evaluates the work of his engineers, I see the mistakes that Ignat made. Who is right?

We sort everything in order

This case is very tough, there are more questions than answers.



Formally, Ignat did everything well:

• followed one of Veeam's core values: Conversation from the heart;
• addressed the client by name;
• clarified the situation before proposing a solution.

Could he have avoided such passions?



Could: notice how gn. Santino communicates (only to you and by last name), abandon the "basic questions", show your interest in the problem and promise to find out if this behavior is normal.



Minimum steps, without the technical part - and they would already help to “put out” the situation. But even if this is omitted, simply “not doing” would also help a little.



It sounds obvious: do not accept a typo at your own expense, do not be offended by a stingy client (even if everything speaks of an inflated ChSV), do not translate the conversation into individuals, do not succumb to provocations ... That's how many there are, these “not” ones, and all the important ones, and all about communication.



And what about the client? The letters are written in "high calm", constant references to their acquaintances at the very top, veiled insults and resentment from apparent disrespect? Yes, we can read it that way. And on the other hand, is it so. Is Santino really wrong in his anger?



And yet, what could be done on both sides? I see it like this:



From the engineer:

• assess the degree of formalism of the client;
• less follow “basic isolation”;
• (it will be subjective now) to read letters more attentively;
• answer questions, rather than shy away from them;
• and, finally, do not succumb to provocations and do not get personal.

To the client:

• clearly indicate the question in the first letter, without hiding it in technical details (this does not follow directly from the dialogue, but believe me, the details were amazing);
• a little more tolerant of questions - not everyone thinks the same way, and sometimes you have to ask a lot to understand the very essence of the problem;
• perhaps restrain the desire to show their importance and acquaintances “at the highest level”;
• and, as for Ignat, to avoid the transition to personality.

I repeat - this is just my vision, my assessment, which in no way is a recommendation or a guide to “how to live and work.” This is one of the options how you can look at the situation, and I will be glad if you offer yours.



I do not protect the engineer - he is himself an evil Pinocchio. I do not blame the client - he has the right to communicate as he sees fit, even if this communication is more hidden in the graceful lace of an almost-sophisticated and polite insult (a good image of a modern hidalgo who does not trade in mercenaries and war, but IT - though .. .).



“I found a scythe on a stone” - that’s how I can summarize this correspondence, or even put it in other words, the truth of which I sincerely believe: “two are usually to blame for any conflict.”



We can say in the words of our business trainer: “past experience, communication habits and different pictures of the world interfere with successful communication.” You can recall the golden rule of morality: “Do things to other people the way you want them to do to you.”



Or you can simply say: two always participate in any communication, and on the other side of the handset or monitor you are a living person who is also scared, joyful, sad, or something else. Yes, it is believed that emotions and business are incompatible, but where can we get away from emotions? They were, are, and will be, and even if we are Technical Support and solve very specific problems, our main work is determined by the second word: “support”.



Support is about people.



***



Remember, I already wrote twice that two were to blame? So, in fact, moreover, it is precisely in this situation that all three are to blame. Why? Just because the engineer is not a thing in himself, but part of the technical support, and it is our job and our responsibility to teach the employee to go through similar situations. We try to learn from our mistakes - and help our employees avoid them.



Is it always possible to avoid such situations? Not always. No matter how good the hypothetical Ignatus’s engineer is, “on the other hand” there may be a person who will do everything to heat up the situation.



But the charm of working at Veeam Technical Support, one of the values ​​we are proud of is teamwork. It is very important to remember: “You are not alone,” and we are doing everything to make it that way.



Is it possible to teach how to live and work in such situations? Can.



We can, love, practice - for this we built our internal training and continue to debug and polish it. In the two and a half years that have passed since the described situation, we have seriously worked on our training program - and now we actively use cases, simulate situations, save up and all the time return to our mistakes and analyze the intricacies of communication.



We believe that our guys now go “into the fields” much more prepared for any situations, and if something appears that they are not ready for, we are there and ready to help, and then supplement our courses with new examples.



And it pays off. For example, a review of one of our clients about our work:



“We've worked in the IT industry for more than 20 years, and we all agree no vendor offers the level of technical support that Veeam offers. It's a pleasure to speak to Veeam's technical staff because they're knowledgeable and resolve issues fast. Support should never be underrated. It's a measure of a company commitment and success. Veeam is # 1 for support. ”



“We have been working in the IT industry for over 20 years, and we claim that no other vendor provides such a level of technical support as Veeam. It is very pleasant to work with Veeam engineers, as they know their job and can solve problems quickly. Technical support should never be underestimated. This is a measure of how responsible and successful the company is. Veeam has the best tech support. ”



***



Any communication is a field for experiments, errors, whether we want it or not. And my opinion is to make mistakes - this is normal, moreover, my appeal will be: make mistakes! It is not a matter of whether you stumbled, but of whether you then learned to put your foot firmly.



Sometimes it’s hard to catch yourself and remember all the instructions and recipes that generously share the “gurus” of communication with customers or experienced colleagues. It’s much easier sometimes to remind yourself: “I’m talking to Man.”



***



I do not pretend to the highest knowledge or a special standard of quality in dealing with customers. A list of only my mistakes would be enough for a full textbook.



The goal I set for myself: to show how it can be in Technical Support and start a discussion of what can be considered acceptable in such cases and what is not.



What do you think?