Category Archives: Support Strategy

Can Your Product Make Espresso?

young girl standing and juggling with red balls

Wish lists and their management are a frequent point of discussion in the customer support and success world. A wish, or enhancement request, is created when a customer would like the product to act differently than it currently does. Enhancement requests are added to the product team’s backlog, together with requirements from marketing, bug fixes and other development items, such as platform and technology upgrades. All items in the backlog are usually prioritized by product management, some will eventually be developed while others won’t

Customer Success and Support teams, focusing on single customers or transactions, are usually concerned with enhancement requests that represent the needs of individual customers. Conversely, Product Management and Engineering will focus on the needs of broader segments of the customer base as well as the overall needs of the market. Consequently, discussions with product management or engineering tend to break down and leave everybody frustrated. The question is therefore, how can Customer Support and Success teams succeed in making the case to Product Management for product enhancement?

From my own experience, there are several key actions to take:

  • Screen – Ensure that any enhancement requests you promote are in line with the product’s strategic direction. If they are not, then you’ll be misleading customers and losing credibility both externally and internally
  • Quantify – the number of customers that need, or are expected to need, this enhancement. [How do you know how many will need it? Sometimes it is obvious, for example, customers using a certain application or technology platform, customers subject to certain regulations]
  • Assign value – Estimate the risk the company is facing as a result of not implementing this enhancement. Consider what the company will lose due to not implementing this enhancement, this can range from having a single disappointed system administrator to losing revenues from multiple large customers for several products
  • Bundle – Are there several enhancement requests that are similar enough to be combined, or close enough to be developed jointly?
  • Recruit Customers – create a forum for customers to help refine the definition of the enhancement requests and solicit votes and comments. Doing so will help you in assigning value to the each enhancement. Françoise Tourniaire has an excellent blog post on managing wish lists in your customer forums

Following these steps will help you come to the product planning discussion equipped with high quality information and better, more strategic arguments than the fairly common “VIP Customer x wants the product to make espresso” argument, and hopefully you’ll have better results to show for it.

Customer Support or Customer Success?

Man Woman face people problem puzzle

I recently read an interesting discussion on the ASPI linkedin group about the role of customer success manager and the differences between this role and others in the customer support world.

A number of people have written about customer success management in the past. For example, Mikael Blaisdell, here, yet the more I read about the customer success manager role, the clearer it has become that there is neither a broadly accepted definition of the role nor any agreement on how people in this role accomplish their task. But, thinking about it in the context of the direction the technology world is taking may have the key to understanding the progression from Customer Support to Customer Success.

Historically and until early in the previous decade, vendors’ engagements with their customer were very structured. Customers made large, long-term investments in technology upfront. The deployment plan was then developed jointly between the customers’ IT and business teams and the vendors’ sales and professional services groups (or a third party implementation partner). The role customer support played in this context was mostly reactive and was focused on rapid break-fix problem resolution

The growing adoption of SaaS delivery brought a very different approach to adopting new enterprise applications. There was no need for a project plan developed together with the IT team, server provisioning or storage space. All you needed was a credit card and you were in business. With BYOD you did not even have to install anything on your company’s laptop. All that’s required are a credit card, a need to accomplish something and sufficient amount of curiosity to go look for an app or tool that will address that need

This change introduced a new and very different challenge that SaaS vendors had to address and which traditional enterprise IT vendors never faced. In their world every small purchase (or download of a free application) could eventually develop into a large deployment. The conditions faced by those vendors were relatively challenging:

  • The initial investment made by customers is small and usually without minimal term commitment
  • The purchasing individual may not have complete view of the needs and the product’s abilities to fulfill them
  • Products were installed to experiment with rather than to achieve a clear goal

These lead to reduced level of commitment on the customers’ behalf and therefore made it easy to walk away from the product when even the smallest difficulty or challenge are encountered. Obviously these conditions are much more common with small, tool-like services rather than major enterprise products. An individual at an organization may, for example, experiment with dropbox, but a salesforce.com implementation would still be done using the traditional enterprise technology model

