Describing a service as characteristics – to help discover innovations

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

Grönroos’ definition of service is very useful. And we can make it more useful by making it a little more formal and operational by interpreting Gallouj & Weinstein’s model. Which I believe captures Grönroos definition more expressively as interactions between four lists of characteristics.

Here’s the two concepts side by side:

Simplistically, a service aims to achieves the external characteristics (solution to the customer’s problem). And does so through integrations of the other three characteristics. The customer integrates their skills and competences with the provider’s individuals (employees) skills and competence. And either may integrate with technical characteristics (goods, physical resources and/or systems of the provider).

A service, then, can be considered a specific set of integrations between characteristics.

And we should be aware that not all service types requires all characteristics. Self-service, for example, will not require any provider skills. Rather it relies on customer skills and technical characteristics (usually in the form of a goods). Whereas a medical service relies on provider skills and rarely on customer ones.


As a service is a specific combination of integrations of characteristics, we can think of innovation as adding, removing, and/or changing characteristics and/or interactions between them; which I explore here.

We see how goods fit into a service first world (as a technical characteristic). And that as we move towards self-service on the service-service continuum there is a greater emphasis on competence and skills of the customer (beneficiary).

And this model nicely exposes service-dominant logic concepts. Such as Co-value generation, for example, through the integration of customer and provider resources. And we get to see why operant resources (the other actors’ skills) become the source of strategic benefit.

Although the terms used (producer, customer, co-production of value) are less than ideal for service-dominant logic. Where we prefer actors, beneficiary and co-creation. This terminology change is one of the updates I propose. Along with reflecting the network/ecosystem nature of service, and that external characteristics should be the value proposition.

The Idea

I like Grönroos’s definition of service. Well, my slightly rearranged version you can see in Figure 1. It captures that a service is a process, consisting of actions that normally take place in interactions between customer and some combination of service provider elements – employees, goods/physical resources, systems. And that a service is provided as a solution to a customer problem.

Figure 1: Grönroos’ definition of services

Wouldn’t it be great if we had a slightly more formal way of describing this? One that captured the same thinking, yet allows us to define a specific service. That helps us understand the differences between positions on the service-service continuum and implications of innovating on it in either direction. (That’s not a typo, I do mean service-service – and it’s an evolution of the goods-service continuum you may be familiar with). And allows us to systematically hunt for innovation.

And I believe we can do so using Gallouj & Weinstein’s model.

Describing a Service

Let’s take a look at Gallouj & Weinstein’s model, described in “Innovation in Services”. It builds on a model from Saviotti & Metcalfe that helped define products using 3 sets of characteristics. And is described in “A Theoretical Approach To The Construction Of Technological Output Indicators”.

Gallouj & Weinstein show us how a service can be defined by four characteristics (although they quickly go on to call two of them competences). 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 you can see in Figure 2.

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

This is less complicated than it looks at first glance. Simplistically, a service aims to achieves the external characteristics (solution to the customer’s problem). And does so by the other three characteristics integrating. The customer integrates their skills and competences with the provider’s individuals (employees) skills and competence. And either may integrate with technical characteristics (goods, physical resources and/or systems of the provider).

Let’s unpack this now at a high level. And I’ll go through each part in more detail after we look at an example.

External characteristics

Starting at the right of Figure 2, we find the list of external characteristics – Y=(Y_1 Y_2 \dots Y_m) . Gallouj & Weinstein refer to these as aspects of the offering. These are the outcomes of the service from the user/customer perspective. And we can see these as describing the problem the customer is trying to solve. But, aspects of the offering are also wider than that. They include characteristics such as open times, and experience such as ”feeling safe”.

In my updates to this model we can leverage my updated view of value to observe external characteristics are the the value proposition. That is to say what functional and non-functional progress the service offers to help the beneficiary make.

Incidentally, if the way these characteristics are written here looks somewhat mathematical, don’t worry, it’s really just a short-hand for a list of sentences as we will soon see in an example.

Achieving external characteristics

Achieving those external characteristics requires specific integrations of the other 3 characteristics.

