Zach Skaggs

Before I write on specifics about interviewing a potential support candidate as a followup to this post, I wanted take a moment to talk about interviewing in general.  I’ve noticed a lot of my peers in the WordPress space are facing making their first hire, and/or don’t have a lot of experience interviewing candidates or even being interviewed themselves.  That lack of experience can make discerning a candidates value ifficult.

Interviewing can be a bit nerve wrecking for both the interviewer and interviewee, but there are a few tools which, when understood, can make the process easier for both parties.  One of my favorite interview tools is the STAR method.  The STAR method is incredibly helpful for interviewers, but primarily outlines the response of the interviewee.

Responses within the star method contain four basic components:

1. Situation – What was the problem you were trying to solve?
2. Task – What was the goal you were working towards?
3. Action – What actions did you take to complete that goal?
4. Result – What was the result of your actions?

Notice that in the above description of the STAR method, I highlighted the word “you” every time it appears.  The focus of a star response should always be on the candidate, personally.  Responses should never be in the form of “my team and I did x” or “my group was assigned y.”  The point of the STAR method is to dig deeper into individual accountabilities, actions, and the results of those actions.  It’s easy to hide behind a team, and it’s common to do so especially in interviews.

When I give an interview, I always explain the STAR model before the interview begins, and I set the expectation for the candidate that I’m looking for personal contributions they’ve made (even if working as part of a team) to a project.  I don’t care about what their team or group was able to pull together…I care about what the candidate was personally responsible for as a part of that project.

For example, a common question I ask in interviews is “Tell me about a time when you went above and beyond in helping a customer resolve whatever issue they were facing.”

A great answer that I received from a former GameStop employee went something like this:

SITUATION: “A customer came in looking for a newer game for their son that we unfortunately didn’t have in stock.

TASK: Instead of telling the customer we didn’t have that game in stock, I took it upon myself to find a copy for them.

ACTION: I called around to a few other stores in the area before finding one that did.  The store that carried the item wasn’t too far from my home and wasn’t far out of the way, so I let the user know that I would personally pick up the item for them from the other store and hold it for them for 24 hours so they could pick it up sometime tomorrow if they’d like.

RESULT: The customer was ecstatic and came in the next day to pick up their copy of the game.  They asked to speak to my manager and let him/her know how much they appreciated my tenacity and saving them the time of having to drive across town.

Notice that I’ve again added emphasis to the “ownership” pronouns above. “I”, “my”, “myself”….these are the words you want to hear in a STAR response.

Here’s an example of a response to the same question that should raise red flags and prompt you to stop the interviewee and ask for further clarification:

“One time we had an outage across our network that caused considerable customer impact.  My team was responsible for managing our customer happiness and worked overtime a few nights that week fielding calls and emails from frustrated users.  We decided to issue a bill credit to the impacted users who complained, and in the end most of our users were really happy that we had helped them!”

Nothing in the answer above identifies an individual action that was taken above and beyond the line of duty.  In fact, nothing in that answer identifies an individual action at all!  Followup questions are justified.  Some examples might be “What was your specific role in this situation?” or “What did you personally do above and beyond your normal duties to help out a specific customer?”

Below are some other examples of STAR questions I use on a regular basis when interviewing:

• Tell me about a time you disagreed with your manager.  How did you handle the situation?
• Tell me about a time when you had two competing needs in your position.  How did you choose which to prioritize, and what was the outcome?
• Tell me about a time you made a mistake in a previous position?
• Tell me about a time when you received critical feedback from a colleague?
• What was the most difficult customer interaction you’ve ever had?
• Give me an example of a time when you took the initiative to resolve an issue without the oversight of a manager.

Even if you’re not an interviewer for your organization, the STAR method can provide a valuable tool to your own toolbox when interviewing for positions.  Answering with the STAR method in a traditional interview is still a great way to show you individual accomplishments even if the interviewer doesn’t ask for this specific format.

What are some other tools you’ve found handy when interviewing potential candidates (or being interviewed as a candidate?)  I’d love to hear what you’re doing!  Hit me up here or on Twitter! 

This is a question that I get quite often from friends of mine in the WordPress space.  Several of them have businesses teetering on the edge of needing help to maintain their current customer base while simultaneously working on growing their products and business.

We got an interesting reaction on Twitter a few days ago when we announced that we’ve never hired anyone at The WP Ninjas with WordPress experience. This has been true for every hire from development, to support, to marketing.  In every instance, this has worked out phenomenally, adding very little friction to our on-boarding process into the company…even my own.

Instead, we hire primarily for a set of qualities that we believe are key to getting the right people in our support roles.  According to Gino Wickman in his book Traction, to have the right people in the right seats every person must meet three criteria (called the GWC):

1. Get it – They understand the overarching goal and strategy of your organization (and applicable seat), and are on board with your vision.
2. Want it – They want to be a part of your team, they have a drive and vision of their own for the seat, and they truly want to be there.
3. Capacity to do it – They have the knowledge, wisdom, and skills needed to complete the functions the job requires.

For individuals we are going to trust with direct interactions with our users, each of these criteria has a more specific definition.

Get It

In customer service, people who “get it” understand that the customers needs come first.  They enjoy the challenge of angry users and get a kick out of turning a vocal critic into a vocal advocate.  They can look at your product with fresh eyes and see the UI/UX issues that you’ve become too jaded to realize are there.  They’re empathetic to the struggles that users face.  They are capable of venting about difficult users without building a disdain for them. They get excited about coaching, learning, and training others in the skills they have learned. They’ve likely worked in customer service before and are excited about the opportunity to do it again.

Want It

People who want it show a passion and a desire to learn.  These are people who love customer service and don’t feel limited by it.  For them, customer service isn’t just a stepping stone for something else.  They’re genuinely excited about the idea of representing you and your brand with your users.  This person never just emails a resume with no follow up.  You’ll hear from them often until you’re able to engage them about the position, and those communications will include excitement about the subject matter of the job, not just a job in general.

Capacity to Do It

Technical experience isn’t strictly required, but aptitude is.  People with the “capacity to do it” in our space are the kinds of people who might never have used WordPress before, but the idea of installing a local server on their computer and experimenting isn’t an intimidating prospect.  They have excellent written communications skills (in addition to supporting users, they’re often responsible for creating and maintaining documentation as well), and they’ve got some experience with technical writing.  These individuals have the ability to break down complex ideas into smaller, bite sized chunks not only for their own learning but to help teach others.

The idea of GWC has been really invaluable to us at The WP Ninjas, and I strongly recommend looking into it more for your organization.  It’s a surprisingly great metric not only for hiring, but evaluating individuals that you might already be partnering with.  For us, it’s the foundation for the rest of our hiring process.  If a candidate doesn’t meet every GWC criteria, they’re not even considered.

What are your thoughts?  What is your screening criteria for potential candidates?  I’ll talk more about interviewing in a later post, but I would love to know more about your processes or any questions you might have about ours (or the GWC).  Hit me up here or on Twitter!

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!

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.

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.