How To Not Change Your Product

Change Management on the Metal Gears on Black Background.

The blog has been silent for way too long, I know. I will do my best to continue at a better pace until life intervenes again

One of my guiding principles, at work and outside of it, has always been “no surprises”. I try to apply this principle to every interaction and relationship, customers and partners, executives and fellow employees.

Recently the validity of this principle was reaffirmed when an online service I use extensively eliminated a very valuable feature without notice. The change removed important data users have saved and, initially, did not offer any way to access it. The problem was fixed, in a very kludgey manner, only after several weeks, during which the data was not available for use. The official statement, released after the fact, claimed this was done in the name of user experience improvement

The vendor’s customer support team provided a response along the lines of We have your data, you just can’t see it. We plan to make it available again, but don’t have a time estimate.

Having encountered similar situations in the past, there are several guidelines I’ve always relied on when making product changes with potential impact to customers:

  • Plan Well – understand the change you are introducing, the variety of ways it will affect customers, and the number of customers impacted. SaaS vendors, especially, have more detailed knowledge of their customers than on-premise, and should use that information
  • Weigh the need – ask yourself whether the benefit offered justifies the impact to customers’ ability to derive value from your product or service
  • Seek customers’ input – invite customers to offer their perspective on complex or high impact changes. This can be done in a variety of ways, from 1:1 conversations through surveys all the way to open discussions on your community sites or during user group meetings
  • Communicate deliberately:
    • Provide sufficient advance notice – let your customers know the time a change will take place, and do it well in advance of the change so that they are able to prepare for it. If your customers’ business follow a business cycle, aim for the low activity periods
    • Explain the impact the change will have, list ways with which customers could minimize or eliminate this impact and explain the benefits in case they are not immediately obvious
    • If customer data or their ability to access it will change in any way, explain the data’s disposition – what will happen to it, how it can be accessed, when it will be available for use again
    • Provide a mechanism to circumvent the problem – for example, in this example allow customers to download a copy of the data for offline use
    • Offer a mechanism for feedback at each and every stage
  • Prepare for impact – arm your support team with answers and talking points. Some customers will invariably be unhappy about this change, ensure your support team is not facing them empty handed

Obviously, different demographics call for different methods. High end enterprise vendors could schedule individual meetings with customers to prepare for high impact changes, while those in the consumer markets could send a single generic email with instructions. In any case, however, do not leave your customers in the dark!

Seven Wastes and One More: Lean Perspectives on Enterprise Support

Folding Rule

It’s very exciting to see the increasing coverage Lean Manufacturing (or just Lean) is getting. From my experience, Lean provides very useful and intuitive methodologies for process improvement and streamlining as well as a more robust set of tools for advanced implementations. A good number of books have been written about Lean Manufacturing over the years, from its origins in the automotive industry with Toyota (hence the alias TPS for Toyota Production System) through other implementation to the influential ‘The Lean Startup

In its most basic form, Lean provides guidelines and ideas for reducing or eliminating waste in process driven operations. Waste, for this purpose, is defined as anything that does not add value that the customer will appreciate and pay or. There are seven different types of waste (sometimes known by their Japanese name Muda) that are recognized: Transportation, Inventory, Motion, Waiting, Over Processing, Over Production and Defects. Additionally, for some organizations, including Enterprise Support, I believe it is useful to add Unused Employee Talent as the eighth waste

When discussing these wastes we should keep in mind that some apply to the work in progress (from cases and knowledge items through equipment being repaired to employment candidates) while others apply to the resources (people or machines) that perform the work. We should also know that Lean distinguishes between necessary waste and unnecessary waste. Necessary waste, known as ‘Type I’, could, for example, be any activity that’s required for compliance – from inventory audit to health and safety drills. Un-required waste is known as ‘Type II’, and should be eliminated. While the first distinction is built into each waste’s definition, determining which wasteful activity is necessary and which isn’t is subject to individual analysis

