« Beeminder home

Beeminder Blog

A workerbee making an assembly line of humans do its bidding

By popular demand… (I.e., thank you to our fantabulous community for the impetus to write this post!) This is crossposted at essay.dev.

Not to brag but our users are constantly telling us that Beeminder’s customer support is shockingly good. The best they’ve ever seen, even. Long ago we wrote about our secrets of success in “Beehind the Curtain” and that’s all still true and it’s one of our classic posts that we refer to all the time. Today we’re sending our users out of the room to tell our fellow startups and small businesses more about one of those secrets, and, importantly, to give it a concept handle.

Upside-down support is what we call it when we turn a support request from a user upside-down and ask for the user’s help to improve the app or website the user needs support with. We’ve collected various techniques for doing this over the years and it makes so many things in support so much better. We even have a much better way to say no to users!

First, in case any of our users are still in the room, [1] we should emphasize how great this is for everyone involved. [2] It turns out that trying to be the diametric opposite of helpful to users in support delights them all the more. Weird, right? But less weird than it sounds. Let us explain, first by quoting ourselves from seven years ago, since this has clearly stood the test of time:

I spotted this in an old email from one of us: “Let me know if there’s anything else I can help you with!” Perfectly informal and sounds so friendly and helpful. But I’ve come to believe that it backfires.
 
First, people are thoroughly cynical about companies wanting to “help” them. Second, psychology! People want to help people. They go out of their way to do so. People are nice, even altruistic. They don’t want to take up our time asking questions.
 
When we were just getting started and willing to do pretty much anything for our initial users, Melanie, our resident fitness expert, would offer advice and coaching and people would think to themselves “well, that’s not fair, I’m not paying for that”.
 
You can bend over backwards offering help and it makes users feel guilty or suspicious and ignore you. If you ask them for help — or make clear that asking you questions is not a burden but a vital form of feedback that you need for improving the product — then they respond effusively, and bend over backwards to help you.
 
It’s an empirical fact. People respond better to helping us than us helping them. To be clear, this is no gimmick. Users only need our help in the first place because our website sucks. We’re not helping them, we’re just making up for the sucking (and learning how to unsuckify it). So no matter how much you help someone, don’t talk about it that way. Turn it around and explicitly thank them for helping you suck less.

Since we wrote that, we’ve really doubled down. How so? I’ll start with a fictional example from our job posting for new support workerbees. The scenario is a user who’s being kind of obtuse and a little demanding:

Hi! Oops! Sorry! I didn’t submit my information on time again and then I didn’t notice this until today so the charge has already gone through. This wasn’t a legitimate charge because my cat ate my phone and I couldn’t enter the data. Afterwards, I hit the wrong button (button A) again instead of… button B, I think? So now my goal is broken again. Can you fix that for me? I know there’s a way for me to fix it, but I’ve been really busy this week and I just can’t remember how it works and keep breaking it.
Thanks!
Userperson

One goal is to make them happy, of course, but our primary goal is to turn the interaction upside-down and make it about helping Beeminder. Here was my own off-the-cuff attempt, pretending I was in support replying to that person:

hey userperson! eek, we need your help! can you show us a screenshot and write down some of your internal dialog so we can figure out how to make this button-A-vs-button-B thing easier for people? and then the same for fixing it (button C is probably what you’re thinking of). the fact that you can’t remember and worry about breaking it is really important for us to understand better. (if you do break it, we’ll of course fix it for you; we just really need to understand how that kind of confusion/frustration arises.) thank you so much for helping making beeminder better!
 
ps, i did the refund for this goal. it really helps us when you can reply quickly when something’s not legit.

Here’s a non-fictional example where a user called non-legit on a derailment because they didn’t get Beeminder’s reminders and we replied like so:

Yikes, that’s extremely bad that the Beeminder emails stopped coming through for you. Can you go to beeminder.com/reminders and confirm that the checkboxes for email are still checked? You can also go to an individual goal’s settings tab and send a test reminder and see if that comes through. Really appreciate your help figuring out what went wrong there! Deliverability problems with email could be devastating for us.
 
PS, canceled the charge and undid the derailment on your ____ goal.

In both cases above, we ignored the user’s actual request (until addressing it in a PS as an afterthought) and instead recruited them to help diagnose what went wrong. Importantly, we include “user was confused” as something going wrong with Beeminder!

(Clarification from Support Czar Nicky: In the case of an actual refund or canceling a charge, it’s probably worth making it a prescript rather than a postscript. It can still be written as incidental, just that users can be very anxious until getting the reassurance that their money’s safe and sound. After that they can better engage with the rest of the reply!)

