But I’ve Never Done A Support Call!

When a colleague — a tester — asked us to recommend some reading that he could do in advance of his first support call, we realised we didn’t know of anything suitable. So we decided to pool our knowledge and experience in software development, testing and technical support; what came out of it is this short series of articles that cover:

• A basic introduction to tech support.
• Preparing for a support call.
• Being on a support call.
• Ending and learning from a support call.

We think that these are the key things testers who are asked to help out in support might want to consider.

This series can be read in a couple of ways:

• As a handbook for when you’re asked to be on a support call with a customer. It'll help you to understand your role, ask the right kinds of questions, provide the right kinds of information, and extract the right kind of value for the customer, your company, and you.
• As background material, to give an insight into how people on the frontline of engagement with your customers utilise a similar skillset to you, but with different emphases and different constraints.

Who is this article for?

We'll sometimes use the term tester to refer to the person being asked to help in technical support because that was where we started thinking about this topic, and also perhaps because all three of us would self-identify as testers. But we think we’d give the same or similar advice to people in other roles in software development teams too.

When Things Are Not Working

Does your company have a product? Do customers use the product? Does the company value those customers? If so, then there are probably people on your staff who help your customers through any problems they experience.

These helpful folk might have formal titles such as technical support analyst, customer support operative, helpdesk assistant, field service engineer, or application specialist. In smaller companies, like startups, there could be people performing customer service along with another role in the company.

What they all have in common is that they're the face of your company to your customer when things are not working, and that’s a particularly special role to have. It requires a good blend of investigative, technical, domain, social, and management skills and knowledge.

Sometimes a particular problem requires additional knowledge or expertise. At those times, support staff will often call upon developers, sysadmins, Ops, and testers to help resolve the issue.

Definitions And Context Of Technical Support Interactions

Let’s consider, in this context, that technical support is primarily those times when you are asked to interact with a customer directly in some way in order help understand or resolve an issue or question.

We won’t try to distinguish technical support from customer support from application support from other similar terminology: the customer has a question that needs answering, and you’re either expected to answer it, or helping the person who is expected to answer it.

We’ll focus on live interactions, rather than those carried out indirectly through a ticketing system or email, because the live ones are naturally more pressured and likely to take us out of our comfort zone. But we think much of the advice here will cross over into customer interactions using any medium.

We’ll use the word call to mean a phone call, teleconference, video conference or even face-to-face meeting with a customer, aimed at resolving some issue the customer is experiencing. We’ll only mention a specific type of call if we think it’s important.

We’ll also use the terms customer and user interchangeably, even though that distinction might be important in some environments, such as when your product is a component in a product made by another company. One of our reviewers agreed, and pointed out how difficult it can be to communicate indirectly with a customer via a reseller.

You may be familiar with terms like front-line support, levels or tiers of support. We won’t care too much about those here, but we’d expect that in many companies it’s less common for testers to be involved in straightforward support issues. So implicitly we’re probably providing suggestions for those times where the customer has already been talking to someone about their problem for a while.

Over the years, we’ve found that even if you have great social skills, are naturally empathic and are adept at speaking about technical matters, all of which are invaluable on support calls, the experience of being on a call with your own customers is a very different experience to anything else. For us, the combination of wanting to provide a good service to the people who ultimately pay your wages, wanting to do a good job for yourself and your company, and dealing with the pressure of being on the spot with a problem to solve, is uniquely challenging.

Finally, we’re going to assume that in any support call situation everyone is doing the best they can to work towards a positive outcome for the customer, although note that in many situations there may be more than one way in which that could be achieved.

Reasons A Customer Would Ask For Technical Support

When a customer decides it’s worth their time and effort contacting your company they’re probably suffering in some way, a way that’s important to them, related to the product you’ve built.

For example:

• They can’t do something they want to do.
• They appear to be able to do something, but it’s not turning out how they expect.
• They can do something, and get what they expect, but it takes too long.
• They lost access to your service.
• They lost access to their data.
• They lost the will to live because of accumulated frustration.

You probably have documentation of some kind, but perhaps they don’t like to read docs, or perhaps they don’t have time, or perhaps they tried and it didn’t help.

Whatever the reason, your customer is now looking to you, to the company, to the experts in your product, to provide some kind of resolution for them. The support team’s mission is to give them that resolution as quickly and painlessly as possible. Your task, when called upon, is to assist your support staff in that mission.

Sometimes the customer will even expect you to be an expert in the ecosystem in which your product sits. We’ve found that it is not unusual for support staff to know more about the IT infrastructure of a customer’s company than the customer themselves.

Support Basics

We think that supporting customers is a specialist job in its own right, and it’s only through repeated interactions with customers that you’ll learn how you can best do it. Having said that, we believe that there are useful heuristics that can help you with customers who are seeking your assistance.

Representing Your Company

