Sometimes The Extra Mile Is Free

Restaurant scene

Recently I visited a coffee shop while waiting to meet a friend. Walking in, I was impressed – the place was large, well lit and tastefully decorated. The food and pastries in the display cases seemed attractive, with quality ingredients and professional preparation. Clearly, those who designed and built this business aimed high, and their prices reflected that. As a long time observer of service operations I started wondering – could they deliver on the promise of the decor and the food?

Considering I only had tea, I couldn’t tell anything about the food except that other diners seemed to be enjoying it. However, from the service perspective I left with a few nagging points that directly apply to other service organizations:

  • The food is served in nice porcelain dishes which the crew clears once the customer has left. But, they do not wipe the tables, consequently, each table had some crumbs. Very few, but noticeable. When clearing the tables they do not use a tray, so we got a chance to see one of the crew walking slowly with a pile of dishes on her arms, trying not to drop them. Solution – get a tray, and put a little wet towel on it. Clear the dishes into the tray, wipe the table and be done.
  • When ordering a drink they take your order at the counter and bring the drink to the table. But, the crew has no clue how to walk straight while holding a cup. It was very comical watching one of them holding a saucer with both hands and walking slowly trying not to spill the coffee. Solution – rehearse, work on your muscle memory.

In both these cases, not only did the operation look unprofessional, but the employees were visibly embarrassed.

  • Last – my tea was delivered to the table in a cup. There was nowhere to dispose of the teabag nor were there sugar or stirrer on the table. I had to get up and get them myself, negating the point of table service. Solution? You guessed it. Bring a saucer, and place a few bags of sweetener on each table.

Now, there is a common thread between all these points. Fixing them will cost the business absolutely nothing, but requires an observant manager with a burning desire to keep improving the service. This begs the question, how much improvement could each of us make to our support operations at zero cost while helping our employees increase their skill and professionalism? How much better can we make them? What if we took the time to observe our organization from the side, and inspect every move and every action as they are perceived by the customer? Sadly, in many situations this seems to be everybody’s last priority.

Broader impacts of organizational maturity

Office success

In a previous post we reviewed the various maturity stages for a support organization. Having done that, the next question becomes “so what?”, or in other words, how does support’s increasing maturity impacts the value it delivers to the company?

To answer that, let’s look at the relationships with internal constituents, such as corporate management and adjacent organizations, as well as external entities like partners and customers?

Most of us can imagine how the dialog between support and engineering evolves in line with the increasing maturity. Support organizations transition from a front-end where every customer case is escalated to identifying failures, advising customers on product use and having responsibility for the customers and for the well-being of the installed base. Similarly, the interaction with sales shifts from adversarial to a partnership.

But, how does all this deliver actual value to the company?

If we think about it, there are three ways customer support can add value to the company:

  • Increased efficiency, so support costs for unit of revenue grow slower than revenue does
  • Creating additional support revenue through value added services
  • Reduced discounting during the sales process through collaboration with sales, minimized problem impact on customers
  • Accelerated and enhanced consumption of the products, driving the customer to add capacity or licenses

Additionally, a mature support organization can provide the company extensive amounts of information about the products and the customers, for example:

  • Ways in which customers use the products
  • Challenges and difficulties customers face while using the products
  • The most commonly used features, and those used rarely or never at all
  • Interaction with third party partners, their capabilities and deficiencies
  • Customer satisfaction and its drivers and inhibitors

However, the reliability of this information and the ability of the support organization to be a valued partner depends on the maturity of the support organization, but also on the maturity of the entire company.

What’s your experience in taking your organization to higher maturity levels? Where did you encounter the biggest challenges?

Enterprise Support Maturity Model:

Layered rainbow colored pyramid

Several weeks ago Harvard Business Review published a blog post by Vikram Bhaskaran, titled “Customer Support Hierarchy of Needs” which I read carefully but found unfocused and lacking in depth. Consequently I felt the challenge to develop a better, more coherent, model for enterprise technology support.

Eventually I came up with the following as a base model (see the bottom of this post for the naming choice). It is still a work in progress and as it is being refined I’ll post additional versions to the blog.

Pyramid Simple

The model attempts to capture the two most critical investment any organization makes, technology and people, and show the path they progress along in order to deliver a more comprehensive experience. It is based very loosely on the concepts introduced by the various CMM models and progresses through the various maturity stages.

