Reading:
Before A Support Call
Share:

Before A Support Call

When Support Calls: Helping Your Support Team To Help Your Customers: Article 2 of 4

You have been asked to go on a support call with a customer. You are not a member of the support staff. You don’t know what to do.

In the first article in this series, we talked about what a support call is, why a customer would initiate one, and some of the rules of thumb we’ve developed over the years to help us do a good job when we’re invited onto a call.

What we’ll discuss next are the kinds of things that you can consider in preparation for a call. In later articles, we’ll describe the call itself and what to do when it’s over.

You’re Going To Be On The Call

So it’s happened. There’s a support issue and it’s not an easy one to resolve, or it would have been resolved by now. You have been asked to be on the next call for your diagnostic capabilities, your product knowledge, your idea generation, your domain expertise, your experience with similar issues, your capacity to comprehend complex issues, your ability to see things a different way, or some other value that it’s perceived that you can provide that others have been unable to, so far.

This may be daunting, but however it ended up in your lap, whatever your own feelings about being in front of actual customers, and whoever the customer is, you should treat the request as a point of professional pride: someone needs help and thinks you can supply it.

You can try to reduce your level of “daunt” with some preparation. A poor first impression can sour the customer’s trust in your advice. The particularly good news (especially if you don’t fancy being on a call that much) is that you may be able to avoid a call altogether if you can identify potential new avenues of investigation by standing back and providing a fresh view before the call even starts.

Gathering Background Information

By the time you get involved there will typically be some kind of trail for you to inspect: a support ticket, references in bug tickets, support staff notes, or just a conversation with whoever asked you to be on the call.

If other people already familiar with the issue are available, you might talk to them about what they know, what they’ve tried, their relationship with the customer, and the outcome they want to get to.

Don’t forget that this is not the first issue that there has ever been with your product, and probably not with this customer either. There’s likely some historical data that might give at least some context and possibly a solution. Here are a few sample questions you might want to ask as part of your discovery process:

  • Does the customer have a pattern of behaviour that might be relevant here?
  • Has the customer encountered this specific issue before?
  • Has another customer encountered it, or something similar?
  • Have we encountered it, or something similar, internally?
  • Has this problem been described in a bug ticket before?
  • What is your company's relationship with this customer?

Don’t forget to search the resolved bug tickets as customers are often several versions behind what you’re working on day-to-day. Similarly, closed support requests can be a goldmine, as can any kind of manual, FAQ, or knowledge base that your company maintains about your product.

If you have error messages from the customer it’s worth thinking about searching your source code for them, and don’t neglect external resources such as Stack Overflow or searching the internet generally. For example, it could be the case that some behaviour is coming from a library or other component used by your software and there’s information out there that can help.

Thinking About The Problem

Try to find time to think about the specific issue in advance of the call. You might ask: do people really go into calls without thinking about the specific issue?

And we would reply, simply: yes sometimes they do. And if the call goes wrong, perhaps by stalling right at the start because no-one has a first idea on how to proceed, it can lead to a poor impression with the client. Even if you are the Winging It World Champion we would strongly recommend spending a small amount of time in preparatory thinking.

Don’t be afraid to use this time to apply sympathetic scepticism to any data you have been able to gather. It’s not unusual for it to be indirect, incomplete, or vague: the support staff’s report of what the user said about what they thought probably happened in the software when they did something that they can’t quite remember.

Thought-provoking Questions

At this stage in our preparation we find meta questions like these useful to provoke problem-solving thoughts and test our understanding of the problem:

  • Can I describe the environment and relevant components?
  • Can I explain what has been done?
  • Can I find examples of what we did in similar situations?
  • Can I see any inconsistencies, any missing information?
  • Can I identify where assumptions have been made?
  • Can I think of evidence which, if we had it, would help?
  • Can I think of what a solution might look like, if there was one?

Digging Into The Details

The suggestions that we’re making here won’t break down as neatly as our sections might suggest. For example, while gathering background data you'll naturally have questions which will lead you to think about a specific aspect of the problem. These, in turn, will generate more detailed questions and prompt you to seek out more data.

We think that the ability to generate and ask relevant questions is at the heart of being a good tester, and also a strong skill of those who excel at technical support. At this stage, questions help you to identify useful context and perhaps make connections between pieces of knowledge that are distributed across the people, and systems, that have been involved in the support issue so far.

Detail-gathering Questions

These are the kinds of questions we’ll generally be asking ourselves in advance of a call:

  • What was the customer doing when the issue occurred?
  • What were they intending to do?
  • What is the effect of not being able to do it?
  • How long have they had this problem?
  • How angry are they about it?
  • Is the problem repeatable by them, by their colleagues, other customers, us?
  • If this problem is in an area that they believed worked for them previously, has something else in their environment changed?
  • What do we think the problem might be? Why?
  • Do we have a workaround for them?
  • What are you, the tester, being asked for? To observe, to drive the meeting, to act as an expert, to stick your oar in whenever you feel like it?
  • Is there something that you should not do?
  • Are there suggestions you should not make?

Do be prepared to ask these last questions and don’t be offended by whatever answer you get. Your pride is less important than the outcome for the customer.

