Service Design Audit
A read of the service itself, end to end - whether the backstage holds up every frontstage moment, and whether what the frontline learns ever reaches the design.
Our service design audit reads the whole service end to end, the way a service user actually travels it - not the interface, the service. We map the journey and the few moments of truth that decide how it lands, then draw the blueprint: the frontstage the user meets, the backstage of processes, roles and systems that has to hold it up, and the line of visibility between them. Where the backstage doesn't hold, the frontstage buckles - and that's the gap we bring you.
We look at six angles: the journey and its moments of truth, the blueprint across the line of visibility, the failure demand in your workload, touchpoint coherence across channels and handoffs, the feedback loop from frontline to design, and the delivery capability behind the promise. Then we give you the few that matter most - what the service does well and should keep, what's quietly generating rework, and what to redesign first.
Around 40% of customer contacts are failure demand - people coming back because something didn't work first time (Vanguard). It's demand your service creates, not demand it exists to meet, and it's usually the largest thing an audit surfaces.
When a service design audit helps
An audit earns its place when the same strain keeps surfacing in delivery and you need to see the service underneath it, not patch another symptom:
The situation | How it helps |
|---|---|
The frontline is firefighting | Reads the failure demand behind the volume, so you fix what's generating the rework, not just staff the queue. |
It works on paper but not in practice | Draws the line of visibility, so you see where the backstage stops holding up what the user is promised. |
The service feels different at every touchpoint | Reads coherence across channels and handoffs, so it lands as one organisation rather than a set of disconnected steps. |
You're about to redesign or digitise it | Blueprints the current service first, so you rebuild from how it actually runs and don't automate the failure demand. |
Frontline knowledge never seems to change anything | Maps the feedback loop, so what the people delivering the service learn can reach the design and shift what happens. |
The promise is outrunning what you can deliver | Reads the capacity and operating rhythm behind the service, so what you promise and what you can sustain line back up. |
What we look at
We read the service through six angles - the lenses that test whether the frontstage a user meets is actually held up by the backstage below the line of visibility, end to end:
Journey and moments of truth
The end-to-end path a service user travels, and the few high-stakes moments that decide how it lands. In many services those moments are high-stakes for the user in a way no internal metric captures - a decision about their housing, their care, their money.
We walk the journey as a user would, at the pace a real case moves. That includes the stretches between contacts - the waiting, the not-knowing - because in most services the silence is part of the experience.
The service blueprint, frontstage and backstage
Whether what the user sees is held up by the processes, roles and systems below the line of visibility. A blueprint sets each user-facing step directly above the machinery that produces it - cause and effect, finally in view together.
We build the blueprint for the journeys that matter most, then stress the joints - where a frontstage promise depends on a backstage step that's manual, overloaded or owned by nobody. Strengthening below the line is usually cheaper than compensating above it.
Failure demand
The workload created because something didn't work first time - demand the service made, not demand it exists to meet. It arrives through the same phone lines and inboxes as real need, handled by the same people, so it rarely gets counted separately.
We sample incoming contacts and sort them: is this the service working, or the service coming back around. The split shows where users are being failed first time - and fixing those points is the rare improvement that cuts workload and complaints together.
Touchpoint coherence
Whether it feels like one organisation across every channel and handoff, not a relay of disconnected steps. A service can pass every internal check and still feel disjointed from outside - coherence only exists in the user's experience of the whole.
We check what each step inherits from the one before - the referral that arrives complete or doesn't, the promise the next team has never heard of. Most incoherence traces to a handful of specific joins, which keeps the fix list mercifully short.
The feedback loop
Whether what the frontline and service users know travels back into the design, and ever changes what happens. The people delivering a service are its most underused designers.
We follow recent feedback - a complaint, a staff suggestion, a pattern in contacts - and see how far each travelled. A loop that closes even occasionally can be built on; the audit shows where it currently stops, and what a closed loop would have caught this year.
Delivery capability
Whether the people, capacity and operating rhythm behind the service can sustain what it promises. The design assumes a level of staffing, skill and rhythm - and those assumptions age faster than the design does.
We audit those assumptions - caseloads, skills, response times - against what the teams actually carry now. Where capability has grown past the design there's headroom to raise the promise; where it's fallen behind, better to reset the promise than keep missing it.
The six angles stay constant; how we read them, we shape around you - your service, its channels, the roles and systems behind it, and where in the journey the pressure sits - so the blueprint fits your service, not a template.
Why these six angles
We read the service, not the screen. A service isn't its interface - it's the whole path a user travels and everything backstage that produces each step. So we start with the journey and its moments of truth, because a handful of moments carry most of how the service is judged, and work down through the blueprint to the roles, processes and systems below the line of visibility. The tell of a service that's drifting is a frontstage the backstage can no longer hold up.
Failure demand is the angle that pays for the audit. It's John Seddon's distinction: demand you're there to meet, versus demand you created by not getting it right first time. Left unread, it looks like healthy volume and gets staffed rather than designed out. We look for it in the real workload, because it points straight at where the service is failing its users - and quietly costing you the most.
The feedback loop and delivery capability are what decide whether the service can stay good. A service is a living thing, not a fixed process: if what the frontline learns never reaches the design, the same faults recur; if the promise outruns the capacity behind it, the frontstage cracks under load. These are the conditions that let any service keep working, which is why they're in the lens alongside the map itself.
How it works
We read the service the way it's actually delivered - through more than one mode, so the blueprint holds up:
- We watch it run - we observe the real service as a user meets it, and walk it end to end ourselves, so the map is of what actually happens, not the process on the intranet.
- We measure the failure demand - we read the workload for what's rework versus genuine demand, and where in the journey it's generated, so the volume points back to a cause you can design out.
- We listen to the frontline - interviews across a cross-section of the people delivering the service, not only managers - they see the backstage strain and the workarounds first, and where the feedback loop goes dead.
- We draw the blueprint - we build the end-to-end journey map and a service blueprint that marks the line of visibility and looks behind it, so every frontstage moment is traced to the backstage that produces it.
The thinking behind the method
No single view captures a service on its own, so we use several and cross-check them. The workflow diagram tells you how the service is meant to run; observation tells you how it actually runs; the frontline tells you why the two differ. A finding has to show up in more than one mode before we treat it as real, which is what keeps the blueprint honest rather than a tidy picture of the intended service.
We walk the service as a user does, and we read the failure demand in the live workload, because that's where a service reveals itself. An org chart shows the roles; it doesn't show the handoff where the case falls between two teams, or the moment of truth that quietly decides whether the user comes back. Those live in the journey and the backstage, not the process document, so that's where we look.
The blueprint is the anchor deliverable for a reason. Drawing the line of visibility forces the question the audit exists to answer: for every moment the user meets, what backstage process, role or system has to hold it up - and does it? That's what separates reading the service from reading the screen, and it's why we build the blueprint rather than a list of issues.
We interview across a cross-section, not just leaders, on purpose. The people delivering the service live in the backstage the leadership designed but rarely sees, and the gap between those two views - what the service is meant to be, and what it takes to actually run it - is frequently the most useful thing we find.
What you get
A working read-out, not a report filed and forgotten. We walk you through:
- A service blueprint of how the service actually runs, with the line of visibility drawn and the frontstage-backstage gaps made visible.
- The moments of truth that decide the experience, and how well the backstage holds each one up.
- The failure demand you're carrying, and where in the journey it's being generated.
- Where the feedback loop is open or broken, and the few redesign moves that would make the most difference.
Where two things are both true and in tension - "we want the frontline to fix problems at the point of contact" and "the backstage gives them no authority to" - we show you both. That gap is usually where the redesign starts.
How we hand it back - and what happens next
The audit ends in a working session over the blueprint, not a document dropped in your inbox. We walk you through the map in person - the line of visibility, the moments of truth, where the backstage stops holding up the front - so it lands as something you and your team can act on, rather than a report read once and filed.
Some of the most useful findings come as pairs - two things both true and pulling against each other, usually a frontstage promise and a backstage constraint. We name those tensions rather than smoothing them into one tidy recommendation, because that's where the redesign has to do its work.
From there it's your call. Sometimes the blueprint is enough and you carry the redesign yourselves. Sometimes you want us alongside for the work that follows - reworking a broken handoff, closing the feedback loop, or a fuller service redesign. And if what you need turns out to be lighter than you feared, we'll say so.
Focused now, or continuous over time
This is a focused, one-off deep read of your service as it runs right now. If what you want is the whole organisation tracked continuously - service delivery as one thread among eight - that's States of Vitality, our organisational-health platform. Different job: depth on one service now, versus the wider picture over time.
Common questions
Is this a UX or website audit?
No. We read the whole service end to end, online and off, through the service blueprint - the backstage of roles, processes and systems that produces each frontstage moment - not the interface. A screen is one touchpoint in a journey; the audit is about the service behind all of them, including the phone calls, the handoffs and the steps a user never sees.
How is this different from a customer experience audit?
A customer experience audit reads from the customer's seat - how it feels, where perception and reality diverge. This reads the service itself: the blueprint, the failure demand, the feedback loop, the capability behind the promise. One tells you the experience is breaking; this tells you which backstage process is breaking it.
Who do you involve?
A cross-section, not just managers - we observe the live service and interview across the people who actually deliver it, at every step of the journey. The frontline sees the backstage strain and the workarounds first, so their read, and the gaps between what leadership intends and what delivery takes, are where the value is.
How long does it take?
It's usually weeks rather than months, but it depends on the size of the service, how many channels and handoffs it runs across, and how complex the backstage is. We build each audit around your service, and agree the timeline when we scope it.
How much does it cost?
There's no standard price - we build each audit around your service, so the cost reflects its size, the number of touchpoints and channels in scope, and the depth you need. We scope it with you and give you a clear figure before you commit.
Is it confidential?
Yes. Interviews with your frontline are confidential, and we report in patterns and at the level of the service, never in a way that identifies an individual member of staff.
Regulatory guidance redesigned around the people who need it, not the legislation
Complex political finance rules communicated through one-size-fits-all guidance - for an audience ranging from volunteer treasurers running local party branches to professional compliance officers managing millions in campaign spending.
Read case study →
Service improvement led by customers and teams, not handed down by consultants
A growing housing association where staff could recite the values but customers experienced something different - and previous improvement efforts kept addressing symptoms rather than causes.
Read case study →Most service design stops at user research and journey maps. We work both sides - designing the service and shaping the organisational conditions that determine whether it actually gets delivered.
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.
The Service Launch Programme takes your designed service live: the blueprint stood up end to end across the front-stage steps customers see, the back-stage processes behind them, the systems it runs on and the measurement that tracks it. We deliver it with your teams, so the service is running the way it was drawn and owned by the people who run it.
Keeping the Service Sharp keeps your live service fit and improving after launch, and builds your own people's ability to run that improvement themselves. Your service owner and team keep the blueprint current, work a live improvement backlog, and act on what the frontline sees. You can add a light ongoing rhythm with us on top, scoped to as much or as little as you want.
A service blueprint is a detailed map of how a service actually works - what the user sees and experiences on the front end, and everything happening behind the scenes to make it possible. It helps organisations redesign services by showing the full picture.
Contextual inquiry is a user research method where you observe and interview people in their actual work environment while they perform real tasks. It uncovers insights about real behaviour and needs that surveys and interviews in meeting rooms simply can't reach.
A Gemba Walk is a Lean practice where leaders go to the place where work actually happens to observe, listen, and understand. It bridges the gap between how leaders think work gets done and how it really gets done.
Process mapping is a visual method for documenting how a process works from start to finish. It helps teams see the full picture - every step, decision point, and handoff - so they can spot problems and design improvements.
Every organisation has friction - the unnecessary effort, the needless complexity, the things that make simple work harder than it should be. This article explores how to find it, understand where it comes from, and reduce it without creating new problems in the process.
The skills that make someone good at service design - empathy, experience mapping, designing conditions - are the same skills leaders need to create environments where people do their best work. What changes when that lens runs all the way through the organisation.
Thinking about a service design audit?
Tell us what's prompting it and what you want to understand, and we'll say whether it's the right move.