adding new frictionless support page.

daily-routine/contributing-to-github-issues.md

@@ -1,15 +1,23 @@
-# Creating and Contributing to Github Issues
-As a part of our role of customer ambassador, when we find a problem, bug, or area for improvement in the plugin or an add-on, we escalate it to the product team in the form of an issue on GitHub. This is done during ticket time, as a part of the flow. 
+One of the biggest pain points for customers in any sort of support interaction is the feeling of being made to jump through hoops or repeat themselves because they didn't use the correct channel. 
 
-Any time we create an issue on GitHub, we notate the ticket with the GitHub URL and the GitHub issue with the Help Scout URL.
+We call this hoop-jumping and repetition "friction" and it is the enemy of providing excellent support. The different types of friction generally fall into three types:
 
-The following are all valid reasons to create an issue:
-## Bugs
-If in the course of replicating customer issues we find a bug that is replicable in a separate environment, we should immediately create an issue on GitHub in the appropriate repository. Keep in mind that issues created in public repositories are visible by anyone, and should use discretion when it comes to discussing internal policy or issues. 
+1. People with urgent issues who need to be helped when a support technician is leaving for the day.
+1. Customers who ask for something other than technical support in the Support inbox.
+1. Customers who have answers that need escalation to the Head of Support.
 
-In creating the issue, we take care to ensure that the developer tasked with replicating the problem has all necessary information to quickly replicate the problem, and find a solution. It is the job of the support technician to help the developer anticipate how fixing the bug could impact other use-cases of the plugin or add-on. We know (often with more clarity than the development team) how our users are using the plugins, and should give them as much context as possible.
-## Feature requests
-When a customer requests a new feature, we listen. As support technicians, it is not our job to weigh the validity or feasibility of a feature request, so much as to keep a record of how many customers are asking for certain features. For the purposes of creating issues for feature requests, all of those should be routed through the senior support technicians or the head of support, for simplicity. 
-## Clarification based on user insight
-We highly value customer insight into issues of user interface, interacting with other plugins, themes, or the greater WordPress ecosystem, etc. An example of an issue to escalate to the product team would be clarifying the language of an in-app documentation string based on user feedback.
+##Using the Urgent Tag
+When a customer's live site is actively not taking donations (after a period of having taken them) this is an urgent issue. All replies on urgent-tagged tickets should be placed back in the "Unassigned" Help Scout box so that they receive attention as soon as possible. 
 
+This requires some discretion on the part of us as support technicians: just because an issue is urgent to a customer does not make it an urgent-tagged ticket.
+
+Even if the person contacting us is on a tight deadline and has tremendous urgency, it does not fit the criteria for the urgent tag unless the site was previously accepting donations and now is no longer. 
+
+By this definition, a site that is not live yet or has never taken donations before can't have an urgent-tagged issue. 
+
+###Responding to Urgent tagged tickets
+When a ticket is marked as urgent (according to the above definition) and left in the unassigned box. all technicians on the unassigned box are to prioritize it. 
+
+That doesn't necessarily mean that they should be the one to answer, but that they should alert the technician who tagged it to answer when there is a response from the customer. 
+
+If the original technician is out for the day at the time of the customer response, the remaining technician(s) should take over the ticket, and respond. 

principles-of-providing-excellent-support/frictionless-support.md

