Skip to content

Customer Experience Led Service Design

This article is part of our post-structural, randomised, Let’s Build a Bank series of articles

In this article, we explain the practical steps needed to build CX driven services, towards a capability driven architecture for your business or service.  NB this is closely aligned with Building Capabilities, which is the subject of a separate article – building new services is likely to lead to a need for changes to capabilities, so the two activities are closely linked.

We’ve written a lot about service architecture, the nature of a service versus a process or capability and why banks need to become more service aligned.  As a reminder, our definition of a service is a configuration of capabilities that delivers value to the customer.  Everything that your organisation does is delivering a service to somebody, who may be an internal customer, but we’re assuming for the sake of this article that you are building an external customer-facing set of services.  The same technique can, and should, be applied to internal customer facing services.

Delivering service aligned organisations requires a fundamental shift in how we think about services, and as we’ve covered elsewhere, a key part of this is aligning the organisation to the customer rather than trying to fit the customer into your organisation and processes.  Achieving this is not possible using traditional product and technology led design approaches, because in order to align to the customer, you need to start with the customer.  While the tools you use may vary, we strongly urge you to go through all the steps; some may seem unnecessary or fluffy on first reading, but our experience has shown that skipping any part of the linkage between the customer and the services you support them with, leads straight back to inside-out thinking and a functional/product based approach to service design.  This results in missing key opportunities and often building something because it’s easy, fun, or a pet project, instead of being customer driven.  We’ll expand on the rationale for each step as we walk through them.

The output of this activity will drive more activity, so it’s almost always an early kickoff shortly after you’ve assembled the team; this will mean that the output is necessarily raw and will be subject to adjustment as you progress and build solutions, but we recommend taking many of the key artefacts this exercise generates and keeping them visible as you progress with the build – we always work with a Target Capability Model on the wall, together with some key principles.

Who to involve and logistics

These activities are almost always project-led, but they can also be initiated within a business capability or service, so who’s in charge isn’t really important; what is important is the mix of people you have in the team.  It’s also critically important to hold the service design activity face to face; although we live in a virtualized world and your team is likely to be distributed, this is one activity it’s really important to lock people in for and to get them together with the old-fashioned whiteboards, markers and post-it notes.  That also means you need enough physical space, and enough time from everyone.  While it is ideal to have the whole team co-located for the whole delivery, in reality this usually isn’t practical, so we recommend a division between pre-work and onsite, to maximise the effectiveness of the face to face session.

How much you can allocate to pre-work and how much needs to be done face to face will depend on the experience of the resources and how much or how little they share the vision, so there are no hard and fast rules, but we usually ask people to come to the table with the following:

  • Target Customer personas
  • Target Customer journeys
  • Key capabilities that will be needed

All of these will be refined and much will be jettisoned during the face to face session, but bringing the different perspectives together gives you a strong starting point while getting team members in the right mindset.  That means that you should usually have a few preparatory sessions (which can be done remotely) to work through some of these activities with the team before the session, and these can be done in smaller groups or even by individuals.  Collaboration tools can be very useful to this stage of co-working.

Team size will depend on what you’re doing and how many skills/areas are involved.  In some cases you may have a very small team, and in some cases a fairly large one, but we recommend a minimum of five and a maximum of 25.  Beyond 25 it becomes difficult to coordinate, and teams with fewer than five are likely to suffer from groupthink or be dominated by a single individual.  We have run teams with up to thirty, and this can be done with an experienced facilitation team.  Ideal team size is 7-12.

The team must have at least one strong facilitator who’s well versed in service design.  Building these skills isn’t hard; people who get involved in service design workshops and have good facilitation skills anyway are ideal, but most leaders can pick them up when they’ve been through a couple of service design exercises.  If your organisation hasn’t done this before, though, you need to get an external facilitator who works in this way, because otherwise you will struggle between the “we’ve never done it before” and maintaining credibility.

