How to Show Problem Customers Out

In yesterdays’ post I discussed our “metrics” on how we know when it’s time to fire our customers.  Once that decision is made, though, what’s the best way to show users the door?  Here are a few strategy points to follow in your organization.

1. When possible, give the user a warning shot

If the user is approaching dangerous territory in their treatment of your team, let them know that you understand their frustration and even side with them…let them know if their frustration is justified (hint: it’s likely more justified than we’re willing to admit.)  Let the user know that you will always provide a respectful response to them, and that to continue your partnership together you will expect the same in return.

If you’re letting them go because they’re a massive drain on your support team, be sure to constantly send them documentation in your responses leading to their dismissal.  Instead of phrasing this as ignorance on the users part, a better solution might be to mention that your product might not be right for them or their use case if it continues to be to complex for them to continue on their own.

Feel free to offer alternative solutions to their use case if you understand it well enough, and let them know that you might not be able to continue supporting that use case as it becomes more complex.

Most times, these simple statements will snap frustrated users back to reality and remind them that they’re dealing with real people, ending the escalation there.  For users who are relying on you to do everything for them, it sends the message that they will need to take ownership of their projects or find an alternative solution in advance.  Most will, at this point, take the initiative to read your documentation and study up on their own.  This preemptive step can often prevent you from having to fire a user at all.

If can also offer an opportunity for the users to “resign” instead of you needing to fire them.  Offer a refund, even if outside of your refund policy, for ANY user you’re considering firing.  Often times, they’ll take it and save you the headache.  For some especially difficult users, I offer a limited time refund offer: “If you would like a full refund, we can extend our 14 day window to expire this Friday for you instead. Please let me know by then if you would like to use this offer.  After that date, we will no longer be able to offer a full refund.”

If you’re frustrated with the user, there’s a good chance their frustrated with you as well, so this is a good change to end the relationship fairly amicably.  Surprisingly, we’ve even received some 5 star reviews in the WordPress repo from using this tactic.

2. You’re never pot committed to difficult users.  Refunds are always okay.

To be honest, I hate this point.  Don’t get me wrong…it’s not about the money.  In fact, I actually love refunding users and at least giving them a good parting experience with us, especially when they’ve been awesome, respectful customers.

What I hate is the idea that I should reward users with unprofessional, abusive, childish behavior by refunding their purchase.  If the user demands a full refund or you’ll get a terrible review, you’ll likely get a terrible review anyway (or at best a 3 star).  Why refund them, then?

The truth, I’ve learned through experience, is that this is the best way to fully walk away with the moral high ground.  Are you obligated to give users all of their money back?  Absolutely not.  However, once you have done so, they have absolutely zero claim to you or your time.  You can officially “wash your hands” of especially problem users and not feel bad about it.  They can trash talk your product all they want (if they’re that bad, they likely would anyway) but by refunding them, you’ve given your team and yourself permission to ignore them.

Refunds, in some instances, are just a mental health play.  You have more important things in your business to worry about.  It doesn’t matter how much support for this user has already cost you.  Cut your losses, walk away, and take care of your other users.

3. Explain WHY you’re letting this user go

If you were able to give the user a warning shot, this step is MUCH easier as you likely already have the documentation to back up the actions you need to take, and the user will likely see this coming (though it will likely still frustrate them).

Be blunt but respectful.  It’s necessary in all circumstances to maintain the higher ground in these support interactions.  Was the user abusive to your team?  Did they threaten you in some way?  Let them know exactly what they did.  If you can do so professionally and without snark, quote their response that pushed you to this decision.

Even customers who are “jerks” deserve to know why you’re ending your partnership with them in a professional manner.  Occasionally, these users will continue to spam your inbound system or social media with more comments, questions, concerns, or complaints.  As mentioned above, once your partnership is ended, you have no obligation to continue that discussion and in fact I would highly discourage getting baited into them.

I fell into this trap publicly one time and ended up accidentally pointing several users towards a competitor.  It was ugly but taught me a valuable lesson.

