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.
- 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.
- Failure demand - the workload created because something didn't work first time - demand the service made, not demand it exists to meet.
- Touchpoint coherence - whether it feels like one organisation across every channel and handoff, not a relay of disconnected steps.
- The feedback loop - whether what the frontline and service users know travels back into the design, and ever changes what happens.
- Delivery capability - whether the people, capacity and operating rhythm behind the service can sustain what it promises.
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.
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.