Other than the facilitator(s), who can also be business or project leaders if they have the appropriate experience, you need the following:

  • The people who will be delivering the service to the customer (the “receiving organisation” in project terms) – this should be your largest group and may involve a wide variety of skills and different parts of the organisation, depending on the scope and type of services you’re designing.  This is another reason why it’s important to work through a few customer journeys before you go into the workshop, as that process will help you to identify the skills and functional representation you’ll need from the receiving organisation to cover the full customer experience.  You should also source people who are actually interacting with customers, rather than managers who usually don’t have very clear understanding of what team members are actually doing.  You should also include some key stakeholders in your future vision, so the seniority profile of the group is likely to be very mixed, which is a good thing as it captures both the broad and the detailed view.
  • A customer, or more than one could be a good idea, especially if it’s a B2B service.  End customers (B2C) may be less helpful in the face to face workshop, although they should be part of the pre-work and obviously engaged to test the output.  But a lot depends on the nature of the service and the nature of the customers.  In many cases you may already have customers in your group anyway, if you’re designing a commonly used consumer service, because your team are customers of the service.  You should of course be cautious of taking this group as representative, because they are tarnished by their insider knowledge of how things work in the organisation, but they can be challenged to think as external customers by carefully structured questioning.
  • People with business architecture skills who understand what needs to go into designing a future state – these will challenge and ask questions to ensure the outputs can be used.
  • Someone to write stuff down – you may choose to rotate the responsibility between other team members but if it’s a big group, it’s usually better to have one or more people who just capture ideas and actions – the group will also be writing, but you’ll be running multiple whiteboards capturing different outputs, so we recommend one scribe for teams of more than 12 and a couple for very large teams.
  • Someone who will drive the activities forward after the workshop, who could also be the facilitator but could be another participant, especially if your facilitator is external.  This is core project management so you’ll need someone with project management skills and where the activity is led by a receiving organisation leader, you should ensure there’s someone with a clear brief to run the plan following the workshop if project management falls outside her skillset.

Diversity of function, age, culture and gender is important.  If your team looks too homogenous you should consider including some people who may not be central to the receiving organisation but will be able to challenge appropriately.

For workshop planning, we recommend three days to a week, but with a smaller or more experienced team it may be possible in fewer days.  Beware, though, we’ve often seen teams try to squeeze it into two days, who end up reconvening for another two days at a later date to complete activities, which ends up building delay into the project and costing more, so be realistic about the size of the team, the level of experience they have and how much you want to achieve.

Current state vs future state

We recommend starting out with future state design before mapping your current state.  This is a really important element to designing the future unshackled by preconceptions about the as-is, although of course your team will also be carrying their own worldviews into the workshop and many of them will be working in the as-is, so will be carrying preconceptions with them.  You can limit this to a large extent by leaving current state analysis until after the future service model has been agreed, and it’s also important to continually challenge what looks like as-is thinking in the workshop – for example, where reconciliation is captured as a service, why are we reconciling?  Is it something we could eliminate if things work better in the first place?

Try to avoid using as-is terms for capabilities unless they are very generic in the first place; for example, you may have a department called “Customer Relations” which actually does a variety of different things.  When considering a future state capability called “Customer Relations” it will be very hard for your team to lose their worldview of the as-is “Customer Relations” function if you use the same name, so choose names which are different and more descriptive such as “customer interaction management” or “customer problem resolution” instead.

A word about focus groups and adoption barriers

We’ve touched on customers above, and of course it’s essential to involve customers in service design.  However try to focus more on current customer behaviour rather than speculative “would you use this?”.  Study after study shows that customers are spectacularly bad at predicting whether they’ll adopt a product or a service; and that’s not because they’re lying, it’s because it’s difficult for a customer in a focus group situation to predict how they’ll behave in the real world.  The questions that are more likely to generate useful answers are:

  • What problem do you (the customer) need to solve?
  • What are you doing to solve this at the moment (including nothing)?
  • What would incentivise you to replace what you’re doing today (including nothing) with an alternative (proposed) service?

There’s a lot of theory behind this and an excellent short book by Clayton M Christiansen and others, Competing Against Luck, is a recommended resource for further colour.  Asking these questions will allow you to asses your service in context of the challenge of adoption, rather than the typical focus group approach which is to demonstrate something to customers, they say “wow, that looks cool” without considering how it would enter their lives or what it would really help them to do, and consequently give inaccurate answers about their attitude to purchasing it.  Offering slightly loaded negative versions of these questions can also be effective, e.g. “what would you need to change before you would switch to this service?” or “what stops you from moving away from what you do today?”.

