Pattern Chaining: How Services Are Built, Not Designed

Six weeks into a discovery phase for a new citizen-facing service, a programme team put their journey map on the wall. It was excellent work: well-researched, user-centred, carefully validated. It showed every step a citizen would take from first contact to final outcome, including the failure paths, the edge cases, and the moments of highest friction.

I looked at it for a few minutes and then said something that made the room uncomfortable.

'We have already designed this. Twice.'

Not this specific service. Not these specific users, these specific business rules, this specific technology context. But the structural logic: the intake moment, the triage routing, the formal assessment, the decision, the notification, the ongoing case management if the outcome required it. That sequence had been designed, delivered, and hard-won in two other programmes in the same organisation. The knowledge existed. Nobody had named it in a way that made it transferable.

This is the problem that pattern chaining addresses. Not the absence of good design work. The absence of a mechanism for design work to accumulate.

Built, not designed

The distinction between building and designing matters more than it might appear. Designing, in the way most service teams use the word, means beginning with a blank canvas: user research, problem framing, creative exploration, iterative prototyping. It is valuable work. It is also work that treats every service as a new problem to be solved from first principles.

Building means something different. It means starting by identifying the structural components that apply to this type of service, understanding how they connect, and then doing the creative and contextual work within that structure rather than before it. A builder does not design a door from scratch. They select the right door for the context, hang it correctly, and finish it appropriately. The craft is real. The component is inherited.

Pattern chaining is the discipline that makes building possible: defining which patterns apply to a given service, in what order, under what conditions, and with what branching logic when an outcome produces more than one possible next step. It does not replace design. It gives design a foundation to build on.

How chains are structured

A chain has three components. The patterns themselves, each doing its defined structural work. The transition conditions: the rules that determine when one pattern is complete and the next should begin. And the branches: the points at which the outcome of one pattern determines which of two or more subsequent patterns is triggered.

Consider a benefit application service. The citizen first encounters Register and Express Interest, establishing their identity and signalling intent. That pattern completes when a record exists and the citizen is acknowledged. Apply and Submit follows, producing a formal application with supporting evidence. Check and Assess follows the submission, evaluating the application against eligibility criteria. Then Get a Decision, which produces and communicates a formal outcome.

So far the chain is linear. It becomes interesting at the decision point, because decisions produce branches. A positive decision triggers Handover and Onboard, bringing the citizen into a new ongoing relationship with the organisation, followed by Pay and Account for the financial dimension of that relationship, and Manage a Case for sustained oversight over time. A negative decision triggers Notify and Communicate with the rationale, and potentially Refer and Support if the assessment identified needs the refused application cannot address. A request for further information triggers a return loop to Apply and Submit, with a time-limited window before Close and Complete is called on the lapsed application.

That is not one linear sequence. It is a structured network of patterns, with defined entry conditions, defined completion criteria, and defined branching rules at every decision point. The service is not a journey. It is a directed graph, and a pattern chain is its map.

Why chains matter for programme planning

When a programme team can see the chain before delivery begins, three things change that cannot be changed later without significant cost.

Scope becomes legible. A chain makes explicit how many distinct structural interactions a service contains. A programme that includes Manage a Case and Comply and Certify alongside its intake and decision patterns is a fundamentally different undertaking from one that closes at Get a Decision. Chains make that difference visible at the point of planning rather than the point of discovery, which is where scope surprises are expensive.

Dependencies become explicit. The chain reveals which patterns share data, which systems need to communicate, and which teams need to coordinate. A transition from Check and Assess to Get a Decision requires that the assessment record is accessible to the decision-maker. A transition from Get a Decision to Refer and Support requires that the referral destination knows what the decision was and why. These are design constraints. In a chain, they are visible from the start. In an undocumented service, they are discovered during integration testing.

Risk becomes addressable. Every transition in a chain is a potential failure point. Chains make those points visible. Visible risk can be governed. Risk that lives only in someone's head, or in a process that nobody has mapped end to end, cannot.

Chain templates for common journey types

Across the public sector, certain chain templates recur reliably enough to be defined in advance and adapted rather than constructed from scratch for each programme. These templates are starting points, not prescriptions. A programme team inheriting a chain template remains entirely free to adapt it to their specific context, to split a pattern into sub-patterns, or to identify a structural interaction the template does not account for. The point is not to constrain design but to prevent teams from rediscovering structural logic that other teams have already worked out. Innovation happens in the contextual detail, not in the basic sequence of intake, assessment, decision, and resolution.

An enforcement journey typically follows Capture and Triage, Check and Assess, Get a Decision, and Notify and Communicate, with an Enforce and Escalate branch if the decision is not complied with and a Manage a Case pattern sustaining oversight throughout. A local authority planning enforcement team and a food hygiene inspectorate operate under different legislation, with different evidence standards and different escalation paths. The chain template is the same. The content within each pattern is specific to each domain.

A licensing or permitting journey typically follows Apply and Submit, Check and Assess, Get a Decision, and Notify and Communicate, with Inspect and Record as an ongoing obligation once the licence is granted and Enforce and Escalate as the consequence of breach. A driver licensing service and a premises licensing service share this chain. Their data models, their decision criteria, and their legal frameworks differ entirely.

A support and referral journey follows Capture and Triage, Check and Assess, Refer and Support, and Manage a Case, with Close and Complete when the need is resolved. This template is more branching than the first two, because support journeys frequently involve handoffs between organisations and multiple concurrent Refer and Support patterns running in parallel as different aspects of a complex need are addressed simultaneously.

What chaining reveals that pattern-level thinking cannot

Individual patterns are the vocabulary. Chains are the sentences. A vocabulary list tells you very little about how a language works until you can see how the words combine.

Chaining reveals the throughput logic of a service: how volume flows from intake to resolution, where it accumulates, and where it clears. A service with a fast Capture and Triage pattern feeding a slow Check and Assess pattern will build a queue at the assessment stage. That is not a discovery a programme team should be making six months into delivery. It is a structural characteristic that chain analysis reveals before a line of process design has been written.

Chaining also reveals the data architecture of a service. Every transition between patterns is a data handoff: something must be known about a case at the point of transition for the next pattern to begin its work correctly. The data model for a service is not an IT design decision that happens after the process is agreed. It is implicit in the chain from the moment the chain is defined. Architects who read chains and technology teams who design data models should be in the same room at the same time.

The seams

There is one further thing that chaining reveals, and it is important enough that the next article in this series addresses it directly.

Every transition between patterns is a seam. Seams are the most consistently neglected element of service design. Teams design the patterns, the stages, the activities within each stage, and the happy path through the chain. They rarely design the seams with equivalent rigour: the conditions under which a transition should be held, the handling for a case that arrives at a transition in an unexpected state, the governance that sits at each handoff to ensure that what enters the next pattern is what that pattern was built to receive.

Most service failures are seam failures. A referral that was made but never received by the team it was sent to. An assessment that completed but whose outcome never triggered the decision process it was supposed to feed. A case closed at one organisational boundary and never opened at the next. The pattern was fine. The transition was not.

Chains make seams visible. Visible seams can be governed. That is the subject of Article 7.