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.
No comments:
Post a Comment