We also recommend less focused approaches to customer questions; instead of “what could the bank do better for you?” which immediately sends customers into an As-is view of the world, turning the question around to focus on them instead opens out the opportunity for additional service areas you’re not in already, or which they can’t visualise you entering.  One of my favourite customer questions is the genie in the lamp one: “If you found a genie in a lamp, what’s the one thing you would ask her to do to make your life/your business better?” – that can generate all sorts of useful replies.

To get a true view of this, it helps to walk customers through scenarios, just like you do for customer journeys, but this time for the journey of changing from what they do today to your service, and at each point challenge their decisions – for example, if you’re offering an online accounting service and they currently use a real accountant, early questioning would establish that the online service would be cheaper, so the online service looks attractive, but then they could already have bought an online service, but they haven’t.  What does the real accountant offer that has kept the customer sticky?  Does he offer advice, or is the personal touch actually important to the customer?  Is it a trust or confidence issue? Or, if the answer is simply customer inertia this, too, is a more powerful force than customers realise when it comes to actually changing habits – even an unloved familiar product is better than a leap of faith, and a new service has to offer significant and demonstrable benefits before the merits of the service alone will pull them away; it’s also critical to remove adoption barriers; in our accountant example, he holds all the customer’s historical records, for example, so changing to a new service looks difficult to impossible to the customer, unless you can provide and demonstrate a way to make it easy.

Customer research data can be misleading for all the same reasons, and even the best structured research will tell you what they like or don’t like about their current services, but not how sticky those current services are when they’re offered a better alternative – and remember, that applies even is the current service is “nothing”.

So while customer data and focus groups are useful inputs, there’s a further stage of customer research that can only be done with reasonably live-like scenarios or, better still, live trials, to really understand the impact of customer inertia on their behaviour.

Service design activities step by step

1. Who’s your customer?  No, Who’s your customer?

Tools: customer, collaboration tools, whiteboards, markers, can be developed in advance of F2F session and further refined in the workshop situation.

Many companies are guilty of forgetting they have customers at all, but even those who design with customers in mind aren’t usually thinking about who their customers are.  If the answer to the question above is “a corporation” or “a CFO” or “a B2/ driver” then you’re not thinking about who your customer is – you’re thinking about what your customer is, which is still an inside-out view of the customer which won’t help you understand the problems they’re trying to solve.  And yes, corporations are people too; the purchasing decision is today always made by an individual or a collection of individuals.  These individuals have perceptions, opinions, behaviours and needs that are influenced not just by their role title, but much more by their personal characteristics and circumstances.  How secure is the CFO in her job and does she feel she has the expertise and confidence to make the decision you’re asking her to make?  How much time does your B2 driver have to process the information you’re giving him, given the two jobs he’s doing and the time he wants to spend with his four kids?

Developing customer personas helps you to think of the customer as an individual, which in our experience significantly changes how you design your service around his needs.  Effectively it’s moving away from the survey data to a more in-depth, scenario-based approach, as we described above, but with constructed personas that will become familiar to the whole team.  No man is an island, and people’s decisions and behaviours are profoundly influenced by wide cultural norms, by organisational and societal expectations, and by their personal circumstances.  Going back to our accounting scenario, any customer would be put off by having to expend significant effort transferring their records, but what if some of the customer’s friends also use the same guy and there are behavioural trends he feels drawn to follow as a result?

For most services, you are likely to have a variety of different customers with different needs.  Understanding how the personal circumstances of an individual shapes their behaviours and habits really helps you to understand the sorts of problems they need to fix, and talking to real people like them helps you validate what they’re using to fix them today.

The example we’ll use in this article is Jon, a Danish builder with a team of fewer than 10 people, married with kids and living outside Copenhagen, who runs multiple jobs and occasionally has fallow periods.  He sometimes buys in additional support from subcontractors, he buys most of his supplies on account at the same builders’ merchant and he has to authorise his team to put things on his account.  He uses an accountant to manage his payroll and tax, and his bank for basic accounting and small business advice.  The accountant is expensive and the bank is closed when he usually needs to talk to them – because he does his paperwork after dinner on his PC at home.  The answer to his genie question is “get customers to pay faster so I can manage my cash flow better.”

