Chapter 1: Active Listening

The Importance of Active Listening

“ When we listen, we hear someone into existence ” - Laurie Buchanan, PHD

Active listening is a communication skill where you give your undivided attention to the speaker and try to connect to the speaker during the conversation. This connection will help you stay engaged with the speaker and remember the conversation better.

For this course, we will learn how to use active listening to connect with customers. We can use summarizing and labeling to show empathy and build rapport. We can also validate their experience through normalization. Normalizing a conversation generally refers to making it more regular, typical, or in line with accepted standards. If we use normalization, we can help the speaker feel better about the experience they are having during their interaction us.

We can use active listening to help us resolve disagreements, disputes, and relationships with partners, clients, or customers. Often when people are talking they are talking to reply not to be heard and they are often throwing misplaced emotions out in the current debate they are having. We are listening not to find fault, but to seek the answer, relate, become informed, or discover common ground. This is why we often seek counseling; a neutral third-party person who has no gain in the outcome of the dispute, debate, or discussion. The counselor can listen and chime in when they hear conflicting statements and also highlight important points that each person has put on the table for review and further discussion. Our position is neutral and remember it’s not our fault.

Empathy

We do not want to take blame or ownership of the situation, but we can show empathy. Take a look at these 30 Empathy Phrases from Hubspot. As they demonstrate, just active listening can be a way to demonstrate empathy. You do not have to say anything, but oftentimes, customers calling in for support are having a rough day. They wanted to log into their account, pay a bill, or any number of other tasks that your company’s application is supposed to facilitate and it is not working how they expect it to. Let’s say that someone is attempting to pay a time-sensitive bill and the application is not processing their payment. Simply saying, “I am sorry you are experiencing a long wait time. Let me see what we can do to quickly resolve the issue you called in about.” shows empathy for the customer. They are stressed because the bill is due today and they don’t want to pay late fees. “I am sorry you are experiencing a long wait time.” shows that you understand that trying to complete a time-sensitive task and being asked to wait on hold can be a scary situation for anyone and that you are ready to listen and want to help them get their bill paid in a shorter time frame. The second sentence also demonstrates your understanding of their fears around time by using the word “quickly”. Using “we” can also demonstrate to customers that you are going to work with them collaboratively to find a solution. At no point, however, did the technical analyst take ownership of the real issue at hand, which is the application not processing the bill payment.

Note

You may be worried that if you apologize for the situation, a customer may take that to mean that you are personally at fault, especially if you are not able to find them a resolution. As we have demonstrated, with empathy, you can show concern for a customer without taking blame for the problem. If you are anxious or concerned about a customer finding personal fault with you, some may encourage you to try using “we” instead of “I”, such as “let me see what we can do for you”. You may still have an angry customer and we will talk about that when we talk about handling rejection, but the slight difference in language may bring you comfort that the customer knows that the team is on it and that you are not the only person resolving a problem.

According to a 2022 study by NICE , 57% of customers will abandon a brand after one to two negative interactions. Demonstrating empathy in your interactions with customers can make your interactions with customers good even if you do not have the solution for them. Think about the customer who is trying to pay a time-sensitive bill. Even if you cannot personally get the customer’s payment processed, coming from a place of empathy, you can think of alternate solutions that help assuage the customer’s concerns. You can contact the correct department so that they know the customer’s payment is pending and not to charge a late fee. This simple action can save the customer’s day and ensure that the interaction was good for the customer even without the resolution to the application’s bug. For more information about how empathy can change the game in customer service, check out this article from Dixa .

Summarizing and Labeling

Summarizing is an active listening technique used to figure out what the other person is feeling or what a person may be thinking. Since we are not able to read minds we must try to ask more questions about what the speaker may be feeling. We want to exercise caution here since we are not sure what they are actually experiencing. A good way to check is to repeat back to the speaker what we think we heard them say to ensure we fully understand the issue. With a strong focus on understanding the speakers’ perspectives and emotions, we can attempt to respond in a helpful and supportive way. Use phrases like “seems like”, “feels like” or “sounds like” to gauge the situation before engaging in the situation. We do not want to ask leading questions like “are you upset” or “are you angry.” This is an actuation language and also volunteers a feeling to adopt. Additionally, we do not know how many times the speaker has already had the feeling directed at them before they got to us.

Labeling is a facilitation technique introduced by Chris Voss where we share verbal observations of how the person may be feeling. An example would be “I can see that this is upsetting to you.” This technique is commonly associated with negotations, but it is applicable in any situationw where we need to gracefully handle conflict. We use labeling and summarizing to better understand how the speaker is feeling and to ensure we have the right emotion before we try to help. We can see an example of labeling in this article from Dixa with the phrase “I can understand how frustrating that is.” In this case, you can identify the speaker’s emotional state and demonstrate empathy. When we have the right emotion labeled, people often feel heard and will want to dive into the conversation about what is going on with them further. This postitive response enables us to attempt a solution, and gauge if the speaker is still feeling the same emotion or if they have moved towards a positive or less negative position. Learning to label is a valuable skill that can be used in a variety of situations, not just board room negotiations and customer service calls. By learning this skill you can help to prevent conflict and problem escalation. Check out this article from Facilitator School about how labeling can be of use when leading meetings.