Taking all these into account, we can begin to see the difference between the engagement model in traditional enterprise deals and that for SaaS delivery. It is safe to assume that while large, enterprise implementations are driven by sheer momentum, visibility and active management, small, ad hoc purchases are made and often neglected as discussed earlier. The role of the customer success manager would then be identifying installations that are not progressing according to certain pre-dtermined success criteria (see this post on the totango blog for a very good discussion ) and helping those customers overcome challenges, understand the capabilities of what they have just bought and make the most out of it, hopefully expanding the product’s use and stickiness

Obviously, as the terminology around customer success proliferates, we see increased creep into areas traditionally covered by other roles, for example, support account managers or technical account managers, engagement managers and others. But, I still believe the clear distinction between customer support and customer success is in the latter being more proactive and focused on the implementation and usage expansion while the former is more reactive and break-fix focused.

What is your opinion around this topic? Have you implemented customer success management in your organization? How have you defined the role and goals?

On Metrics and Employee Confusion

There’s an excellent post from Bob Champagne discussing the misalignment of strategy and metrics. I frequently seen this practice in employee objectives and evaluation as well as in job postings. It is not uncommon to see an enterprise software company talk on one hand about concepts such as knowledge creation and future call avoidance and on the other use low-complexity call center metrics, such as after call work and average call length. In this situation, employees will always veer towards the objectives that pay them more, either financially or in management praise or both. Conclusion? Take time to develop your metrics based on your strategy and objectives. Ask yourself how you would behave if you were faced with the choice and do not assume your employees will act differently.

Who Are You Serving?

Every once in a while we encounter a discussion that attempts to apply concepts from the consumer environment to the enterprise, without giving much thought to the differences between the two. I wanted, therefore to share an academic paper (pdf) I came across recently, that does just that – analyze the differences between the consumer and enterprise environments. The paper is called “Outsourcing Services to other Firms: A Framework for the Analysis of Consumer Satisfaction” and was written by Roland Böettcher and Marco Gardini.

the paper makes several important distinctions, chief among them is the distinction between the roles different individuals play in bringing an enterprise service transaction to completion:

“…individuals consuming the service and perceiving the quality most likely are not involved in the purchase process, i.e. in decision-making with respect to provider selection and price-quality trade-offs.”

The paper proposes a simple model for understanding the different roles:

This model, in turn, helps us understand the source for discrepancies in service negotiation, design and delivery between B2B and B2C interactions:

and identifies three potential gaps that can impact customer satisfaction:

  1. Definition Gap – Between the customer’s expectation and the negotiated contract
  2. Design Gap – Between the vendor’s contractual commitment and its ability to provide service
  3. Delivery Gap – Between the contractual commitment and delivery performance

Many support managers are intuitively familiar with these gaps and understand how they are created. Formalizing the definitions gives us additional information towards resolving them.

Tiers Or No Tiers?

John Ragsdale has an excellent post about the cost differentials between escalated and non-escalated cases across support tiers. The case for eliminating tiers in support has been made by quite a few support industry members, here is one example, by Phil Verghis.

When looking at multi-tier organizations, we should do that from three perspectives, the customers’, the support employees’ and the case that’s being resolved.

From the customers’ perspective multi-tier support does not generate any benefit. In many cases they have to explain the problem to someone with not enough knowledge or experience to handle it, only to have to explain it again to someone more qualified when the case have been escalated. As Phil notes, there is little to no recognition of the customers’ knowledge and experience or the circumstances of the problem.

From the support employees’ perspective, the tiered model presents several challenges. First, it does not allow them to exercise their skills beyond the limits defined for their tier. The model also encourages exclusive thinking, where higher tiers have a disincentive to share knowledge and coach lower tier employees for fear of losing their relative advantage.

From the case perspective, the journey becomes really fascinating:

  1. Case opened, customers describe symptoms to the best of their ability
  2. Tier One researches case, calls customer for additional information, can’t find a solution, needs to escalate
  3. Tier One must qualify the case for escalation, sometimes fill a long form or go through some other process
  4. Case is escalated, Tier One reviews the case with Tier Two
  5. Tier Two begins to research the case, often repeating many of the steps performed by Tier One
  6. If Tier Two is successful resolving the case, fine. If not escalation to Tier Three repeats the entire process