Other example personas in this sector (Danish SMEs) we’ve used are Jesper, a Danish pig farmer who exports to the UK and worries about the impact of Brexit on his bottom line, Minnie and Raj who are opening a new Indian restaurant in Copenhagen and Sky, a fintech innovator who’s a bit clueless about how to expand her markets.

Our statistics tell us that “an SME customer” has two major pain points; cash flow and administration, which Jon and the others confirm.  However, when we’re working through customer journeys, it’s easy to be led into making assumptions and adjusting our customer to suit the products and services we want to, or find easy to, deliver.  Fixing certain behaviours such as Jon’s use of a real accountant gives us the problem and the opportunity of addressing these real-world challenges, rather than hoping for a smooth path, and we therefore end up with a service that they actually find useful and want to adopt.

Customer personas need to include their behaviours and their characteristics.  How risk averse are they? Educated? Political affiliation? Attitude to family and work? All of these and more will influence what the problems are that they need to solve and how far you can help to address them.  Jon is educated, technology literate, ethical and cares about his employees.  He’s very aware that his professional reputation is key to growth and he’d prefer to have access to services online.  The thing that would add most to his quality of life is not having to do paperwork after dinner and the thing that would help him grow his business most is access to more subcontractors and resources in whom he could feel confidence, so he could take on bigger jobs.  He loves living by the sea and wants to spend more time with his family.

2. What problem does our customer need to fix and what do they do to fix it today?

Tools: customer, collaboration tools, whiteboard, markers, research upfront to bring to whole team in face to face situation

We’ve already touched on this a bit, and it’s important as before, to start not from what your products or services do, but what your customers need.  That obviously gives you the opportunity to refine your service offering, but more importantly it also tells you what they don’t need, and can offer opportunities for further innovation.  If you’ve chosen some appropriate customer personas, this part becomes a lot easier.  Let’s look at Jon again:

  • Thinking about Jon as a business owner, the most important thing to him is managing incoming payments so he can balance his outgoings more easily.  Jon also has big problems because his customers make on-the-fly decisions which sometimes cost money, but it’s hard for him to prove it.  He’s also spending a lot of money on the accountant who does his payroll.
  • Jon has been trying to use Facebook to recruit because everyone’s trying to recruit skilled tradesmen at the moment; Denmark’s going through a building boom.  He doesn’t want to recruit foreign tradesmen because of the complex building regulations, so his reach is limited, and he’s further limited to his word-of-mouth network; he’d also like to collaborate with other builders to take on bigger jobs and grow his business, but again there’s a trust problem.
  • He also spends a lot of personal time processing his paperwork, typically after dinner in his home office on his PC.  He finds his bank inconvenient because they’re based a long way from his seaside home, and their opening hours don’t match the times he’s doing his paperwork.  He also has to rely on the person he needs to talk to being available when he calls, or has to make an appointment and take time away from running sites.  He spends a lot of money on his accountant, who processes payroll for his 7 employees every two weeks and his tax returns every quarter.

So Jon’s problems are the classic SME problems we knew about upfront from the class data: cashflow and administration, but we’ve got a lot of very critical additional information from walking through his problems more holistically and being specific about the problem scenarios, some key points being:

  • Although doing all his own paperwork isn’t costing Jon extra money – he does it offsite – it’s eating his quality time, so there’s a huge emotional upside to removing some of this work, which may overweigh a more financially significant benefit.  If we can give him back his family time, his quality of life improves.
  • He’s helped us to refine his cashflow problem to a particular pain point – getting customers to pay on time.  If we can address this by changing his customer behaviour or providing other mitigation, it will help solve the effort he currently puts into chasing customers and the emotional anxiety, as well as the numbers.
  • We’ve also identified a completely separate problem – the collaboration/recruitment/trust issue – that banks don’t address today, but which we could help to resolve through the data we collect in addressing the first two scenarios – if we’re collecting information about Jon’s customer billing and the jobs he’s running via helping with the accounting side of things, we can also build a trust profile which he can share with his customers and peers, as can other builders and tradesmen in his industry.  Giving him access to this network may be the most important element of the service we provide to him, and yet this would not have emerged if we had stuck to asking him about traditional “as-is” banking services.

