Sometimes a technical support engineer is faced with a difficult choice: to apply the dialogue model “We are for a high culture of service!” or “Press the button and get the result”?
... Having broken the wing of cotton wool,
Let's lie down in the clouds, as in crypts.
We poets are rarely holy,
We poets are often blind.
(Oleg Ladyzhensky)
Working in Tech Support is not only about funny stories about self-jumping time and GPS unicorns, and not even just detective puzzles in the style of Hercule Poirot.
Technical Support is first and foremost about communication, and communication means people, and there are very different characters among our clients:
- A German who works from a cafe opposite his office in Berlin, the owner of a truly Nordic restraint, perfect calmness, a carefully calibrated network, an extensive server park and cognitive abilities to set up 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.
- A Briton who has changed two companies over the past 5 years, but not the style of working with support. They either run away from his cases, like from the bubonic plague, or take them, anticipating all the “charm” of working with this person in advance, because he can take control at a remote session without warning (to check his mail, sometimes personal), put pressure on engineers and management over the smallest trifles and, finally, just as suddenly close applications with the comment "DUPLICATE".
- An Indian with a polysyllabic and unpronounceable surname, who refutes all the myths about Indian IT: polite, calm, competent, reads documentation, listens to the advice of an engineer and always does everything himself, the owner of a chic turban (yes, we found it on Facebook) and a perfect Oxford pronunciation.
Each engineer can remember five such "named" clients, without even thinking too much. We scare our newcomers with some of them (“if you misbehave in the lab, a babayka will come and! ..”), we brag about some of them (“and I already have 5 applications with N. closed!”). And most often we even remember and understand that positive and negative examples are just our perception, and it follows from communication, ours with clients and clients with us.
And communication is very different.
Once we wrote about , and now I want to show how it happens, on a live example.
Here is a good example from two years ago: the client's reaction to the "traditional" troubleshooting steps by the engineer and the engineer on the client's communication style.
Fragmentation Case
So here's the case: A very experienced and tech-savvy customer opens a support ticket and asks a direct question, providing plenty of detail to describe the situation.
I took the liberty of rewriting the correspondence into a dialogue, keeping the stylistic features.
Client (K): — Good afternoon, sir. My name is Marco Santino, we took advantage of your best practices and installed the latest technology recommended by you, but we see that the system 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 this always show up? Have you tried defragmenting?
(K): — Dear Ignat! Yes, it always shows up. We tried to defragment, but, alas, it takes too much time when the system is completely idle, and therefore it is not possible.
(I): - Listen, but I can’t find this best practices. Where did you find him? And maybe still do a defragmentation, huh?
(K): — Dear Ignat! Understanding that you do not take our problem seriously and with difficulty restraining yourself from a direct, and not 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 education. Best Practices were given to us by your Product Managers at dinner in Barcelona, and I sent you a link to them. We ask you directly, Ivan, is this situation normal? If you are not interested in talking to us, please find someone who can help us.
(I): - Marco, I didn’t find these best practices. I need the logs and I will refer the problem to another engineer. I'll tell you this: if you see fragmentation and don't defragment, it's stupid and irresponsible. And in general, how did you manage to confuse the noble name “Ignat” and call me Ivan?
(K): So, that's enough! I am not your brother, Ignat, not a matchmaker, so that you call me by my name, so please contact me Gn. Santino! If you can't find the document, if you can't cope with such a simple task, then either quit the company, or ask its author, who gave us this document! As for the logs, we cannot give them to you without special agreement, as 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 thing: if we say that we “tried to defragment” and it is “impossible”, then we tried and it is impossible. Ignat, I beg you, stop suffering from nonsense and get busy with your work - either give us an answer, or find someone who will give it to us!
After that, the application was transferred to a higher level, where it died - the client did not provide logs, full-scale testing did not give anything, and the problem simply could not be confirmed.
Question: what could an engineer do to avoid the heat of passion and the escalation of the conflict?
(Try to answer this question for yourself before reading on.)
Lyric technical retreat
For fans of solving puzzles and answering 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 users of ReFS could suffer.
It took Microsoft more than a year, with the support of many vendors, to finally fix this error (which we see as our merit - many copies were broken about the support of this giant at all levels).
I, answering the question “what could have been done?”, I want to ask another, eternal question: “Who is to blame?”
Out of professional solidarity, I really want to say: “The client is to blame,” and start shielding the engineer. As a manager who constantly evaluates the work of his engineers, I see the mistakes that Ignat made. Who is right?
Let's take everything in order
This case is very tough, there are more questions than answers.
Formally, Ignat did everything well:
- followed one of the core values of Veeam: Conversation from the heart;
- addressed the client by name;
- clarified the situation before offering a solution.
Could he have avoided such a heat of passion?
Could: notice how Mr. Santino communicates (only in you and by last name), refuses "basic questions", shows his interest in the problem and promises to find out if this behavior is normal.
Minimal steps, without the technical part - and they would already help to "put out" the situation. But even if it's omitted, just "don't do" would help a little too.
It sounds obvious: do not take a typo personally, do not be offended by a caustic client (even if everything points to an overestimated heart rate), do not turn the conversation into personalities, do not succumb to provocations ... That's how many of them, these "not", and all are important, and all about communication.
But what about the client? Letters written in a “high calm”, constant references to your acquaintances at the very top, veiled insults and resentment from seeming disrespect? Yes, we can read it that way. On the other hand, is it Mr. Is Santino really wrong in his anger?
And yet, what could be done on both sides? I see it like this:
From the side of the engineer:
- assess the degree of formalism of the client;
- follow “basic isolation” less;
- (now it will be subjective) read letters more carefully;
- answer questions rather than avoid them;
- and, finally, not to succumb to provocations and not to get personal.
To the client:
- clearly state the question in the first letter, without hiding it in technical details (this does not follow directly from the dialogue, but believe me, the detail was amazing);
- be 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 dating “at the highest level”;
- and, as for Ignat, to avoid becoming personal.
I repeat - this is just my vision, my assessment, which is in no way recommendations or guidelines "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 your own.
I do not defend the engineer - he is his own 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 elegant lace of an almost-refined-polite insult (a good image of a modern hidalgo who lives not in mercenarism and war, but in IT - although ...) .
“I found a scythe on a stone” - this is how I can sum up this correspondence, or even put it in other words, the truth of which I sincerely believe: “two are usually to blame in any conflict.”
We can say in the words of our business coach: "successful communication is hindered by past experience, communication habits and different pictures of the world." You can remember the golden rule of morality: "Do to other people the way you want them to do to you."
And you can simply say: two people always participate in any communication, and on the other side of the handset or monitor from you is a living person who is also scared, happy, 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 quite specific tasks, our main work is defined by the second word: “support”.
Support is about people.
***
Remember, I already wrote twice that two are to blame? So, in fact, more than that - specifically in this situation, all three are to blame. Why? Simply because an engineer is not a thing in itself, but a part of technical support, and it is our job and our responsibility to teach an 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 a hypothetical engineer Ignat is, “on the other hand” there may be a person who will do everything to inflame the situation.
But the beauty of working in Veeam 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 our best to make it so.
Is it possible to teach how to live and work in such situations? Can.
We know how, we love, we 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 are actively using cases, simulating situations, saving up and always returning to our mistakes and analyzing the intricacies of communication.
We believe that our guys now go “to 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, here is 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's commitment and success. Veeam is #1 for support.”
“We have been in the IT industry for over 20 years and we can say that no other vendor provides the level of technical support that Veeam does. It's a pleasure to work with Veeam engineers as they know their stuff and can resolve issues quickly. Technical support should never be underestimated. It is a measure of how responsible and successful a company is. Veeam has the best support.”
***
Any communication is a field for experiments, mistakes, whether we like it or not. And my opinion is to make mistakes - this is normal, moreover, my call will be: make mistakes! It's not about whether you stumbled, but whether you then learned to put your foot firmly.
Sometimes it’s hard to catch yourself and remember all the instructions and recipes that are generously shared by “gurus” of communication with clients or experienced colleagues. It's much easier to sometimes remind yourself: "I'm talking to a Human."
***
I do not claim to have higher knowledge or a special standard of quality in dealing with clients. A list of only my mistakes would be enough for a full-fledged textbook.
The goal that I set for myself was 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?
Source: habr.com