Here is my litmus test for whether I am properly “firing” a user.  If this user takes to social media or our reviews page and posts my message to them (or a part of it), would the community back me up based on the text of the message alone?  It’s a good way to step “outside” of the situation and think about what the wider community might think about the actions you’re taking, and I think this has saved me from some pretty aggressive responses to problem users in the past.

What are your thoughts?  Have you fired users before?  How did you go about it?  What works for you, and what mistakes have you made?  Let me know in the comments, Facebook, or Twitter!

When is it Time to Fire Your Customers?

I’m a huge advocate in the idea that providing excellent customer services doesn’t mean that you unconditionally tolerate customer behavior ranging from abusive to, in some cases, laziness.  I certainly believe a line exists that customers can cross where it’s no longer mutually beneficial to continue your partnership with them, but identifying where that line is can be a hazard in and of itself.  Below, I’ve outlined a few times when I’ve felt compelled to “fire” customers:

1. Their use case represents a hazard to themselves, their users, or the reputation of our product.

Working on a customer’s site a few years ago, we noticed they were using Ninja Forms to store (not process) the users name, credit card information, and address.  We warned this user that this was incredibly dangerous (they were storing these in plain text), not PCI compliant and likely in violation of their merchant agreement, and they replied that they would look into an alternative solution.

A month later, this same user returned with another issue and we found they had added the users birthday, mothers maiden name, SSN and more to the still present credit card fields.  Their excuse was that this site was for managing instrument rentals online and they needed this data to submit to the credit bureau if instruments were not returned.  Since we had already warned the user about the dangers of what they were doing and continuing support for them would mean that we were complicit in their actions, we immediately revoked their product licenses.  After all, we could no longer continue to support their use case, and support and updates are what they were paying us for.

The user was outraged, they stated that we had no right to tell them what they could and couldn’t use our product for after they had made the purchase.  I politely pointed them to our terms and conditions (which state we can revoke a license for any reason), pointed out to them again how dangerous their use case was for them, their clients, and their users, and that we had already warned them that this wasn’t a use case we would support.

To protect ourselves (imagine the potential headline if the users site is breached and Ninja Forms was used to hold all of this sensitive data), this customer’s client, and their client’s users, we did the only thing that we could.

2. They refuse to help themselves no matter what resources are provided

These are the users who open a ticket with credentials to their site, describe your use case, and demand that you set it up for them.

To be honest, we indulge these users a fair amount.  Everyone gets the benefit of the doubt the first few times.  If the use case is simple enough, we’ll often make the changes for them (usually accompanied with screenshots or a short video of how to make those changes) and provide the user with a link to the documentation for the feature.

In once instance about a year ago, a user was having an issue with one of our addons.  We answered 20 tickets from this user in the span of one month.  One of those tickets was a minor bug, but the other 19 questions from the user were all clearly answered in our documentation which was linked in every single response to the user.

On ticket 21, we informed the user that we were happy for their business, but that the cost of supporting them at this point significantly exceeded the price they paid for the addon and that continued support requests for questions already answered in the documentation would ultimately result in us needing to terminate our support agreement and provide a refund.

3. Insulting our product or support team

As in the screenshot at the top of this article, I don’t take berating my support team lightly.  If a user is frustrated, that’s one thing.  If they take out their frustration on my team by calling us “total idiots” or any other similarly colorful phrase, depending on how egregious the violation they might get one warning, or their next reply from our team might be their last.

We’ve had a handful of users over the years who have crossed this line.  In one circumstance it was so bad that they took to Twitter to personally call out, every few hours for a several days, how terrible our product and support were.  I think they assumed that this would get them better service, but we feel that if you hate our product that much that you deserve a refund so you can find something that better meets your needs.

Interestingly, through a customer service workers community that I’m a part of (shout out to the Support Driven community!) I learned that this individual in particular was known by four other companies and did the same thing to them.  Firing that customer honestly felt good.  He continued to berate us on social media for some time for revoking his licenses and providing the refund, but since he was already doing this anyway there was no downside for us there.

4. Threatening with bad reviews, BBB complaints, or lawsuits

This is a one way ticket to license revocation.  The instant someone mentions starting legal proceedings against us, we immediately end our partnership with them, including their support agreement and revoking their licenses.  Since this inevitable further angers the user who has threatened us, the next reply they get will be from our companies lawyer, who has access to our support system as well.  In every case so far, this has ended the dispute rather quickly.

