blue ocean characteristics competences customer external employees innovation interactions jobs-to-be-done physical resources provider service systems technical

Service, as we’ve identified, can be defined in several ways. Including as the “the application of specialized competences (knowledge and skills)” as well as taking place through “interactions with service provider elements (employees, physical resources and systems)”.

Let’s look at how we can be a little more consistent on how we describe any particular service. In doing so, we get a model that helps us explain what the service does and involves. And where we can systematically seek innovations.

I’m going to use Gallouj & Weinstein model. Which sees a service as being made up of four characteristics:

  • external characteristics – this is the solution/offering as seen from a customer’s perspective
  • technical characteristics – the items used internally to the service delivery. This can be goods or systems of the provider as well as processes.
  • provider characteristics (competencies) – the individual skills of the provider employees needed to deliver the service
  • customer characteristics (competencies) – the skills the customer needs to have in order to co-deliver the service

And we show the interactions between these characteristics and competences as follows:

A service can be seen as 4 vectors of characteristics: the customer and provider competences and the technical and external characteristics
Vectors of service characteristics acting in a service

Simplistically, provider and customer competencies integrate and with the help of technical characteristics deliver the external characteristics.

Innovation is “simply” adding, removing, and/or changing characteristics and/or interactions between them.

Let’s jump in by first recalling how we are defining a service.

What is a service? A quick review.

Remember what we gave as our preferred definition of service? It was a slight re-organisation of Grönroos’ definition. For quick reference, here it is again in Figure 1.

Grönroos defined services a solutions to customer problems; processes made up of a sergers of activities that the customer may interact with
Figure 1: Grönroos’ definition of services

With this in mind, let’s look at the example I’ll use throughout this article. It concerns a financial service popular in Sweden for instant payment between friends (and increasingly to businesses).

Swish – an example (financial) service

Swish is a popular mobile payment application in Sweden (280 million euros in June 2020). It helps the beneficiaries make progress in securely and instantly transferring money between bank accounts. Initially, it was provided as a consumer-2-consumer solution but has expanded to support consumer-2-business payments.

Mobile phone numbers are used as proxies to bank accounts. That further helps the beneficiary make progress – I can simply send money to +46 708 88 112 – stored in my phone contacts. Rather than trying to get my friend to remember and tell me their IBAN number and sort codes.

You can see Swish in action in the video below.

Video: Take a look at how Swish simply works

The service’s process is a series of intangible actions. Initially, when installing the Swish mobile app, users link their bank accounts to their phone number. When they wish to make a payment, the payer enters the payees mobile phone number, amount, and clicks a pay button. The payee receives notification of payment. And users can also see a history of transactions in the app.

These actions take place in interactions with the Swish organisation’s provided system: the Swish mobile application. And, not uncommon with service, there is an ecosystem that delivers. An ecosystem that involves the Swedish banks – whose systems enact the transfer – and the Swedish banks’ owned BankID service – which provides identity and security services.

So how would we describe this service a little more rigorously?

Getting more rigorous in describing a service

We can describe any service a little more formally to remove uncertainty and have consistency.

Let’s take a look at Gallouj and Weinstein’s model, described in “Innovation in Services”. It is a model that breaks a service into four characteristics (though they quickly go on to call two of them competencies). And these characteristics are:

  • External characteristics (Y) – aspects of the offering
  • Technical characteristics (X) – goods, processes, places, ways of working etc, involved in the delivery
  • Provider competences (C) – skills of the provider’s individuals
  • Customer competences (C') – skills that the customer brings (or needs to acquire)

And these characteristics work together as I show in Figure 2.

Describing a Service as a set of service characteristics
Figure 2: Describing a Service as a set of service characteristics

OK. So, Figure 2 is actually less complicated than it looks. Let’s unpack it, at a high level, from left to right.

Simplistically, q customer competencies (C'=(C'_1 C'_2 \dots C'_q)) that integrate with p provider competences (C=(C_1 C_2 \dots C_p)). And by using the n technical characteristics (X=(X_1 X_2 \dots X_n)) the m external characteristics (Y=(Y_1 Y_2 \dots Y_m)) are delivered.

Now, not all customer, provider and technical characteristics integrate with each other. Individual external characteristics come from particluar combinations. For example:

  • just provider competencies (e.g. employees, AI).
  • provider competences integrating with technical competences (processes, physical resources, systems,…)
  • customer competences integrating with technical competences (processes, ways of working, systems, physical resources,…)
  • customer competences integrating with provider competences (relations, interactions,…)
  • customer competences integrating with provider competences and technical competences

Let’s check how this looks for our Swish example.

Swish as Characteristics

For our Swish example, we could define these competencies and characteristics as in Figure 3.

An example service described as its sets of service characteristics
Figure 3: An example service described as its sets of service characteristics

