CX5 Talks - An Interview with Craig Stoss

I caught up with Craig Stoss recently on Zoom as we both just transitioned to work from home. We discussed living abroad, his transition to a new role and of course, customer service! 

Craig has over 20 years in customer facing roles. He has been lucky to work across 30+ countries, with hundreds of clients, across several verticals. Through this experience, he has grown a strong perspective on how customers want to be treated. He currently builds and leads global support organizations for software companies and frequently writes on customer experience and support topics. You can find him on twitter here.

Question 1

Jarrod: Thanks for taking the time to talk today Craig. Your background is in software engineering and process improvement. Let’s start with a broad question. Where do you see technology improving CX today and importantly, where do you see it actually hurting? Is it different on the agent or customer side?

Craig: CX technology today gives you tons of data, which is a good thing. To give your customers a customized experience that meets their needs fast, you require data to understand things like where problems can be anticipated, what expectations should be set, what support or contact channels they are demanding, etc. Technology exists today to give you all of that information towards building incredible customer experience

Where it hurts the most is that someone still needs to take the time to understand and actually do something with that data. We all have seen so many awful chatbots, auto-response emails, surveys, or knowledge base implementations and the main reason is that no time was taken to actually know what the customer wants and in what format. It isn't as easy as implementing a chatbot and saying, "Great! That's done!" You need to watch the patterns, and requests that are working and aren't working and constantly improve that offering to be better each time the customer uses it. CX technology's greatest lie is that the tool solves the problem. That's simply not true. The tool can give you insight into the problem, and then people need to solve it.

Question 2

Jarrod: In terms of software and tools, what are the most typical problems you see in contact centers. I’m thinking of what tools are typically missing, or perhaps used improperly or not to their full potential.

Craig: The biggest missing piece isn't usually a single tool; it is usually the fact those tools are not connected in any meaningful way. I met a Support leader recently whose team built a custom integration between their support ticketing system and their customer success management tool. That way Success had full visibility and notification into serious support issues and ticket trends, and Support knew what was happening from an account level.

How better to serve your customers than understand their current context in full? Do they have existing open tickets, are they due for renewal, are they angry about a price increase, or sensitive to a recent product change? Knowing this can change your tone, allow you to tackle multiple problems faster, share knowledge better, etc. Integration and sharing of account details are going to be the biggest game changer in the next few years. Support teams who treat account support issues as an entity, not as a series of one-off tickets, will produce better customer experience and see better renewals and more referrals.

Question 3

Jarrod: When you worked at Vidyard you introduced programs to increase both the content and use of their knowledge base. What was the situation before you made changes? What kind of problems lead to the realization that a change was necessary?

Craig: As we started to scale the company on a global basis in addition to releasing a freemium-style product line, it became clear that supporting the customer base with our industry-leading response times and high-level of customer coaching was not going to scale well. This was due to a combination of the increase in language and time zone coverage requirements and providing support for customers who were not paying you any money. However, Support still needed to be successful for any chance at converting customers to paid accounts.

At this time, the KB was basically a list of articles on a webpage. Mostly with outdated screenshots, very little cohesive branding, and no real way for the customer to even get there. There was not even a link from the main marketing page to the KB, nor a fully detailed Support page. All of these things lead to customers not using the KB, not trusting the KB, or not even knowing it existed. This meant there was no other choice but to contact support through email or phone.

Questions for the product were also very repeatable, so our support representatives were constantly writing the same emails or having the same conversations. They were getting less engaged with their work, and the customers were frustrated they had to contact in the first place. This was high-touch and not scalable for international or exponential customer growth.

Question 4

Jarrod: Now, what exactly did you change and why? What specific business goals were you trying to reach?

Craig: We needed a way to actually understand what customers were asking for and get them their answers quickly. Our business goals were:

• Reduce the number of times a customer had to contact a support representative
• Improve access to answers without reducing customer engagement and responsiveness
• Upskill the support team to handle previously unknown, more technical issues in an effort to remove workload from developers and build more engaging roles (i.e. Less technical escalation to development)

To achieve these, I started with implementing a model similar to Knowledge Centered Service (KCS). Every new ticket was assessed for its likelihood to repeat. Was this problem likely to be asked by other customers or was it a highly specific issue only affecting this environment? If it was the former, an article had to be attached to show it could be solved by written knowledge. "Attached" in this context means either a new article created, or an existing article delivered to the customer.

The second key principle was changing language we used in the KB. Most knowledge bases have titles phrased how the company would ask them, not how the customer would. For example, an article called "List of all Product Settings" may be exactly what it contains, but that isn't how a customer is likely to ask for the information. They are more likely to phrase the question: "How do I change XYZ?" The setting XYZ may be found in the article "List of all Product Settings," but it may not be obvious to the end-user. In this case we would create an article called "How do I Change Product Settings?" that gives step-by-step instructions to find the settings and how to change them, while also pointing the user to the "List of Settings" article to find the right one to change. It is a subtle difference, but it makes it easier for customers to recognize and find their answers faster.

Once the content started to improve and we could show that 70+% of tickets could be solved with existing content. We then started a significant "marketing" campaign which only increased our usage. We:

• celebrated milestones of KB growth and search growth both internally and externally.
• rebranded our KB to look like our marketing page, so it felt like one company
• embedded the search bar, and in some cases links to specific, important articles, within our SaaS application
• featured the KB search directly from our newly created Support contact page.
• engaged with Customer Success and Sales to start using it to answer customer questions and respond to RFPs.
• monitored failed searches and used that data to improve keywords, or create new content

In short, we made everyone aware of the knowledge base so we could nudge customers to use it first while continually improving, updating, and adding content.

It was a widely successful program! Calls were reduced, customers were satisfied they could get answers to their questions, and our response times on the most difficult cases plummeted since the team had more time to focus on those issues.

Question 5

Jarrod: Last question and we'll try to make it a tough one. Some people wish that CX would be a C-level KPI. But for that to be true, there'd have to be an agreed upon method of measuring it. Do you think CX should be a C-level KPI and what data should go into measuring it?

Craig: This might sound contrarian again, but I believe that C-levels have to be actively involved in the CX process, but not so much at a KPI level. What I mean by that is that all executives need to buy-in to the value of CX, and actively encourage the CX the company wants to be known for. The KPI, in theory, isn't some magical number, or the existing CSAT, NPS, or CES metrics, it is sales, referrals, renewals, repeat customers etc. So instead of focusing on a new KPI, CX leaders need to illustrate to the C-level that by taking time to construct a cohesive, consistent, and highly engaging customer experience, the company will be better off.

I am reminded of the well-known policy the Ritz-Carlton's hotel chain has that any employee is able to spend $2000/situation without any approvals to help create a better guest experience. That empowers employees to do the right thing, make customers happy, and solve issues more quickly. What metric would you measure that by at a C-level? Sure, in theory, this will improve all the usual CX metrics, but wouldn't a better metric be measuring repeat-stay rates? If a customer who made use of this policy is more likely to return to the chain for future stays than the average customer, it is easy to show the policy works, and measure if the expense had a net positive return on revenue.

In short, Customer Experience should be seen as a company-wide attitude, not a singular department to be measured. That attitude starts with the C-levels visibly living, promoting, and valuing CX within the company. They already speak this way when it comes to things like travel and entertainment expenses: "Treat company money like your own." I would argue C-levels need to treat CX the same way: "Treat customers like you would want to be treated." Implementing freedoms to allow employees to do what is right will lead to existing KPIs reflecting that inherently without adding new measurements to the mix.