Here is a detailed breakdown of the individual rings:
Representing the user-centred focus of service design, the service ecosystem places the user at the heart of the visualisation. The user's “underlying need” occupies the very centre of the circle, while needs specific to individual phases are located in the relevant segments of the next ring outwards. Taking the example of a service ecosystem for an insurance provider, the underlying need for the user might be something like “feel protected in case of the unexpected”, or more succinctly, “peace of mind”. During the “usage” phase, in which an event occurs that triggers a claim, the more specific needs might be “reassurance” and “assistance”.
The next ring outwards contains the discrete interactions the user has with the service, phrased in very simple, concrete terms (often ‘verb + noun’). Within a segment of the “Interactions” ring corresponding to a phase, no order is implied by where interactions are positioned; they are simply scattered through the segment. The interactions are also written without reference to a touchpoint, to avoid bogging down the document in unnecessary detail. Continuing the example of an insurance provider, interactions might be “initiate claim” or “change customer details” (not, “report claim via app” or “change address details in customer domain”).
An additional benefit arises from identifying interactions in an agnostic manner within this ring. Because all of the in-use touchpoints are identified for a given phase, the service ecosystem can inform decisions on what interactions will be supported on what touchpoints. This can be done later, while scoping the functionality of the service (writing user stories or otherwise creating specifications), thanks to the generic way the interactions are written. By supporting the re-use of interactions across multiple touchpoints, the service can be built more efficiently, and also meet the needs of users who don’t want to be confined to doing things only within one channel.
The places on which the interactions of a given phase occur are gathered together in the next ring outwards: “Touchpoints”. Here, touchpoints that play a role in a specific phase are named. They could be things such as “app” or “call centre”, or “email newsletter”. Similarly to interactions, no order is implied by where they are positioned in the ring, and no attempt is made to visually link interactions and touchpoints. Finding the right level of detail when describing touchpoints is also important. “Online”, “digital” or “face-to-face” would be too vague to be of use. “Public website” is acceptable, but there may be even more value for naming specific aspects of that website as well, such as “customer support forum”.
The outermost ring is self-explanatory – it contains the high-level phases of the service that the user progresses through. In practice, these phase names should correspond with phases used in later deliverables, such as customer journey maps. For many services, typical phase names will suffice (e.g. “awareness”, “orientation”, “purchase”, “use”, etc.). It often makes sense to identify the phase names in advance of the service ecosystem workshop, to kick-start its creation.
‘As-is’ and ‘To-be’ service ecosystems
A service ecosystem can be created both for current services (‘as-is’), as well as for services that don’t yet exist (‘to-be’). For ‘as-is’ services, the creation of the visualisation relies on capturing details about the service experience as it is today. When creating a ‘to-be’ service ecosystem, care must be taken to ensure the identification of interactions and touchpoints match with the user needs. Specifying interactions and touchpoints without properly validating them risks an ‘inside out’ approach, and mismatched expectations. Therefore, a ‘to-be’ service ecosystem relies on clearly articulated user needs at its centre.
A word about granularity
It is tempting – especially with experience creating detailed customer journeys and service blueprints – to go into a great level of detail when creating a service ecosystem. However, this risks creating an unwieldy and overly-complex document, which will require significant time to create and interpret. Much as in customer journey mapping, a significant proportion of the value delivered by a service ecosystem comes about in the awareness and discussions it triggers within the team during its creation, and not simply the deliverable itself.
For an interaction, “pay bill” is adequate; it's not necessary to reveal further complexity by having individual interactions for “pay bill by credit card” and “pay bill by direct debit”, for example. Similarly, avoid getting too detailed when identifying touchpoints and phases.
Lastly, I've been asked several times about the possibility to create multiple service ecosystems. For example, to cater for different personas, when their needs differ. In our view, it's best to stick with one service ecosystem, and abstract the persona needs enough so that they can be shared by all personas. However, in cases where the service is platform-based, individual service ecosystems do make sense. As an example, the service experiences for riders and for drivers with a car-sharing service is significantly different (especially the underlying needs and interactions), so it makes sense to visualise both services separately, as different ecosystems.
It’s also worthwhile saying that a service ecosystem will offer little added value for simple services that have very few interactions, or only one or two touchpoints. And lastly, don’t attempt to build a service ecosystem for a single touchpoint, such as an app. Keep the holistic nature of the deliverable in mind.