Our Swish service offers Instant payments to friends and businesses (Y_1) with no fee to the customer (Y_2) and is secure (Y_3). I should say that for reasons of space I haven’t made these lists comprehensive! And you can see the technical characteristics, customer and provider competences. Putting them together in terms of how they interact we come up with Figure 4.

Swish as a service
Figure 4: Swedish instant payment service Swish as interactions between service characteristics

And what we are saying in Figure 4 is, for example, that the secure characteristic (Y_3) is enabled by interactions between technical characteristic X_5 (the BankID technical solution) and customer competence C'_4 (that the payer knows how to use BankID application on their mobile phone).

Let’s go through each of these classes of characteristics in a little more details to see what they mean along with any gotchas. And we’ll start with what we can call the service experience.

Experiencing the service: the External Characteristics

We experience a service through its external characteristics (sometimes called the final characteristics in Gallouj and Weinstein’s paper). And these characteristics cover, for example, performance, opening hours, parts of the business model, etc.

External Characteristics

Other ways of thinking of these external characteristics is that they are:

For edit: I break into 3 – visible parts of business model; the job being done; the place (servicesphere). Links nicely to blue ocean strategy canvas.

We use the vector Y=(Y_1 Y_2 \dots Y_m) to refer to these characteristics. And when we want to talk about all of them we just say Y. If we want to talk about a particular one, say the 3rd, then we say Y_3. Don’t worry, that’s as mathematical as we’re going to get.

For our Swish example I’ve defined the following three external characteristics:

  • Y_1 = instant money transfer between two bank accounts
  • Y_2 = no fee to sender or receiver (the customers)
  • Y_3 = secure

Y_1 captures the job-to-be-done or progress the beneficiary wants to make. Whereas, Y_2 is part of the business model. And Y_3 is capturing an attractive (and necessary) attribute of the service: it is secure.

I should probably have added 24/7 availability too as a Y_4 and perhaps even more external characteristics to fully describe the service; but let’s keep this simple.

Bringing competences to bear: end-user and provider working together to deliver the service

Over on the left of the model we have the customer and provider competencies.

Customer and Provider Competences

Their positioning reinforces that these competencies usually work together in achieving the service. And this is what we refer to as co-creation of value. For the mathematicians amongst us, this almost resembles matrix multiplication.

We use the vector C=(C_1 C_2 \dots C_p) for provider competences and C'=(C'_1 C'_2 \dots C'_q) for the customer competences. And notice that C' has q items and C has p. What we’re saying is that there is no need – and its unlikely – that customer and provider have the same number of competencies. Or even the same competences.

It could be that the list of provider competencies, C', is empty. Such as we see in our Swish example. In such cases, we are talking about self-service. And it is possible for the list of customer competencies to be empty – for example when considering some professional knowledge-intensive based services (p-KIBS) such as lawyers and doctors.

But what types of competence are we talking about?

Types of competences

First, I have to highlight that provider and customer competencies are individual competencies. That is to say, associated with the individuals and not the organisation. Organisation wide competencies are seen as technical characteristics. However, individual characteristics that are seen as beneficial can become codified as technical characteristics in the future.

Gallouj & Weinstein roughly categorised competences as follows:

  • scientific and technical
  • internal and external relational
  • combinatory or creative (i.e. those that combine technical characteristics into coherent sets and subsets)
  • operational (or manual).

Let’s take a look at customer characteristics first. And how we might end up requiring them to get new competencies. Or how we can benefit from competencies they have gained from elsewhere. Finally, we’ll look at provider competencies.

Customer Competencies

Customer competencies are the skills and resources the customer brings to the service delivery. This builds on the co-creation of value we see happens in service.

The degree of co-creation varies across services. Seeing your doctor, for example, usually requires little more than your ability to describe what you see as your problem. Whereas engaging an interior decorator could require more input from the customer.

In our Swish example, we need the customer to have the skills to use the application. And so define the following customer competences:

  • C'_1 = they can use a smartphone mobile application that uses common, standard user interface components.
  • C'_2 = that the payer can find the phone number of the payee
  • C'_3 = (see next section)
  • C'_4 = that the payer can use the separate BankID application to identify themselves and sign a legally binding agreement to transfer money

Once you started listing customer competences you might find that your offering requires customers to gain new competencies.

Requiring a customer to gain a new competence

When you define your customer competencies, you might find you require the customer to have a competence they currently do not.

For example, virtual reality always appears to be the next breakthrough interface. But if your offering requires customers to have competence for that, you would currently be struggling, in 2020.

If your service requires a customer to gain a new competence, then think through how you give it to them…otherwise you'll quickly hit innovation resistance. Click To Tweet

If you are requiring customers to gain new competence, you have to help them. And you can attempt that by addressing the factors Rogers’ identified that affect innovation adoption speed. But more importantly, you should minimise the opportunity for innovation resistance.

But this can also work the other way around. Some other market/industry may have given customers competence that you can take advantage of.

Using a customer gained competence from elsewhere

