I found myself nodding in agreement multiple times while listening to Rachel. As someone who works in customer support, this felt like a much needed pep talk to me. Check out Rachel’s other talks, writing, presentations, and books here. Watch and listen to the full Industry Conference talk here.
In our experience with Perch, the support that we offer for the product is possibly as important as the features of the thing itself.
When we look on Twitter to what people are saying about us, a lot of the stuff we’re seeing is about the support. It’s about what people think about the help they’re getting. And we see some really nice tweets from people.
So support can be an amazing marketing tool. Especially for people like us.
We have a product that is aimed for people that are using it for their business. They’re using it to provide services to their clients. So, it’s really valuable to them that we’re going to help them out. And they know they’re going to get help.
Support is really great marketing tool. People talk about good support.
The level of help we’re giving people and the speed of our response is really important. Because we’re a commercial product in the CMS space. And there’s a ton of free content management systems out there.
So what makes us different?
And one of the things that makes us different is that we help people. We really, really help people.
I think sometimes the fact that people get support is what makes them buy Perch the first time. They think this is important, and I’m a bit worried will I be able to do this, and they know they’re going to get help.
So maybe they’ll buy that first license. And we see that a lot. You get help. It’s worth it. It’s worth paying for.
Support is important. I say it’s actually been vital to the success of Perch. It’s been vital to allowing us to become a product business at all.
Feature requests come up in support a lot. A lot of our requests is people actually saying I want Perch to do this or that.
And that’s great in an awful lot of ways. The development and direction of Perch has been massively led by what the customer has asked for.
When we first launched, we were essentially a content editor. We had no ability to add new pages. We didn’t have an API at the time. It was a very limited content editor.
We didn’t really see a need for it to add new content pages. We thought people would build a site and let people edit stuff. But then there was sort of an overwhelming demand from people wanting something a bit more than that.
So we built on it. And created all sorts of functionality. Perch is able to manage much bigger sites than we ever imagined Perch 1 would do.
The more you talk to people, you can kind of see the path and the road map. People often say, “What is the road map for Perch?”
And we say, “Well we kind of know what we’re going to be doing in the next month. But then we’re going to see what the feedback is to that.”
We recently launched a Members app, which is essentially for people to be able to login at the front end and downloading PDFs or accessing secure content. That was something we never thought was a Perch thing. But it became this up-top request.
So we’re always getting information from people. What do they want? What can we build? What can we do to make people happy?
However, while you’re doing that, you have to be really, really careful. Because you have to protect the core use case of your product.
It’s really easy to say yes to every request that comes in. Yes, we can do that. It’s just code, we’ll write that.
If you’re doing client work, that’s kind of ok, because you’re just building one thing. It’s fine to say, oh yeah, code that and there it is.
But if you’re adding stuff to your product, it’s a whole different ballgame. You could quite easily end up with a product that is bloated and unusable.
And in our case, it would of sort of become the thing we built Perch to get away from entirely.
However hard you try to meet the needs of people and however hard you try to give people what they want, there is always going to be someone accusing you of not listening because you haven’t already added their very specific feature request.
We get a whole ton of stuff in, and some of it is incredibly specific. We can’t find a good way to make that a generic thing that could be useful to more people.
We’ve got to decide, not only how not to bloat the product and make it unusable, but also where is worth putting development time in.
What will benefit the majority? What will benefit the most people when we add it?
You’re not filling that request of that noisy person because you are listening. You’re listening to the majority.
The majority is quite hard to listen to because they tend to be quiet. You don’t hear from people who are happy.
If people are happy, it will just get in the way, they’re working on their projects. They might say on Twitter, “I just launched this with Perch.”
But you don’t hear from them because they’re happy.
It’s really easy to think everyone is asking for this one thing, so we should develop it. And it’s actually a tiny percentage of the customers who want that one thing. And is that the best place to spend our time.
Sometimes a difficult customer is just a customer that has a different way of interacting or perhaps is using English as a second language.
We have a lot of that. Sometimes translated English can come across a bit rude or just difficult to understand. Web designers tend to have very good English because they need it to do their job.
But how that actually comes across can be a bit strange. We’ve got a story, I don’t think this customer was using English as a second language, but she certainly was confused by what we said to her.
So Drew was talking to this customer, and she was confused by some aspect of the software, and Drew referred to the mental model or how to sort of visualize something. Or how things worked.
And this made her furious. Drew couldn’t understand why the customer was furious. I read the thread, and I didn’t know.
Turns out the customer thought Drew was calling her a mental model.
Maybe she was a model. I don’t know, we don’t tend to call our customers names. But it was this baffling thread, and left you wondering why this was happening.
But that happens quite a lot. Sometimes a person comes in and we’re thinking this person is really angry at us, and what have we done.
It’s just translating from another language, and they come across as very short.
To some extent, you can design support out of your product. I’ve got an example here.
This was the Perch login screen. When someone logs in to admin Perch, it does a check that Perch is registered against that domain.
People can set up they’re staging and live domains for each license.
So our original messaging said, “Sorry your license key isn’t valid for this domain.”
And the person would then come into support. So we changed it.
And we changed it just to give them an instruction of what to do. So people knew what to do when they saw the message and we didn’t get any more support requests about it.
So if a lot of people are contacting you about the same thing, there really ought to be something you can do to fix it. It’s tempting just to stick things in FAQ. But if you do that, you end up with a huge FAQ. And that isn’t useful to anyone.
If you can actually fix the issue in the product, then the support just goes away.
Sometimes people need help and they need it in different ways. We have a load of documentation and it has to serve everyone.
It has to serve that person who can barely write HTML right through to the person who is an experienced PHP developer.
For someone who is new, text documentation isn’t the best thing for someone who is starting out with a content management system. So we put out a bunch of video.
The videos are massively successful. A lot of support requests don’t come in anymore because people go and find the videos.
And when people do say they’re having trouble getting started, we ask if they’ve watched the video. They say no, and they go watch the video, and they’re sorted and up-and-running.
Providing a variety of help materials and in different formats is really useful.
An awful lot of requests that come into the Perch system basically say, “Help. It’s not working.”
What do we do about that? We ask them what is not working?
Here’s the thing. If several thousand people are using a product and the support forums aren’t full of angry people, it’s working for most of them.
So obviously what you’re doing is slightly different. It doesn’t mean you’re doing something wrong.
You might being doing something that is slightly unusual that we haven’t come up against yet.
It’s really hard for anything to be completely bug free. You need to give some information. Things tend to not be just broken.
Whether you’re heading into support for a product you’re using or whether you’re heading somewhere like StackOverflow to post some request for help with CSS or whatever, the more information you can give about the particular environment your code is running in, the easier someone can help you.
In fact in those free support forums like StackOverflow, kind of those quick wins, are the ones everyone wants to answer. If someone has given all the information, you can read down and say, yes I know what the answer is and answer it.
That’s great you feel good, you’ve answered someone’s question.
The question where you know you’re going to have to tease out some information is not so fun to answer. You know it’s going to take you all day.
Generally, once you can reproduce an issue, it’s well on its way from being solved.
And that’s the key really for any support. How can it be reproduced?
If it’s a CSS issue, how can I actually see it on my screen?
If it’s something in Perch, I’m going to need their template or the things that they’re using to get to that point.
Something that is really important for us to know is what did you expect to happen.
Most bugs that people encounter aren’t actual bugs that throw an error. What they are is you thought that doing this would cause one effect and another effect happened.
So when someone comes into support and says, “Well, it’s doing this.”
We’ll say, “Well, yes, because that’s how we wrote it. That’s what it does.”
Because we don’t know the important information that they thought it did something else.
If we know what they expected to happen, we can kind of guide them to what they need.
Ultimately, good support gets you back to your project as quickly as possible.
We don’t want people to spend a lot of time hanging around in our support system. Not because we want rid of them. Not because they’re annoying to us.
But because if they’re in there, they’re not working on their project. They’re not working on their business and doing what they want to be doing.
For us, we want to deal with people as quickly as possible and get them back to their projects, so they can have a good experience using Perch.
That’s really what all support should be.
It should be about getting people back to work with the tools they need to continue.
Thanks for reading!