Jon’s a real person and these are real problems that he faces.  But you can, with sufficient knowledge of your customers, also fabricate personas to be generic; we’re lucky that Jon is very representative of his sector (high end small Danish builders), but of course there are other customer personas with other problems and we need personas in this area too, while Jon’s customer and supplier ecosystem have their own, less developed personas so we can also use these as we work through the problems.  Using this problem-based approach also allows us to understand how far these challenges face our other customers, and to what extent they need further support.  For example, Minnie and Raj will be looking to recruit internationally, and may not need so many trust-based guarantees but will need other types of support with recruitment and management, which our data may be able to help.

3. Decide what success looks like

Tools: whiteboard, magic markers, core team in face to face situation

Based on Jon and others’ problems, you can now decide what type of problem you want to address, and what a positive customer outcome looks like, which will form the guiding principles for your service model.  You will also need to be guided by the type of service you’re able to build and the capabilities you have to an extent, but I prefer to remain open ended at this point unless there’s a very clear restriction, such as limited availability of people.

So sticking with Jon, he has some specific and some generic requirements, most of which come out of the issues we’ve described, although some result from the more detailed analysis we performed.  And for him, success looks like this:

  • Access anywhere – so he doesn’t have to wait to manage his money when he gets home, and he can make and record decisions on the job at the same time
  • Control flow of cash
  • Address customer payment lag
  • Reduce cost and effort of administration and reporting
  • Pass on risk of late payment to suppliers more effectively
  • Independently corroborated record of guarantee for customer confidence and to build partnerships
  • Marketplace for partners and tradesmen
  • Job managed in one place with record of agreements and any changes

All of this translates to a set of guiding principles such as:

  • Build for mobile
  • Build in communications and ability to exchange pictures e.g. photo of finished work
  • Link contract to job accounting and outputs
  • Provide confidence management

While our service alignment principles give us some further guidelines:

  • Customer objective driven
  • Viable for different customer personas

And our architectural principles still more:

  • Capability based
  • Partnership/marketplace model for capabilities
  • Scalable

You can then use these to test your customer journeys and any solutions you develop as a result.  It’s likely they will be further refined, especially once you start testing ideas with the customer, but this is a good example of a set to start building journeys around.  Make sure they’re visible to the team as you progress both the face to face activities and beyond.

4. Build customer journeys to address the problem

Tools: post-it notes, whiteboards / sticky wall, markers, whole team F2F although again some pre-work can be done on this by smaller teams

Your customer journeys are the starting point to designing services, so they form the foundations for your service model.  By continuing to focus on customers, you keep the focus outside-in rather than inside-out, and avoid diving back into the as-is and services you can name today.

When building customer journeys, the first thing you need to decide is who your customer is.  We’ve already done that in Jon’s example, but in a B2B situation it’s easy to forget, because we actually have multiple customers; there’s Jon; while the legal entity is actually his business and not him as an individual, as we explained at the top of this article, decisions about businesses are made by individuals and in this case, that individual is Jon.  He is also a potential customer as an individual but we’re talking about his business offering here.  Then there’s Jon’s customer, Johanna, who should also find our model attractive enough to want to work with it, but we’re not building it primarily to benefit her.  Then Jon’s subcontractors and workers are also actors and potential customers in the system.  So it’s important to choose and focus on one customer, which in this case is “Jon in the role of the manager of Jon’s building business”.

A customer journey is a set of activities that starts with a customer having an objective and ends with the customer achieving that objective, or possibly a different objective (sometimes they change their mind on the way…).  The set of customer journeys you develop should cover the full set of likely scenarios that the customer will go through when interacting with your services.  The critical difference between the services you’re going to offer and the customer journeys, is that customer journeys will typically start before your organisation gets directly involved, and end after the interaction has finished.  So, for example, in one of our Jon customer journeys, it started with Johanna having some money to invest and deciding to spend it on home improvements.  Neither of those decisions involved any interaction with our services, but by including that event in the full journey, we’re able to see how we can best support other activities that might surround it, such as the networking and confidence building side in that example.