Firstly, we have a list of customer skills and competences – (C'=(C'_1 C'_2 \dots C'_q)). And those integrate with a list of provider skills and competences (C=(C_1 C_2 \dots C_p)). What we mean here is that the customer and employees work together to co-create value (or co-produce as Gallouj & Weinstein called it).

Secondly, both the customer and employees can integrate their skills and competences with physical resources, goods or systems of the service provider. These are the technical characteristics (X=(X_1 X_2 \dots X_n)). And they include processes, procedures etc.

The model is clear that the producer characteristics relates to the individuals in the producer, rather than skills of the producer. Those are seen as processes/procedures etc, ie technical characteristics.

It’s worth noting that I’ll keep refering to customer and provider in this article. Since that is what Gallouj & Weinstein used. But they really should be changed to beneficiary and other actors to align with our evolved service dominant lens. And that’s one of the changes I make in my update.

Using these 4 characteristics, we can describe all types of service all along the service-service continuum.

Different Service Types

We need to be aware that not all services require all characteristics.

For example, when using a legal service, your competences, as a customer, are likely negligible. Whereas the skills of the individual lawyer are highly relevant. And the lawyer will probably rely on their firm’s processes (a technical characteristic) whilst you would not.

Alternatively, in self-service, there are no provider employees involved, so no provider skills required. But customer skills and competence become more important.

And, as we move along the service-service continuum, the balance between customer and provider skills changes. As you would expect.

Figure 3: Different types of service described as characteristics

I look at how this model covers types of service in more details over in this article.

Ok, so before we jump into the details and subtleties of these characteristics, lets take a look at this in action.

Swish – an example

Now we’ve seen the basic idea of the model, let’s take a quick example. Swish is a popular mobile payment application in Sweden (280 million euros of transactions in June 2020). It helps beneficiaries (customers) make progress of securely and instantly transferring money between two people’s bank accounts. And reduces hindrances of doing so – the need to remember/find bank account details and sort codes etc. It does that by using mobile phone numbers as proxies to bank account details. (It’s worth noting that Sweden is pretty much a cashless society nowadays).

Essentially, I use their mobile app, type in your phone number (or get it from my address book), the amount I want to give you, and click send.

Initially, a consumer-2-consumer solution Swish has expanded to support consumer-2-business payments. Powering, for example, farmer’s markets, food trucks, and retail stores. It is free for consumer-2-consumer transactions. And a small fee for consumer-2-business which is below credit card processing fees. And you can see Swish in action in the video below.

Video: Taking a look at how Swish simply works

Swish as a service

This service follows Grönroos’ definition. It is a process, made up of a series of intangible actions. Some happen before a transfer, such as the customer linking their bank account details to their phone number. And some during the service, like entering the payees mobile phone number, the amount, and clicking a pay button and authorising the transfer. And these actions take place in interactions with the Swish organisation’s system: the Swish mobile application.

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 (and is a widely used system in Sweden). This idea of ecosystems I explore deeper in my proposed updated model.

We can capture the Swish service a little more formally.

Swish as characteristics

Let’s take the view of Swish above and see how it might look as our four lists of characteristics (Figure 4).

Figure 4: Swish as Characteristics

These are not meant to be exhaustive, so if you feel something is missing, it might well be. But they are sufficient to explore as our example.

Next, we can flip them into our lists of characteristics. And here – in Figure 5 – you can see it is not scary maths, just a list of sentences).

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

And then rearrange into more familiar structure in Figure 6.

Figure 6: Swedish instant payment service Swish as interactions between service characteristics

What can we read directly from this?

What insights do we get using this model?

Well we see there are no service provider employees involved in this service. Which is not unexpected for a self-service. And that means the service is reliant on customer’s skills and competence. That gives us a hint that there might be innovation resistance to be addressed. Perhaps in the usage patterns and/or traditions & norms areas.

