The recent release of Sim City, in a design driven by paranoid digital rights management and a resulting need to force traffic through centralized sites, has fallen on its face spectacularly. Here is one of many articles outlining the headaches Electronic Arts has pawned off onto paying customers.
This prompts me to share part of the reason I have deliberately not played an EA game since the year 2005.
Showing posts with label support and service. Show all posts
Showing posts with label support and service. Show all posts
What is satisfaction? Invite your customers to spy on you.
In the news recently. A couple who wanted to have their wedding at a ritzy
five-star hotel found out in a not-so-pleasant way... it isn't going to happen.
The hotel's wedding planner sent an email to her boss and accidentally cc'd
the couple saying, "I know this probably doesn't sound very nice, but I am
trying to put this wedding off as I don't think they are the type of people
that we would want to have at Stoke
Park."
I will avoid debating the rights of a private
establishment to refuse service to whomever they choose. I'll also ignore the fact the bride
in question is adult glamour model Pauline Bailey.
There’s another customer service lesson here besides
remembering to watch the cc line in those emails. The lesson is: think positively
about your customers and pretend like they’re eavesdropping on everything
you say about them.
Interactivity, Relevancy, Immediacy
Fifteen years ago, someone attending a talk would expect a speaker to stand up and deliver 45 minutes to an hour of speech, with a few minutes for questions at the end. Attendees didn’t expect too much interactivity, relevancy or immediacy regarding their own concerns. Now, EVERYONE expects that.
In Customer Service: "Trust, but Verify”
When I advise teams, I make a point of how design principles change based on market, complexity, product flexibility, and customer profile. There is not a magic one-size-fits-all approach to support models (or to much else in life). Even so, I think this “trust” principle merits global consideration.
While a goal of “taking the customer at his word in all things” is admirable, it can actually create problems for the customer, your company, and your reputation. This is particularly true in technical or financial service support.
This isn’t a cynical view. Instead, we are simply taking into account the reality: People often do as they are incented to do. As third parties, we don’t always have a good view of those incentives. We shouldn’t judge, but we do need to verify key things are as they should be, particularly before taking important actions. Take one example I have seen over the years where customers are disincented from being entirely truthful: software warranty.
In the world of enterprise software, customer administrators are told in our warranty and documentation not to activate certain settings in certain combinations on certain hardware. If they miss or ignore these caveats, administrators may damage the capacity or stability of the product. They put themselves in configurations technical support cannot diagnose or support. Nevertheless, some administrators will consciously deploy unsupported configurations and either forget or hide them later on. This can invalidate technicians’ diagnostic tools and routines when problems later arise. Worse, it can cause our troubleshooting to further damage the customer’s systems and data.
A more robust approach is, "Trust, but verify." This is not just a good idea. It is essential in some service disciplines to ensure you have the information you need to render good service. It also helps eliminate situations where the customers are trying to get you to help them do something that... perhaps... they shouldn't be doing.
While a goal of “taking the customer at his word in all things” is admirable, it can actually create problems for the customer, your company, and your reputation. This is particularly true in technical or financial service support.
This isn’t a cynical view. Instead, we are simply taking into account the reality: People often do as they are incented to do. As third parties, we don’t always have a good view of those incentives. We shouldn’t judge, but we do need to verify key things are as they should be, particularly before taking important actions. Take one example I have seen over the years where customers are disincented from being entirely truthful: software warranty.
In the world of enterprise software, customer administrators are told in our warranty and documentation not to activate certain settings in certain combinations on certain hardware. If they miss or ignore these caveats, administrators may damage the capacity or stability of the product. They put themselves in configurations technical support cannot diagnose or support. Nevertheless, some administrators will consciously deploy unsupported configurations and either forget or hide them later on. This can invalidate technicians’ diagnostic tools and routines when problems later arise. Worse, it can cause our troubleshooting to further damage the customer’s systems and data.
A more robust approach is, "Trust, but verify." This is not just a good idea. It is essential in some service disciplines to ensure you have the information you need to render good service. It also helps eliminate situations where the customers are trying to get you to help them do something that... perhaps... they shouldn't be doing.
Subscribe to:
Posts (Atom)