It is increasingly common that consumers gain skills through experiences in one market/industry and expect to apply them in yours.

Customers may gain a competence in another market or industry…and then expect to start using it in your market/industry. Click To Tweet

For example, QR codes became common in the entertainment industry as a form of mobile ticket. It then rapidly spread across the travel industry in a similar ticketing capability.

And, Swish has taken advantage of the customer competence built in those industries to solve a hinderance in mobile payment. How do you minimise the risk of typing in a wrong phone number? Use a QR code, that when scanned, transfers the right details to the user interface.

Video: Using QR codes with Swish

And you can now generate your own QR code in the app so someone can quickly pay you if they don’t have your phone number in their address book. Or the vendor can display a static QR code with just payee details or even a dynamic QR with payee and price details. It’s all about making the payment quicker (less typing) and safer (less chance of typing error).

That’s quite a lot on customer competences! Let’s jump to the provider competences.

Provider Competencies

Provider competencies relate to skills of individuals in the organisation. For example, some people have great customer service skills, or are fantastic at programming in a particular language, or can expertly cut hair, or are a leading expert in a particular niche of law etc.

Individuals get these competencies from various sources. Originally from education, training and experience. And often from the repeated interaction with customers.

What we might normally think of as organisation competencies – the processes, routines or ways of working the organisation has – fall under technical characteristics in this model. The better technical characteristics the organisation has the higher the general perception can be. But it is the individuals that bring that little something on top. And that leads through to various comments you see about treating your employees well and they look after your business. As well as foundational premise of service-dominant logic:

Operant resources are the fundamental basis of strategic benefit

Foundational premise #4 service-dominant logic

It is worth noting that mature organisations will often look to codify beneficial provider competencies, as technical characteristics, to replicate them across the organisation. In that way an organisation can become known, for example, as having great customer care, codified through routines. But there will still be individuals with inherently better (or worse) skills.

In our Swish example, there are no provider competences. Because the customers do not interact with any individuals from the provider (it is all done through a mobile app – which is a technical characteristic of the service).

As an aside, I would place modern technology approaches such as Artificial Intelligence (AI), Machine Learning (ML), Robotic Process Automation (RPA) as technical characteristics (assets used to deliver the service) rather than provider competencies.

Finally, let’s look at technical characteristics.

Using Technical Characteristics: the products, processes, people, places involved

Last, but not least, we have the technical characteristics, X=(X_1 X_2 \dots X_n), of the service. These are the tangible and intangible assets used internally to deliver the service. And by tangible, I mean the scissors and the hairdryer of the hairdresser, etc. Whereas by intangible, I mean the processes and frameworks used, etc. Also included here is the servicescape see under the 7Ps of the marketing mix – including (digital) client interfaces.

Technical Characteristics

With that in mind, our Swish example has the following technical characteristics:

  • X_1 = The Swish Mobile Application
  • X_2 = Associate a phone number with a bank account
  • X_3 = Check with Payer’s bank there are sufficient funds
  • X_4 = Interface to inter-bank transfer in near real-time system
  • X_5 = Interface with BankID system

The technical characteristics can impact the provider and customer competencies required.

Finally, we can bring all of the characteristics of our Swish service together and see how they interact.

Bringing it all together

Now we have the service characteristics we can draw how they interact to provide the service (Figure 4 partially shows this).

Swish as a service
Figure 4: Swedish instant payment service Swish as interactions between service characteristics

So what are we saying? Well, let’s start from the external characteristics. Y_3, which was that the service is secure, is provided by technical characteristic X_5, the interaction with the BankID service. Which, in turn, relies on the customer being able to understand how to use it (customer competence C'_4).

And we can read this the other way around too. For example, the customer has a competence, C'_2, to be able to link a phone number with a bank account. That competency uses the service’s technical characteristic X_2, which securely enables phone number and bank account to be linked.

More complex is the instant transfer of money, Y_1, which is enabled by characteristics X_2, X_3, X_4. That is to say, payee and payer bank accounts are linked to phone numbers, there are sufficient funds in the payer account, and the service is linked to the banks’ instant transfer system(s).

Wrapping Up

So as we’ve seen through our Swish example, Gallouj and Weinstein’s model is very useful to understand and describe a service. We get to model the competencies the actors involved need in order to deliver the service. As well as the people, processes, place required. And how they all interact.

I believe it’s possible to pull out competences from this model and feed into the strategy canvas of Blue Ocean to search for those uncontested red oceans (growth). And that, as with service theory in general, that job-to-be-done is baked into o the external characteristics.

What can we do with this model?

  1. Understand service and the impact on customers (as we have seen above)
  2. Identify patterns of service (such as self-service – see this article [link to come])
  3. Search for and understand service innovation (a particular combination of adding, removing, and changing characteristics as well as the interactions between them – see this article)

Describing a Service as a set of service characteristics

Leave a Reply