With this understanding, let’s look at each waste and how it can manifest itself in the enterprise support world. With that understanding we can determine how reducing or eliminating it can help us improve our operation. We should also note that certain wastes can generate other types of waste:

  • Transportation – is focused on the work items, and can equally apply to physical movement as well as to transitions of ownership or responsibility. For example, are we moving cases unnecessarily between teams and individuals? How much extra work is created every time we change case ownership? For hardware support organizations, are we moving returned equipment between departments or locations unnecessarily? Excessive transportation can sometimes lead to increased inventory – another waste
  • Inventory – this is another work item waste. Are we keeping cases open unnecessarily? Why do we have so many open cases? In what stages are they open? Do we respond to all recruitment candidates as soon as a decision was made? How much equipment do we have waiting to be repaired? What’s keeping us from getting that equipment to the lab? How much inventory do we keep to support potential customer failures?
  • Motion – this is a resource waste. For example, are we asking support engineers to move physically in order to do parts of their job, for example go to the lab to recreate a problem? Are we requiring our employees to repeatedly switch contexts? For example, do we instruct support engineers to drop whatever they are doing to answer incoming phone calls?
  • Waiting – this is another resource waste, where people or machine are idle due to lack of work or the need for another person’s knowledge or a constrained resource. Typical examples include access to systems needed to recreate a customer’s problem, access to a specialist with knowledge that can help make progress with a case and generally waiting for any other person or resource required to complete a task
  • Over Processing – this is a work item waste, where the organization invests work that does not add customer value. For example, complicated forms acting as a barrier to escalations rather than facilitate rapid problem resolution, repeated analysis of a customer’s problem by multiple engineers and repeated attempts at fixing a customer’s problem or repeated repairs of returned equipment
  • Over Production – this also is a work item waste. It usually refers to making items ahead of customer demand. A typical example could be preparing and publishing knowledge items for a one-time problem that will never be used again, or repairing products to be used to replace customers’ failed units in excessive quantities
  • Defects – again a work item waste. It focuses on an end product that does not address a customer’s need. From providing the wrong fix through creating a knowledge item that misguides customers to hiring a person that’s not qualified to do the job
  • Unused Employee Talent – I have written in the past about the impact of untapped employee talent from a knowledge management perspective. Additional examples include forcing escalations to happen within a certain time, even when the front line engineer has all the knowledge required to resolve the customer’s case

I am sure every reader can think of many other examples for wastes in their own environment. This post does not purport to provide an exhaustive list. Rather, it was an attempt to give readers a glimpse into the world of Lean as an additional tool to use for improving process flows. I hope you begin to make use of Lean thinking and that it works for you as well as it did for me

Guest Post on

The people at TeamSupport invited me to write a guest post on their blog. The result is Bridging the Gap in B2B Service Expectations which was published yesterday (12 January 2016). The theme should be familiar to regular readers, touching on some differences between B2B and B2C support, and offering several actions we can take to avoid some potential traps

Metrics In The Eye Of The Beholder


A previous post on this blog discussed several reasons for not using case life as a goal for first line support engineers. I was reminded of that post, and the reasons for writing it, while hearing someone state that organizations should “only measure outcomes, not activities”. It’s easy to agree with this statement, after all, outcomes are the only thing that matters in business, right?

Let’s take a moment and try to understand how these outcomes are realized. The obvious question to start with is “what’s the organization’s deliverable to the company?” Over the years, through my own and others’ experiences, I have seen a variety of answers to this question as it concerns enterprise support organizations. Goals ranged from operational objectives through customer satisfaction all the way to maintenance renewal rates and revenues. Surely the organizational deliverable is an important metric to track and report on, but is it the only thing that matters? And more importantly, does it apply to every member of the organization?

Similar to case life mentioned earlier, or to the goals listed above, outcomes are trailing indicators. They, almost by definition, represent an aggregation of a variety of activities and inputs. Making any improvement to the operation requires us to understand the individual components our deliverables are composed of and build a system of metrics that allows us to understand the way we perform on each, identify weaknesses and measure improvements. We should also measure inputs, from the number of cases to the growth in the number of customers and track the way those inputs influence our performance, all the way to delivery on our goal. In essence, we should design a metrics structure that breaks down the goals of the organization into departmental goals supporting it, and into the activities that these goals are composed of

