Categories Articles, Service

Jordan Munson Wistia Image

Jordan Munson is a member of the Customer Happiness team at Wistia, a startup in Cambridge that helps businesses do awesome things with video. At a recent Olark event called Customers FTW, he spoke about how productivity tools – namely, Alfred, Dash, and TextExpander – can make workflows significantly more efficient. Jordan knows a thing or two about saving time.

The support team at Wistia has a top-notch documentation page on their website that helps customers solve problems quickly and easily. I had the pleasure of speaking with Jordan about the inner workings of documentation at Wistia and what makes their support team so effective.

Read the full interview below to find out how the Wistia support team helps customers succeed.

The documentation page of the Wistia website is pretty impressive – were you involved in creating it?

The documentation that we have now precedes my time at Wistia by a few months, but since then I’ve been pretty heavily involved in tweaking it, updating the content, approving it, what have you. The documentation itself was made by Jeff Vincent. It’s kind of a custom solution for us – it’s not a help desk software or anything like that. It’s actually built off of a system called Jekyll, which is designed for blogging, static pages, and stuff like that. It’s a pretty simple system that you can use Markdown to write pages and posts in and put them within the system. It’s nice because it’s gives us a lot of flexibility, but without the cost of ease of use, which seemed to fit the perfect balance for us.

How do you decide what sort of content to put on the documentation page? 

It’s kind of a guess-and-check sort of thing in a lot of cases. More recently, it’s been informed by actual data and anecdotal evidence of things that people need more regular explanation of. Originally, it was: “Let’s compile a list of the most commonly asked questions, or things that are cut-and-dry with their answers and not particularly contextual and can just be answered with the same thing over and over again.” So we got all of those things in there and figured that was a good place to start. And since then, we’ve got into a pattern of waiting for things to crop up in support that are semantically linked, in terms of confusion and relative consistency in how we answer them, and we put those in there.

Whenever we have new features or new parts of the product that we launch, or major changes, we’ll make sure that the documentation goes out with the featured roll-out because people always have questions about new features…

Whenever we have new features or new parts of the product that we launch, or major changes, we’ll make sure that the documentation goes out with the featured roll-out because people always have questions about new features – or that we’re ready with documentation that fits what we expect their needs to be. So we just point them there, and if they are like, “Oh, well, this documentation is great, but it doesn’t answer my question,” we can tweak it and adapt from there. But it’s mostly informed by new features and new questions that come up and fit documentation mold.

The Wistia documentation page has a search bar front and center. Do you find that people ever search for things that aren’t listed on your documentation page? And do you ever add things to the documentation page based on what people are searching for?

Search is an interesting one for us, in that, it’s kind of useful, but most people who need the documentation have a hard time using it – you kind of have to know what you don’t know to get the most out of the search – you have to know certain terms that you’re searching for. If you start to use Turnstile, which is our email capture gate, you have to know that it’s called Turnstile to be able to find that phrase. So search is kind of an interesting piece that I think we want to try to find a way to make much better and easier to use. People do use it, just in a relatively limited capacity, which is why on our documentation homepage (where you see the search) you’ll see a number of links to most commonly accessed and most popular articles.

Do you track site behavior using Google Analytics? And do you find that people are interacting with your Greatest Hits?

We use a number of different tools to kind of inform those decisions. The most common one that we used for a long time was Qualaroo, but that was mostly from a qualitative feedback standpoint to make sure that people were finding what they need in our documentation, and if they aren’t finding what they needed, what they were expecting to be somewhere, what information was missing, or where their confusion was.

The other complicating factor is that we don’t make our documentation super front and center. It’s pretty easy to access if you want to go find it, but there’s obviously going to be a subset of people who aren’t do-it-yourself-ers and want to find their own answers there. They get stuck and they’re like, “Help Wistia, I have a question,” rather than Googling “Wistia Support Documentation.” And so I think the people who end up going to the documentation more are people who are more capable, generally speaking, of using documentation well, so I think our data is not exactly accurate to this full situation.