• You are your company. Once you have engaged with the customer you have made a commitment to them. The way you communicate with the customer may be the difference between them walking away from your product or recommending your product to others.
• You are your company. So important, it’s on the list twice. Don’t argue in front of customers; have a convention for when you want to interrupt someone from your side (e.g. hold up your hand or pass a note); don’t air dirty laundry.
• You are your company. Three times, in fact. Don’t blame colleagues who are not on the call, even if it really is their fault. You might want to take it up with them outside of the call, but the customer doesn’t care and probably won’t respect you or the company for mentioning it. The customer just wants their issue fixed.
• Always be polite, courteous and friendly. Customers won’t be calling up just to have a chat, though. They have an issue and may be annoyed already. Don’t let yourself reflect this back to them: being aloof, arrogant, or patronising won't help.
• Be open. Bearing all of the above in mind, it’s still OK to have an open discussion about a customer’s problem in front of them. Customers will typically appreciate you being honest and involving them, even as listening participants.
• One size does not fit all. Staff who are regularly on support calls learn about the customer base and specific customers and modify or moderate their behaviour and communications as a result.

Treating Customers With Respect

• Treat the customer with respect at all times. Remember that a customer might only use your product once in a blue moon. Cut them some slack when they're slow, or uncertain, or just plain don’t know something.
• Keep the customer in the loop. This can be as simple as an aside or follow-up email explaining what’s happening, or why it’s not happening at the moment, and when it will.
• Summarise back to the customer. Be sensitive to their knowledge of, and desire for, technical detail. First, it’s respectful and polite to do so and, second, they may be able to contribute additional information. Sometimes you'll be called upon to summarise to a person who wasn’t on previous calls, in which case bear their context in mind too.
• It is important to appreciate the customer’s emotions. They might be angry, but that's usually born out of frustration and an inability to do their job or meet a deadline because of the issue they have.
• Try to keep your own emotion out of the conversation. Try to listen and remain sympathetic to their issues.
• Listen to the customer. In fact, don’t just listen, really work hard to hear what they're saying. Don’t shy away from asking if you’re not sure what they mean.
• Time delays are frustrating. Think about what can you do to get faster turnaround for the customer.

Seeing Things From Their Side

• Don’t be pedantic. The customer isn’t immersed in your world, so they won’t talk about things the way you do. Ask for clarification on what they mean and use that as an opportunity to introduce common or standard terminology if you feel it would be helpful.
• Be mindful of your language. Use an appropriate level of specialist language, be that domain, company or technical. Avoid using words or expressions that may be perceived as detrimental to the product or company.
• Some customers are incredibly sensitive to terms like known issue — “if it was known, why wasn’t it fixed before I encountered it?” — and others will read you taking responsibility for a problem in your product when you say bug but be happy that the cause of an issue may be undetermined, perhaps in the environment or something they’re doing that’s non-standard.
• Be clear when asking the user to perform any action. We think this is so important we’d even go so far as to say be exceptionally clear.
• Do ask your question again. If you don’t get the information you think you need to progress an investigation, you may need to keep asking. (Within reason.)
• Don’t ask your question again. On the other hand, If you’re struggling to get that information, ask yourself why they're not providing what you need, and how you could make it easier for them.
• Do provide suggestions. For example, a user might not think to provide a screenshot, or copy-paste an error message, or send the logs rather than describe a symptom.
• The medium can be the message. Although you might start on a call, it’s wise to remember that another medium (phone, video, email, support ticket, …) might better suit the customer at times.
• The customer just wants it to work. Typically they don’t care about whose fault it is, or how technical the problem is, they just want something that is blocking them to go away.

Setting Boundaries

• Be prepared to apologise. Note that this is not necessarily the same as taking responsibility for whatever the problem is. One way to start might be to say “I’m sorry you are having this trouble, let’s see if we can work out what’s going on”.
• Take responsibility for the problem. When it’s clearly or likely to be the fault of your company or your product.
• Don’t make promises you can’t keep. Customers are often prepared to wait but will judge you by your say-do ratio and that will influence your company’s image.
• The customer may not care about why. Some customers don’t want to know the nitty-gritty detail of whatever the problem is. They will just be happy to be told it’s working now, so don’t force the reasons down their throat.
• Know the limits. Understand that there might be company-sensitive information that you can’t discuss. It’s worth asking others on your side what this may be if you haven’t been explicitly told.
• Keep customers separate. You probably shouldn’t just refer back to that other customer who had the same problem, particularly not by name

Recording Interactions

• Share data. Internally, give everyone involved access to all of the data about an issue.
• All of it. Yes, really, all of it. The data will be extremely useful when handing over calls, or picking up a call from a while ago, and also for just keeping a track of what has and hasn’t happened. (If you’re questioning “all of it”, you’re right. We mean all of it that isn’t sensitive for some reason such as revealing commercial secrets, personal details, requiring certification or specialised training and so on.)
• Store it consistently. Having silos of information in email threads with a restricted audience can be at best frustrating and at worst detrimental to an investigation. How frustrating would it be to discover that the answer you need was in a system you don’t have access to or didn’t even know existed?
• Use appropriate tooling. If you have a support call tracking system, use it.
• Consider video. Occasionally, we have asked customers whether we can record a call, for example using a video conference tool. This can be useful later to go back over the evidence collected, perhaps looking for details that were missed the first time.

So that’s set the scene: we’ve introduced support calls and given some basic advice on interacting with customers. In the next piece, we’ll suggest the kinds of preparation that might make sense before being on a call.

Key Takeaways:

• Technical support skills overlap with other roles.
• Direct engagement with customers is special.
• Put yourself in your customer’s place.
• Most customers are not experts in your product.
• Most customers just want their problem fixed.
• Take responsibility where appropriate.