I think doing this is harder than it seems. For my cofounder and me, it comes a bit more naturally. Beeminder is our baby and whatever caused this user to email you, it’s ultimately our fault and it stings and our thoughts immediately go to how to fix the root problem — how to make Beeminder better.

But even for us, it’s taken training and practice and pushing ourselves out of our comfort zones. Our support workerbees — Nicky and Simone and Robin — are extraordinarily good and kind humans and every instinct in their bodies screams at them to leap to your assistance when you email support with a problem. So it takes very conscious control to flip the interactions upside down.

Tips and tricks

Big companies have ruined most variants of “thanks for the feedback”. Here’s a way to not just express appreciation but demonstrate it:

Keep this kind of feedback coming; hugely helpful!

I like how it’s particularly unapologetic about the upside-down-ness. It’s literally an imperative: keep doing this (because it goes without saying that the point of support is improving Beeminder). Or here’s a less direct version:

Ok, I fixed your thing; thanks for highlighting the confusingness of this; it really helps us figure out how to make this work better for newbees!

Sometimes it seems like there’s no way to turn a support interaction upside-down. The user has some problem, only you can fix it, so you do, and now you need to tell them you did. Even then, we reframe it as helping Beeminder. Think about what the ideal version of Beeminder would’ve done to have avoided the problem in the first place.

Oh no! I think ideally Beeminder should ____ or ____ in a case like this. Or maybe ____ would make it moot? Thanks for the help in thinking this through!
 
PS: I fixed this for you for this instance.

Next trick, from Support Czar Nicky again: for any support interaction which isn’t 100% routine, you want to come away with at least one piece of useful feedback. For instance, we often get people asking us to put in breaks because they won’t be able to enter data. It’d be easy to just do that, assuming they forgot. Don’t assume! You’ve got to ask. So here’s an example:

Oh no! Normally when you need breaks, you need to put them in a week in advance, because of the akrasia horizon. It would help us a lot to understand better how that can go wrong for people. In your case was it (a) not knowing how to put in breaks or (b) not knowing you needed to do it in advance? I’ve gone ahead and put in the break for you since it’s too late for you to add it yourself, but definitely let us know what tripped you up! It really helps us figure out how to improve the interface and the documentation.

A better way to say no

Suppose a user is all entitled and asks for special treatment in some way, like, “can you short-circuit my pledge to go straight to $810? I don’t want to pay for a month of premium to do that for just that one goal?” We’re way too fairness-obsessed to say yes to something like that, but upside-down support gives us a much better way to say no than something like “I’m sorry but our policy is…”. We can instead do this:

Hi ____, I sure love how you think! And this is also really good feedback that it feels a little … unfair? money-grubbing? I’m not sure how to put it… that we don’t let you set your own pledge level without the fancy premium plan. Some of the history behind our thinking on this is at blog.beeminder.com/shortcircuit.
 
​ ​Actually it would be really good to have you read that and see if it changes your mind about our stance on this, or if you have ideas for us on either how we could convey this better so that it seems more fair or, if it doesn’t convince you, what actually would feel the most fair to you.
 
​ ​​Thanks so much for all the beeminding and helping us think this stuff through! Can we send you stickers? Tell us a postal address if so!

That’s not exactly a no. The door is open a crack to change our minds, but they’d have to make the argument from Beeminder’s perspective, not their own. (Also notice that they’re getting stickers as a consolation prize.)

Don’t be helpful!

In conclusion, don’t do things for users that they could do themselves. Point them in the right direction and ask for feedback about how easy it is to find and do. And even when the support request really does require you to do something for the user, always explicitly shift the focus to the user helping you (the business/startup/app), not you helping them.

I also want to re-emphasize the genuineness of all this. We really do need users’ help in understanding what Beeminder could’ve done better to have avoided the problems users email us about — figuring out the root issues. And asking for help is really hard. But it’s worth it and we’ve gone to great lengths to overcome our fear of doing it and Beeminder support interactions tend to be pretty amazing because of it. Well, that and our amazing support workerbees.


 

Footnotes

[1] Who are we kidding? We led with “by popular demand” — of course the users are still in the room. But humor us. We’re trying to write this for an audience of other businesses because we want this support philosophy to spread!

[2] We’ll de-emphasize, by burying it in this footnote, the cold-blooded corporate take that upside-down support gets users feeling more invested in your app. I think that’s true too but we’re not exactly being Machiavellian here. We’re quite sincere that this is all quite win-win. Again, our users keep saying our support is the best they’ve ever seen. So unless we’ve really brainwashed them, it’s probably not particularly cold-blooded. The warm-fuzzy way to put it might be that it puts you and your users on the same team. Support interactions take on a collaborative tone.


 

Image credit: Faire Soule-Reeves

Tags: