Since I recognize the words you use, I obviously understand you. And since my nouns and verbs and dangling participles are familiar to you, you must understand me.
Well . . . maybe not. Actually, one of the biggest mistakes we make in working together is assuming we understand each other. But often – very often – we mean different things by the words we use.
For this reason, when I evaluate service level agreements and service guides for clients, one of the first things I look for is explanations of service terminology. Consider, for example, the ambiguity inherent in such terms as respond, acknowledge, problem, and resolve. It’s not a stretch to imagine how providers and customers might interpret these terms differently.
Let’s say, for example, that you’re a provider who has agreed to respond to a customer’s problem within four hours. Does “respond” mean that you’ll have the problem resolved within four hours? Or does it simply mean that you’ll have confirmed receipt of the problem? In the absence of established definitions, customers might reasonably assume that the problem will be resolved in four hours.
That was the case with one customer I visited. As the customer learned to his dismay when a problem arose, the vendor’s intention was to acknowledge receipt of the problem report within four hours and then establish a timeline for resolving it.
Alas, this four-hour response commitment is ambiguous in several other ways as well.
Ambiguity Amplified
For example, what determines the start of the four-hour countdown? How must the customer report the problem to start the clock running? And does the starting point slide if the customer’s description of the problem is confusing or incomplete?
These questions lead to even more. For example, whatis the definition of “problem”? From whose perspective must it be seen as a problem? Is the same response time available to a customer whose mission critical work is halted due to a product malfunction — and a customer who is puzzled about a particular product feature? After all, both customers experience their situation as a problem.
Furthermore, what exactly does it mean to “resolve” a problem? Does it mean restoring service to its previous functionality by any means? What about solutions that can be implemented within the specified time period, but only at exorbitant expense? Must the resolution be a permanent fix? Do workarounds count?
And who determines that the problem has been resolved? The provider? The customer? Both? By what means is it determined that the solution is satisfactory? And who is authorized to declare the problem closed?
Of or Pertaining to
Clearly, these questions are not about mere dictionary definitions, but about how providers and customers intend to interact, communicate, and work together. As a result, almost every word in a service commitment bears examination for potential differences in interpretation, because clashing views about service delivery can often be traced to ambiguities such as these.
For this reason, a dialog about the meanings of such service terminology is one of the most important facets of the communication between providers and customers. In my experience, this dialog often leads to a wide-ranging discussion of how each party perceives service delivery. The result, when they’ve reached agreement, is a shared vocabulary that minimizes misunderstandings.
Should you be reviewing your service commitments to ensure that they adequately explain potentially ambiguous service terms? If not, gulp-inducing surprises are likely sooner or later. And that’s the case, no matter how you define “sooner” and “later”!
