Verbal communication is complicated in its own right. It has a number of spokes that make it seem effective—the words spoken, voice intonation, body language, and facial expressions to state a few. Going by the quality definition as stated in Chapter 1, Communication Training, face-to-face communication where the communicator and recipients sit across physically from one another is the best form of verbal communication as the communicator gets an opportunity to communicate using all the aspects of verbal communication—spoken words, tone, body language, and facial expressions. But is it practical these days? With widening workforces and serving customers across continents, does it make logical sense for people to be physically present in a room for every meeting?
There needs to be a compromise made to make pragmatic sense of communication. The compromise comes in the form of telephones, where the communicator has only the spoken words and the voice tone to play with, but instead, is saving a bunch of time which would have involved the logistics of getting in and out of a discussion room.
In this chapter, I will primarily discuss telephone communication. I will focus on the specific elements that are crucial for effective communication on the phone, such as the use of language and tone of voice.
Today, a voice call need not be on a telephone alone. Most organizations employ Voice over IP technology (VoIP), which enables us to place and receive calls through our computers. The introduction of VoIP technology has made voice communication informal, in comparison to how it was viewed at one time. Earlier, when calls came through a telephone, we used to start with a greeting—at least by introducing ourselves. Thanks to VoIP, the professional greeting is replaced by an informal one—what's up? I am not saying this is wrong, but the changing trend is affecting the way we handle our professional calls that land on our telephone lines as well.
In an IT organization, there are mainly two channels of telephonic communication:
- Communication between employees of an organization
- Communication between employees and customers
Before I get into the channel specifics, there are a few common denominators that I want to address first.
I am certain all of us have taken calls where the party on the other end knows what needs to be said but has not figured out yet how to say it. I am not talking about the people who beat around the bush before bringing up the topic that's the reason behind the call. I am referring to people who start out uncertainly, go in a certain direction, retract, give a few pauses, and then take another track. In the end, the unprepared caller has wasted both your time and their time, and has left a bad taste in the mouth of the person at the receiving end. Imagine if this happens to a customer.
The point being, if you are the caller, come prepared. Before you make the call, know what you are going to talk about, how you are going to say it, and the path you are going to undertake in jumping from one topic to another.
I for one like to write down what I am going to talk about in my notebook, and I also write down the sequence of topics that I would like to bring to the table. This gives me the confidence of being in charge of the call. For example, let's say I want to call my customer with the following agenda:
- Explore new business
- Understand the pulse of the customer
- Seek approval for a downtime of services
The call will progress along the following lines:
Abhinav: Hi, Mike. This is Abhinav from ABC Technologies. Is this a good time to talk for a few minutes?
Mike (customer): Sure. No problem.
Abhinav: I am sorry that I called without prior notice. A pressing situation has come up and I needed to discuss it with you.
Mike: That's okay. I can talk now.
Abhinav: One of the servers in the data center needs patching. A security patch has been released and we don't want to delay deploying it. So, we were planning on doing it over the weekend. Emails would be affected at the most for an hour, but we hope to complete it well within the hour. Are you okay with this?
Mike: I think one hour outage should be fine. Email me the specifics and I will relay it to others here.
Abhinav: Wonderful. I will send you an email with all the details. And, it has been some time since we spoke. How are you finding our services? All OK?
Mike: Yes yes. Everything is fine except for the delay in project A. But I guess that didn't impact us too much though.
Abhinav: Yes. I am aware of the delay, and we have already taken preventive steps to ensure that similar delays are avoided.
Mike: Good!
Abhinav: I also heard about your new acquisition. The acquisition gives you a better hold over the region doesn't it?
Mike: Yes. You are right. It does. It was a good strategic move for us. And, it all worked out well.
Abhinav: Wonderful. You need us to help you out with the additional resources you are getting from it?
Mike: Yes. We were discussing integrating the environments. So, let's discuss the specifics next week.
Abhinav: Sounds like a plan. I will check with your assistant and book a slot next week.
Mike: Good. I will let her know my preferences.
Abhinav: Thanks Mike. We will talk next week. Have a great weekend.
Mike: You too. Bye.
This transcript is in fact from one of my meetings earlier this year. I had listed down the topics to bring up in a specific order and it came out just the way I intended. My notes looked something like this:
Downtime needed. Security patch. Important. One hour.
Pulse check. Project A delay—procurement process overshot the plan. New process in place.
New acquisition. Strong player in the market. Expansion of services.
A word of caution. At times, you may have prepared with notes such as I did, but the discussion may not go as intended. It may take a turn where the customer might start asking for specifics for which you are not prepared for. In such cases, you need to improvise. One way of doing this is by expanding on your notes by planning in detail—if the customer says this, then I will say this, else I will say something else. You get the idea?
No, professionalism and friendliness are not two sides of a coin. Both can co-exist at the same time, and the combination if applied well is deadly in a good way. In a telephonic conversation, the person on the other side of the phone can hear your voice only and nothing else. So, whatever you want to express, you need to do it with your voice—whether you smile, frown, or respect.
When you speak on a call, be warm and friendly and speak wholeheartedly to the person. Yet, at the same time, stay within the boundaries of work and focused. You can display friendliness by staying enthusiastic about the conversation and showing genuine interest in what is being said. If you are disinterested, don't put up a face, but rather find a way to curtail it without being obtrusive about it.
When I say professional, I am only talking about the limits that we need to impose. The limits are generally work related, without bringing up personal tastes, topics, and derogatory statements.
When I worked with some customers from Australia, they appended the word mate during conversations, and this brought about a sense of friendliness. The discussions revolved around projects and services, and at times, the weather, food, and weekend plans. We never ventured into talking behind people's backs or discussing topics in a derogatory sense. The discussions were always above the table and professional. By the end of the month, I knew that my customer had two daughters and a wife who loved Indian food.
Through my experience, I want to highlight how friendliness and professionalism can co-exist, and I'm not indicating that you are expected to know the customer as a friend. No, you are not expected to be your customer's friend, but the warmth in your voice must comfort the person to open up, and tell you everything without withholding any information due to lack of trust.
Don't be misguided by the topic heading and think that I have started teaching psychology 101. Staying positive means being approachable and not finding the fastest way to end a conversation.
Consider the following hypothetical transcript:
Abhinav: Hi, Mike. This is Abhinav from ABC Technologies. I called to tell you that the server has been successfully patched.
Mike: Good. I had something else to ask you. The delay on project A delivery. Can you tell me where the delay was ebbing from?
Abhinav: Aaah…. I don't know.
Mike: OK?
Silence
Mike: I want to know the reasons for delay. Send me a report detailing the cause for the delay. I would like to have it within the next hour. Thanks!
What is wrong with it? Everything. I didn't know the causes for the project's delay, which is reasonable. But, I further pulled myself down by saying that I don't know what the reasons are. This told the customer that I was evading the topic by playing ignorance. What was the end result? The customer was upset, and I had a stringent deadline for giving him the data that he needed. Perhaps the customer may never see me as before, and will look down upon me every time I speak to him. Not good.
If I could go back in a time machine and redo the conversation, this is how it would have gone:
Abhinav: Hi Mike. This is Abhinav from ABC Technologies. I called to tell you that the server has been successfully patched.
Mike: Good. I had something else to ask you. The delay on project A delivery. Can you tell me where the delay was ebbing from?
Abhinav: Mike, let me get the details and email them to you today.
Mike: No problem. I have to present a report to the board on the outage. As you know, the delay cost us some business and this got the board interested in the matter.
Abhinav: I understand that the delay has impacted you financially. I will send the report at the earliest.
Mike: Sure. You can send it to me by the end of this week. I am not expected to report it until Wednesday next week.
Abhinav: Thanks Mike. Have a good day!
How different was this? And, the only difference in the conversation is my attitude. Although I did not know the cause of delay, I proactively volunteered to obtain the details. And, the customer opened up and told me why he needed it, and the timeframes as well were not too stringent.
To reiterate, never say I don't know to the customer. But, that should not stop you from saying no. Some believe that if we say no, then it counts as negativity, so they avoid saying no and fall into bottomless pits. Say it when necessary—like when a customer demands services that are outside the contract. Saying no and I don't know are two different things. The first has to be embraced with prudence and the second avoided.
There was a time when I interacted more with my colleagues sitting in a different office than my family who stayed under the same roof. This is certainly the case with most IT professionals. The job demands constant communication and coordination with other colleagues, and perhaps this is the sole reason why many organizations subscribe to team building activities.
With colleagues, the three common denominators that I discussed at the beginning of this topic apply just as well. Although I mostly mentioned about customers, you can just as well substitute customers with colleagues and the principles will not change. Fellow employees enjoy working at a friendly cum professional level, so well prepared telephonic communications that are treated appreciably and positivity increase the mutual trust and respect between individuals.
In this section, I will highlight certain types of interactions that are common in the IT industry and provide a few specific tips on how telephonic communication must happen. There are numerous other exchanges that you can apply based on the principles that I am about to share in this section.
In IT, handing over work from one employee to another is common. Work changes hands constantly, at various stages of a project or a service. Data flow between entities (design to deployment), performance (from functional manager to people manager), and work handover between shifts are just a few examples.
At the core, work handover revolves around exchanging information from one entity to another. As IT is all about information, there is prime importance given to information exchanges such as this. If the exchange is inaccurate, it is possible that projects may not succeed and customer satisfaction may take a hit. So, to state plainly, work handovers are critical.
There are a number of ways to do this. Any medium can be used to hand over work. But, for effective handovers, follow the method that I recommend based on my ground-level experience.
The data that needs to be handed over must be written down in a document or an email. Writing helps in reflecting on thoughts and putting down information that has been given some thought. After putting it in words, share the document with the person receiving the handover. And then call this person to go through the document that you have prepared. While you explain the document, the person receiving it has the benefit of listening to you and reading through it as well. This two-dimensional approach helps in effectively communicating work handover information. But wait, there's more. While the person handing over explains the written content, the data goes through another round of validation and perhaps the person receiving it can probe further to get information that may have been left out.
Action Point
Exercise (for students to attempt at the end of this topic followed by a group discussion):
- How is work handed over from one team to another, or one employee to another, in your organization? If there are no face-to-face or telephonic handovers, how effective is it?
Not everybody in IT is omniscient. In fact, I can be certain to state that none can boast knowing it all. At some point or another, we need to consult with others—request support.
The ideal way to consult with others is through a telephone. I am aware that some employees request support from others through an email or business instant messaging. But, these two non-verbal mediums are not always instantaneous, and it is the human tendency to ask for help at the last moment. If employees are collocated, then face-to-face trumps it all, including telephonic help being sought. But, we don't have this luxury anymore. Most of our teams sit elsewhere, and the best we can afford is a telephone, and we should go for the best option.
When you need help, you need it right away. First and foremost, when you speak to a person seeking help, the probability of denying support is minimal. And, the person asking for help can always confirm if the understanding is right. The feedback confirmation is critical in getting help, and the best way to get it if teams are not sitting together is through a telephone.
Action Point
Exercise (for students to attempt at the end of this topic followed by a group discussion):
- Let's say a colleague calls you and asks for your help in solving a problem that the colleague is facing. To show the solution, you must use a drawing tool to explain certain technicalities, but this is impossible over the telephone. What kind of a solution would you employ to alleviate this problem that telephonic communication comes with?
Meetings are part and parcel of our IT lives. We meet to discuss, exchange views, and to improvise on work products. So, it is imperative that meetings are successful, especially the telephonic ones, and by now you know the reasons why I am stressing on telephonic meetings. The comfort of taking a phone call at our own desk is incomparable.
I have dedicated an entire section in the next chapter on meetings. Yet, I wanted to bring this topic here and discuss the specifics related to telephony.
If you are using a presentation in your meeting, the people sitting across and beside you can follow the slides on the screen and you can run through them in any fashion that you wish. But, when you have people who are blinded by distance and aided by telephonic technology, you need to put extra effort in reading out the slide numbers every time you jump to a new one.
When people sit across from you, you can read their body language and ask relevant follow up questions like "It seems something is unclear on this slide. Which part do you want me to repeat?" But the people on the other side are at a disadvantage. So, to minimize it, you need to ask after every slide whether they have questions that need to be addressed. Not all listeners speak up unless called out for. And, at the end of the day, meetings are conducted for everybody's benefit as effective information exchange leads to better work products and delivery.
Action Point
Exercise (for students to attempt at the end of this topic followed by a group discussion):
- What type of meetings do you prefer? Telephonic or face-to-face communication? Depending on the choice of your answer, what are the reasons for opting for one channel over the other and why is there a comfort level? (When I have asked this question to some of my teams, a few have stated telephonic and the comfort level is aided by online games that they can play during the call.)
There is always something sacred about communication with customers. Every communication you make, you are either building the confidence levels of the customer or breaking them down. It cruelly seems like customer perception depends on communication rather than the actual work that is being carried out.
In any customer-IT organization relationship, there is a fair amount of transactions that happen over the telephone. Although the critical meetings are always held face to face, a number of ad-hoc and routine meetings are preferred to be run over the phone. And, these telephonic meetings often act as a precursor or post-meeting follow ups for the face-to-face critical meetings.
In this section, I am going to touch on understanding the customer's requirements, speaking in a language understood by the customer, and meeting the requirements.
To understand what the customer really needs, you need to (carefully) listen to what the customer has to say. Remember that the customer will not tell you the requirements in your language–with jargon. The customer states it the way it's seen by them, and there is a big difference when it comes to how they see it and how you vision it. So, you need to momentarily put yourself in their shoes and understand what they are trying to convey.
For example, a customer may call you and tell you that they are not able to receive emails on their system. So, you will start to think of all the things that make up the email solution and what could have gone wrong, either centrally or on the customer's system. But, what the customer could have probably missed telling you is that the email program is not running yet. This is a true incident experienced by one of my engineers.
In essence, you need to gauge the customer and the level of technicality they can go into and then start conversing at their level. If you find a tech savvy customer, then zip to the short forms that you generally use on the job.
Also, it is unlikely that you will understand the exact requirement in the first instance. You may need to probe further and ask the right questions. The topic of questioning comes into play in this case.
In the email incident that I mentioned earlier, if the engineer taking the phone call had (really) heard what the customer was saying, he would have perhaps deciphered that the email program wasn't open yet. The engineer could have further probed to check whether all the basic things were in place before moving into the specifics.
In short, when a customer states the requirement or a problem, you need to listen word for word and not use imagination and assumption to fill the void that customers create when they speak. Instead, fill the void by asking questions. Will you require support during off business hours? Are you trying to access the Internet within the office premises? Do you see the email program running and trying to fetch mails?
After listening and probing, still don't assume you know everything that the customer needs. Relay your understanding and let the customer confirm your understanding.
Conclude your understanding of the customer's requirements with empathy. If the caller is distraught that all the mails in the mailbox are lost, reassure that you will do your best to recover the lost mail. I am not stating that you make false promises, but rather be human and act human, the way you would if a friend was to share a problem with you. Do not act like a robot in getting the requirements and confirming them.
Action Point
Exercise (for students to attempt at the end of this topic followed by a group discussion):
- You are a customer who has called in to obtain certain information. You are told by the call center employee that the team that is responsible for answering this query has left for the day. You are not happy with it. Enact a role play, where one is a call center employee and the other is a customer. The objective behind this is to learn the importance of being flexible depending on how the call is progressing. The role play can be further expanded with various flavors such as the customer's query getting answered and the employee taking a long time to find the required information.
I have covered this topic in detail in an earlier chapter, but I want to reiterate it once more due to the gravity the topic carries. When you are speaking to a customer on the telephone, it is natural for us to envision the technical architectures, project deliverables, and IT problems in our own language, which is studded with technicalities, and relay the same set of words to the customer. It happens to all of us. So, we need to take extra precaution, especially over the telephone, since we do not have the time to think through our answers like in an email before replacing jargon with layman terms.
Action Point
Exercise (for students to attempt at the end of this topic followed by a group discussion):
- Role play. Pick up a technical topic in your domain. Identify an employee in your organization who isn't technical, like those who are managers. The exercise is to call the manager and explain a technical solution, but in a language that the manager understands. After the call is complete, ask the manager to let you know what they understood. If what has been understood and what you said are a close match, you have successfully communicated jargon-filled expertise in plain English. And, you have a good future in dealing with customers and managing accounts.
Once you understand your customer's requirements, you will have to follow the process of answering your customer's queries or fixing issues that may have cropped up. Well, this process will take its course, but what we are going to concentrate on is the communication aspect.
Set the expectations of the customer. If you are going to answer the query right away or fix their problems while they are connected on the call, that's all well and good. But, if you are going to need a couple of hours or a few days to respond to their queries or issues, tell them as such. Make sure you set the expectations correctly, and in the competition of making the customer excited, do not make false promises.
Suppose you set an expectation as the next business day, and even after diligently working towards the solution, you were not able to provide what the customer wanted. You will need to call the customer before your deadline ends and provide them the reasons why you were unable to resolve the problem, and then provide a new expectation.
Customers appreciate being informed about possible delays proactively rather than after the deadline has passed. Since all the communication happens over the telephone, it should not hinder you from making the calls as soon as you find out about a possible delay.