Tag Archives: concepts

The service concept revisited #2: service name and organising idea

Much has been written about the importance of selecting good names for things so that I probably don’t have to write much here. Just keep in my mind that the service name will be used very frequently, so taking time to find a good name or even changing an existing name to something better will pay of quickly.

The organising idea is the briefest meaningful summary of what constitutes the service under discussion. It is our first opportunity to communicate intent. A single sentence, perhaps even only a phrase, will often be sufficient.

To Johnston & Clark (2005), the organising idea is “The essence of the service bought, or used, by the customer.”

I’ve written about explicitly stating intent on my old blog before. First and foremost, it allows others to make independent progress toward a larger objective.

Live tweeting from London Lean Kanban Days 2019, Tobbe Gyllebring shared this:

That’s much nicer and much more powerful than what I used to say. Going forward, I’ll just borrow this:

Clarity of intent enables autonomous aligned action.

— Karl Scotland (paraphrased) via Tobbe Gyllebring

I like the notion of an organising idea: What is the fundamental idea that we should organise everything else around? Or even better, that we should let everything else (and everyone) organise around?

See The service concept revisited for context and for links to related posts. Interested in exploring this further? Please get in touch, I’d love to hear from you!


Johnston, R. & Clark, G. (2005) Service operations management: improving service delivery. 2nd ed., Pearson.

The service concept revisited


My discussion of The structure of the service concept is the most popular post on my old blog On Service Design. When I wrote it almost six years ago the topic didn’t seem to get much attention. Academic services marketing and service operations literature mentioned the term frequently, but almost no-one bothered to define it or describe its structure or content.

The Service operations management textbook by Johnston & Clark (the recent edition is by Johnston, Clark & Shulver) is by far the most thorough discussion I was able to find.


I still like the idea of a service concept very much, in particular for its effectiveness. A well-written service concept can communicate a wealth of information in a very small space.

I typically use the service concept in a fairly casual form when exploring initial ideas for digital services with clients and colleagues. Interestingly, I’m back to the earlier (2005) version of the concept’s structure (although the differences aren’t huge).


It’s useful for me to revisit the fundamentals and relate it to other relevant concepts, including some of the popular design canvases. Furthermore, I want to dig into its elements in more detail. I’ll be doing this in a series of future posts.

I look forward to discussing how the service concept works nicely with the things Tom Graves is doing (see his Toolsets for enterprise architecture overview) and, particularly, his Enterprise Canvas.

 Watch this space for updates…but don’t hold your breath.

Interested in the idea of a well-defined service concept? Let’s talk, please!

Other posts in this series

Related older posts


Johnston, R., Clark, G. & Shulver, M. (2012) Service operations management: improving service delivery. 4th ed., Pearson.

Johnston, R. & Clark, G. (2005) Service operations management: improving service delivery. 2nd ed., Pearson.

Different to a human, but not to a computer

We were discussing different ways of modelling information about two different concepts. One of my colleagues observed:

Concepts X and Y look very different to a human, but they don’t look all that different to a computer.

He suggested (looking further into) representing these two concepts using the same entity in the system.

A number of things struck me as noteworthy: I think it might be beneficial to more frequently distinguish conceptual models and implementation models (or conceptual and implementation concerns) in design discussions. I’m glad this happened here. Relevant concerns in a conceptual model don’t necessarily have the same relevance in an implementation model and vice versa.

We frequently still seem to draw on sub-classing as the mechanism of choice for distinguishing different types / categories / kinds of things in our models. Other mechanisms such as type attributes or type objects may yield much better results in many situations.

My colleague’s description of this thinking (looking different to a human but not that much to a computer) seems so much better than my ramblings about conceptual and implementation models.

Martin Fowler’s Analysis Patterns book contains a wealth of ideas on this and related topics — it’s highly valuable and relevant 15+ years after its first publishing. Get a first look here and here. Look for discussions of the knowledge level vs. the operational level in models.