We can all understand that the various maturity phases will not have clear transitions. In fact, most support organizations I have seen tend to have different segments of their operations at different maturity levels. The common theme for all, however, is the desire to make progress along the path to a more mature level of operation. Obviously, as companies expand, efforts may be directed to other pressing concerns, such as global expansion, supporting additional product lines, or adding third parties to the support chain. However, the need for continuous progress up the maturity levels is shared by most support executives I have met.

As a a first step I’d like to define a few of the essential characteristics for each phase identified earlier:

  • Chaos – Usually exist only very early in a company’s life, ad-hoc process, lack of infrastructure, metrics or dedicated staff. Support is provided by engineering teams and frequently personal heroics are key to resolving problems with any significant urgency or complexity. Third party partners may provide some support to specific customers, but the interaction is mostly at the technical level.
  • Managed – Basic processes exist, along with entry level staff to manage non-technical customer communication (e.g., case opening, status requests). Technical interactions still managed by engineering. Basic case tracking and multi-channel capabilities exist. Metrics are used but will usually focus on cost and volume. Basic offering parameters defined and communicated to customers.
  • Professional – Processes more elaborate than those at the Managed level, and may include various escalation guidelines. Technical staff is added to the support organization, and the infrastructure becomes more sophisticated in capabilities as well as utilization. Customer Satisfaction will be added to metrics. Sporadic collaboration with engineering. Additional services may be offered, such as Support Account Managers or extended coverage (e.g., around-the-clock or weekend) to supplement standard offering.
  • Proactive / Predictive – Knowledge management is used, customers are alerted to potential problems through proactive notification. Close collaboration with engineering teams to ensure high impact or widely encountered problems are addressed rapidly. Vendors can predict which customers or hardware components will encounter certain failures and act accordingly.
  • Invisible – Support integrated into other organizations in the company, resting a continuous customer experience through all points of interaction. Multi-channel interaction through forums and other social and traditional channels channels managed consistently. Customer intimacy used to eliminate failures, reduce their impact on customers and increase value derived from products.

How does this model fit with your experiences? Surely everybody who has been in this business for some time has a similar concept about the progress support organizations make over time. It does open the door to understanding the different perspectives to this progress, which we’ll discuss in future posts

The main reason I chose to call the model Enterprise Support Maturity Model as opposed to the frequently used Hierarchy of Needs is that while an individual’s needs have hierarchy, an enterprise customer has choices. We can imagine a hungry person might give up dreams of self-actualization while searching for food. A customer, on the other hand, will go looking for other, more competent vendors.

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?

Is It An Airline? Is It A Hotel? No! It Is Enterprise Technology Support!

Drawing of scale on blackboard

The blog’s previous post discussed confirmation bias and the way it impacts our actions. Frequently we encounter a different type of bias, usually coming from individuals not very familiar with enterprise technology support, and holding their support teams against standards that may not necessarily apply. Support managers find themselves having to explain the difference between supporting enterprise technology and a number of popular consumer businesses, including an airline, an on-line apparel vendor, a hotel chain and a department store.

There is no doubt that each of these companies have mastered customer service for their customer base, and surely there is a great deal we can learn from them, but in order to do that we need to understand the differences and ensure we adopt those those behaviors that can help our customers and us.

In the past I wrote about the differences between high volume / low complexity operations and low volume / high complexity ones. There are additional models that can help us complete the picture.

Stacey‘s Matrix attempts to illustrate the complexity in decision making in relation to two dimension:

Stacie Matrix

The first, on the horizontal axis is the degree of certainty in which the problem addressed is understood, including the cause and effect chains. The vertical axis then illustrates the degree of agreement between the various participants on the way to resolve the problem.

If we use an airline as an example, the vast majority of cases handled by its service employees is relatively straight forward and falls within the “rational decision making” zone of the chart – both the customer and the airline are clear on the objective and the way to accomplish it. Even when recovering from a service failure (e.g., lost luggage or a cancelled flight) there usually is clarity concerning the cause and effect as well as agreement on the best way to resolve the problem.

Now let’s look at enterprise technology customer support situation. Most company have done a good job at documenting their knowledge and making it accessible to customers, partners and other users. This causes the support organization’s workload to contain an increasing proportion of cases where either the cause and effect chain are not clear, or there is little agreement on how to achieve the end result, or both. These disagreements take us away from the relative comfort of the rational decision making zone, and increasingly into judgmental or political decision making, or even into the complex decision making zone.

