The 2026 Guide
Index

Joined-up delivery

Joined-up delivery means making a person's whole task work from end to end, including the steps handled by other services that come before and after yours in the person's journey. A person rarely sets out to use one service; they set out to move house, start a business, or recover after a death, and that task usually crosses several services and several ways of getting help. Joined-up delivery pulls together four things: seeing the user's whole journey across every service and channel it touches, working with the teams responsible for the services on either side of yours, connecting the systems so they exchange information instead of asking the user for it twice, and keeping every channel in step so the phone line and the counter give the same answers as the website.

Your service is one box in a bigger journey

Most of the time, people do not want to use a government service. What they want is to move to a new country, start a job, raise a child, retire. The service is the thing they have to do to get to what they actually want. As Louise Downe, who led design for the UK government, put it: good services are verbs, and bad services are nouns.

Government touches those big moments, but the services for any one of them are split into fragments, spread across departments and across federal, provincial, and municipal government. A person has to work out, on their own, what to do and when.

Your service is one box in that larger journey. The part your team owns, the visa, the health card, the tax account, can be flawless on its own and the journey can still fall apart if the boxes do not join up.

Map the journey first, then design your box to fit it. Mapping the whole journey shows where it breaks between offices, which is where people get lost, scared, or stuck, and it shows the steps that repeat and the parts that could be reused.

What good looks like

  • The user's whole journey is mapped end to end, across every service and channel it touches, including the steps that happen before and after your own part.

  • The teams responsible for the services on either side have agreed how the journey works across organizational lines.

  • Systems exchange information so a person gives the same information to government once, rather than repeating it to each service.

  • Existing solutions are reused and functionality is exposed as a service, so the next team can connect to yours instead of rebuilding it.

  • Every channel gives a consistent experience, and a change to the online service updates the phone scripts, letters, and in-person steps at the same time.

  • Front-line and operations staff who help users know how the current service works, and there is a process to keep them up to date when it changes.

  • People who cannot or will not use the online service on their own can get help by phone or in person, and the non-digital channels stay easy to find.

Why it matters

A person does not experience your service on its own. They experience the whole task, and that task usually runs across departments and across channels.

When the parts do not join up, the person is left to:

  • work out how government is organized just to get something done;
  • give the same details to one service after another;
  • or fall into the gap between an online form and a phone line that knows nothing about it.

The Government of Canada sets the expectation in its digital standards, to design around user needs and collaborate widely, and the Policy on Service and Digital makes it firmer: services should take an omni-channel approach that gives an integrated client experience, with service standards for every channel and non-digital channels kept open so people have a choice. Joining a service up is also how someone who needs the phone or the counter is not left behind as more of the service moves online.

Whose job it is

Joined-up delivery is shared across the team and the organizations around it, with each role holding a different part:

  • Service designers and user researchers map the whole journey, run the cross-organization mapping, and find where the journey breaks between services and channels.
  • Developers and architects build the connections, expose the service's functionality through an API, and reuse what already exists so systems interoperate.
  • Operations and front-line staff deliver the phone and in-person channels and the help people need, and keep their scripts and knowledge current as the service changes.
  • The business owner of the application takes responsibility for agreeing how the journey works with the other organizations, and funds the non-digital channels and the support that go with it.

A closer look

Comparison

Two ways to join up a service

Pax

Meet Pax, a service manager. They treated moving as one journey across the services it touches:

  • mapped the journey with the other programs and agreed how the address change would flow between them
  • exposed the change through an API so the downstream services updated, and the person entered the new address once
  • updated the call-centre scripts and trained front-line staff in the same week the online form changed, and kept the phone option easy to find

The result: a person could update their address once and have it reach the programs that needed it, and the phone line gave the same answers as the website.

What Joined-up delivery looks like in each phase

Joining a service up is work in every phase, not a one-time launch task.

The cheapest time to join a service up is before it is built. The team maps the whole task the way the user experiences it, works out which other services it touches, and decides what to reuse or connect to rather than rebuild. Designing the service to expose its functionality as an API from the start is far easier than retrofitting it later. The research that maps the journey is the same research that tells you who relies on the channels around it.

The official instruments behind joined-up delivery

Everything official this subject brings with it, and where in a service's life each one comes up. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.

  • Service in both official languagesEvery serviceStanding duty

    The duty to offer and deliver the service in English and French, equally and at the same time. For a digital service this covers the interface, the content, notifications, error messages, and the human support behind it. Quality has to be equal, so a translated afterthought does not meet it.

    • DiscoveryCheck
    • AlphaGather
    • BetaFillSubmit
    • GrowthKeep current
    • MaturityKeep current

Further reading

The UK Service Standard on solving a whole problem for users sets out the principle behind facet 1 and reads across cleanly. To see how the Canadian Digital Service frames the end-to-end craft, its service design practice lays out the principles and methods a designer uses to plan a service across digital and offline channels. For the working-across-boundaries part, GOV.UK's guide to working across organisational boundaries with service communities gives you a practical way to set up and run a cross-organization group around a shared user journey. And if you want the whole journey expressed as named stages, Australia's service design and delivery process walks a service from discovery through to live so you understand the problem before building the solution.

See also

Assumptions this page makes

You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.