And we can see how the service plugs together. The progress of making a real time payment (Y_2) depends on interfacing with bank systems (X_4). And that payer knows, or can get, the phone number of the payee (C'_1).

Whilst I haven’t drawn all the connections, the non-functional progress of securely (Y_3) is handled by technical competence (X_5) – interface with BankID system. And that is associated with customer skill C'_1 of being able to use BankID. One reason for rapid adoption of Swish in Swedish market is the widespread use of BankID when dealing with banks and government agencies. If you were to transfer Swish to other countries, where digital ids are less common, you probably have an additional challenge.

OK, so that’s the general idea. Let’s now dive into the details and subtleties of each of these characteristics. Starting with the external ones.

Experiencing the service: External Characteristics

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

Figure 7: The external characteristics of a service

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

And those give us 4 tools we can use to systematically hunt beneficiary related innovation.

In my update to the model, we’ll see that these then really describe the value proposition. That is to say the functional and non-functional progress the service offers to help the beneficiary make.

What does the Swish example look like?

In our Swish example I’ve defined the following six external characteristics

Figure 8: External characteristics of Swish

Firstly, Y_1 captures that we will transfer money between two bank accounts. And this is really the problem the service offers to solve. Whereas Y_2 to Y_4 are the more non-functional requirements. That is to say, we want to experience this transfer in real-time, securely and that it is simple to use. And Y_5 captures the lack of fees (at least for consumer-2-consumer). With Y_6 telling us this done via a mobile app.

I could have added 24/7 availability as a Y_7. And perhaps even more external characteristics to fully describe the service. But let’s keep this simple.

Now we know service’s external characteristics, let’s look at the how this are realised.

Bringing competences to bear

Service is the integration of resources – skills and competence. Some of those may be frozen in goods, physical resources, or captured in systems – we’ll look at those shortly. And other skills and competence come from the customer themselves and/or the employees of the other actors involved in the progress being made.

We find these last two over on the left of the model. Where we have the customer C'=(C'_1 C'_2 \dots C'_q) and provider C=(C_1 C_2 \dots C_p) competencies.

Figure 9: Beneficiary & Provider Competences

For the mathematicians amongst us, this positiong of characteristics – one horizontal and one vertical – almost resembles matrix multiplication. And I like to believe that was deliberate. To emphasise that there is co-creation of value.

However, it could be that either of these lists is empty. And if so, then the model is describing a very specific type of service. An empty provider competences list means we are looking at a self-service service (including just providing goods). Whereas if the customer competences list is empty, then we are likely looking at a highly skilled service – lawyers, doctors etc.

But what types of competence are we talking about?

Types of competences

First, I have to highlight that provider and customer competencies are tied to individuals. Not the enterprise. That said, useful individual characteristics can be codified by the enterprise to be technical characteristics. Take a lawyer working in a firm as an example. They will have skills and competences that sit on top of the processes (codified competence) of the firm. Perhaps how they interact with clients, or their way of acting in court.

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

Your customer will often need to bring skills and competences to the service act.

Figure 10: Customer & Provider Competences

The amount varies. And we can see it increases as we move along the service-service continuum in the direction of self-service. Where we eventually end up with the beneficiary using a goods of the service provider. And so they have to know how to use that goods themselves in order to make their progress.

That leads us to two points to discuss. Firstly, you might need your beneficiaries to gain skills and competences to use your service. In such cases, how do you achieve that? And secondly, your customers might be gaining skills and competence in other markets/industries. How can you leverage that?

Lets check in with our Swish example first, then look at those two points.

Swish Customer Competences

In our Swish example, we need the customer to have several skills and competences:

Figure 11: Competences used in Swish (note there are no provider competences)

Firstly, they need to be able to use a smartphone application. Something we can almost take for granted today. And Swish benefits from the widespread use of BankID service in Swedish society used to prove ID to banks and government authorities. That might not be the same if you launch a Swish equivalent in another country with less developed/widespread electronic ID services.

There are two interesting cases around customer competences. Sometimes your can leverage skills your customer is gaining elsewhere. We’ll look at that in a moment. And sometimes your service might require beneficiaries to gain new competence.

Requiring a customer to gain a new competence

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

Let’s take Virtual Reality (VR) as an example. It always appears to be the next breakthrough interface but hasn’t made it quite yet. If your value proposition requires customers to have the competence of using VR, then you’ll have to think about how they can gain that.

The traditional view would be to look at Rogers’ factors that affect innovation adoption speed. But more importantly, you should minimise the opportunity for innovation resistance. And that means addressing the factors in Figure 12.

Figure 12: Causes of Innovation Resistance