There’s no need to be afraid to do this, either.  In fact, this is industry standard practice for customer service at most organizations.  When I worked in call centers, every time a user threatened any kind of legal action against our company the only reply I was permitted to give was “Please hold for our legal department” when I would pass the call straight to them.

Threatening lawsuits is no joke and should not be treated lightly.  There are only two reasons to do this: Users think the threat will get them better service (I have a hard stance against rewarding threatening behavior with a faster response) or they are serious.  In either situation, this is not a customer you want to continue partnering with.

Similarly, when users threaten with bad reviews we politely let them know that we are looking into their request but that threats against us or our support team aren’t going to expedite the process for them, and that (if anything) they likely disincline us to help them.  Most of the time, these users will apologize to our team for lashing out from their frustration.  Sometimes, though, they double down on their threats.  In our experience these users are likely to leave a bad review anyway and even if they do have very small circles of influence (threatening others to get your way doesn’t lend itself to large circles of influence, after all) and they usually end up fired.

Those are my metrics for knowing when it’s time to fire a user. Let me know in the comments (or on Facebook and Twitter) what yours are!  Tomorrow I’ll post about the “how” of firing users to try and ensure minimal backlash especially from those deeply vested in your product.

The Attitude Guaranteed to Improve Your Customer Service

There is a trap that everyone who works in customer service/support falls into at least a few times in their career (if not more often).  The sad truth is that some customer service “professionals” live in this trap, in perpetuity, leading to poor customer experiences as well as their own burnout.

The attitude that customers are idiots is a slow killing poison and given enough time will dismantle from within even some of the best companies, products, or services.  All too often when users come to us for help, their needs are painfully simple.  It’s tempting to ask “Did you even read the documentation?” or “What do you think the giant button labelled (insert feature here) is for!?”  These requests can be common and mind numbing for those who answer them day after day.  It’s easy to forget how foreign these products or services were when we first started using them.

For this reason, I’ve chosen to approach every support ticket with this thought in mind:  “Whatever this user is coming to me for help with, it’s our/my fault.”

That single thought has the potential to revolutionize the level of support you provide to your users, but it’s also incredibly difficult to adopt on a regular basis.  It’s difficult to learn to point the blame inward instead of outward.  It goes against our very nature as human beings.

That really obvious, easy to use feature that that’s confusing them?  SOMETHING in that feature is not as obvious or easy to use as you think.  Respond as if experience with the product has blinded you to this reality, and after providing assistance to the user go ahead and ask what, if anything, would have helped them in the product without them needing to contact you.

Users who don’t understand your product because they’ve not read documentation?  Where is your documentation?  Do you link to it from within your product in the places where it might be most relevant (this is a project we’re working on for Ninja Forms right now).  How clearly written is your documentation?  Is it just a list of features in your product or what they do, or is it written as a clear, guided solution to whatever your users most common problem is?

In the end, users are contacting you because there is a problem you have the power to correct:

  1. The product UI/UX isn’t as friendly as it could be
  2. Documentation is hard to find or unclear
  3. Marketing copy for the product is unclear or accidentally misleading
  4. A bug or appearance of a bug in your product

If we aren’t willing to concede that there is ALWAYS something we can do better in our products or in our documentation, our ability to innovate is vastly undermined.

The good news here is that your support interactions are an absolutely treasure trove of data on who your users are, how they’re using your products, and what their needs are!  As a product or service owner, these are the most valuable data points you can have to grow your product or business.  To do so, however, requires a great deal of humility and self-awareness.

Here’s my challenge for you this week…answer every support interaction from this position of humility.  Recognize that for this user to come and ask for your help that you’ve let them down in some way before this point, and make a list through your day of the ways you could have stopped that user from ever needing to contact you.  You’ll likely learn a few not-so-surprising things about your product or service…but I’d be willing to bet you’ll learn a great deal that wasn’t already on your list as well.

Ask Your Users These Three Questions to Improve Your Customer Support

Almost daily I come across at least one support request from a user that reads the way Miss Teen South Carolina answers this question:

