Ending A Support Call

So far in this series on testers and other non-support staff joining tech support calls, we’ve covered what support calls are, why a customer might initiate them, how to prepare for them and how to behave during them.

There are a few things obviously missing from that list: when to draw things to a conclusion, how to end calls and what to do afterwards. Finding a good way to exit can be challenging, but manageable, with a few agreed upon signals and a firm goal.

Resolution

What counts as a resolution? That’s a good question. We might also add to which parties, and when?

The primary party is the customer. The primary resolution for them is that they're able to complete (to some acceptable level for them, right now) whatever task they were trying to do when they encountered the problem that prompted them to call you.

In some cases, this could mean a software fix, but in other cases it might mean a workaround of some kind, perhaps a different route through your product, using a different browser, or installing some third-party tool. Or it might mean that you have to help them pose a question to their internal IT group about their own infrastructure, offer to process some data for them, or provide some free consultancy to help them understand the software better.

Finding candidate workarounds can be seen as parallel to generating test ideas. In your day job, you’ll have a piece of software and you’ll be trying to think of scenarios in which an outcome might not be as expected, based on your knowledge of the way the product behaves.

To generate a workaround, you are trying to think of scenarios in which an unwanted outcome is avoided, based on your knowledge of the way the product behaves. This can sometimes mean doing actions in a different order, finding different ways to perform the same or comparable actions, finding a way to create a subset of the outcome that is sufficient for the customer’s needs, finding an alternative outcome that satisfies the customer, and so on.

In some cases, the customer was just doing the wrong thing or, at least, doing something that wasn’t consistent with their intention. Be extremely cautious about putting this down to user error without further consideration. Ask yourself questions like these:

How did they get there?
How well did the product protect them from themselves?
To what extent did the product lead them into the bad place?
What could we change to make this less likely in future?

Sometimes an acceptable resolution is not reachable. If you’re lucky you'll have a set of partial solutions with pros and cons which can be proposed. This can give the customer options and shows you have been thinking about their problem.

If you can’t give the customer options, then the next step is to be clear about what you’ve tried, what you know as a result, and what you suggest you'll do next, if it’s possible. Although it’s hard, sometimes the right answer is not to invest any more time in trying to resolve an issue. This is generally not your call, but you might be asked to provide data to stakeholders to help them make the decision.

Being upfront and open during attempts at resolution can build up trust which can make future tough conversations easier to have.

Even if you do provide some kind of fix for the customer, it might be only the first level of a resolution. When the issue the customer saw is likely to recur then resolutions which are effectively one-offs don’t look as appealing. That’s especially true when the cost of those resolutions, or the frequency of those issues, are high on either your side or the customer side.

A second level of resolution might be needed to provide longer-term customer satisfaction and reduce future support effort and expense on your part. There might be some configuration changes on the back-end of the web service, or an improvement to the documentation associated with the product, some change in process for the customer registration, or a software fix.

Often a support ticket could be marked as resolved while some other ticket — like a bug against the product — remains open. This reflects the immediate and longer-term aspects. We’ve talked in this series about shared understanding and terminology and it’s relevant at the close of the call too. As one of our reviewers pointed out, the term “resolved” can be controversial to customers. To you, it might be the status of a ticket, but to them is the status of the problem.

Use this opportunity to close the feedback loop. Now that you’ve seen how a customer uses the product, you can add your observations to the bug ticket or enhancement requests. Although do remember that one customer is not every customer — the plural of anecdote is not data — so don’t jump to unwarranted, general conclusions without data.

Signing Off

As with the introductions, you’re unlikely to be called on to wind up proceedings yourself. Usually whoever is leading the call from tech support will take care of business, although in our experience, it’s reasonably common for you to be asked to summarise your findings.

Depending on how far you got towards a resolution this might be a kind of au revoir where you are telling the customer what next steps you, they or both of you are picking up, and when you'll be back in touch.

When delivering bad news about the (potential for) resolution, it’s important to be upfront with the customer. We’ve found that customers generally appreciate the truth, and generally like to understand why that’s the truth as you see it. When you aren’t sure, say so. For example, if you are asked to provide an estimate for some investigation before the next call, a non-committal timescale can be acceptable, as long as it’s realistic and justifiable. Providing a workaround in the interim can help to make extended periods without a fix more acceptable to customers.

Regardless of the resolution, we recommend that someone from your side says something like “Please don’t hesitate to contact us again with any further issues or general feedback on the product.” It leaves the door open and, regardless of the outcome of the call, shows that you value their opinion.

Even if not called upon to speak at the call’s conclusion, it’s a good exercise, and a good learning opportunity, to think about how you would summarise the experiments, your findings along with the risks and value of them.