Figure BFB-BTF-CXDSD-1: building a customer journey

Customer journeys are also likely to persist across multiple services and can continue for a very long time in real terms, for example the customer journey around buying a house would start well before the customer interacts with the mortgage, with the decision to save money and change lifestyle behaviours, while it will end long after the mortgage is sold to the customer, as their experience of the whole lifecycle of the mortgage as they make payments and adjustments, is relevant to their experience of the service offering.  In this example, there’s an obvious advantage to the bank recognising triggers that the customer may be considering buying a house, and providing guidance on savings, for example, that can build the trust relationship and encourage the customer to select the same bank to supply his house financing services in the future.

And of course in a B2B situation such as Jon’s, we’re not dealing with a single individual, so it’s also important to ensure the other actors in the journey are taken into account.  That doesn’t mean that you have to improve the experience for all of them, but the actors that Jon in turn relies on should also have a positive experience of your services as delivered to them by Jon, wherever there’s an impact, which will benefit both you and Jon.

The customer journey should be laid out across a wall, with the title of each macro activity at the top and the detailed activities added by the team on post-it notes; once this is done, run a walk-through when you will almost certainly need to move some activities around in the journey as you think things through, and you’ll probably want to draw relationships on it as well. The output of this will be a fairly randomly arranged list of activities, which you can then use to build out the capabilities needed, but don’t worry if it seems a bit all over the place at this stage.

5. Build and map capabilities

Tools: Post-it notes (different colours!), magic markers, whole team in workshop

Once you’ve got your core customer journey/s, you can walk through and identify any capabilities you’ll need to support that.  It’s a good idea to be reasonably far-reaching at this point, as you will be refining later on, so keep things creative by not shutting down any ideas.  Remembering capabilities are things that someone needs to provide to accomplish the tasks in the customer journey, you are likely to capture some capabilities that you can’t, or won’t include in your service offering, and there may be some that you want to provide eventually but won’t do in the immediate future.  These can be parked, or captured for future design, once you walk through the next stage.

When you think you’ve got all the capabilities captured, do another walkthrough, this time capturing core capabilities – i.e. those without which you don’t have an offering, again in a different colour or a different sized post-it.  You should end up with capabilities that will underpin most of your service model, which you’ll start on next.

NB this is one of the more difficult sessions to control; ensure your team is addressing the task at hand and try to shut down side conversations as soon as possible.  It may be valuable for some people (particularly architects) to have a few huddles, but try to keep people together as much as possible.  If you have a large team, split them into groups of different core capabilities.

Capture all your core capabilities in one place and break them down into key elements – e.g. identity management could include authentication, KYC, key management etc.so you have some detail but not to the nth degree.  Review with the team to see what you’ve left out or if there’s anything that’s superfluous/do later.  Try to avoid getting dragged into solutioning at this stage, it’s really tempting but this will distract you from the customer and probably eat a lot of time as well.

As you map the core capabilities you will also start to expose some of the key data entities; keep these but again try not to get into too much detail about how they’ll work. The capability discussion will also drive conversations about how to achieve these capabilities, for example whether you need to engage a partner or can build in-house, which are important considerations when building your roadmap, so capture these too without being sucked into solutionising.

BFB-BTF-XCDSD-2: Core capabilities and high level processes

6. Build use cases/services

Tools: whiteboards, markers, whole team (and some more post-its)

Now you’re ready to build out use cases where the customer is interacting with your services, based on the customer journey and capabilities.  You will now be making decisions about how the customer experiences your services, which forms the foundation of the design of those services.

The use case build is effectively a more detailed breakdown of the customer journey, in chunks, where your team is using the output of the previous sessions to apply the guiding principles at the top end, to the configuration of capabilities you’ve identified that the customer will experience.  Remember, a service is a configuration of capabilities that delivers value to the customer.

