Continuing with our book excerpt....
Our definition of the term service
For our purpose we need to define the word “service” as a term of art:
Service is the coordinated performance of one or more “activities” by one or more people on behalf of somebody else for their benefit.
Throughout the book, we will refer to restaurants and electric utilities as examples – if our definitions fit those two disparate service business as well as IT services, then we can safely assume the definition is generally applicable.
A restaurant is in the food service business. We go to a restaurant because they cook for us, they have expertise in cooking dishes we am not competent to prepare and wash the dishes. Alternatively, we could buy groceries and utensils, learn a recipe, cook it.
The same is true for electric utilities. We could buy a generator (or solar panels)., maintain it, provision it with gas and produce our electricity. Or we could contract with the local utility to deliver electrical power at a certain price and availability. They buy generators, maintain them and do all the necessary activities to ensure electrical service is available.
In both cases, we benefit from their service. This base definition works at the common sense level.
Next, we need to extend this definition and formalize the roles.
A service always has at least two participants: a performer offering to perform one or more task or activities to a certain specification, and a customer willing to either accept the offered specification of the work or to request and specify the work.
In this definition, a service is either offered to a customer or requested by a customer. Alternatively, we could say, without a customer involved, the performance of those tasks is not a service—The customer needs to either specify the work or specify what work they want performed.
Back to the restaurant example, when we go to McDonald’s we agree to accept the specification to a Big Mac without too many changes – maybe we can ask to remove the sauce. But we can’t ask for the Big Mac to be made with filet mignon. Nor can we ask for a hot dog – not available.
We could go to Burger King and order a Whopper without mayonnaise or onions, add mustard. Burger King does allow for more customization, but it’s still a within the burger category.
The specification, requested or offered, needs to include:
Terms and conditions of the work to be performed, including minimally time for fulfillment of the performance, benefit, and an exchange of value for the work performed
Terms and conditions are the specifications that make a service offer or request finite and set boundaries to the performance of the service and set the expectations of the benefit for the service. In IT services, terms and conditions are sometimes referred to as a Service Level Agreements (SLA) but SLA is both less and more. Terms and conditions may include a large number of elements—when we talk about IT services, we will have many detailed specifications. But even a travel service is governed by complex SLA’s—just look at the back of a typical ticket. One different between “T&Cs” and SLA’s is that SLA generally imply making the term and conditions observable, measurable and actionable.
Time. Without the notion of time, explicit or implicit, a service is nonsensical. When wills the hamburger be delivered? What time is installer arriving? The customer needs to know. How long do we have to deliver? The performers need to know too.
Sometimes, time is implicit: at the fast food restaurant, the burger seems to arrive soon or now--why bother specifying time? But in reality franchisees are trained to deliver orders in 1 minute, they are measured and the franchise is graded based on those metrics.
What’s implicit for a customer is not for the performer. For more complex services, time explicitness is critical. Time for response, for completion, for communicating major milestones and breakdowns need to be defined and communicated—or the service experience breaks down in acrimony, misunderstanding and distrust.
Benefit. A service provides a benefit that helps or profits a customer. The service takes care of a concern, worry, want, requirement, or need. It is this expectation of benefit that often causes the biggest disconnect between customers and performers. The customer expects certain benefit, but the performer is focused on activities. A service is different than a pure task because of the expectation of benefit. The benefit of a service needs to be articulated clearly, quantified, and qualified in a way that both parties can each objectively understand what is to be achieved by the service. Often benefits are implicit which is ok for well understood services such as restaurant service, but need to be made explicit for complex services such as IT.
Exchange of Value. For a service to be considered a service, rather than an activity, it must have some value for the customer, and because the customer gets value some exchange needs to take place. This doesn’t mean necessarily only monetary financial transaction need occur; it could be accounting charges to cost centers. But there needs to be a clear financial cost to the customer and a clear financial benefit to the service provider. If a service is always free, without consequence to the customer, then that service will be over-consumed which will cause diminish the availability and quality of that service to other customers. We like to call this soviet monopoly services, because “it’s free, but we don’t have any.”
This is difficult to do in some organizations, so a way to think of this attribute is that there is a strong form and a weak form of value exchange. In the strong form, there’s a direct financial correlation between both the customer and the performer and the benefit and the value. In a weak form, the customer and performer are not connected directly. Examples of this occur when there’s an intermediary buying the service (think government, healthcare) or the value is non-financial. Either approach is ok, but your service quality will be affected by the weak form.
Watch for part 3 next week.
Comments