Hey, I spoke at the DevRelTokyo conference. Here are my slides with notes.
Because maybe that's your thing.
I built this for a technical guide, so even if you don't do CI, you can use this for custom cron jobs and other things that Pantheon doesn't do out of the box. This example uses a Digital Ocean Ubuntu droplet, with my pre-installed ssh key.
Make sure Java is installed
ssh root@<your ip address>
Test by logging in as jenkins user and verify you can sudo su
As the jenkins user, from the user's home directory (probably /var/lib/jenkins/):
Visit <your ip address>:8080
Your Jenkins user should be able to push and pull to Pantheon, so create a user for it on Pantheon (call it Jenkins or Integrations or something), generate a private key on the Jenkins server and add the public key to that user's Pantheon dashboard. Check it by doing a git clone from Pantheon to the Jenkins $HOME dir. If you don't get prompted for a password and it successfully clones, you are good to go.
Let me know if you find an error in this doc.
Building a great support or customer success team is often a complex and delicate process, full of adjustments and lessons learned. Often, as the product evolves, so do the skills needed to support it. The first several years may be involve more high-touch interactions, when fewer customers are using an immature product and your team is learning the ropes. As new and varied user personas jump onboard, their goals will vary accordingly.
What can make this a less risky process for a manager is building a team that can realistically grow and adapt. What skills does your ideal team possess? And after you compile this list, consider this: are you giving the people, your users, what they want? For example, in the customer success world, one of the most sought-after traits in CSMs is empathy. But does having a team of empaths translate to happy users? Of course not. Product knowledge, domain knowledge, and other soft skills all matter.
What’s the right mix? According to a recent HBR article, what managers desire in a support team isn’t what your users say they want. For this study, support engineers were grouped into several personas: “Accommodator," “Empathizer," "Hard Worker," “Controller," etc. An Empathizer approach their job focusing on understanding the customer’s viewpoint, and are “wired” to solve other’s problems. Accommodators look to compromise and meet customers halfway, and so on.
Managers and customers were asked what type of support person they look for when hiring, and Empathizers came out on top. However, when measuring performance across a balanced scorecard, which included customer surveys, Controllers came out ahead. Who is a Controller? A controller cares about the feelings of the customer, but mainly to the extent of solving the problem as rapidly and efficiently as possible. Controllers tend to take charge of the situation. They may not follow the playbook, instead opting to take the most direct route to resolution.
During my years in the service industry, it was often said, “Run the bar, don’t let it run you.” One of the best bartenders I met would refuse to make the drink ordered if he thought the customer was making a poor choice. He was revered by customers.
Isn’t there someone on your team, or on a past team like this? Someone opinionated, measured, and willing to say the difficult things?
Customers certainly appreciate a customer success managers that is "always there for them," but if they can’t solve the problem, empathy and fifty cents will buy you a doughnut (SF residents price-adjust the metaphor accordingly). If every complex issue needs to be escalated past the empath, or if time it takes to solve a problem is spent understanding a customer’s situation, opinions about support quality will drop. Customers want their problem solved. They didn't want to ask you in the first place.
This doesn’t mean that hiring very technical support engineers will solve the problem. A better goal is to look for problem solvers. Yes, I know: during an interview, who isn’t a problem solver, right? But a problem solver doesn’t necessarily have a long customer service history or a emote any particular passion to help customers. But given a problem, she or he looks for the most efficient way to solve it.
The moral of the story with this survey, is that what you think your customer wants may not be what is really best for them.
Need help building a great team? Let me help! I am super-controlling.
Organic growth doesn’t really mean a user base expands in a tsunami of adulation and advocacy. What often powers growth are attractive improvements to the offering. With complex products, reducing the adoption curve through education, through externally maintained and contextual (in-product) documentation, is vital.
Here in Japan, as well as in many other countries where English is not the preferred language of users or decision-makers, the best intentions and countless hours spent in documentation offer no succor to users trying your product, right now. Japanese people in the tech community often say the same things to me about their biggest hurdle for adoption. For engineers, it is native language documentation; for stakeholders, it is relevant data: collateral, case studies, sales enablement, etc. They can’t use the product, and they don’t know why they should.
Support comes up, but usually not as a blocker. Neither is lack of localization a deal-breaker. Of course, there are hurdles (payment, compliance, SLA, etc.) to delivering a SaaS product globally. But building an MVP or an initial user base needn’t be arbitrarily hard-wired to English-speaking countries. Don’t make going global a massive undertaking.
This is where you should say, if only there was a company who offered a simple way to get native docs, collateral, and enough marketing to get the word out. To that I would say, click this.
The Jerry Lewis interview is manna from heaven if you enjoy awkward situations as much as I. Anyone who has been on the other side of a prickly interaction with a customer can empathize (with a large helping of schadenfreude) with the reporter, as he keeps digging a hole.
Some non-complementary behavior might have helped. Tense situations often devolve into a feedback loop, and the best way out of it is to break the cycle. It’s also the hardest thing to do in the moment, witnessed in how he continues with his list of banal questions that just makes Jerry angrier. If the car is headed towards a cliff with no brakes, why keep plowing ahead?
Here are some suggestions, for when we find ourselves living in awkward times:
If you want to change your counterpart’s behavior, don't "make" them change it. Change your own first, and give them options to react differently. Did that cheer you up, Jerry?
If your customer-facing employee training works well, your team is gaining not only product knowledge, but also your vertical's best practices, and an understanding of the issues and goals of your various types of customers. If your company has this mastered, don't create a separate onboarding experience for your users. What your users need to know is generally a subset, and it’s a bigger subset than you probably think. This means that your Support team shouldn’t be front-line.
Every resolved support, Customer Success, or onboarding issue has a teachable moment. In a typical SaaS example, support is on the front lines, doling out answers based on accumulated knowledge. This is backwards. When there is a technical question, it should be posed to a training team, preferably well-versed in Customer Success fundamentals. If the training team understands the user and the appropriate user journey, the trainer can determine if the answer is provided in a training resource, or it can be added when necessary.
Then as questions arise, the dynamic is different. A training mentor provides answers via a constantly improving set of documentation, as well as a comprehensive answer: next steps, common pitfalls, and fundamentals key to understanding the reason for the design of the product. Support, rightly, works best with a limited scope: solve a problem.
Feature requests, bug reports, when applicable, should be routed before they ever get to this point. If these non-support related issues account for more than 5% of incoming support requests, it’s probably time for a deeper look. The workflow can vary, but the more complex the product, or the more difficult adoption is, the more up-front training opportunities should be.
Customer Success is responsible for understanding user motivations and challenges. Customer Success needs to build a framework where the training team and the support team are well-leveraged. Emphasizing the scalable parts of great customer experience — creating a product which supports itself first, then providing great self-guided training, then ultimately human help, allows for the scalability to make other human interactions largely positive and reinforcing.
Often, the reason behind a new product or feature never flows down to Support or other customer-facing teams. When they understand the internal motivation: the use cases that warrant a feature's creation, the potential benefits to new or existing customers, or internal factors which necessitate a change, they are able to perform engaged support, and provide better answers. Just because you know the feature is worthwhile, doesn't mean the front lines do. When someone puts a stack of work on your desk, don't you like understanding why?
As a waiter in my mostly-forgotten twenties, I had some great managers. They had enough trust in us to know when to buy an upset customer a dessert, a drink, or comp the whole table's meal. They never questioned us, and we never abused it. Setting the parameters to allow your support staff to say, "I know that must have sucked," will go further than "I see you are frustrated, I am very sorry." A one time credit, a temporary upgrade, or other small gesture turns a negative experience into a relationship-building one.
Docs are aren't the answer to all technical issues, but they are a common destination. If a feature needs a doc, and that doc doesn't get the user up and running, why bother writing it? Ask for Support's guidance regarding documentation and training to insure people are using the product and the documentation the way you think they are.
Relevant customer journey data used includes drip click throughs, content A/B tests, actual user testing, e.g. watching the users using your product. Financial data helps build a balanced scorecard: lifetime value, upsell, churn, etc. Data from support and engagement interactions is also important.
But, looking at the data often leads to a single question, “Why?” Why did customer A visit your site and buy, when customer B didn’t. Agile use of surveys help answer these questions and iterate and make decisions based on these results.
Oh, I can help you solve your user’s mysteries.
Most Customer Success frameworks are built on customer journeys: the idea of following your users through single or multiple paths of using your application, and identifying areas causing friction. But what is a Customer Journey?
Think of Agile Project Management, where you have stories and epics. A story is a short goal: A user I want to successfully create an account. An epic is a collection of stories: I want to go on vacation using your service (create an account, select a flight, purchase a flight, be allowed onto the plane, have the hotel expect my arrival, have a great vacation).
Make sure you are thinking from the perspective of the customer. Their objectives are probably different than your sales, marketing or product vision.
Tracking user journeys requires your company to data efficiently, since you can’t watch over all your user's shoulders. The more data sources you can integrate, the more informed you are. This often means making decisions early on in the design process to make sure your APIs are able to easily capture and serve this data. The more you can build the product in a way that makes it easy to track user date, even if using an external service, Mixpanel, etc. is less work later on, when you invariably discover you need it.
Also having a defined goal allows you to use real statistical analysis to see if your data is in any way correlated. It's super easy to get focused on a data point, spend months improving it, only to realize it doesn't move any needles. That's an awesome thing to have to explain to your boss.
Copyright 2016· All rights reserved