Why Customer Support is integral to UX

Why Customer Support is Integral to UX

As a developer turned SaaS co-founder, one of the things that really hit me early on is how integrated all aspects of growing a SaaS business really are.

Being one of a team of two we’ve had to take on multiple roles, many of which are new to us. One of the great outcomes of that experience, is that you are able to see similarities between traditionally distinct areas of business. Doing so can have a really positive effect on your business, allowing you to see patterns and apply methodologies and skills from one area to others.

An example of this is the rise in popularity of the “Growth Hacker”, which to me feels like what happens when developers have to market, or when marketers look into at how they can scale their methodologies with tech. One discipline cross-over that I didn’t see coming at Paperform however was support and user experience (UX).

I usually think of UX as the flow of a user’s experience with a service. In the day-to-day this looks like analysing UI designs, user interviews, constantly reviewing the messaging and similar activities. I’ve found with Paperform though, there is huge value to be had in integrating support as a part of our over-all intentionally designed user experience.

<a href="https://medium.com/media/370fa529e5eae8867a8c3dbba9f624c9/href">https://medium.com/media/370fa529e5eae8867a8c3dbba9f624c9/href</a>

This is story is brought to you by Hacker Noon’s weekly sponsor, Paperform. Create beautiful forms. For Hacker Noon readers, 10% off all plans forever.

Good support covers a multitude of sins.

In an ideal world, your product would be so complete and intuitive that there would be no need for a user to ever need to ask you a question, request a feature or complain about a bug. Unfortunately that’s not the case for us. With our imperfect products, and (dare I say) imperfect users, support can act as an amazing coverall, a way of turning a poor experience into a fantastic one.

So what does this mean? For us, there are a couple of really important implications.

Be intentional and consistent in how you interact with customers

The personality and culture that you display when you talk to you customers needs to be consistent and given as much thought as the copy on your website. More than tone and style of writing though, you need to be available.

Support should be available when the user needs it, and they should already know how to access it. By being consistent with the tone of language and responsiveness of support, you’re reinforcing the brand around your product. Great support from real people gives customers the warm and fuzzies.

How many times have you looked to ask a question and have been funnelled through a rabbit-warren of “suggestions” and “did you mean this?” and progressive categorisation to the point where you finally get to a contact form, submit it, and hear back two weeks later (or never at all)? What did that experience tell you about how much that brand cares about you?

A few months back we had some DNS issues with AWS CloudFront. After searching all of their help docs to ensure it wasn’t a configuration issue or any human error on our part, I figured I’d need to contact tech support. It turns out getting any support from AWS is a paid subscription service. Now I completely understand that support is a huge cost to a business the size of Amazon, but it blows my mind that as a user of their service, it is the customers responsibility to pay to tell them when their service isn’t behaving!

Now Amazon and many established players might be able to get away with this kind of behaviour, but for small fish like us, we need to talk to our users.

Support should be a part of your product. Not only should we allow users to talk to us, the product itself should actively encourage dialogue between the users and support. We want people to ask us as soon as they hit something they don’t understand.

For us at Paperform, this looks like responding within a few hours to every question (ideally as close to realtime as we can). We take shifts through the night so that users on the other side of the world are looked after as well as our locals.

Because we want to respond while we have our user’s attention, we really love chat. It’s non-threatening and really easy for our users to understand. It also allows us to set an expectation of when we’ll reply, as well as the ability to respond sooner if we can. It also means if a discussion is needed it can be had synchronously; there is no waiting for long email replies. Our chat is always present for users while they’re in the product. Users aren’t required to go to some isolated support site, where they’re forced through a twelve step program before they can get through to a human.

This of course only works when you can handle the volume of support this encourages. Do you want to cut down the volume of questions your support teams gets asked? Don’t bury your support, make your product better at explaining itself.

Support should feed back into the UX of the product.

You should be taking queues from support as an indicator of what UX improvements can be made in the product.

Take for instance, when we first released Paperform, we had a really common question about how you delete pictures. Our form builder works much like a doc editor, so you can actually just click beneath and delete the image. A lot of people obviously didn’t get it though, so we made the simple change of including an “✕” in the top right corner of images, and voila, the question stopped being asked. This isn’t rocket science, but you’d be amazed how much low hanging fruit is left on trees when a product team isn’t in constant contact with the users of that product.

In the reverse direction, when we get a bug report come through on support, it is put straight through to me as the developer, where I can then talk directly to the customer to diagnose if there is indeed an issue, and if there is, release an update to resolve the issue as soon as possible. It’s not uncommon to receive a bug report and release a fix within the hour. The effect this has on how a customer feels about Paperform as a brand is incredible. We did some historic research over all of our support conversations to date, and in over 10% of our conversations users have voluntarily used the word LOVE. Users are people. They need to feel heard. They need to feel valued.

On a side note, it’s easy as a designer/developer to feel like a user is stupid for not understanding your product. Fight that temptation! If they don’t understand, it’s probably a product issue. It’s exactly this reason that product owners should be directly interacting with users on support. If product owners are removed from feeling the pains, they won’t feel an impetus to fix them.

<a href="https://medium.com/media/33d3df00b53e8752b898189b3d6929c9/href">https://medium.com/media/33d3df00b53e8752b898189b3d6929c9/href</a>

I know as the team grows it will get harder to have the same level of overlap between business areas. As Paperform continues to grow though, one thing we’ll be thinking about is how to keep a tight integration between our product and support teams.

I’m Dean — one of the founders of Paperform. Paperform is a beautiful form builder that enables you to create powerful forms that can take payments, be embedded anywhere (including Medium!) and look fantastic.

<a href="https://medium.com/media/1da9e891f9236e06d932cb6fc0f5e3c1/href">https://medium.com/media/1da9e891f9236e06d932cb6fc0f5e3c1/href</a>

This post originally appeared on the Paperform Blog.

This is story is brought to you by Hacker Noon’s weekly sponsor, Paperform. Create beautiful forms. For Hacker Noon readers, 10% all plans forever. Learn more about becoming Hacker Noon’s Weekly Sponsor (spoiler alert — this form is powered by Paperform).