Category Archives: Support Management

Hiring Your First Support Leader

Rainbow team background

In the past few months I had several opportunities to discuss the transition start-ups make when hiring their first support leader. Typically, they are in a situation where they have 2-3 engineers providing support to existing customers, partners and field teams. Those engineers will most likely report into the engineering team and as their workload grows the need for managing support as a separate section of the organization becomes clear. At this point in time support is not large enough to justify hiring a full time, experienced executive. The company therefore decides to compromise and looks for a Support Director with the following qualifications (slightly modified to protect the innocent):

  • Strategic vision and the experience to implement it
  • Ability and knowledge to scale the organization, including hiring, and preferably globally
  • Technical knowledge and willingness to take customer cases until the organization is large enough to occupy the person full-time

I am fairly certain there are a few individuals that are able and willing to fulfill all requirements, but I have yet to meet even one of them. Eventually, it seems, companies will hire an engineer with some management experience to the position of director and be content for a period of time. At a certain point the demands of the role (grow and scale the organization, establish relationship with remote partners and sales teams) will extend beyond the person’s ability and impact the business. At this stage the company is forced to hire an executive to manage the support organization, while having to address two distinct challenges. First, this hire is done reactively and usually in crisis mode, and second, the need to address the dissatisfaction of existing management who feels pushed away from the action.

In order to address these challenges, companies must recognize the two stage approach to hiring. First, hire a manager / team leader using job specs similar to those posted above. Do not attempt to hire someone you believe will be able to develop from a case taking team-lead to an executive with global, strategic vision and the ability to implement it. You will fail and the price of recovery will be steep in business and personal terms. Instead, recognize the need for several levels of skill as you plan the organization, hire and communicate accordingly.

How To Not Ask Questions

Time for feedback

A coworker of mine from many years ago had as one of her guiding principles “Never ask a question if you are not ready for any possible answer”. I was reminded of her, and her favorite principle, while discussing customer surveys and customer feedback recently

It is common practice in service situations to inquire about the quality of the service, and I am sure every person who is even remotely associated with supporting enterprise technology had participated in numerous discussions about surveys, customer forums and similar initiatives. But then, how much thought was given to making the results actionable and actually acting on it? Here’s an example I am sure many of us encountered while having a meal in a restaurant. Inevitably one of the waiters will come by the table and ask if everything is OK. Our answer, very frequently, is “yeah, everything is great”, even if, in fact, nothing is. I am sure we have all wondered what would happen had we provided our honest feedback in response – “the soup was cold and the bread was stale”

Now, anybody who has visited more than a single yelp page would know, negative feedback is an opportunity to make things right, but that opportunity is too frequently neglected, leaving the customer to vent over the internet and creating significant damage to the restaurant’s reputation

So, how should we address customer feedback? Here are some pointers:

  • Only ask questions that will provide you actionable information
  • When feedback is received, act as soon as possible and keep the customer informed
  • Clarify negative feedback, e.g., when a customer responds with a poor survey, call and discuss their concerns
  • Report back to the customer community through a newsletter, website updates, or similar means on all the changes you made based on their feedback, encouraging them to provide you with more information more frequently

Complicated? Not really, but it does require constant focus and commitment.

What methods are you using to collect customer feedback and encourage dialog?

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?

What Can Enterprise Support Learn From Auto Rental? (Part 3 of 3)

How to choose correct education?

So, what did we have in our car rental story (part 1 and part 2)?

  • Lack of familiarity with regular customers
  • Redundant requests for information
  • Confusion of onstage and backstage activities
  • Asking questions that the company has no intention to act on

How many similar failures are built into each of our processes? Let’s think about possible situations we are all familiar with:

  • Transitioning cases between individuals in different tiers (here’s something I wrote in the past)
  • Incomplete record of customer entitlements, support levels and preferences. These may have multiple reasons ranging from poor maintenance of records all the way to legacy of acquisitions with different offerings and practices
  • Being unprepared for a meeting or conversation with the customer. How many of us have employees going on a phone call with a customer without reviewing the case record or possible resolutions?

Many of these habits were discussed in the Harvard Business Review article, Stop Trying to Delight Your Customers. What can we do to correct them?