We should also keep in mind that metrics can serve different roles depending on the audience. One group’s outcome is another’s input. Activities represent a major investment for the organization and ensuring their efficiency and effectiveness is a primary concern for anybody running a process driven operation. Any measurement system we design will have to take into account the organizational deliverables for the short and longer term future, the investments it has to make into producing those deliverables, the inputs it requires in order to do that, and the way these measurements apply to every function within the organization. On that in our next post

NPS Again, This Time With Feeling?

Recently I came across two interesting posts discussing NPS®. Each of them seems to miss one, or more, important points about creating a sustainable customer survey program that actually produces tangible results

First, and very interestingly, is Fred Reichheld, creator of NPS, on linkedin telling us to Stop Thinking Like a CEO (and Think Like a Customer Instead). If we think about the title for a minute we’ll realize that unlike the customer, a CEO has responsibility for identifying weaknesses in the customer experience and taking action to fix them. In his post, Mr. Reichheld tells the stories of two CEOs who transformed their companies’ customer experiences. But, did those CEOs do what Mr. Reichheld is asking us to do? No, they did not. They never stopped thinking like a CEO, but they did bring the customer perspective into the organization, and, most importantly, acted on it to deliver a better customer experience

In his post Mr. Reichheld claims that:

“The best approach is to ask customers on a scale of zero to 10 how likely they would be to recommend your products or services. This is what […] companies do every day to be loyalty leaders. By closing the loop with their customers and taking action on the reasons why customers love doing business with them or not […]”

But while the scale is detailed, the need to “take action” remains nebulous – how do we know what actions to take, and how do we verify their impact?

Another post that caught my eye last week was on the Bluenose blog, titled Driving Net Promoter Adoption: 3 Must Do’s. In his post Don MacLennan, Bluenose CEO, states that leadership commitment, organizational alignment and customer follow through are essential to increasing a company’s NPS results, and he recommends engaging with customers as a survey follow-up in order to establish the cause of their dissatisfaction and eliminate it

Some readers may ask whether there’s anything wrong about engaging with customers to find out what’s causing dissatisfaction. The answer is that there’s nothing wrong about that, but when we think about a process driven business we can’t rely on anecdotal evidence as the sole input to our improvement efforts, and that for several reasons:

  1. The plural of anecdote is not data – so no matter how many customers the company interviews they will be only a small portion of the customer base and their opinions remain anecdotal rather than a complete picture
  2. Discrepancy between stated and actual behavior drivers is a well known phenomena and is documented in numerous academic papers
  3. The challenge in converting anecdotal evidence into a sustained organizational effort to improve products and services

With that said, what would be the best way to follow up on NPS, or any other, survey and generate sustained improvement

The answer should be no surprise to the blog’s followers. Survey responses, in correlation with your operational data, provide the organization with very clear insights on actual (as opposed to stated) customer behaviors and their drivers. With these insights it is possible for the organization to develop sustained improvement efforts based on the most critical elements of the customer experience, and gauge their impact on customer satisfaction, as well as customer behavior. It’s doable, and usually easier than we tend to think, but does require commitment and a change in the way we think

Net Promoter, NPS, and the NPS-related emoticons are registered service marks, and Net Promoter Score and Net Promoter System are service marks, of Bain & Company, Inc., Satmetrix Systems, Inc. and Fred Reichheld

How to not respond to customers

Reply target

Recently I had the need to contact a company for support concerning a feature they removed from one of their product which I, and many other users, sound extremely valuable. Despite it being a free service, the support team responded on a weekend in time that would put most enterprise vendors to shame. However, the content of their message left a lot to be desired:

Thank you for contacting us!

Personally, I’m glad you brought this out. At […], we are constantly working to improve our platform and products. Suggestions from […] like you are an incredibly important part of that process. Updates can be done without notice, we will keep you informed if we make an update on our platform. We want you to know how much we appreciate your input and support!

Parsing this message, we find a number of items for improvement:

  • They start by saying “Personally, I’m glad” – but this is not a personal matter, I am interested in the company’s position, not the agent’s personal opinion
  • Then “At […], we are constantly working to improve our platform and products” – in this case they made a change that has negative impact on the customer experience, in the opinion of a large number users
  • Then “Suggestions from […] like you are an incredibly important part of that process.” – First, this is a general statement that has no bearing on anything, and second, I did not make a “suggestion”, I pointed out a change that’s making it harder for me to use the product
  • Followed by “Updates can be done without notice, we will keep you informed if we make an update on our platform.” – which is a plain contradiction
  • And the concluding sentence is “We want you to know how much we appreciate your input and support!” after doing everything to show that they don’t

