Service Model Design
Service model design gives you your service blueprint: the end-to-end design for how the service actually runs - the user journey, what people see and touch, the work behind the front line, and the systems and evidence that hold it together, worked out in detail and ready to put into practice. We design it with your frontline staff and, where it fits, the people who use the service, so the result is genuinely theirs.
Our service model design gives you a service blueprint your organisation can run on, and we design seven parts: the user journey and the moments that matter, the front-stage the user sees and touches, the back-stage work behind the front line, the support processes and systems the service leans on, the roles, handoffs and decision rights, the prototype tested with real users and staff, and the measures and feedback loops that keep it working. You walk away with a design that is specific to how you deliver and ready to put into practice.
A service model works when the people who run it helped design it. So we design with your frontline staff and, where it fits, the people who use the service, drawing on the knowledge already inside the organisation and combining it with our outside frameworks. The blueprint comes out both accurate and owned, and you come away more able to redesign the next pathway yourselves.
A company's performance on whole customer journeys is 35% more predictive of satisfaction than its performance on any single touchpoint, and 32% more predictive of churn. Designing the service as one journey, not a set of separate interactions, is what moves those numbers (McKinsey & Company, 'The three Cs of customer satisfaction', 2016).
When service model design helps
Service model design is the next step once you know a service needs to change - often straight after an audit has shown where. These are the situations we are most often asked into. If one sounds like yours, this is a good place to start.
The situation | How it helps |
|---|---|
The service works on paper but breaks in the handoffs | Maps the back-stage and support processes against the line of visibility, so the design holds together instead of depending on staff working around the gaps |
Users have to re-tell their story at every step | Redesigns the journey end to end from the user's side, so the moments that matter connect and the service reads as one service across channels |
A new service or pathway needs designing from the ground up | Produces a full blueprint - journey, front-stage, back-stage, support and evidence - worked out in detail and ready to stand up |
Demand or caseloads have outgrown how the service was built | Redesigns the model for the volumes you are carrying now, with roles, handoffs and support processes set for real workloads |
Channels have grown apart and the service feels different in each | Designs the front-stage and evidence so the call, the form, the letter and the screen deliver one coherent service |
You want a design your frontline team will actually adopt | Builds it with the people who run the service, and prototypes it with real users, so it lands as theirs and gets used in practice |
What we design
We design seven parts of the service model, and make each one concrete enough to run on:
- The user journey and the moments that matter - The end-to-end experience mapped from the person receiving the service, with the make-or-break moments named - the points where the journey is won or lost.
- Front-stage: what the user sees and touches - Every visible interaction and every piece of evidence - the call, the form, the letter, the screen, the face at the desk - designed so the service reads as one service across channels.
- Back-stage: the work behind the front line - The steps staff take out of sight to make the visible service happen, mapped against the line of visibility so nothing depends on a heroic workaround.
- Support processes and systems - The internal systems, other departments and suppliers the service quietly leans on - named and tied into the model so the design holds under real caseloads.
- Roles, handoffs and decision rights - Who does what, where each decision sits, and how work moves between people and teams - so the model runs smoothly instead of stalling at the seams.
- Prototyped and tested with users and staff - The model tried in the rough with the people who use it and the people who run it, and refined - not signed off on a slide.
- Measures and feedback loops - The signals that tell you the service is working - journey-level, not just per-transaction - built in so the service keeps sensing and adjusting after launch.
Why these seven
These seven are the parts that have to line up for a service to work as one whole. A redrawn journey with vague back-stage steps stalls where the old one did; a slick front-stage sitting on undesigned support processes still snags the moment caseloads rise. The parts that get skipped most - the support processes, the evidence, and the measures - are the ones that decide whether the service runs in practice or stays a diagram. So we design them together, as a set.
The seven follow the established service-blueprint frameworks, organised around the lines a blueprint is actually built on - what the user sees, what happens out of sight, and the systems underneath. We use them to make sure the design is complete, so front-stage, back-stage, support and evidence each stand as a decision, rather than as a model to run at you.
How it works
The method produces one thing: a service blueprint your organisation can run on. It works by designing the model with your people rather than presenting one to them. Your frontline staff already know how the service really behaves, and your users know where it helps and where it hurts, so our job is to draw that out, combine it with the outside frameworks and pattern-recognition you bring us in for, and shape the two into a design that is both expert and genuinely owned. It works in four modes.
- We start with your design principles - Before anything is drawn, we agree a short set of principles with you - the rules the service has to honour, like 'the user never re-tells their story', 'no dead ends', or 'decisions made once'. They turn every later blueprint choice into a matter of principle rather than preference.
- We design with the people who run the service - Frontline staff know where the current service bends and breaks in ways no process map shows, and users know which moments matter. We build with them, turning that knowledge into design choices - so the model fits how the service actually works, and is owned by the people who will run it.
- We bring the outside insight and the frameworks - An inside view on its own tends to redesign around today's habits, so we bring the outside pattern - what makes services like yours work - and the blueprint frameworks that check the design is complete and the layers line up before you commit.
- We prototype, test and leave the capability behind - We try the model in the rough with real users and staff, refine it, and work so your people learn to design as we go. By the end you have a tested blueprint and a sharper sense of how the decisions were made, so the next pathway is one you can redesign yourselves.
The thinking behind the method
We design with your people rather than deliver to them because of a hard fact about service redesign: the model that gets adopted beats the model that looks best on a slide. A service blueprint is a set of new behaviours that hundreds of daily interactions follow, and staff follow a service they helped design - they understand why it is shaped the way it is, and they trust that it fits how the work really goes. Prototyping it with real users tells you the same thing from the other side of the counter, before launch rather than after.
So co-design gives you a service that is both right and real. The knowledge inside the organisation makes it accurate; designing it together makes it owned; and the outside frameworks keep the two from simply reinforcing what was already there. Get all three and the service works in practice. Miss one and you get an expert blueprint that gets rejected, an owned one that stays parochial, or a clever one that never gets used.
What you get
By the end, you have four things:
- The service blueprint itself - a worked-out design across all seven parts: the journey, front-stage and back-stage, support processes and evidence, with roles, handoffs and decision rights mapped, on a page and in the detail beneath it.
- A tested, adopt-ready model with its measures built in - prototyped with real users and staff, refined, and handed over with the feedback loops that let it keep adapting, so what you get is proven in the rough rather than signed off on a slide.
- A design that is genuinely yours - built with your people, grounded in how you actually deliver, so it is owned and used rather than filed.
- The capability left behind - your people come out more able to blueprint a service, so the next pathway is one you can redesign yourselves.
The best service is both expert and owned, and those pull against each other: expertise wants to hand you the answer, ownership wants your people to reach it themselves. Holding both at once is the craft of the work.
How we hand it over - and what happens next
The point of the work is a service blueprint your organisation can run on, so we take care with how it lands. Because your people helped design it, and real users tested it, the handover confirms something the team already understands rather than revealing it cold. We walk through the finished blueprint and its measures - why it is shaped the way it is, what it settles, what it deliberately leaves open, and what the first moves are.
From there, some organisations take the model and stand it up themselves, now more able to. Others bring us alongside for the harder work of making it real - the implementation stage of the journey. The design has done its job when you can see the new service clearly, believe in it because you built it, and know the first steps to get there.
Where this sits
Service model design is the second step in how we approach service design. It follows the Service Design Audit, which reads the service you run today, and leads into implementation, which turns the blueprint into how the service runs day to day. It also stands on its own - if you already know a service needs to change and want the model designed properly and owned, this is where to start.
Common questions
Is this just a set of workshops?
No - what you get is a designed service blueprint, tested with real users and staff and ready to stand up. We work with your people in the room, because that is how the design becomes both accurate and owned, and the sessions are the means to that. You walk away with the worked-out model itself, its measures built in, and a design your people helped shape and are ready to run.
What exactly is a service blueprint?
It is the end-to-end design of how a service runs - the to-be model. It maps the user journey, the front-stage the user sees and touches, the back-stage work that delivers it, and the support processes and evidence underneath, organised around the line of visibility that separates what the customer sees from the work behind it. Alongside it come the roles, handoffs, decision rights and measures. Designing those as one set, rather than one piece at a time, is what keeps the layers from pulling against each other.
How is this different from the Service Design Audit?
The audit reads the service you run now - where it works, where it breaks, and why. Service model design is the next step: it builds the future service instead. The audit answers 'what needs to change'; this designs and prototypes 'what to build'. Many clients do the audit first, because designing on a clear read of the current service sets the work up well, but if you already have that clarity, you can start here.
How is this different from a customer-experience offer?
Customer experience designs the felt experience - what the interaction looks and feels like to the user. This designs the service model that produces that experience: the front-stage and back-stage, the support processes, the roles and handoffs, the systems and evidence the service runs on. The two fit together - a good experience needs a service model that can actually deliver it - but they are different pieces of work, and this one is the machine behind the moment.
Does this cover our technology and systems?
At the level a service model needs. We design the systems and data the service depends on as principles and service-flow - what each touchpoint has to do and how it hangs together - with your own technology, data and operations leads. We design the service model, not the platform or the integrations, so where deep technical build is needed we specify what it must do and shape it alongside the specialists who own it. The same holds for any regulatory, clinical or safeguarding requirements: we design those into the blueprint with your subject-matter and compliance specialists.
Why build it with our people rather than design it for us?
Because a service only works if it is used. The model that gets adopted beats the one that only looks best on a slide, and staff adopt what they helped design far more readily than what is handed to them. Your frontline team also holds knowledge about how the service really behaves that no outside team can fully see, and prototyping with real users catches what neither of us would spot alone. Co-design combines that inside knowledge with our outside frameworks, so the model is both right and real.
Ready to design your service blueprint?
Tell us which service is prompting the redesign and what you are trying to achieve, and we will talk through what a service model design would look like for you - and whether an audit first would set it up well. If you already know where the service stands, we can go straight to designing the blueprint, built with your people so it is genuinely yours.