Would you say that a lot of the questions that your support team receives could be answered by the documentation page? And do you find yourself redirecting people, linking back to the documentation pages? Or in cases like that, do you just walk them through it anyways?

I think it’s a good mix. We’ve done a really good job in automating away the easy stuff and training our customers upfront to look into the documentation first before they ask us questions through support. But, of course, there are people who just won’t read, or don’t care, or just don’t feel like looking up documentation, or try to and fail. Whatever the reason, there will be always people who ask questions in support that can be answered by your documentation – finding clever ways to mitigate that is the next step of us.

…there will be always people who ask questions in support that can be answered by your documentation – finding clever ways to mitigate that is the next step of us.

But generally speaking, a lot of the stuff that comes in through support at Wistia is very contextually intense. Where, it may be answered, in piecemeal, by different parts of documentation, but – at least to the customer and sometimes to us – it seemed specific to that person and their use case, as opposed to a one size fits all thing, which is what people would expect from documentation. And so, the most common situation in support that we get people asking questions that could be answered by documentation is exactly that, where the perception is that their question can be answered by documentation, but through a little bit of custom response stuff and links to documentation, it totally can be.

What types of problems can’t be answered by documentation?

Things that are really intensely contextual and specific to someone’s use case. So for us, if you, for example, are using a content management system with a special type of plug-in and you run into some sort of trouble getting those videos to display in a slider, there’s a pretty good chance that the problem you’ve run into is one that is mostly unlike problems that other people have. And so, the usefulness of having documentation for that exact problem is not very high, so putting more information to our documentation to obscure the stuff that is more common is not advantageous for us, nor is spending the time to write really good documentation for that use case. Anything that is really narrowly-scoped to someone’s contexted use case, is stuff that documentation is probably not going to do a great job with.

For customer service teams that don’t have documentation sections on their website, what would you say they’re missing out on?

The obvious thing is the time it saves you in not having to write the same stuff over and over again and having to just deal with emails that you wouldn’t otherwise have to deal with. But the major win that you’re missing out on, if you were to have documentation, is that the correspondence you can have with customers is so much deeper and more meaningful, where you can talk to customers in a really specific way, and it’s not just copying and pasting. It’s: “Here’s your context; here’s where our documentation is; here’s stuff that’s outside of our documentation,” and the interaction you have with a customer is much more interesting and meaningful, as opposed to, “Yep, we have an answer in our documentation. Here it is. Have fun.”

But the major win that you’re missing out on, if you were to have documentation, is that the correspondence you can have with customers is so much deeper and more meaningful, where you can talk to customers in a really specific way, and it’s not just copying and pasting.

Your documentation page sounds like it saves you guys a lot of time. Is there any way to guess how much time it saves you? Do you have any idea how to quantify that? Would you say that you would probably need another employee if you didn’t have this documentation part of your website?

I don’t think we really do have a good way to quantify it, but I can almost certainly tell you that if we were to have no documentation, or severely limited versions of our documentation, we would probably need another customer happiness support person, or two. It would be a pretty severe difference, comparatively, to what we have now.

…if we were to have no documentation, or severely limited versions of our documentation, we would probably need another customer happiness support person, or two.

We’ve spent four years tooling on our documentation intensely because we definitely go by the mantra of: “Automate wherever you can, and be intensely human wherever you can’t.” So, for as many things as you can, finding the right ways to make documentation or permanent resources, or ways to nip those problems in the bud. And so four years of doing that, as one of our primary objectives, has gotten us to a really good place in our documentation where it’s pretty useful and valuable, and people know about it. Once you’ve had one good experience finding things in documentation, you tend to go back there because you know the answers are probably going to be there.

…we definitely go by the mantra of: “Automate wherever you can, and be intensely human wherever you can’t.”

As far as keeping the documentation up to date, what’s that process like? Do you primarily update it when there are big product updates? How does that work?