Now, in order to resolve the customer’s case, customer support must ultimately reduce the uncertainty and clarify the cause and effect chain for the problem. Once that has been accomplished the case can be resolved and the problem eliminated. Consumer brands rarely have to address the need for reducing complexity and gaining agreement on the problem definition or the cause and effect chain leading to it.

Comments Now Require Signing-In

ランチョンミート

Even though the blog enjoys a regular following, the number of non-spam comments has been minimal while spam comments have been in the thousands every month. To make administration easier, users wishing to leave a comment will be asked to sign in with their wordpress credentials before doing so.

Evaluating People By Metrics

??????????????????

Harvard Business Review has an excellent post discussing people evaluation through metrics. This is not a new topic for customer support managers. Operating in a heavily instrumented and measured discipline, it is easy for support management to focus on the measurable performance portions to evaluate their employees and ignore those that are more qualitative.

Over the years I have seen many different metrics for measuring and evaluating employees, from rating on a customer satisfaction scale to number of cases resolved, through a plethora of other metrics. The biggest, and most frequent, challenge was the attempt to evaluate individuals’ performance along the same scale, regardless of their formal role or how they operate. For example, most of us are familiar with the individuals who can process a large number of cases very efficiently, and with others who excel at methodically analyzing the most complex cases, one at a time. Both these individuals may carry similar titles, but evaluating them along the same performance guidelines is futile and frustrating to the employees and their managers.

A far better way to evaluate employees is to evaluate each along their role they play in the team, their strengths and the improvements their managers would like to see. Yes, this requires a greater involvement on the managers’ part as opposed to cookie cutter evaluation criteria, and it definitely makes stack ranking much harder, but I do believe that this system is a much more positive way for managing people and will create a much better functioning organization.

About Assumptions

old razor

A friend sent me a link to a study claiming that when asked, very fast typists could not assign the correct letters to keys on a keyboard. Their underlying assumption was that their keyboard would not change and therefore the location of keys remains constant and did not require memorizing.

This led made me to think about the way those very fast typist would do with a different keyboard, and to the underlying assumptions we take with us from one role to the other without appreciation of how the different circumstances we operate in may require different solutions to those we are familiar with. How many decisions were made because the decision maker is in a somewhat recognizable situation and chose to blindly replicate past experiences, and how many of them are made because they represent the perfect response to the situation at hand?

Complexity and Volume

fading sound noise

Apologies for the blog’s long hiatus. A few personal projects took priority over posting.

The differentiation between high volume / low complexity and low volume / high complexity operations is probably familiar to most readers of this blog. We use it as a way to explain the difference between supporting enterprise technology and running a call center for a consumer product. As part of the research for my nascent book (yes, there is a book in the works!), I have been trying to find documented criteria for organizational differentiation. Strangely enough, I could not find anything documented anywhere and therefore this post is an attempt to start a discussion on these criteria. If any of the blog’s readers is aware of another source for this information please let me know via email or the comments section.

To illustrate the challenge, we can think of a continuum, on one end is an automated telephone service telling responding with the current time, on the other a single, most difficult problem imaginable. Maybe something on the scale of bringing Apollo 13 back to Earth. Analyzing the differences between these two extreme situations, we can come up with the following evaluation criteria:

 
Low Volume / High Complexity
High Volume / Low Complexity
AutomationComplexSimple
Customer IntimacyImportantNot required
Amount of offline work (Customer and Support)HighMinimal
Technical Interaction LevelVery HighVery Low
Interactions / CaseHighLow, Single
Value GeneratedContentVolume

Some of those criteria are self explanatory, however, I feel that “Value Generated” requires a few additional words. With high volume / low complexity transaction, the main learning for the organization is in the demand for the service. The service provider may find correlation between demand to other variables (e.g., time of day, day of the month, other special events). On the other hand, going back to the Apollo 13 example, the value generated by that effort, besides bringing the crew back in one piece, was the content of the analysis performed by the various teams, the decision making processes and the learnings associated with that.

What is your experience in using the volume / complexity continuum? Have you seen other, more detailed discussions? What was the reaction you received?

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.