For this activity, it’s ok to have separate sub-teams building the use cases but you will need the whole team for the walkthrough and expect a fair amount of interaction between the teams.  Give each sub-team a clear use case to work on, for example “onboard member”, and send them off to get on with it.  The things they’ll need to include are:

  • Roles/actors
  • Events and how those events are experienced by the customer, plus a fair amount of how the events are driven
  • Decisions and the inputs/outputs that support them

Figure BFB-BTF-CXDSD-3: Service Use Case

Each stage of a use case involves one or more actors doing something: “Jon asks Johanna to sign up to our service so she can agree quotes and authorise payments without paperwork”; “Johanna signs up to our service and reviews the quote”, etc.  In workshops you’re unlikely to have the time to work through all the “unhappy” situations where something goes wrong, but these are also a critical element and should be included later if you don’t do them in the workshop.  In classic use case language these are known as “alternative scenarios”.

Once you’ve written up all the service use cases, walk through them with the team again.  This will again inform your capability model, so be prepared for more alterations.  As you go through the walkthrough, you’ll also be able to agree critical principles such as managing barriers to entry, basic structural elements of your information architecture and how processes will work at a high level.  Together, these will form the basis for your service model.

7. Allocate responsibilities and next steps

Tools: whole team, magic markers, cameraphone, beer.

Without this activity, you haven’t achieved anything.  One of the most important outputs of the workshop is gaps and plans for further work.  First, go back to your core capabilities and, capability by capability (including sub-capabilities) decide who’s going to do what.  This may be internal teams, partners, suppliers, or, indeed “not yet” but needs to be captured so you can plan.  Then there are several immediate next steps you’ll need to agree, or should have agreed in advance, but apart from the core activities there will also be a number of actions that have arisen from the discussion, and it’s very important the team leaves the room with clear visibility of who’s doing what.  Core activities include:

  • Writing up the flipcharts (words and pictures)
  • Organising the output and reconciling it – capability maps, customer journeys, etc
  • Agreeing further interactions, roles and responsibilities etc
  • Next steps for plan formation and build

Once all that is agreed, you should then take a photographic record of absolutely everything that’s been written on the walls including all the post-it notes.  NB if you don’t have much space, please take photos as you go – even if you’ve been scribing the whole thing there are details that you’ll need the pictures to remember effectively.  Save these in your project folder.

Then it’s very important to take the whole team out for beer.  In fact, we usually do this on the middle evening, because people often have to travel so can’t stay after the last day; for remote teams the social side is incredibly important and you will almost always get a lot of useful input, as well as the important business of finding out more about each other and teambuilding, from the social sessions.

Following that, write everything up, however trivial or transitional it looks.  It’s easy to assume the first day’s brainstorming has been superseded by the more detailed planning and analysis of the following days, but you will want to refer to this material again, frequently, and you need it in some sort of shared and usable format.

If you’ve managed to work through all these core sessions in three days, congratulations.  Most teams will take a week or more, but the output will still be considerably richer and more effective than what organisations typically pay consultancies many millions of dollars to achieve, and you’ve just done that with 7-25 people’s time over a few days.  Next, the really important thing is continuing the momentum and achieving results.

8. Ask the customer

Although you’ve taken a lot of customer input into your workshop, you’ve just spent two or more days in a hothouse situation, and hothouse situations (even with a customer in the room) generate false assumptions.  The customer may have gotten so excited by the whole experience, and so engaged with your team, that he’s forgotten he’s a customer, and anyway, to the point we made earlier, when presented with solutions, customers are terrible at predicting their own behaviour.  So you need to go back to your original customer and test all the assumptions and ideas with them.  As before, do this by asking broad questions and not trying to lead them in certain directions, although now you’ll have a much clearer basis for your questioning and the ability to challenge your own perceptions.  Key things to include in your questioning are:

  • What would you need to happen before you’d really change (bearing in mind current state conditions)
  • How much would your quality of life really improve if these things changed?
  • Is there anyone else you know we should be talking to?

Although we’ve been very focused on the end customer in this article, there are still critical barriers to entry and conditions you need to address for internal service changes as well.  I’m sure we’ve all seen the release of software based on Gartner’s magic quadrant, where the organisation adopts the best in class and is then really surprised and disappointed that nobody uses it.  It’s partly because they haven’t gone through the stages described above, particularly in identifying which problem are we trying to address, but also because they’re not able to reduce barriers to entry and demonstrate quality of life improvements.

