In one of my previous roles before I decided to move completely over to test, one of my responsibilities was e-commerce customer support coordination. Over the tenure of my contract, my goal was to streamline e-commerce customer support, find major defects and UX trip-ups which had found it's way into production, reduce time-to-ticket-completion, and reduce overall ticket volume, because e-commerce customer support calls were taken by the same team as call-centre sales. Overall, enable the company's e-commerce to scale without havoc on the customer support side.
I had the interesting challenge of working with sales and customer service staff on IT problems that had no IT training. Of course, it's all trainable, so that wasn't really the issue. The issue was finding ways to work with each staff member. In the end, I used a combination of documentation, training over-the-phone, and demonstrations.
Back to the start.
As support had no tech background, the following issues were occurring, and I did this too when I began in the role.
- Reporting every single defect as high priority.
- Missing major defects because they don't understand why it is an issue. They either don't consider it worth checking, or it simply doesn't occur to them. They put it in the bring it up later basket. In more sophisticated companies with observability and monitoring set up, these issues might very well be caught by SRE. If you don't have that set up yet.....
- Issues were more difficult to replicate, taking senior support, QA, and dev precious time to divine from a few scattered sentences.
While in most cases support may have the technical skills, they are often missing the business context. And even if they do have commercial awareness, they may still be missing crucial information on what is important to the particular business they're working for.
That's why it's super important for business to share with support their perspective on criticality and severity, impact and likelihood, and invite support to share theirs back.
So, what does bringing engineering closer to support look like in practice?
Well, this is what I did.
Improving your defect replication process
Standardise your defect replication process, and strengthen it.
It should have at least the following:
- Exact steps to replicate the issue.
- Any error message that was given by the system.
- Exact environment details in which the issue was replicated. Eg: Browser, OS, signed in/signed out, version of the software etc.
- Actual Result that you get as of now following the replication steps.
- Expected result from the functionality in question.
Also:
If possible, screenshots &&/or video.
Shorten the feedback loops
Befriend a few customers with a software or IT background
While they most likely won't be representative of your typical customer, they will have more technical knowledge than said typical customer and may be better at explaining where they are having trouble.
Have a senior support person talk to them regularly about the product. How regular depends on how often they use the product and their most recent experience with it.
Request screenshots &&/or video if they run into trouble.
Have product owners regularly talk to support
If your support agents don't understand what the customer is talking to them about, enable them to talk about it with skip-levels. Have customer support in the room during product ideation. This requires building psychological safety in your team. They have to feel, and have to know, that you consider no questions stupid.
Embed support with engineering
I was a marketing assistant embedded in the engineering team with support responsibilities. As we had a small team, this enabled me to coordinate multiple teams without taking my manager, the Director of Innovation, away from bigger issues. Give read access to Intercom/Zendesk and Jira/Trello to people from both sides. The company I knew with the best understanding of its customers and highest growth share the customer support chat logs with development and the bug tracker with support from the start. It helps eliminate misunderstandings, and provides further clarification.
At the company I coordinated e-commerce customer service for, I eventually started reviewing every e-commerce ticket which came in. The customer service/call-centre sales team was run off their feet, so I had the time to pinpoint their bring it up later patterns, and could set priority by noticing now many customers were irritated, and how much revenue it was impacting. It also enabled me to prepare more comprehensive pro-forma responses which covered more than the standard case.
Simplify your documentation
Use Plain English - short, simple, words. My principle is that it should be able to be understood at first glance by the most pre-occupied, busiest person in the team.
Aim for no higher than 4th grade level. If you have a highly technical product, that may be difficult. In which case, apply that rule to everything except the jargon, which could be explained in-line in the docs. Ask your support team what they don't understand, and why. Then rewrite it.
Make it pleasant to read. Add spacing between paragraphs, use good headings.
Add context
In internal documentation, talk about the software architecture / user experience thinking / business structure/process that led to the workarounds / process created. It saves time for later if you ever decide to ~refactor~ your systems, as you'll have your company's institutional knowledge written down.
Don't assume knowledge
Are there steps between the steps which you just expect support or your customers to know? It may feel ridiculous for you, but you are not your customer.
Put it in the knowledge base.
This makes life easier for new customers and new hires, and people who just have a lot on.
Make documentation easily available
Easy-to-find, easy-to-search FAQs
Tech support is often asked "basic" questions by customers who either don't want to look at the documentation, or aren't very comfortable with technology. Both groups can be gently directed to the documentation after being given the initial set of instructions, but it has to be easily found. With chats, you can send them to the exact link. However, with phone, they'll be back quickly if you just hand them a generic link.
On your marketing website, have a collection of well-organised, searchable frequently asked questions.
Ask a new hire to read this documentation and tell you what they're missing details on when they try to replicate the steps as part of their on-boarding activities.
Place workarounds prominently in internal documentation.
Develop in-depth up-to-date product knowledge
Run internal demonstrations on new features and bug fixes for support. Run walk-throughs. Have support be the first users.
Have your more technical people take time out to explain concepts to less technical people. In my company, that was the developers talking to me, and me talking to customer service. In fact, I was on-call. When customer service wasn't sure how to handle an issue, they were advised to get the information they needed to replicate the issue, and then send it straight up to me.
The results
In the company I worked for, we had...
- Better quality bug reports.
- Issues solved faster.
- Maintenance of good social capital between customer service and the developers.
As an aside
- A few of the salespeople I trained in tech talk moved to sales roles at tech companies after.
Remember, anything worth doing is worth doing right, and sometimes that means spending what feels like an uncomfortable amount of time on it upfront.
Top comments (0)