5 Reasons Why Your Team Members Are Shying Away From Direct Communications With Customers

Continuing our 5 Reasons series, this month we tackle the lost opportunities of avoiding phone, Zoom, and Teams communications and hiding behind email. This is often couched in terms of “young people don’t know how to use the phone anymore” but I think it’s a much more nuanced — and interesting — problem. Here are 5 possible root causes, and what to do about them.

1. They don’t know how to get out of a call

Direct communication mechanisms need to reach a conclusion, and customers often won’t get off the phone until they have an answer, or at least become convinced that one will be forthcoming. It’s up to the support engineer or the CSM to provide that assurance that the end of the conversation is not the end of progress.

Train your team members on the art of making a strong promise. “I’ll get back to you” is a very weak promise. A promise must be specific and time-bound, a la “I will reproduce the issue on my own system and give you an update by 4pm”, or “I will propose alternatives to the pricing for the renewal by Friday.”
Convince them that staying on a call as a “hostage” as it were is not constructive for them or the customer, even if the customer is hounding them to do it. Give them suggested wording (never a script!) so they can confidently state that the solution will occur faster if they can work on their own.

Lesson: Provide training on how to achieve a graceful exit.

2. They don’t see the value of a direct conversation

Why bother with slow, dangerous, hard-to-schedule calls when we can instead live in a world of email? Because synchronous communication is so much richer, especially if we are trying to build rapport or defuse anger or other negative emotions. You know that, but do your team members know it? I regularly facilitate workshops with support engineers who believe in their hearts that the best way to say no is to do it (first) in writing, so “customers can get mad on their own time”. Good grief!

Look at your own behavior: are you sending bad news or upbraiding your team in email?

Lesson: Model the behavior of switching channels for your own communications.

3. They are afraid of saying the wrong thing

It’s easy to say the wrong thing on a call and very hard to “backspace” to erase the error. But most errors occur when the team member feels pressured to say something, doesn’t know what to say, and makes something up. In other words, they know they are on dangerous ground but can’t help themselves. Here’s the antidote:

Prepare what to say.
Anticipate the conditions under which when you will choose not to answer a particular question.
Rehearse a few ways to back out from pressure. Not, “I have no idea what you mean”, but rather, “This is interesting, I’m going to research it further”. Not, “I will do everything you want, even though it’s against policy”, but rather “I understand this is importnat to you, let me review your request with my manager”. This goes back to the graceful exit strategy, above.

Lesson: Encourage team members to prepare for each call (briefly), including when to get off the call.

4. They want control of their time

Email is so convenient: we can send our messages when we want to, and the other party can do the same. And email is quick: a diligent team member can produce one in minutes. But it can also lead to incomprehension and wasted cycles.

Show your team members how to recognize unproductive exchanges. If they asked for something multiple times and the customer did not provide it, another round of asking won’t help. If the thread is argumentative, more of the same will only make it worse. If the customer is confused, they may become enraged if messages pile on. In all of these cases, it’s faster and more productive to switch to a synchronous medium.
Provide guidance on how to limit schedule creep. Proposing limited options, such as “Do you prefer 2pm or 3pm?” avoids having to dash the hopes of a customer who was given complete freedom to propose a meeting time.
Shape scheduling so that calls are actually possible. I still see lots of support engineers in particular who are scheduled to be “on queue” all day. When are they supposed to schedule those calls you think would be so helpful?

Lesson: Plan for outbound calls and show team members when they should switch channels.

5. They don’t know how to talk to managers/executives/large groups

Most support engineers and CSMs are perfectly able to handle a call, even a challenging one, with their normal contacts. But add more bodies to the call, especially those of higher-ups, and fear creeps in. And it’s a good thing, as far as I’m concerned: the stakes are much higher when managers, executives, and multiple parties are involved.

Here, I believe the best approach is to have a desensitization program. Plan for team members to observe such calls as mere observers, so they can appreciate that larger calls are indeed more challenging but completely doable. And they can pick up good habits.

Anticipate and research who will show up (see the Planning step above, #3).
Define roles and responsibilities ahead of time if there are multiple participants on the vendor’s side (ditto).
Consider the business implications of the information they are conveying.
Ask their contacts to help them communicate with higher-ups.

Lesson: Create an observation program to tackle the fear and inject some practical lessons at the same time.

What do you do to encourage your team members to use calls more? (And if you need help, we can train both support engineers and CSMs.)