The problem

A financial services business reported that roughly one in five applications in its assisted channel were straight-through. The figure was well established internally and was shaping the investment case.

A day spent alongside the operations team produced a different picture. Applications counted as straight-through were being checked, re-keyed between systems and followed up by people.

Both readings were correct. Straight-through processing has no single agreed definition. The business measured data arriving digitally through the form, which is common and defensible. The stricter benchmark most of the market quotes is an application completing without a human touching it. Same operation, two definitions, two very different views of the available headroom.

The useful part is not that the gap existed. Gaps like that exist in most programmes. It is that both readings were on the board, sourced and reconciled, inside four weeks, which happened because of the artefact they landed in rather than because of who was in the room.

That is an infrastructure question, and it is the one most transformation programmes get wrong. They rarely fail on strategy. They fail on continuity. The reasoning behind a decision leaves with the sponsor who made it. A delivery partner joins nine months in and re-opens choices already settled on evidence, because the evidence is in a slide deck nobody can search. A backlog item gets descoped without anyone noticing it carried the strongest finding in the research.

The common factor is the deliverable. Discovery produces a service blueprint, the map of how a service works front to back, and that blueprint is accurate on the day it is signed off and decaying from the day after. Nielsen Norman Group named the problem in 2019, across 97 practitioners: keeping a high-fidelity blueprint current once the service changes. The default answer is still a static file and someone's promise to maintain it. A programme that cannot trace a decision back to its evidence re-decides it, at delivery rates rather than discovery rates.

Dynamic blueprinting is our answer to that. A service blueprint built as software, rendered from a live evidence layer, running inside an agentic delivery model. It is the process we bring to a client, not a document we leave behind.

What it is

Four things make it work.

1) An evidence layer underneath everything. Every input lands in one ledger before anything is mapped: interviews, workshops, ethnographic observation, product documentation, quantitative analytics. Each is broken into atomic claims, one statement per row, typed as fact, hypothesis or assumption, then sourced, dated, attributed to an actor and a journey stage, and rated for confidence. Every claim has lineage. First-hand observation outranks second-hand report, corroboration across independent sources raises confidence, and claims that contradict each other are flagged and investigated rather than merged into something that reads clean. That last rule is why two incompatible readings of a straight-through rate can sit side by side with their sources attached, instead of one of them being smoothed away in synthesis.

2) Governance sits in the same layer, by design. A claim is an atomic statement attributed to a role and a journey stage, not a transcript of a named individual, so what the ledger carries is the finding rather than the raw recording. Source material stays inside the client's environment under their access controls and retention rules, participants are briefed on how their input will be used, and the agentic lane only ever operates on material the engagement is scoped to In regulated work this is not an add-on. It is the condition for running the approach at all.

Views that are rendered, not drawn. The blueprint is a view over the ledger. New evidence does not trigger a rewrite, it re-runs the view, and the current state, the target state and every principle and persona move with it. Nothing downstream loses its thread, because each element still resolves to the claim and source that produced it.

3) An artefact that is software. The blueprint is built in HTML, CSS and JavaScript, driven by a component library designed in Figma. The design system and the live artefact are one ecosystem rather than two files kept in sync by hand, which is what keeps every step described at the same level of detail and lets a board spanning a dozen journey stages and several actor groups read as one system. Because it is code, it updates as evidence lands rather than at the end of a sprint. It is interactive, so a sponsor can move between the whole system and a single step, open a friction point and read the claims and confidence ratings underneath it. It opens in a browser, so there are no licences, no exported copies in circulation and no single owner of the master. And it is structured data, so every step resolves to an item a delivery team can pick up, and an agentic layer can operate on it directly.

4) An agentic model around it. Two lanes run in parallel across align, discover, define, design, deliver and monitor. The human lane sets intent, interprets, prioritises and decides, with a gate before anything advances a stage. The agentic lane prepares and collects, classifies claims, synthesises and drafts the views. Machines read everything and sort it consistently. They are poor at judging what matters. The lane split is drawn on exactly that line.

Rigour on its own produces a defensible artefact nobody opens. Craft on its own produces a compelling artefact nobody can defend. Dynamic blueprinting holds the two together, which is why the ledger and the interface are described here as one thing.

What it produces

Three outcomes, in the order a programme feels them.

Evidence becomes available in days rather than at the end of discovery, because synthesis runs continuously instead of in a block at the end.

Findings survive challenge and outlast the people who found them, because every claim carries its source, date and confidence, and the reasoning sits in the artefact rather than in the heads of the people who ran the workshop. In the case above, that turned an argument about a number into a decision about a definition. One definition was agreed, it became the baseline the target state is measured against, and instrumenting touch time became a recommendation rather than a dispute.

The target state arrives in delivery units. Steps are marked proposed or retired against the step they replace, so the output is a build list and a stop-doing list rather than a set of recommendations someone still has to translate.

On that engagement the numbers were over 400 claims, 108 of them at fact confidence, distilled into 17 problem themes, eight design principles and 16 target-state opportunities, in four weeks. What the client held at the end was not a report. It was a working artefact still connected to its evidence.

Where it applies

The approach earns its cost where evidence is contested, distributed or long-lived. Regulated industries where a design decision has to be defensible a year later. Programmes spanning several systems and several vendors, where no single group holds the whole picture. Anywhere a reported metric and the observed reality are likely to diverge, which is most places once automation is in the mix. It is less useful on a short, contained piece of work with one stakeholder and a clear brief.

The shift underneath this is one data and AI teams made years ago and design has been slow to follow. Provenance matters. A number without lineage is an opinion, and an insight without a traceable source is the same thing in a nicer font. As organisations put agentic systems into customer journeys the pressure only increases, because a model acting on a customer's behalf will eventually need what a regulator needs: a clear account of why the experience was designed this way, and on what evidence.

None of which replaces the fundamentals. The discipline is still design thinking and human-centred research, and the day alongside the operations team is what surfaced the straight-through gap, not the tooling. What the tooling changes is the infrastructure those methods run on, and how long their output stays usable. Static deliverables cannot carry that. Living ones can, well after the engagement closes.

Dynamic blueprinting is one capability inside the agentic design model we run from align through to monitor, with a human gate at every stage. How the rest of that model works, and where we are deliberate about keeping a machine away from a decision, is the next piece.

Author: Gianluca Caico is a Lead Experience Designer at Bound, a boutique digital consultancy combining strategy, human-centred design and engineering. His background is in design thinking, human-centred design and customer strategy, leading discovery and transformation work across financial services, healthcare and utilities. Bound is part of The Omnia Collective, a group of founder-built Australian businesses across technology, design, data, AI and talent.

Source: Nielsen Norman Group, Service Blueprinting in Practice (2019).