Note

As noted in the above article, you should treat negative emotions with extra care. Because of negative connotations of certain emotions, the customer may feel less heard and more judged. In the case of our customer who is attempting to pay their bill, instead of saying “I know that you are impatient for a resolution and feeling testy”, you might try “I understand that you are frustrated due to the time-sensitive nature of the matter.” With the former, “impatient” and “testy” implies that the customer is an overgrown toddler experiencing a tantrum. The latter phrasing shows that you understand how stressful the situation is and frustration is a valid emotion in many stressful situations.

Validation Through Normalization

The experience the customer is having is real so the more we demonstrate understanding, the quicker we can resolve the problem with the customer. To normalize a customer experience, we can tell them we would feel the same or similar if we were in the situation. However, we want to avoid saying “I know how you feel” this can create a new problem. They may feel the need to own the feeling they are having at the moment. Also, we do not know about all the other things that are going on in their life.

We can echo back to the speaker/customer the feeling we think they’re experiencing. For example, “it sounds like you <restate the problem]> and you are feeling <labeled feeling>.” At this point, we pause and wait for acknowledgement to confirm the accuracy of the restatement and labeling . Once they have acknowledged the feeling we can say we understand why they are feeling the feeling they have and try to take it a step further by inviting them to help solve the problem. Remember, whatever the customer is feeling is not our fault but what they are feeling is real to them so focus on handling the situation to the best of your ability. By normalizing and validating someone’s emotional experiences we can help them to feel less alone and more understood. When you hit a roadblock in your troubleshooting steps, escalate the problem to the appropriate manager or supervisor.

3 Technical Communication Tasks

Primary Task - Identify the Problem To understand the problem-solving process, we need to locate the root of the problem. As a technical analyst, our first task is to quickly identify the problem. Without the problem, there is no solution. We have to ask questions about the experience the customer is having so we can troubleshoot. Once we have successfully identified the problem, we can begin searching for the solution in the most likely places. For example, if you are managing a software application, and there is a user guide that has a troubleshooting section and you have never seen this problem before, the user guide is a good place to start. In software engineering, we use root cause analysis to help identify the root cause of a reported problem. The steps for solving any problem are similar. We want to address the root cause to eliminate the problem from happening again, not just apply a bandage that patches the problem temporarily.

Secondary Task - Research the problem solution set We will often have access to written documentation from software developers and engineers to help us locate the root cause of a problem. These documents are likely searched so we should be able to identify and extract the contents given we provide good search context. Similar to Google search, if you want to find the best solution for a gift you may type a very specific search term into the search box. To better understand this let’s look at an example.

Example 1 - Halloween Sweaters

In this example, what we are asking the search engine to do is find all the Halloween Sweaters on the internet. This can return a lot of data to filter through before we find the one we are looking to purchase.

Example 2 - Funny Halloween Sweaters Unisex

This example is similar to the previous but we have added that we are interested in only unisex sweaters and sweaters with the descriptor funny. This is still a long list of sweaters to review before our purchase

Example 3 - Funny Halloween Witch Sweaters

Here, we are very specific about the types of sweaters we want to purchase and in theory, gives us a much smaller list than the two previous search terms. The previous examples demonstrate why it is important for us to properly identify the problem. Once we have the problem, we can search for a likely solution in the technical documentation, user guide or knowledge base.

Third recall/recognize - Identifying patterns and trends in data and code Our final step in our analysis is to identify the frequency of problems we are solving. Take note of how many times we get a call about the same problem and escalate the problem to the proper team to review and resolve. Often we have limited reach in our analysis so we have to escalate problems to other teams to continue our analysis where we hit the wall. Excellent verbal and written communication skills are essential for problem escalation. Clear communication is the key to building any relationship. How we document the problem/solution/installation steps in software engineering is called technical writing or technical documentation and it is meant to be very technical in nature. It should outline all the steps required to get a system installed, to fix a bug, or to escalate a problem. We will take a closer look at technical writing in Week 2 but for now, our focus is on the required steps for the team to pick up where we left off with our attempt to solve the problem.

Technical Documentation

Our technical documentation should contain all of the following items

Screenshots (if applicable) of the error or issue that was reported.
Notes - providing any information that we think is relevant to the problem we are working to resolve.
Steps we have taken from articles or knowledge-based sites.
Links to articles used to solve the problem.

If we can grab a screenshot of the problem it can help other team members that come behind us clear the problem queue. They may see something we missed during our analysis. It is also a professional best practice to ensure we are able to clearly communicate complex steps/problems. Being able to clearly articulate your thoughts is a demonstration of your depth of knowledge and understanding. So you should take pride in communicating and documenting your thoughts.

There are many forms of communication and documentation that include but are not limited to email, chats, web, and written knowledge-based systems. We can use these systems in our analysis steps. Our documentation should stand on its own. This means it will be a proper representation of what needs to happen next. This not only helps us when we get back to the problem but it should allow anyone who can help to move forward without any additional input (or at least very little help from us) from us. This includes any screenshots we took and all the steps and links to documentation we used to solve the problem.