What is more important? What you buy or from whom you buy it?

I recently had a very enlightening and satisfying customer service experience.

Not too long ago, I bought a new car. I love the car - it drives great, gets great gas mileage, looks cool, and is basically everything I was looking for in a car. Unfortunately, this car was also having persistent issues with the emissions system, causing the Service Engine Soon light to come on after about 1700 miles. I dutifully took the car into the dealer to have it serviced. Then I took it in again. And again.

With each trip to the dealer, my frustration mounted. I began to conclude that I had inadvertently been sold a "lemon". I did some research into California's "Lemon Law" and as a result immediately contact the manufacturer to notify them of the issues with the car, tell them how frustrated I was, and see what they would do.

Because of other customer service experiences - satellite/dish providers and mobile/telco providers spring immediately to mind - I expected the worst. To my surprise, the customer service provided by BMW North America was superb. The customer service representatives (I talked to two during one 20 minute call) were helpful. They showed empathy for my situation. They told me they would advocate on my behalf. They offered suggestions for what to do next. They asked me what would I thought would help bring the situation to a successful conclusion and promised to work toward those outcomes.

As a result, I was immediately calmed. I asked for a root cause analysis of the problem and I agreed to another attempt to service the vehicle. In the end, I didn't get a root cause, but I did get my car back with the issue fixed, was treated exceptionally by the dealer, and am probably on my way to becoming a lifetime customer.

Every successful company cares about their customers. So what makes one vendor or manufacturer different from another?

I am very often asked by customers, partners, Oracle sales people, and others what differentiates Oracle and our Identity and Access Management products. Usually they expect that I will tell them what our products do, how they are built, and why that makes them different from other products they may be evaluating. What I typically tell people is that it isn't WHAT we are selling but HOW we stand behind it that makes all the difference. The example above perfectly illustrates the point.

Let's face it, there often isn't a lot of easily identifiable functional differentiation between products sold by big enterprise software companies. While most claim otherwise, this is also true of many of the smaller start up and niche vendors in the identity and access management market.

The same can also be said for car manufacturers like BMW, Lexus, and Mercedes Benz, which is what got me thinking about this in the first place, that it's more about from whom you buy and how they help you after you buy it than what you buy in the first place. Setting aside the price aspect for a moment, generally this kind of thing is referred to as a commodity.

So when I listen to customers talk about what is really important to them, I generally hear them focus on two things:

1. they think of most software and the hardware it runs on as commodities, and;

1. as a result it isn't the product functionality they are worried about, but the robustness of the solution and how easy it will be to keep it up and running in their environment.

In fact, when asked to spend $100, many will spend $70-80 out of that $100 on tools/features for existing software that facilitate diagnosing or troubleshooting issues. As it turns out, this is an indication that these customers are worried about whether - when something goes wrong - someone will be there to listen, to help them through their problems, to understand what defines a successful outcome, and be an advocate toward that outcome.

So how do vendors and customers work together to achieve a successful outcome? What do commodity vendors do to differentiate themselves from other vendors?

While working with customers, I've noticed a few things that our team does that almost always
help:

• Be proactive. If all your interactions are based on hair-on-fire escalations you generally don't have a good basis for cooperative, constructive problem solving. Since most enterprise software support systems are by their nature reactive, proactive communication will help by establishing a raport and creating trust outside of the scope of reacting to a specific problem. Proactive communication will also allow you to anticipate key upcoming milestones so that you can prime your reactive support system to be ready before problems occur.

• Be transparent. Tell your customer what you are doing and why you are doing it. Most support escalations occur when your customer contact doesn't know what to tell his/her boss. Picking up the phone periodically, even if just to explain that you have nothing new to report but are continuing to work on or monitor the situation, can help defuse most potentially explosive situations.

• Show empathy. Don't make exaggerated claims or promise to deliver things you cannot deliver. The single most satisfying thing about the customer service I received from my car manufacturer was the fact that they made it clear they were on my side. They made no promises other than to be my advocate. That was enough.

• Engage action. Get everyone on the same page about why they come to the office everyday: to ensure customer success. If everyone is on the same page about why, you can avoid disputes about what needs to happen, who needs to do it, and when it needs to get done. The most successful resolutions I've seen have been the result of strong collaborations of cross functional teams where the day job of most of those team members was not, strictly speaking, customer support.

This is a pretty basic description of what the folks at my car manufacturer did for me. Of course, there is no one-size-fits-all solution that creates undeniable differentiation around a commodity product. Nonetheless, when prospective customers ask me what sets Oracle apart, I don't spend a lot of time telling them about software features. Instead, I describe the process above, explain why that is important to us as an organization, and how that emphasis benefits customers.

Usually, that is enough.