This should be a very familiar interaction, similar to those you regularly have with stakeholders on other projects. The added pressure of wanting to get it right when you’re representing your company to people who pay for your services can be daunting, but manageable with planning and practice.

On some occasions, such as when an issue was particularly hard to track down and we’re not sure that we’ve managed to resolve it completely, we have tried to follow up with a customer later. Typically, the primary contact for the customer will be someone from technical support, so it’s probably a good idea to check in with them before initiating direct communication.

After The Call

Support calls, especially the “how do I do X?” ones are great opportunities to learn and improve the usability, accessibility, and discoverability of the product. It may be a language/terminology issue, it may be that the customer has a very different expectation or works in a different context which supports a perspective that hadn’t been considered. Gathering this kind of information and delivering it to the relevant people can create visibility for quality issues.

Ask for feedback from the tech support team and use it as a way to improve your own customer interactions on calls. A few things you could ask are:

What weaknesses did you perceive in my knowledge?
Did I handle a tough customer interaction correctly?
What could I do better for the next customer engagement?

Remember Why You’re Here

Being in front of a customer, and in particular working on a problem in front of a customer, is an education, and not only in communication skills.

Providing support can be a connection between the teams inside your company and the real world. It can remind you and your colleagues that, yes, there is life outside the bunker! It can also highlight the reality gap that sometimes exists between those who create a product (beautifully-designed and achingly clever) and those who have to work with it (non-standard and painfully fiddly). Or the other way around; it’s interesting when customers don’t care about something that really bugs you.

Talking to users of your software can remind you that there is no the customer but rather many individual customers. It is part of the job to build a picture of the specific customer you’re engaging with to help you to frame technical answers, questions, and suggestions in terms that they will understand.

Building a good relationship with your colleagues in tech support can provide you with access to the knowledge and experience of a set of people who represent and understand customers. They are likely to be motivated to give you feedback on product changes, use cases for features, and customer-like perspectives on issues.

Supporting customers exposes you directly to the data, workflows, problems and frustrations they have. This information can be brought into issue triage, feature design, prioritisation, and testing strategies. Support is a source of feedback that enables product improvement.

Keep in mind that this kind of work is unlikely to be cost-free. We know of one team that resolved to respond to all product crash reports on a daily rota basis. This gave the team deep insight into their customers’ usage and pain, but it was a huge time commitment. Nevertheless, the team felt that it was the most valuable action for them to take at that point.

Other Customer Interactions

After being on support calls, you might like to support customers using alternative mediums. Additionally, you might like to see what ways you can find to create knowledge repositories of common problems for use in support.

If your company has online forums for its products, you may be able to engage more informally with customers. Or you might prefer to simply read the contributions of others to get a feel for which bits of your product they're talking about, and in what terms.

If your company offers FAQs or knowledge bases, you could contribute material to them. This can be immensely rewarding, especially if you find that a particular entry is being referred to by support staff, or is showing up frequently in usage logs. (Although you might then wonder whether there’s a product issue that needs to be fixed around it.)

If your company offers training, webinars, conferences, user group meetings, UX research calls, focus groups or the like, you might be able to sit in on them and observe, or take part alongside your customers, or attend as a facilitator.

If your customers are on social media, you might be able to converse with them either as a private individual or as a representative of your company. However, note that even if you are using a personal account, you may be governed by company policy and the customer is still likely to see you as a representative of the company.

Thank Goodness It’s Over!

We’ve explored some of our experiences of providing technical support while not working in technical support. We’ve talked about why customers want or need support, when they’ll ask for it, what kinds of skills are useful to you when you’re asked to back your tech support team up, and the kinds of services you might be asked to provide on calls.

We’ve learned about how you can prepare for calls, how you should behave on them, and what you can get out of them: for the customer, for your company, and for yourself. It’s our feeling that engaging with your customers will be of benefit to your day job too. Remember, ultimately, we all serve our customers and so understanding them better give us the opportunity to do that better too.

Support calls can be time-consuming, frustrating, and embarrassing. Support calls can also be exhilarating, joyful, and extremely satisfying. When you close a call and the customer who was stuck is now unstuck, and you can feel their gratitude surging down the phone line, then you’ll know you’ve done something worthwhile that day!

Key Takeaways:

A resolution might not mean the issue has been fixed.
Be alert to the possibility of a workaround.
… and be able to explain any compromises it entails.
… and what options the customer has.
Let the customer know you value them.
Identify takeaways for you, for the product, for the company.
Relax, you did good!

Acknowledgements

Thank you particularly to Dom Walden for asking that first question, to the Ministry of Testing, and to our reviewers Paul Gilson, Chris Kelly, Ros Shufflebotham, Karo Stoltzenburg, and Marco Vicente for valuable comments and suggestions on earlier drafts.