Expanding Internationally? Here’s Your New World Order

Many companies struggle with expanding their support operation internationally. Many choose to expand their international operations one country at a time, and the support organization usually ends up reporting to the country manager as part of the overall sales organization. As business grows, the likelihood increases that those teams will grow without much planning, coordination or guidance, resulting in under-utilization of some individuals while others are over-extended, leading to employee frustration and attrition. This distributed model is generally viewed as overly expensive and poorly delivering. Certainly it delivers inconsistently across country borders and greatly depends on the support, good will and understanding of the local managers to succeed.

Companies planning global expansion should consider this situation early on and evaluate the benefits and risks of having multiple local organizations vs. having a single centralized operation:

  • Consistent customer experience world-wide can be achieved fairly easily through central management.
  • Focus on local market requirements should be built into the organization by taking the time to understand the needs of individual market and developing ways to address them
  • Flexible deployment of skills – a central organization can shift people to address urgent problems between customers in multiple countries or regions without extensive coordination and turf wars
  • Efficient utilization of resources – reduce the need for multiple facilities, labs, training schedules to address every single need, and focus on a centralized operation to
  • Redundancy of skills – local organizations tend to acquire critical skills without giving much thought to their ability to utilize them fully. This leads to situations where highly experienced engineers utilize their skills for only a small fraction of the time and are otherwise kept busy doing other work
  • Ability to deploy best practices rapidly – local organizations will tend to shy away from investing in best practices or joining initiatives that do not carry immediate benefits, counting on ‘corporate’ or other resources to deliver tools, information and knowledge

The main exposure in a centralized support organization is the need for local variation in delivery. Having a centralized organization that coordinates closely with the local country teams, focuses on understanding their needs and delivering to it can solve the majority of those problems.

Keys to the success of a centralized support organization are on-going executive support and the ability of the the support reporting chain to gain and maintain it through collaboration and execution.

How to Irritate Your Customers Without Even Trying

Evernote is an innovative service that allows users to clip webpages and other files, tag and store them centrally, and then search and access from anywhere. I have been a paying user for a long time and am generally pleased with the service. But, two problems make it inconvenient for me to use the service in certain situations.

I tried to get evernote’s attention to these problems multiple times, and received no acknowledgement, until today when I posted the following on one of evernote’s facebook threads:

“Two questions, 1. when will pdf clipping from safari return? and 2. when are you going to fix the stupidity that focuses on the notebook’s top when moving a note from the middle? This makes organizing information tedious and annoying. I am a paying customer using the mac client, and I find that evernote’s service is non-existant. I have been asking these two questions for a long time and never received a response or even an acknowledgement. Too bad to see excellent technology being undermined by dismal management practices and too much success too quickly.”

The response came a short time later:

“Sorry for your frustration. We are definitely hearing all of the feedback and try to acknowledge all of it as it comes in. Regarding your specific questions. 1. We don’t have a date on this, unfortunately the recent Safari updates has caused some issues with our extension. For a more in depth discussion and explanation you can check out our forum. 2. This feature requested is noted, thanks for passing along. We appreciate all of your support, I assure you we are hard at work continually improving Evernote.”

So, what’s wrong with this response? Many of us have written similar ones over the years. Well, I am glad you asked:

  1. Evernote say they try to acknowledge all feedback. Well, either they don’t, or they fail miserably at that. In any case, not a word about doing it better in the future
  2. Sending users to their forum with no pointer to a specific discussion or record. If there is information in that forum that’s relevant, please post a link, or better yet, summarize it here. After all, forcing customers to switch channels to get a response is one of the poor practices discussed in my previous post
  3. There is no indication of any timeframe or intention to solve the problems
  4. despite this, they end with an assurance that they “are hard at work continually improving Evernote”. Employees’ hard work is between them and their management. Customers pay for functionality and service, and could care less if they are delivered by people sitting by the beach on a tropical island while sipping drinks with little umbrellas

So, evernote, you received some free advice. Will you do anything about it?

Are You Making Your Customers Work Too Hard?


