-
Posts
-
Carolyn has some great points in that article that I feel are SUPER important. I do however think there is a balance as well as slightly different way of accomplishing the same goal.
First off I 100% agree with the fact that, if 100 people ask the same question - it’s not them.. it’s you! Clearly there is a break down in the user interface, messaging or work flow of your app that is causing customers confusion. So simply providing the answer for customers to read online is not a solution - it’s a bandaid. The problem still exists and people are still having it, your team simply doesn’t have to hear about it anymore
So it’s very important that you learn these issues and then address them as a company. The only way to do that is to have your data Now you can get that from first hand contact (phone calls, emails, tweets). But you can also get it from good analytics tools and solid self service portals.
We realized that 3% of our entire support workload was related to the same problem. We showed product how much of a burden this was on our support team - but more importantly our customers.. and now we are changing our system to prevent this problem. That is a prime example of what Buffer practices. We learned that lesson from LOTS of phone calls and emails as Carolyn had mentioned.
On the other hand though, with a solid self-service and analytics tools you can also see data on how ‘big’ an issue something is. If you can still see stats of whats being viewed, search, etc. this can still be an affective channel for you. So this gives you another source of data to mine in order to find potential problems. If 500 people a week are reading the same FAQ or watching the same video, then it’s probably another example of a ‘bandaid’ that you should fix.
I know Carolyn isn’t saying don’t offer self-service. But I think the idea of handicapping it can be problematic.
A good self-service portal can provide answers to customers during the hours that your support isn’t open (if you are not 24/7). Allowing these people to quickly and easily find their answer can make them happy and save you from adding extra bodies to your team. If you hold back on your self service options though, they can have a poor experience. This is something we’ve experienced in the past. We were super helpful and got them an answer, but it was too late - they needed help NOW.
Most people like that when they call us the phone rings twice and we answer. Or they email on their coffee break and have an answer before they go back to work. However some people simply don’t like having to reach out to us. They want to be able to find the answer without reaching out. So impeding their self-service options can leave them frustrated.
As well - there are often smaller ‘problems’ that arise for a small subset just because of unique workflows or particular needs. These problems may not be something you can “fix” - as it would negatively impact the normal workflow for the vast majority of users. Your already well aware of them and have decided not to change to fix this.. however the customer doesn’t know that yet, so they reach out to you. You’ll probably have work arounds or other instructions for these people to help them out as well as explain why you can’t do what they want. Since it’s a small group it shouldn’t be a big deal right? But what if there are a bunch of little work arounds like this? You know what they say about 1000 papercuts Total it all up and this can become a burden. You can always prompt these guys to reach out to - but at some point you’ll start finding yourself bogged down like Carolyn said. And that just leads to an overall poor customer experience.
At FreshBooks since we do phone support - the scaling issue is even further compounded for us. Phone’s don’t scale nearly as well as pure email support. So we have to be smart about what battles we pick. If we can still stay in touch with what issues our users are facing, while reducing support load - it means we can spend more time creating a better experience with every customer interaction. This is why one of the big things we are looking at now is a solid self-service system (our current FAQ is not great).
To be super clear though: We’ll never push a customer to an FAQ over contacting us. But we’ll at least give them the option.. and maybe reduce a little work load in the process.
wow.. I typed way too much
As someone that has worked on the front lines of support as well as managed the support process and bug escalations, I truly love what they are doing.
I think the biggest obstacle I’ve found in accomplishing what Carolyn has explained here is getting buy in from the development and management team to put more priority on incorporating necessary UI changes to address these pain points. It’s often the primary goal to build new and innovative tools/features to help grow the business and gain more customers. So in other words, there is always that fine balance between effort put into retaining customers and getting new customers.
I do agree, however, with @Evan that zero documentation isn’t a great idea. This is supported by @philt‘s comment about after hours requests. During support hours or after, I know I am definitely the “suffer silently” type. Only because I know there are work arounds or I am under a time crunch in my day to get something done. Not to mention that with my own high standards on receiving customer support, I’m not very keen on waisting my time with a rep that won’t quickly (read instantly) understand what I am saying and what the answer is. It’s more work than it’s worth. So documentation is very important and an incredible search tool to find that answer is the workhorse behind a stellar KB.
I enjoyed the article, and think she has some valid points. Are you creating articles as a bandaid for existing issues that should be addressed?
However, for those issues to be addressed you do have to have buy in from development and management as @andrewmoyer said, but your company also has to have the development resources to act on all these pain points relatively quickly.
I also think the article overlooked what does the customer actually want? I, as a customer, do not want to have to contact support. Ever. That is my last resort because it uses up more of my time.
Getting on chat, typing up an email or even making a phone call wastes my time when I could skim an article in 1 minute and get the answer.
Some users never want to have to search a FAQ, but others do. Hiding your contact information and making them use your FAQ, isn’t user friendly. But on the other hand, neither is not publishing help articles and forcing users to contact you to get the information the help they need.
Having both is the best option IMO because how users want to interact with you and get help will be different.
While the core message - use the support feedback loop to identify and fix problems instead of just documenting workarounds - is a great message, the article as a whole is dangerous.
Writing documentation / FAQs / KB Articles is about empowering your customers and your staff. Good documentation gets linked by power users any place that user’s are talking about your product. Good documentation is a resource for your support team to reduce the duplication of effort in helping customers as well as educating them on parts of the product they may not be familiar with yet. Good documentation allows customers who are on your website to quickly resolve an issue, reducing the number of tickets your team gets (which is a bad thing according to the article).
Simply, we don’t learn anything if customers finds the answers themselves on a forum or knowledge base.
If simply having a forum and KB articles meant 0 support requests, that would be pretty awesome. That would free up our team to be proactive instead of reactive. Unfortunately, this just doesn’t happen.
If you have a knowledge base article on an issue, it is likely that you received a significant number of support requests that prompted your to create the KB article in the first place. When you spot a trend like this, report it to the people who can fix it. But fixes take time - sometimes minutes, sometimes years. Until that fix gets shipped, KB articles are vital.
The article implies that KB articles and forums negatively impact the feedback loop. In reality, they give you additional metrics by which to better understand your customers and the issues they are experiencing. Hits on KB articles over time can be interesting. Even more interesting is search log data. Search data can help you to better map internal terminology to customer terminology.
…we ask customers to email, tweet, or live-chat us each time instead
You don’t need to ask your customers to do this because they will be doing it anyway. Whether it be Reddit, Twitter, or your own forums, your customers will be talking about you and your product.
On a slight tangent, I’m not convinced that offering official support through social media or anything outside of your control is a good thing. By funneling users through your website, you have complete control of their experience. You also have better metrics (you decide what you want to track and how you want to track it).
This is a real conundrum for us too. I agree that in a perfect world, all question-causing things in your product are dealt with by better product development. But time from the folks who need to do the development work is hard to come by. So I’m like “Okay, can’t wait to see this new, perfect, shiny feature. But in the meantime, here’s a help doc.”
You must be logged in to reply to this topic.