So you might need to train the customer. Or perhaps use a transitionary technology. For example, people are becoming more familiar with Augmented Reality. In Sweden the postal service allows me to project a parcel I’m receiving onto my desktop so I can visualise how big it is. And from there decide if I’m picking it up on my way home. Or I should drop my stuff home first and then go and collect it. (Swedish PostNord rarely do the last mile of delivery, rather they deliver to collection points where you have to collect yourself. That has both positives and negatives…).

But this can also work the other way around. Your customer may be picking up competence in some other market/industry that you can take advantage of.

Using a customer gained competence from elsewhere

In their daily life, customers are active in many industries and markets. And it is increasingly common they are gaining skills elsewhere that you can make use of. It can also be that they are expecting to make use of those skills in your market/industry.

Let’s take external characteristic Y_4 = Simple as an example. Swish already removes the complexity of remembering bank account details to make a transfer by using phone numbers as a proxy. And usually, those numbers you want to pay to will be your friends and in your address book. Little risk of getting the wrong number, and if you accidentally pay the wrong friend, it should be relatively simple to get the money back.

But when it expands into consumer to business payment the risk for the payer goes up a little. Sure, typing in a new phone number to pay is not horrendously complex. But it is an extra step and not the simplest way.

Looking across at the travel and entertainment industry, we can see the widespread use of QR codes. Customers are quite used to scanning codes and having a code they hold scanned to transfer information. And similarly, QR codes are making inroads into payment processes. Swish leveraged that to simplify their service.

Video: Using QR codes with Swish

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. And, Gallouj & Weinstein indicate individuals get these competencies from various sources:

  • education
  • training
  • 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 #4 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.

Provider competence in Swish

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. These approaches capture provider competences in systems.

Finally, let’s look at technical characteristics.

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

Lastly, we have the technical characteristics, X=(X_1 X_2 \dots X_n), of the service. These are the physical resources, goods and systems of the service provider.

Gallouj & Weinstein refer to them as the tangible and intangible assets used internally to deliver the service. And by tangible, they mean the scissors and the hairdryer of the hairdresser, etc. Whereas by intangible, they 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.

Figure 13: Technical Characteristics – the systems, processes, physical resources and goods of the service provider

Swish Technical Characteristics

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

Figure 14: Technical characteristics in Swish

Obviously there is the mobile app. This is a provider system that the model tells us the customer integrates with. And we have some processes in there too. Such as checking the payer has sufficient funds. As well as making the actual transfer of money.

Since we have no provider skills, there are no interactions between the provider and technical characteristics.

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 15 shows this).

Figure 15: Swedish instant payment service Swish as interactions between service characteristics

We can neatly see what the service achieves. And how that is realised. Further, we can identify if their are skills gaps for our customer that we might need to address. Which links us to den Hertog’s model of service.

More interestingly, now we have described our service more formally, we can begin systematic search for innovation. Simplistically, a service offers to help a beneficiary make progress in some aspect of their life. Innovation improves a service so that the beneficiary can make better progress (including making progress previously not able to be made).

In our model, innovation is adding, deleting or changing characteristics.

Perhaps applying blue ocean strategy canvas to external characteristics. Or capturing provider skills as artificial intelligence system. Maybe borrowing customer competence from other markets/industries. Or moving along the service-service continuum. Or bringing in new ecosystem partners.

With our model, we have a way of systematically hunting for innovation and reasoning what the impact would be.

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. It “formalises” Grönroos definition of service.

With this model we get an understanding of how service is put together.

That means we can use it to understand impact of innovation on service. And for systematically hunting innovation. For example, I believe it’s possible to view external characteristics in a blue ocean strategy canvas to hunt for innovations. That is to say, we can increase, reduce, add or delete external characteristics in the hunt for a blue ocean. And this model helps us understand/trace the impacts and changes needed to offer the new value proposition. Including what the customer needs to bring to the service.

And, whilst this model is useful, there are some updates we can make to further increase its usefulness. For example, using service-dominate logic terminology, reflecting the network/ecosystem nature often seen in service and guiding the external characteristics to reflect the progress being sought.

We find that innovation in service falls into various patterns. Which is useful in systematically hunting for innovation.

Co-create value by leaving your views

This site uses Akismet to reduce spam. Learn how your comment data is processed.