I think all of the different reasons in which we need to update documentation go into the same workflow. The advantageous part of having a Jekyll-based documentation is that it lives in GitHub, so it has its own repository that we can check and change. Whenever we need changes to be made to the documentation, whether it’s a new upcoming feature or some question that we don’t address well enough, or something in the product changed that we need to know, like the addition of multilingual captions, all of that stuff can be tracked right in with all the code where you make the changes. We have one person dedicated almost exclusively for half their week, so she’s kind of the person who takes charge of getting things updated in the docs, evaluating what stuff needs to change, talking with people to get the right answers to make sure that the documentation is clear and that facts are correct. She spends the better part of three days a week doing that exclusively.

Do you find that customers like having videos that they can watch to learn about your product in the early stages of using it?

I think that for customers, it’s kind of a mixed bag. Some issues are great to explain via videos. The basic videos are good because they’re screen capped, mixed with bumpers of people. The real advantage to video is more selfish, I guess, because video has, in a lot of cases, the same effectiveness as texts and screenshots. But the real win for us is that it allows for us to get people from Wistia on camera and it puts faces to names of people that you’re going to be dealing with in support, because we want to be really, really personable and human in support.

…the real win for us is that it allows for us to get people from Wistia on camera and it puts faces to names of people that you’re going to be dealing with in support

We’re people, you’re people – we want to treat this interaction as such. Adding video in our documentation as part of that mix just seemed like an obvious step to say, “This is Jordan, he’s the person I talked with about this issue that one time and now he’s telling me this thing. He’s a support person, he knows what he’s doing.” It’s not just anyone could have written this or, “Some engineer wrote this thing and they don’t understand how to talk to customers.” Which obviously we hope is not the case – we want everyone at Wistia to be able to talk to customers, but the personification is that engineers speak in engineering talk and not in layman terms.

It sounds like being human is an important value to you. Do you have any other values that you really care about?

Being really human is one of our most highly regarded company values just in general, and you definitely will see that through all of our marketing stuff, all of our videos, all of our support, all of our documentation, and our product lends itself to that. In terms of other values that are specific to support, we value thoroughness a lot. We don’t ever want someone to write into Wistia or talk to us in support context and feel like we breezed over their questions, or weren’t listening or doing due diligence to whatever problem was at hand or whatever questions they have. We want to be quick and thorough with every single thing that comes across in a support context. It doesn’t do any good to just regurgitate answers that are in a canned response because you do less learning and customers are generally less satisfied with that – neither of which is very good for us.

We want to be quick and thorough with every single thing that comes across in a support context.

Do you guys use canned responses at all? Or are those covered in the documentation and you try to avoid them all together?

We mostly don’t. It’s kind of an interesting situation where we have a bunch of them available to us, but they tend to not be very useful because we don’t get a lot of generic questions in our support inbox nowadays. People always have different spins on the same questions, or different contextual stuff which changes our answers a bit. It also kills one of the major wins of how we do support in our value system, which is everyone having their own voice and being able to write things in their own way. When you correspond with me, or you correspond with Emily, or Lauren, or Dave, or Sarah-Mei, you’re going to feel like you’re corresponding with that person, not getting the same answer and the same words from any of those people, which kind of adds to the human aspect. And given that we don’t have a huge amount of volume considering the number of customers of free accounts we have and how good our documentation is, it’s not a huge burden.

Whenever things crop up, for example, if we have a major outage in one part of our products, we’ll have canned responses then because we just need to crush volume. We just need to send out a bazillion emails as fast as we can, which is clearly not advantageous to writing a customer response for every person. But, generally speaking, the canned responses we have are more like snippets almost, where they’re just facts that need to be stated as is, otherwise they become less valuable because they’re wrong. All of the fluff and the creative language and stuff is never, ever part of a canned response.

Back to thoroughness – do you have any way of tracking your effectiveness?

We use a couple of different metrics and tools to gauge this. We use HelpScout as our help desk, and it has a bunch of really fun and interesting metrics within it. You can see the number of conversations you have, the number of emails per conversation, the amount of time to resolution. It has built into it a feedback system where people can say how satisfied they are with your support interaction with them and leave feedback. Tied to that is a general happiness score, which you can see on a per employee basis and a general metric.