It’s always frustrating for me not because I’m bothered, but because more often than not this kind of request means this user is likely to get frustrated with me for the increased time it’s going to take to figure out what their issue actually is and get it resolved for them.

I’ve always encouraged our support team to ask three questions, and recently we just went ahead and added these questions to our support form and we’ve already noticed a decrease in our RPR (Replies per Resolve) stat, meaning users requests are getting answered faster our overall customer satisfaction has increased.

When you encounter the issue, what specific actions are you taking? – What is the user interacting with?  What page are they on?  What button/link are they clicking?  Which tools, specifically, are they interacting with?  The number of support requests we get where users tell us something is broke but not what or where they’re seeing the issue is pretty frustrating…but the reality is that most users simply aren’t aware how the extra context can help in troubleshooting their issue.  Asking them for it up front makes the experience better for everyone.

After taking those actions, what are you expecting to happen? – What is the outcome the user is looking for?  This question is especially useful in determining how well the user understands how the product works, including whether it is appropriate to send the user documentation on how to achieve their goal, or even whether or not their goal is something your product is designed to do.  For the latter, these can also reveal some pretty interesting feature requests or improvements for the product, so as far as we are concerned this question is a double win.

What is happening instead of your expected outcome? – Here’s where you’ll get the meat of your response.  What is broken?  Is the user getting an error message?  This question can also help you find potential breaks, misses, or confusion in the design/UX of your product.  Simply put, this is the question that helps you understand what in your product or service doesn’t meet the customers expectations.  Sometimes it’s a bug, sometimes it’s a feature request, and sometimes it just means we have more room to create clarity for the user and their experience with our product.

If you don’t want to add these questions directly into your support flow, they can help in other ways as well.  As an example, we’ve just implemented a policy at Ninja Forms where our support techs are required to restate these questions with answers in their own words before escalating to our development team.

It’s also not a bad practice to make sure that before sending any kind of a response to the user you can answer these questions regarding their issue.  If you can’t, it’s likely you’ll end up wasting a response or two while you figure out the root of the users issue.

I’ve seen some pretty great benefits from adopting these questions, but I’d love to hear if/how any of you are solving these issues in your support queue.  Leave a comment or hit me up on the contact page!

A Bias for Action – Avoid the Only True Failure

Working at Amazon was one of the coolest opportunities I’ve ever had.  I was only there about two and a half years, but my professional growth during that time was astounding.  I learned more about leadership, humility, and even life there than any other experiences I’ve had in my adult life.  Looking back, I can attribute most of the growth towards Amazon’s leadership principles.  I jumped in head first abiding by those principles, and now that I’m 3 years removed from Amazon I’m still all the better for knowing them.  Some ideas are just too good to shake off or unlearn.

The usefulness of the principles comes in cycles.  Sometimes you’ll exemplify some of them and be weak in others.  As you work out your weaknesses, you’ll inevitably realize you’re failing at another one along the journey.  For me, I tend to cycle through the list about once a year, consciously or not, while working to be better personally and professionally.

This time around the principle is a “Bias for Action.”  Amazon defines it thusly:

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

If you read my post from yesterday, this likely rings a bit familiar.  I’ve struggled a lot recently with just doing what needs to be done.  Frequently I get caught up in the planning more than anything:

  • Do I need to get into the gym?  Well then I better make sure I have the right gym bag, the right shoes, the right headphones, good gym shorts, etc.
  • Is it time to hone my writing skills with a professional blog?  I better waste three weeks trying to find the proper domain name.  I better spend two weeks getting all of the ideas I want to write in order.  I better research other blogging tools and calendars, tinker with Calypso and Gutenberg to make writing easier, etc.

At some point, though, you just have to start.  You have to have that “Bias for Action.”  Take a calculated risk!  Creating the perfect plan in most cases is a likely waste, especially when the benefit of starting even if you fail is still a better reward than never starting at all.  We learn more from failing, anyway.

For me, going to the gym at all, even if underprepared, is better than not going.  Starting to write something, even if it ends up being garbage, gives me the practice to write that killer post down the road.

Don’t be afraid of failing…after all, the only way to truly fail is to never start.