How to train customer service team to better describe issues

Question

We run the development team in an agile mode. We have agreed that we will have a place called the "Inbox" so that people in the customer service team can report bugs or important issues so we can estimate and decide if they go in the current sprint based on their description.

However, numerous times it happens that we get issues which are not described well, missing screenshots, links, or steps to reproduce the issue. Also, people who report the issue try to offer a solution from their own understanding of the system, and this is wrong for many reasons, the most important being that they hide some important observations when they switch to solution-mode.

I don't think people need to be technical to describe an issue with enough details that the development team can plan it properly, but it requires holistic thinking and being good at describing the facts and giving some indication of why the issue is important for them (how many customers complain, what they do to avoid/work around it and how much time it takes, etc).

The current process that we are having requires to do a lot of back and forth until we understand the main issue, losing time and focus from actually planning and executing.

What we tried

• bring focus to this problem generally to the customer service team
• creating a template card that they must copy which contains examples of good practices - it has not worked because people didn't copy the card
• making a video, explaining how to better describe issues and send it to everyone in an email
• when seeing an issue that was not well described we took to the person creating it and explained how they could have written a better explanation - We could notice small improvements for individual members but the overall story is that most people still don't describe the issues well enough and we end up spending a lot of time talking to them about the specifics

None of these has worked in the long run and people still fail at the basics of describing an issue well - and we do not have a process when onboarding new customer service members.

Besides this, I want to add that we do not have native English speaking members, but we do all communications in English. I also feel that people are rushing into writing something down quickly instead of taking time to think how their message is going to be received (is it clear enough).

For me it is quite obvious how they are failing to describe the issues, but I do not understand why they lack the motivation to do something about it and what the best long-term strategy to improve this would be.

Do you know of any techniques, ideas, principles to how we can approach guiding or training the customer service team (or any person) to become better at describing issues?

Let me know if you think I have a wrong or incomplete understanding of what a well described issue is, I am eager to become better at this myself.

Answer 1

A form-style template can work well for this sort of thing (if I read your post correctly you have tried something like this with your template card) and, remembering that customer services staff will have other tasks that they will be wanting to get on with, the key thing is to filling the form out to be the path of least resistance and ensure that the minimum information you need to tackle the issue is explicitly formed as certain questions on the form. e.g:

System(s) affected:

Number of users affected:

Steps to reproduce:

etc..

Try as much as possible to avoid free-form sections and really guide them into giving the specific answers you need. Obviously tailor this to your requirements! If there are any individual customer service staff that you have a good rapport with then see if you can get them to test out the form with you before implementing it.

Where possible try to avoid presenting it as "you guys suck at reporting issues" or even "we find it difficult to work on issues with how they are reported" stress to them that the form is there to make their lives easier (which is actually true!) as people are much more inclined to buy in to something that benefits them!

And then if you can get buy in from your management and customer services management you just get firm with the line that any issues that are reported without using the form or without all the required fields filled out simply won't be worked on.

Answer 2

Ask them how you can help them to provide the information you need.

I think it's important to approach this issue with some empathy.

Customer service is not necessarily an easy job in itself and when you ask customer service representatives to add QA tasks to their existing workload it only makes their immediate workload heavier even if it might make it lighter in the long term ( which it probably won't, since refining your product and making it better should help it gain more users ).

Imagine you have an angry/frustrated/desperate user on the phone that just needs to get past this issue to get their task accomplished. Your number one goal is to solve this customers immediate problem and turn them back into a satisfied customer again. This is typically not a great time to be asking for-what the customer might feel is irrelevant-information.

These customer service reps are users of your bug reporting system and you're going to have to cater to their needs just as you would any other user of any of your systems.

Some requests might just not be realistic. Getting a screenshot of a bug from a customer is asking an awful lot from someone who may already be pretty frustrated and upset. You may have to just settle for a transcribed description of how to replicate the issue and have your own QA team try and replicate the issue and fill in the missing info you need.

Some things weve tried with some success are:

Flyers with a brief description of the most relevant information to gather that every rep has at their workstation.

Paper forms that reps can quickly and easily write details down on while on a call. It creates more work for us because we have to deal with hard copies of data, but some info is better than none.

Working closely with CS reps to find out how we can provide a solution that works best for them. This builds trust and increases buy-in in the process. They know that we understand their job is tough and are not just trying to pass off QA work to them.

Answer 3

I had to do something very similar for a reporting tool.

What I did was code the form so that it could not be submitted without everything being filled out. You can try something similar, including requiring something to be in a screenshot, like requiring a file attachment. How in depth you want to go is up to you. There is always a point of diminishing returns, of course.

If you don't want to get that involved, you may want to kick out incomplete or poorly written reports and email them back to the person filling it out, with a CC to their boss.

Answer 4

Using a template that guides the user towards required information is a good idea. Making the template mandatory (ie: "we won't address issues that aren't filled out properly") is also a good idea, if you have the authority to do that.

Another approach - if you can afford the time/manpower - would be to have one or two people dedicated to "bug triage" or "QA" on these issues. These people would receive issues from the customer service team, reproduce them in a controlled test environment, and then fill out a proper bug report for the development team according to the standards you require. (Or they would discard the ticket / send it back as "not an issue" in cases where there is no legitimate issue.)

How many people you have dedicated to this task would, of course, depend on how many issues come in per day from customer service. If there are only a handful, you might be able to get away with assigning just one person - even part-time or rotating weekly - to triage the issues. If you get a lot of issues each day (including potentially duplicates) then you might need one or more people on this all the time. As such, the biggest blocker to this tactic would be getting management to sign off on hiring people and/or dedicating them to this task rather than the stuff your team already does.

The pay off would be that the rest of you could get back to focusing on your existing priorities without interruption or back-and-forth discussion (this would be done by the triage team when needed.)