By: Bill Magnuson (@billmag)
At Appboy, we’re big believers in using data to help forge better relationships with customers. Today, I want to share some thoughts on an important part of the customer-product relationship that I think is often poorly executed on: the collection of, and action on, user feedback.
My brain might be messing with me, but lately it seems that more and more businesses have been asking for my opinion on their products and services. As I think is true of most people, I ignore most of these requests. Even worse, I’m often annoyed by being asked. As a product owner, if you’re not getting me to fill out your survey, you would have been better off not bothering me by asking me to take it. Why do I often turn down the opportunity to provide feedback?
- You’ve made it too hard for me.
- I don’t trust that you’re going to do anything with it.
- You’re asking for too much.
You’ll notice that this list doesn’t include “I don’t have opinions about your product” or “I don’t want the service you provide me to get better.” When I decide whether to answer your questions, call your survey hotline or fill out your online form, I’m making a cost/benefit judgement. Is my effort to provide this feedback going to make a meaningful difference for myself or others?
At Appboy, we want to know what our users think about our products so we can continually improve them. As a CRM system used by marketers and implemented by technologists (as well as all the lone developers out there who wear both hats), we’ve got a lot of touch points and a diverse user base. I spend a lot of time in client meetings and have a good pulse on the reception of our feature set, but how do I know that we’re implementing it well?
Like most startups, we do a lot of active monitoring of how people use our site. This gives us insight into how, when and how much people are using our site. When we first launched, we noticed a pretty big drop off in engagement occurring as people went through our integration documentation. Armed with the knowledge of a problem, we asked our friends and co-workers to go through the documentation, huddled around the whiteboard, and came up with a couple of new designs.
However, even rolling out the new documentation (after multiple A/B tested approaches) is still stabbing in the relative darkness of online user experience design. How could we be sure that we anticipated the correct user, and the correct use cases? Even when we find the design that works great for most of our users, how do we make sure everyone else is happy? For us, the answer was to collect feedback, and the big question was how.
A couple of years ago, I was a Googler. Being a data driven company at all levels, Google asks for feedback when you leave their cafeterias. Their method for doing so is dead simple: they pick a subset of the dishes served each day and ask you to drop a colored glass bead into one of a set of glass jars to indicate your like/dislike of the dish. They’ve made it so easy to give feedback that nearly everyone does it.
There are a few big things that the cafeteria was doing right:
- They didn’t ask for context they could figure out or wasn’t vital to the goal.
- I was being asked about my experience while it was still fresh in my mind and I still cared about it.
- The question was something I had an opinion about.
- I trusted that something would happen when I provided data. I’d seen changes happen in the cafeterias and there was a sign next to the jars explaining the feedback effort.
I took this learning and applied it to our re-designed integration documentation page. Once you’re done with our slide show we ask you a very simple question: How would you rate these instructions?
If you click the red thumbs down, we open a support ticket for you automatically and email you back to inquire. Optionally, a text box will appear below the rating options to let you elaborate on the spot. If you fill that out, we’ll attach it to the recently opened support ticket.
We’re leveraging context because we already know who you are and what your issue was. We also asked you immediately upon completion and targeted the question at people who had self interest in the quality of our documentation. After giving the feedback, we hope we’ll gain your trust by making sure every thumbs down is investigated and handled accordingly.
If you haven’t had a chance to check out Appboy and get our SDK integrated, now’s the time to head over to our site and get started. As part of our CRM system, we’ve got a feedback form built right into the SDK that feeds into our feedback center.
Once inside the feedback center, we give you all the information you need to help your user with their problem. This includes the usage statistics and device information for the user requesting help as well as multiple ways to contact them (push, the Appboy in-app slideup, or e-mail if the user has provided it to your app).
In closing, I wanted to provide some examples of what not to do by sharing some reasons I’ve abandoned giving feedback in the past:
- I was asked for my contact information, even though I was already logged in.
- The last time I gave feedback it wasn’t handled well.
- The form didn’t work in Chrome, or on mobile.
- I’m being forced to type in a survey code with 30 bits of entropy (how many people are taking this survey?).
- I hit a brick wall online and was asked to call someone, then a robot picked up.
- The captcha was impossible.
- Your feedback form was more than one page, but I had no idea how many more times I was going to have to click next before finishing.
- I was offered a reward. This is a tricky one, but to me it changes the calculus from me doing a favor and turns it into work for pay. After all, I’m only human: “Predictably Irrational – Being Paid vs. A Friendly Favor”.
Anyway, I’ve said enough. What do you think? Comment below, or email me at email@example.com.