Sometimes when asking questions you’ll find holes in the story, or identify assumptions that have been made on one side or another, or both. Bitter experience has taught us to be very wary of assuming anything about how the customer is using the product.

Establishing Ground Rules

You probably won’t be on the call alone, particularly if this is your first time. Check with whoever is running the call on your side about what they know, what they want from the call, and what they want from you.

Agenda-establishing Questions

The following are questions you could ask the person organising the call:

  • What is the purpose of the call?
  • Is there an agenda or a planned structure to the call?
  • What kind of outcomes are expected?
  • What kind of outcomes would be acceptable?
  • Who will be on the call from your side?
  • What roles are they going to play?
  • What role should you play?
  • How should you signal that you want to speak, or mute the call?
  • Are you expected to take control of the customer system remotely?
  • Is it possible for you to do that if you think it would be helpful?
  • Are there time constraints? If so, what are they?
  • Is there something you are expected to have produced for the call?
  • Do you need to send anything in advance of the call?

It can be also be very useful to know who will be on the call from the customer side in advance, what their position is, what their relationship to the problem is, what access they have to the system, what attitude they have towards personnel, the company, or product, in general and also right now. The customer with whom we have a generally good relationship but who has a problem is likely to be a different proposition to the customer who has hit problems every step of the way and is now stuck in another.  

You may want to speak differently to a manager who hasn’t yet seen the value of your system, and someone who’s using it every day, loves it, and just needs this roadblock removed.

You might also consider how you want to be introduced. One of the authors always introduces himself as an engineer on the product development team. He found that the term tester doesn't mean the same thing to all customers.

Setting Up Test Environments

Depending on the issue, and other practicalities, you might set up a test environment that’s as parallel to the customer’s as possible. Or, at least, to what you understand the customer’s situation to be. Noting down places where you have to make guesses can be a useful process in helping to generate routes for further investigation or clarification.

Any logs, stack traces, database dumps, and so on that have been gathered around the issue can be invaluable for getting some confidence that the system you are building is like the customer’s in whatever respects you consider important.

Having a rig like this gives you the opportunity to run some experiments before the call, or generate some questions for the support staff to take to the customer, or gives you something to try in parallel with the customer on the call.

Don’t underestimate the value of telling the customer that you’ve set up an environment like theirs and have been trying to reproduce the problem, even if you’ve had no success so far. This is evidence that you are taking them seriously, that you are trying, that you want them to succeed.

Summarising Your Preparation

After doing your prep, consider drafting a summary of the issue and what you’ve found out about it. Maybe come up with a list of hypotheses and a set of questions to help you to see whether any of them hold up. This can be used, as needed, on the call, so that you’ll have something to fall back on when investigations aren’t going anywhere.

If you think you might need to ask the customer to run some commands on their side, generate them in advance and have them ready to paste into a chat message or email across. You can often get file system paths from earlier support ticket conversations.

If you think you’re going to need to ask the customer to perform a set of steps by hand, go through them yourself and note down the names of the various buttons, dialogs, options and so on. You don’t want to frustrate the person you’re trying to help with ambiguous or incorrect instructions.

On some calls, you may ask or be asked to take control of their system remotely. We recommend offering to do that if it’s technically possible and entering complex commands is not going well.

This kind of preparation can convey an air of confidence to the customer and help to reduce any sense of doubt on your part when the call begins. The next article will pick up at that point: being on the call.

Key Takeaways:

  • Don’t worry, you’ll be OK.
  • Find some time to prepare for the call.
  • Look for existing data and knowledge.
  • Understand the context of the call.
  • Understand your role on the call.
  • Consider trying to repro the issue.
  • Summarise what you know
  • … and what you know you don’t know.
James Thomas's profile
James Thomas

Quality Engineer

I'm Vice President of the Association for Software Testing, a non-profit organisation dedicated to the advancement of the testing craft. Over the years I've had many roles including developer, technical author, technical support, and manager, but the combination of intellectual, practical, and social challenges in testing are what really excite me. I blogged about my Test.bash() 2022 API Automation Challenge entry in https://qahiccupps.blogspot.com/2022/10/having-testblast.html

Neil Younger's profile
Neil Younger

Neil Younger has been helping to build successful products and happy teams in the UK for the last 20 years. From working with desktop applications to databases, banking to browsers, security to silicon, Neil continues to shape his craft and put people first.

Chris George's profile
Chris George

Chris George has been a software tester and question asker since 1996 working for a variety of UK companies making tools for database development, data reporting and digital content broadcasting. During that time he has explored, investigated, innovated, invented, planned, automated, stressed, reported, loaded, coded and estimated on both traditional (waterfall) and agile software teams. He also presents at software conferences on testing topics and sometimes writes a blog at Mostly Testing.



Ask Me Anything - Soft Skills
99 Second Talks - TestBash San Francisco 2018
How Admiral Group Automates
99 Second Talks - TestBash Manchester 2018
Continuous Performance Testing - Eric Proegler
Testing Language Models With The Philosophy of Wittgenstein
Explore MoT
TestBash Brighton 2024
Thu, 12 Sep 2024, 9:00 AM
We’re shaking things up and bringing TestBash back to Brighton on September 12th and 13th, 2024.
Improving Your Testing Through Operability
Gain the tools you need to become an operability advocate. Making your testing even more awesome along the way!