Over a year ago, The Harvard Business Review published an article titled “Stop Trying to Delight Your Customers” (caution – pdf, subscription required). In this article, the authors make the observation that improving service beyond a certain point does not necessarily increase customer loyalty and retention. The authors continue to state:

“Reps should focus on reducing the effort customers must make. Doing so increases the likelihood that they will return to the company, increase the amount they spend there, and speak positively (and not negatively) about it—in other words, that they’ll become more loyal.”

To meet customers’ expectations, reps should anticipate and head off the need for follow-up calls, address the emotional side of interactions, minimize the need for customers to switch service channels, listen to and learn from disgruntled customers, and focus on problem solving, not speed.”

The Corporate Executive Board has made the article available, together with an evaluation tool, allowing organizations to assess their own performance on various customer effort criteria. But, the tool evaluates the systems and processes and does not provide

However, thinking about the article, we can quickly realize that there are several ways in which customer support organizations can make their customers work too hard:

  1. Repetitive requests for information, of for the customer to recreate the problem
  2. Multiple attempts at fixing the problem
  3. Insufficient and infrequent feedback to the customers requiring them to follow up

Taking the two into account, it is easy to see the need for an “effort index” that will measure the ongoing effort customer support requires of customers in order to resolve cases. Seems like a topic for a future post.

Have you implemented CES measurement? Are you aware of anybody who does? What’s your impression with it? Do you see the need for a more detailed effort index bases on enterprise support criteria?



Automatic Case Closing, Good Idea Or Not?

Closing cases automatically is a highly debated topic in almost every support forum. In a previous post I wrote about closing cases before receiving the customers’ consent for doing so. That post was written from a purely high-complexity, enterprise support perspective.

A recent question on linkedin’s ASPI group (highly recommended) led me to think about this question in more detail and try to determine times when closing cases automatically can be a good idea. After some thought I arrived at a model that attempts to distinguish between the nature of the technology supported and the nature of the customer relationship:

One distinction the model does not make is whether support is waiting on additional information or confirmation whether a solution worked or not. This can determine the amount of time before closing the case or the number of reminders before closing the case

Do you close cases automatically? How do you determine when to close them? Do you issue reminders automatically? Is there human intervention or other input to the decision? How many of these cases are eventually reopened?

Making The Case For Publishing Knowledge

Employees frequently see knowledge management initiatives as a way to siphon off their knowledge in favor of a cheaper / automated / whatever option (“you want us to document everything we know so that you can fire us and send our jobs to …”).  It is not an easy discussion for managers to win, and to even stand a chance must be presented in a positive rather than negative manner.

The series of charts below came to life in support of this goal. They attempt to open the discussion by presenting the personal benefit for employees to participate in a knowledge management scheme and publish what they know.

The premise behind these charts is that employee pay is determined by their top level skill. However, those same employees spend only a fraction of their time at that performance level and the majority of it at lower levels. This situation is bad for all parties.  Bad for employees since they do not get to exercise their most critical skills frequently enough and therefore can’t expand their abilities and knowledge. It is bad for the company since it is paying for skills it does not fully utilize and will likely be too busy doing other things when needed.

When we ask employees to think about their skills, they usually tend to think about their top skill – “I am a system administrator with 20 years experience”.  This skill determines their pay and organizational status.  When we look at each employee skill we can draw a continuum from zero to maximum skill:

Now, to determine whether the company is receiving the full benefit from what it pays its employees, and whether employees are utilizing their top skills we need to determine what keeps our employees busy and where they spend their time.  We are likely to see a distribution similar to this:

Clearly this is not an ideal situation.  A far more desirable situation would be shifting the organization to spend much more of its time at the top end of their performance level. It is good for the employees as well as the company since this is where they generate most value for the company as well as themselves. The chart, therefore, would shift to look like the green section in the figure below:

This chart shows that some of the lower skilled work (marked in red) is either eliminated through collaboration with engineering, or, more likely, handed off to to entities down the value chain. For example, self service plays well into this scheme, as do reseller training and enablement, further training and empowerment of the call center team, and so on.

What’s your experience in driving cooperation with knowledge management initiatives? What worked? What did not?

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.