We use a lot of that stuff to gauge support specifically, making sure that numbers tend to be moving in the right direction. We don’t really ask specifically to get certain numbers down. I’ll use this as an example of a parallel list, but the numbers don’t really tell much of a story on their own. For example, in Wistia we have a bunch of different metrics, which is kind of what we specialize in, and we tell people a lot: “Don’t pay that much attention to your play rate for your videos, because it doesn’t really mean anything about how people are consuming your video. You could have one million plays, but if on average people are watching 5% of that video it doesn’t really mean anything.”

So for us, it’s making sure those numbers are moving in the right direction, generally – that’s as much thought as we put into it. The most important thing is making sure we’re getting response time down to a reasonable place. If you get a response from someone really, really quickly – almost immediately – they’re really, really delighted. But the diminishing returns on that happen quickly, where you see between a two hour response time and a ten hour response time, you’re unlikely to see much of an improvement or people being dissatisfied more in that range.

So as long as we keep things within a range that we find are happy – that’s good. But it comes with the caveat that, if you’re getting fast response, but people are unhappy with the answers you’re giving them, the fast response becomes irrelevant because you’re still providing terrible support, in that case. They all come with caveats and little gotchas, where as long as they’re moving in the right direction, we’re happy.

They all come with caveats and little gotchas, where as long as they’re moving in the right direction, we’re happy.

Regarding customer surveys, do you ask them how satisfied they were with the experience? Or do you use a Net Promoter® Score and ask them how likely they are to promote your business?

The way it works in a support context … it’s just the corner of every email just has a little option that they can click should they feel inspired to do so. If things were especially good, bad, or mediocre, they can tell us. We don’t ever ask them specifically how it is, but they are free to do so whenever they feel inspired to. In addition to that, we just somewhat recently started doing a Net Promoter Score survey. Jeff and one of our engineers were leading the charge on that and we did the first one a few months ago. We’re gearing up, right now, to actually do the second round because we want to do it four times a year, but I don’t have all the details on that.

What customer service trends do you think will emerge in the next 5 to 10 years?

That’s an interesting one, and I wish that I could have a guess that I could confidently put money in, because I feel like I’d be a pretty rich guy, given how much importance people are starting to put into customer experience, customer happiness, and good customer service. You see people lambasting AT&T and Comcast and all these companies for having terrible customer service, and I think we’re going to start seeing the inverse of that, where people are going to stop caring so much about getting terrible customer service because it’s old hat, and people are just beating a dead horse, at this point. But they’re going to start paying more attention to companies that do really amazing customer support.

You see people lambasting AT&T and Comcast and all these companies for having terrible customer service, and I think we’re going to start seeing the inverse of that…

You already see a little bit of this, like whenever people have great interactions with companies, they’re super quick to shout them out on Twitter and Facebook and stuff. So I think what we’re going to see in the next 5 to 10 years is a dramatic shift in how people are treating customer support outside of support, and sort of what we see people prioritizing in terms of interactions. Some folks have already figured this secret out, I think Wistia is doing a pretty good job at this. We want to delight customers at times that they contact us in support. It can be used as one of the most valuable marketing tools. Word-of-mouth and telling your friends that you love this service is clear and ahead the most effective way to get customers – it’s just hard to do that in mass, getting a ton of people to do it.

If you start gearing your support and interactions to be as intensely delightful and wonderful and impressive as you can, you start to see that number move in a direction that is intensely beneficial to you. So I think in the next 5 to 10 years we’ll find that a lot of people are concentrating more directly on that sort of stuff, as opposed to thinking of it as just support. It’s something you need to have, and hopefully you don’t suck at it, as people start treating it as a marketing opportunity.

 

Want to connect with Jordan? Find him on Twitter or LinkedIn.

 

Subscribe to InsightSquared's Blog

     

Get InsightSquared's latest Sales & Marketing Analytics blog articles straight to your inbox.

 

Recommended Posts
Comments
pingbacks / trackbacks

Leave a Comment

Start typing and press Enter to search