A good way to review this process is through the perspective of Lean methodologies.

So, what can managers do to shorten the case life, reduce the amount of unnecessary work involved in the case, and make their employees and customers happier?

Simple, bring the knowledge to the case, instead of the case to the knowledge.

If we think about it, many of the developments in support, at least those focused on knowledge, are aimed at two goals. First is the accumulation of all knowledge in the extended organization through KCS and user communities, and second is the ‘democratization’ of this knowledge, bringing it as close to the problem as possible. Support organizations should act in a similar manner when managing cases and bring the knowledge, and the person holding it, to the case and the person attempting to resolve it. By doing so the organization gains knowledge transfer that happens better through collaboration than through escalation. It eliminates the cumbersome, overly bureaucratic escalation checklist, and saves its customers the need to repeat the story every time the case is escalated.

There are two prerequisites for such a transformation to take place. First is the need to build a map of the knowledge in the organization, who has it, at what levels, and who are the go-to specialists, and a process to dispatch cases according to this map. Second, and more complicated, is the transition in roles that has to take place. Members of the higher tiers, who until now have been protected by a moat of forms, case handoff processes and chargebacks as well as exclusivity and status will now have to rub shoulders with Tier One employees and proactively guide them through complex cases. The situation becomes more complicated in case the support chain is split along tier lines between, say Sales and R&D, which introduces executive politics into the mix. Indeed, observing multiple support organizations, it is easy to get the impression that multi-tier organizations are born due to either the need to preserve technical knowledge or due to organizational mistrust.

What’s your experience with multi-tier organizations? Does it work for you? Did it fail to deliver? I’d love to know.

PS: As I was writing this entry, Phil added a link to story summarizing the experiences of Red Hat’s support organization going through a tier elimination exercise. It is very interesting and worth reading, including their lessons learned on implementing change.

Support, Transparency and Service Design


Support teams are regularly torn between customers’ pressure to disclose more information, especially when cases are not progressing as expected, and the need to protect the company’s internal processes or the identity of decision makers.  Frequently, we err on the disclosure side, thus exposing the decision makers to unexpected calls from customers and undue pressure.

Those of us who enjoy visiting restaurants with open kitchens will realize that while we enjoy watching the cook prepare our pizza, we hardly ever get to watch the dirty dishes piling up or, indeed, the dishwashing crew in action.  Similarly, there are always portions of the company’s operation that we should consider keeping away from customers’ eyes

Here’s where Service Blueprinting comes into play – it is a methodology for process design and analysis that, among other things, makes process designers aware of the need to make informed decisions about the visibility of sections of the problem resolution process to the customers.  A sample of a service blueprint is:

I am sure each of us can chart our favorite restaurant / bank / airport experience into similar chart,  Can we done it with similar clarity for our support operation?  Is the line of visibility as clear in our operation as it is for other businesses we are familiar with?

I added several blogs to the blogroll on the right with service design and blue printing information.  Wim Rampen’s blog is always insightful, while design for service and desonance have several good entries that got me thinking about

Take a look and let me know what you think.

How Support Generates Customer Value


One of my consulting clients wanted to develop a mission statement for their customer support operation.  The discussion revolved around a defensive “we solve problems” for a while until a breakthrough was made, proposing to focus the statement on the protection and enhancement of customer value.

When we chart the cumulative value customers expect to gain from a product we expect that during the early stages customers gain relatively little value due to implementation and training.  Conversely, towards the end of the product’s useful life with the customer, marginal value generated nears zero as users move to other products.

If we put ourselves in the customers’ shoes we can assume that while they understand the complexity of enterprise software the expectation is that the newly acquired solution will function smoothly and with little interruptions.  The customers’ expectation of value is driven by the expectation for, smooth, trouble free operation.

As customers begin using the product and encounter problems, we can see those problems’ cumulative impact on the overall value customers are able to gain from the product.  Critical problems detract significantly while others very little.  However, over time the total impact of problems can be significant drag to the customers’ value gain:

To help customers mitigate the value lost to problems on one hand, and maximize the value gained from the product, vendors have been introducing value-added services, or whatever fancy name they are called:

Has this post been useful for you?  Send me an e-mail or leave a comment.