This vendor, with a single response, managed to transform an otherwise satisfied customer with a product problem into a skeptical customer, questioning their commitment and willingness to provide service. Analyzing how this happened leads us to several conclusions:

  • Being too familiar and personal, with phrases like “personally” and “I’m glad”
  • Using phrases that sound good but have very little to do with the situation
  • Using feel good language as a substitute to meaningful information

Do your response templates suffer from similar problems or are you making it every individual person’s responsibility to produce their own customer responses? Have you ever read those responses with a critical eye? Or, even better, ask someone else to do that? If you service customers in multiple countries and cultures, are you aware of the differences in perception between those and your native culture?

Update: while writing this post I received a message from the vendor:

I’ve passed your message to our engineering team and will be better able to help with your particular question. You will receive a more detailed reply shortly; we appreciate your patience!

Which sounded like good news, until the following message arrived a day or two later:

Hi there,

We’re experiencing an extremely high volume of support requests currently and may not be able to directly answer every question received. Please browse our […] Help Center […] for articles that may help you resolve your issue, as it provides a lot of solutions to common issues reported by our learners.

If you have been able to answer your question in the last few days, there’s no need to reply to this message. If you have not been able to find your answer and still need assistance from us, please reply to this email and we’ll get an answer to you as soon as we can.

Thank you for your understanding as we continue to improve our support resources to help […] like you!
[…] Community Operations

Many companies have challenges handling growth, this one seems to do a particularly bad job at acknowledging it and taking the actions required.

I’ll post further updates when, and if, they are received

How to create a partner support program

Business men in a hurry run & walk on time clocks

The blog has discussed in the past some aspects of partner eco-systems on support, mostly focused on the motivations of the two sides and the business relations between them. Recently I had the opportunity to discuss support oriented partner programs and the basic building blocks that make them successful. This post, therefore, will focus more on the operational sides of creating a partner program

Companies have different classes of 3rd parties acting as intermediaries between them and some, or all, of their customers. These 3rd parties are sometimes called distributors, OEMs, channel partners, VARs, and more. From a support perspective, however, we are mostly interested in two classes of partners – those who support their own customers and those who do not. In this post we’ll focus on the first group, and we’ll use the term partners for simplicity

Building a successful partner support program requires consideration of four specific points:

  • Which partners should participate – entry criteria
  • What does the company require from the partners
  • what does the company provide to partners in the program
  • What does the company do to ensure partners continue to deliver and what to do if they do not

To join the support program, partners should qualify in several levels:

  • Infrastructure – having a case tracking system, or using the company’s system. Phone access to support staff, ability to recreate customer problems, etc.
  • People – the partner must have dedicated, well trained people to address customer cases. Routing customer calls to services or pre-sales staff in the field is not an acceptable substitute

Members of the partners support program should be expected to provide a certain level of technical expertise and deflect a considerable number of cases before escalating the balance to the vendor’s support organization. It is important to remember that some cases might slip through the net. But, overall the proportion of simple cases that can be resolved via the knowledge base, problem recreation and other relatively simple activities should be much lower than those received from direct customers

Partners are an extension of the company’s support organization and as such their ability to successfully support their customers is key to their customers’ satisfaction with the products as well as propensity to renew their support and maintenance contracts. The company must therefore ensure partners have access to as many information resources as possible, from internal and external knowledge bases through customer cases all the way to training and more. When given access to customer cases then customer identity should not be shown to the partner staff

To ensure that partners continue to deliver the expected service levels to their customers, companies must think of developing a relationship that borrows some elements from the customer success discipline. For example, a periodic business review, where metrics are reviewed and an open discussion of what works and what doesn’t, and most importantly, how to capitalize on the positives and fix the negatives

In short, a successful partner program treats the partners as an extension of the company to ensure its success rather than ignore them, or even worse, create an adversarial relationship

How to not ask for feedback