9. Build a demo and probe for feedback

Now you’ve got a pretty good idea what you want to provide for the customer, it’s very tempting to just put together a waterfall plan with every stage in it from requirements to delivery, but as we know that doesn’t wash nowadays, so a reasonably realistic service demonstration is critical.  This should involve both the CX people from your team and the technical/operational architects, together with your receiving organisation.  Depending on the nature of the service you may also need some technical input, but the focus should be on delivering a realistic experience.  Then, when you demonstrate it to customers, be prepared to start again from scratch.  Be prepared to change significant elements of the value proposition and the scope of your business if needed, to deliver the solution to the customer’s problem in a way that will overcome adoption barriers.  Bear in mind that the closer you get to a real experience, the more the customer can visualise it and he will be likely to come up with additional challenges he hadn’t thought of when discussing the idea theoretically.

Conversely, as you show your demo to your client, he will naturally absorb some of your energy and excitement, plus he may be pretty happy to be at your meeting rather than dealing with his day to day business, and however realistic your demo is, it’s not “real” and there are elements of the situation you can’t mock up, so his behaviour may be far from representative.  So it’s really important to continue asking questions about what he does today and his barriers to entry.

This now moves you into iterative design and development, which are not the concerns of this article, but you must ensure that you keep your customers and customer facing teams involved in the development work.

10. Write a service catalogue

Following all of this creative work, you now have some clear services and processes you can capture to describe the service offering you will give to your customers.  Recording this includes the services and the level of service, the activities and outcomes that your customers will experience, the processes and decisions they will be engaged with and of course, the metrics by which they will be measured.  These service descriptions and metrics should all derive directly from your service design and cover all the elements of the service we’ve discussed elsewhere, a reminder below.

Figure BFB-BTF-CSDSD-4: Service Operating Model/Elements of a Service

A service catalogue primarily needs to be useful and usable, so we recommend significant use of visuals and an accessible, online format.  At this stage, you are pre-live so the main objective is to capture the output of your service design work so that it can be shared with the teams developing the services and adjusted by them as they learn from the customers and the organisation; as your services are used after you go live, you should also maintain similar feedback governance so that you can continually learn from the organisation and adjust the services as needed.  NB if you’re looking for some additional guidance, an old-fashioned ITIL style IT service catalogue provides a pretty good framework, although you will need to adjust some of the elements.

11. Build a plan

The main output from all of this activity will be gaps that need filling. Again, it’s a good idea to start with your operating model construct and your services, to identify what needs to be done to get from where we are to a live service.

  • Who’s going to provide this capability and do I need to build new capabilities to support it?
  • Who’s going to drive the technology?
  • Where can I find the resources to do this stuff?
  • Do I need additional sponsorship based on the scope that’s come out of my service design?
  • Who else do I need to engage in the organisation?
  • How can I overcome the company rules to make this change happen?
  • What cultural changes do I need to achieve to get the teams working on it?
  • What skill changes?
  • Who do I need to talk to in the industry / regulators / governments to overcome other barriers?
  • Do I actually need to build a new unit new company to achieve this and what’s involved in doing that?

Answer these questions to identify activities, find someone responsible and get commitment for delivery, in addition to the more obvious activities that have been exposed by the workshop output; as before, this is not just about drawing process diagrams and developing some technology; developing a new service or service model requires a holistic approach that covers all elements.

Conclusion

In this chapter, we’ve described the process for going from idea and vision to service design and a first stage plan for execution.  We’ve explored some of the barriers but focused on the logistical element, because the benefits for this type of design activity are enormous and always outweigh the logistical challenges.

Key points:

  • With some carefully coordinated prework, design needs to be done in a locked room with the core team
  • It’s critical to start with who the customer is, not just demographic and statistical evidence
  • You need to think about customers’ problems holistically, rather than in the context of existing services and products
  • Tight workshop control is critical to success
  • Follow-up needs to flow into developing real services, including a holistic build of the services into your organisation.