Category Archives: Customer Relations

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!

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

Are Your Technology and Policy Aligned?

time to upgrade

An interesting discussion on the ASP Group on Linkedin asked for ways to address customers who won’t upgrade their systems and keep requesting support. There are several valuable suggestions in that discussion, but I’d like to use this opportunity to address the how vendor choices impact customers upgrade decisions.

There are two main choices vendors can make that impact customers’ decision. First are policy choices: for example, the number of supported release and the options available to a customer on a non-supported release when encountering a problem. Second are engineering choices: complexity of the upgrade process, the amount of work the customer need to invest in the upgrade and whether any equipment needs to be acquired. These decisions influence customers and their ability, and desire, to upgrade. The interaction between policies and and technology choices will tend to drive customer choices and the resulting actions vendors can take.

The following matrix offers a quick visualization of the choices and their impact.

matrix

If we think about these four options, we can identify some familiar categories and use cases:

  • Quadrant I is empty due to the fact that simple or automated upgrades make it easy for customers to upgrade vendors can get away with strict policies, sunsetting releases rapidly, reducing support levels for backward releases and sometimes charging high maintenance fees.
  • Quadrant II Is for situations where upgrades involve high expense and risk, and the vendors are willing to continue supporting these releases either for customer retention of for the increased maintenance fees. The most famous example is Microsoft’s extended support for Windows XP.
  • Quadrant III Represents cases where software upgrade is simple and in many cases automated. A typical use case would be Anti-Virus software with auto-update capabilities and little effort investment on the customers’ side.
  • Quadrant IV Here we find extremely complex technology deployments (think large scale ERP systems), requiring extensive customization, and subsequent testing and adaptation when upgrading. These are extremely expensive, time consuming and very risk prone. Frequently customers would rather stay on their original release and avoid upgrading Vendors who refuse to support their older releases or who impose high costs for doing that may find their customers defecting to third party maintenance providers.

Understanding these categories and the choices you make will help you understand how your company’s policy and technology choices impact customers’ upgrade decision and your maintenance business.

Product Design and Customer Satisfaction

Rugby Player scoring a Try!

The usually excellent Barry Ritholtz posted a massive rant against the location of the power switch on his MacBook Air laptop, ending with the promise to reconsider the purchase of additional computers, with this flaw being the driver.

In support we come across similar situations regularly, especially with smaller implementations, where customers find that certain product features diminish the value they can derive to the point of eliminating all value generated by the product. Those customers also make it a point to tell us about it. This raises several questions. First concerns the mechanism for disseminating customer feedback into the decision making ranks. The second looks for a way to evaluate the scope of the problem (or in other words, what part of the customer base is affected by the problem and to what degree?)

Now, how would you address the challenge from Mr. Ritholtz? Obviously there is a range of options to handle the individual customer, but I am curious about methods to convert feedback into actionable information. Any ideas?

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?

Still Measuring Call Time?

I came across (via a comment on Wim Rampen’s excellent blog by Arie Goldshlager) a very interesting interview with American Express’ EVP of Service reviewing changes to the company’s contact center practices. In the interview Mr. Bush makes several interesting statements such as “We also strongly believe that great service doesn’t come down to what we think about our performance internally. It’s all about what the customer thinks after every interaction. So we’re not measuring our performance by internal measures.”

Later in the interview the discussion continues to review some of the benefits and guiding principles behind the change. Most importantly, however, is the focus on the long-term relationship between the customer and the company. If this kind of thinking works for a high volume operation like American Express it should work for the Enterprise Software market as well.

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?

So You Think You Can Delight Your Customers With Break Fix Service?

[This post touches on a few aspects of service theory and is therefore a little more academic than usual.]

I have, for a long time, supported the position that it is impossible to delight customers in a break-fix service setting, but to understand the reason for that, let’s first review the definition for delighting customers.

According to service theory, customer expectations for service quality span a range, called “zone of tolerance” (very good ppt presentation detailing the concept here). The low boundary of the zone is “adequate service”, or the minimum level the customer will accept, while the high boundary is “desired service”, the best level the customer can imagine. Now we all know that customers expectations for service are derived from their prior experiences, so even if we do a good job at delighting customers, our job will become increasingly difficult with time as expectations will rise in accordance with prior service experiences.

But wait, didn’t I say earlier that it is impossible to delight customers with break-fix service?

I did, and here’s the reason:

Some time ago I wrote a post discussing the ways customer support protects and expands customer value. You may recall the point made there, that break-fix service should be focused on restoring the product to delivering its expected value. Now, we can safely assume that for our customers desired service is having the product work flawlessly, then the inevitable conclusion is that delighting customers with break-fix service is not possible.

Do you try to delight your customers? Are you successful doing that? If so, I’d love to hear from you, and from everybody else as well.

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?