Earlier this week I had the chance to participate in a seminar. It was an interesting day in a beautiful location, and lunch was provided. Part of lunch a bag of chips which contained this text:


It’s possible the manufacturer had every intention to solicit all feedback from customers. But, my first reaction was “what number should I call if I don’t love your chips?”

I am sure many of us have similar stories about such interactions, from the car dealership asking us to “fill the survey only if we can give them 9 or 10, otherwise call the manager” to this bag of chips. While these are amusing stories they have a valuable lesson – you get what you ask for, and if all you want is positive feedback that’s what you are most likely to get.

Having said that, let’s remind ourselves of the value in customer feedback. First, and usually the case of these entertaining messages, is reconfirmation – we’d like the customers to confirm for us that we are doing a good job. Second, and most importantly, is that systematic customer feedback helps us understand where our operation is failing to deliver the expected product or service. If we don’t solicit that feedback we’ll never get it and eventually lose to those who do and continue to improve their operation based on that.

Minimalistic Surveys?

Green hexadecimal computer code fading to the right

Recently I had to contact Coursera support to ask a question. A day later I received an email message asking for my impressions:


Clicking on the link in the message takes the user to a text box for additional comments.

Given my interest in surveys, and using them for insight and improvement, I found this message thought provoking. There are several benefits to using such a short survey:

  • Reduce survey fatigue – fewer questions will drive higher response rate
  • Binary choice – customers’ opinion is very clear

However, there are a few downsides to this type of survey:

  • Lacking nuance – gaining improvement insights from a single binary choice requires extensive additional processing and analysis to correlate results with operational metrics. Lack of rigorous analysis will drive over reliance on text comments
  • Interpretation bias – reading text comments in an attempt to gain systemic insight presents a danger of several biases. Eloquent comments will naturally be given more weight, and comments in foreign languages depend on the availability of someone who can read and translate them

With these points considered, can enterprise technology companies enjoy the benefits of shorter surveys without sacrificing the quality of insight produced? To answer that, we need to look at two distinct points:

  • What’s the shortest survey that will provide the information required to gain insights into the most beneficial improvements?
  • Can the company analyze text comments and maximize information gained out of those?

Finally, how can companies make shorter surveys work?

I believe that in order for these surveys to work well and provide meaningful insights several conditions must be fulfilled:

  • Sufficient volume of cases and responses
  • A wealth of operational data to correlate to survey responses
  • Rigorous analytic process, including text analysis (remember your non English speaking customers), and no, reading the comments for broader insights is not rigorous

Observations on Customer Experience Improvement

Good Better Best Keys Represent Ratings And Improvement

Just came across a very interesting article courtesy of McKinsey Quarterly‘s Classics mailing, discussing the need to optimize service delivered to customers needs. While it focuses on consumer businesses there are a few key learnings for enterprise technology support operations, demonstrated by this quote:

“Finding these savings requires rigor in customer experience analytics: […]. It also requires a willingness to question long-held internal beliefs reinforced through repetition by upper management. The executive in charge of the customer experience needs to have the courage to raise these questions, along with the instinct to look for ways to self-fund customer experience improvements.”

The McKinsey article identifies two main drivers of resistance to implementing effective improvements:

  • Organizational momentum and deep held, but often misplaced, beliefs. Frequently these beliefs are shared across management levels, causing the company to operate with ineffective goals that remain unchallenged
  • Lack of both rigorous analysis as well as the ability to present those results convincingly and effectively

A future post will discuss analytics techniques. Here I’d like to focus on a few causes preventing organizations from progressing towards effective and efficient improvements and combine a few of the blog’s previous posts for the benefit of new readers. First, we previously had a high level discussion of several differences between consumer and enterprise support, namely the different roles we interact with and the many more opportunities for friction.

We also wrote about complexity and volume. This is a very useful distinction, touching on the operational differences between high volume/low complexity operations and those with low volume/high complexity, as most enterprise support operations are.

Having said that, we frequently find concepts and metrics from consumer businesses that are not beneficial for the unique challenges of supporting enterprise technology. It becomes our job to educate the organization and provide deep, actionable insights to help the company excel efficiently. We’ll cover that in future posts