@@ -0,0 +1,99 @@
+# Communicating Effectively (aka the “Tone Guide”)
+
+We are our customer’s wise friend, not a corporate policy enforcer or policy defender. We want our customers to succeed, and we are the guide to help them when they need it. Our customer is James Bond, we are Q: equipping them with the tools, resources, and knowledge to win the day<sup>*</sup>. To that end, our tone is marked by these qualities (with the helpful acronym CREW):
+
+* **C**onfident, not Apologetic
+* **R**esults Oriented, not Argumentative
+* **E**ducational, not Haughty or Overly Technical
+* **W**elcoming, not Thankful
+
+The best support technicians know their biases and tendencies. For example, if a technician is prone to argument, they should take special care to make things results-oriented. It's helpful to do a postmortem of all negative rating interactions to see which part of the tone guide broke down in the process. Almost all negative ratings (even the unfair ones where they rate the technician negatively because of a lack of feature) can be traced to a breakdown of one of the four points in CREW. 
+
+{% hint style="info" %} **Pro Tip**  
+_Slow Down_. There's no substitute for proofreading when it comes to tone. It's a best practice to take the extra 30 seconds to re-read drafts checking for each of these items before sending the message, asking the question "is this CREW?" and modifying the message before sending it. {% endhint %}
+
+## Confident, not Apologetic.
+
+We are proud of our product and company and don’t apologize for things that are not our fault. We empathize with our customers and don’t waste time defending our products or ourselves, but we never apologize for things beyond the scope of our (team’s) control.
+
+**Things to apologize for:**
+
+* “So sorry for my slow response to this issue. The fastest way to resolve the problem is _____”
+
+**Things you shouldn't apologize for:**
+* “I’m sorry for the theme conflict you are experiencing.”  
+ **Instead:** “We work very hard to ensure that our products are compatible with the vast majority of the themes out there. It looks like our product is not playing nicely with your particular theme. Here are the steps to resolve this:”
+
+* “I’m sorry for this bug”  
+**Instead:** 
+“This issue has been urgently escalated and our developers are working as I type this to release a patch. I’ll let you know as soon as I hear anything from them. ”
+
+## Results Oriented, not Argumentative
+
+Many of the folks who reach out to support are frustrated, having attempted to solve a technical problem for potentially hours before reaching out. In their ticket or response they can resort to attacking us, lashing out at the product or team, or getting distracted by inconsequential details that don’t move the issue toward resolution.
+
+We do not respond to their frustration with a defense of our actions, our team, or the current reality. 
+
+Instead, we seek to find the source of their frustration, and resolve it. 
+
+For example, let's say a customer replies to you saying “Your team is incompetent”.
+
+* **Ineffective response:**  
+“Actually we’re quite competent. I have a degree in `Something`, have spent the last `however many` years in customer support, and thousands of people are thrilled to use our products daily”
+
+* **Effective Response**  
+“I’m happy to get to the bottom of this with you. Other users who have had this problem resolved it following these steps:”
+
+Functionally, we simply ignore the insult, and then prove them wrong by resolving the problem. 
+
+We never stand for sustained mistreatment of our team by customers, but can understand and empathize with frustration. While we won't work with customers who are repeatedly abusive towards our support team, it is important to us to step into their shoes and be on their side to resolve the problem. 
+
+Most of the time resolving the problem results in a change in tone from the customer. When it does not, those situations are escalated to the Head of Support. 
+
+## Educational, not Haughty or Overly Technical
+
+We are experts in WordPress from a technical standpoint. We understand hooks, functions, PHP, and JavaScript, and are able to resolve problems. There is a temptation when talking to customers to show them how much we know by using jargon, insider-speak, and overly technical language. 
+
+Far from making the customer feel better, overly technical jargon makes them feel incompetent and ignorant. If our job is to be the Q to their James Bond, we have to always set them up to understand the things we are showing them. 
+
+For example; let's say a user had a Javascript error that was making things difficult for our plugin.
+* **Ineffective Response:**  
+“The problem is a script loading in the header that’s throwing a jQuery error preventing the rest of the form from loading”
+* **Effective Response**  
+“A file that is loaded by `Example` plugin is not playing nicely with one of our files, and that conflict is preventing the form from loading correctly. Here’s how I recommend confirming and resolving the issue…”
+
+It’s helpful to imagine scenarios where you are in similar situations. One example is the doctor’s office. Imagine going to a medical doctor for an issue with your daughter's development.
+
+* **Ineffective Response:**  
+“The issue here is acute craniosynostosis of the posterior temporal suture” 
+
+This response, littered with medical jargon, serves no purpose other than to demonstrate to the listener that the speaker has a large vocabulary, and possibly a firm grasp on a medical condition. In a strange twist, the more technical language actually proves less about the competence of the doctor than simple and understandable language would.
+
+* **Effective Response:**  
+“You know how the skull has gaps (soft spots) in it when you are born, that you can feel? The issue for your child is that one of those gaps, specifically one of the ones on the back of her head, closed prematurely. Here’s how we go about fixing that...”
+
+If you can’t explain it to a ten-year-old, go back and rewrite it. 
+
+{% hint style="warning" %} **NOTE**  
+ Avoid being patronizing to developers and agency folks who reach out. If they reference the developer console and provide a specific line of code where they are having a problem, treat them with respect, and educate them specifically about our products. {% endhint %}
+
+## Welcoming, not Thankful
+
+Thankfulness, especially as an opening, is functionally white noise to the customer. Like an automated greeting that says “Your call is important to us…” the line “Thanks for contacting support” is ignored at best, or ridiculed at worst.
+
+Instead, we are excited and welcoming. Taking the few extra seconds to find some common ground with a customer and personalize the welcome is a difference between a customer being on the defensive (because they are prepared to meet the policy enforcer) and being delighted that they have found their wise friend to help them win the day.
+
+For example, how you set the tone with your first sentence in your first reply makes a big impact. 
+
+* **Ineffective Opener**  
+“Thanks for contacting Give support”
+
+* **Effective Opener**  
+“It’s so great to help raise awareness for Autism and special needs children. I’ve seen this technical issue you’re experiencing before, and look forward to getting you back to doing what matters: helping the kids.” 
+
+{% hint style="warning" %} **NOTE**  
+ Don’t fake it. If you are not excited about their cause or charity, skip straight to “You’ve come to the right place: we’ll get this technical issue sorted for you in no time.” Lead with being welcoming, even if you can’t lead with excitement for their cause. {% endhint %}
+
+When people go to tech support, they brace themselves for being made to feel stupid. Our job is to welcome them, and explain that we’ve been here before. 
+
+<sup>*</sup>hat-tip Donald Miller's [StoryBrand](http://storybrand.com) for the "make the customer the hero" insight.