Digital service delivery: End-to-end and front-to-back (part 2)

In our last post, we defined the generic steps people need to go through to access most public services. In this post we’ll explore the front-to-back layers that underpin a service experience. As I said in Part 1, by making it visible and naming the parts, we’re hoping we can unlock more fruitful conversations about who’s working where, what’s influencing outcomes, and how we can all work together to improve the delivery of public services. This combined axis of end-to-end and front-to-back is a key framework for understanding the system-wide orchestration required to deliver the services that people rely on.

What do we mean when we say front-to-back?

Front-to-back refers to all of the layers required to make a service possible. The “front” might be a service counter or an online form, and the “back” might be a bit of technology that stores information or data. In between are many layers where much of the operational work in public service happens every day. For example, reviewing and processing applications, ensuring a secure flow and storage of data, or collecting metadata to measure the effectiveness or impact of a policy. These layers also include the processes, workflows, policies, and a myriad of tools we use to handle and manage whatever is needed to move a person on to the next step in the end-to-end journey of a service. 

Some of the front-to-back is visible to people. For example, various ways of interacting like websites, phone numbers, in-person service, or places to mail applications (sometimes called channels). But a large proportion of what makes services operate is like an iceberg; a lot of it is not visible and it’s bigger than you’d think. There are not only people and whole teams that operate behind the scenes, but this is also where a lot of digital investments and technology reside. Many of the products CDS provides have bits that the public use, but using and configuring those platforms is only visible to people behind the scenes.

In our strategy, we shared some ideas about how we see ‘digital’ integrating across the top few layers of the front-to-back. We know that good digital services should be designed to be integrated with other service channels like call centres, in-person service centres, and even processing teams. This integration helps improve people’s experience and makes it possible for people to switch channels if they need to. Behind the scenes, it can make services more efficient and also help prevent “failure demand” where gaps in one part of a service show up as increased demands in another. For example, if a webpage about eligibility requirements provided online is unclear, demand might show up as increased call volumes, or if an online form is difficult to complete, people might revert to mailing paper forms, or showing up in person.

We’ve also been thinking about the deeper layers of the front-to-back. There’s lots of ways we could define these layers, but here are the distinct layers we think are critical to include in conversations about supporting good digital service delivery:

1. Digital services: Public facing information and transactions that happen online (websites, apps, social media, chatbots, etc).

2. Integrated channels: Public facing call centres, service centres, paper based applications that people can use when they don’t have online access.

3. Processing and back office: The internal facing people, processes, and tools that are used to intake, input, review, adjudicate, approve or deny, and fulfill a program or benefit.

4. Program and policy: Often considered the owner or authority for a program or service, this could include both the people and processes, as well as the policies or regulations that define a program.

5. Digital tools: Tools that public servants use to specifically support a service (like analysis/reporting tools, workflow management, or searchable knowledge bases).

6. Digital integration helpers: Things that support connecting separate systems with each other (such as APIs, or code that can allow things to be built on top of legacy technology). This can also include people and services that support building new services (like user research, process optimization, compatibility analysis, etc.). 

7. Common components and platforms: Repeatable, reusable, configurable services that can be combined (or composed) with other parts of a service (like sending notifications, building forms, sign-in, etc.). Ideally these components work well together, and can be joined in multiple ways, with little or no coding.

8. Supporting infrastructure: Fit-for-purpose, often shared infrastructure that meets security, privacy, and accessibility requirements (such as hosting, data storage, processing, and computing).

Caption: An iceberg showing the 8 distinct layers of front-to-back service delivery. The first 3 are clearly seen above the waterline: digital services, integrated channels, and processing and back office. The other five are below the waterline and harder to see from the surface: program and policy, digital tools, digital integration helpers, common components and platforms, and supporting infrastructure.

Why does the front-to-back matter?

An important nuance of the front-to-back is the farther the work gets from the “front” (where people are being served), the more abstract the connection to public outcomes can seem. The job of securing a cloud hosted database can be pretty far removed from a digital form or a call centre agent. The teams that manage and make decisions about these products might not have much line-of-sight to the full end-to-end journey or end user experience. What’s more, the lifecycle of products and services in the deeper layers of the front-to-back (the part of the iceberg that is deep under the water) can move at vastly different paces. They might be enabled or constrained by an entirely different set of funding, rules, dependencies, or decision making bodies. 

Programs’ ability to adapt their services and respond to change can be substantially enhanced or limited depending on how monolithic (all-in-one) or composable (small pieces, loosely joined) their front-to-back is. This can become critical if urgently needed changes to public facing services are directly dependent on multi-year contracts or upgrades to platforms or infrastructure. It’s why we believe it’s important to see and understand how everything is connected.

Bringing the end-to-end and front-to-back together

It’s my hunch that making the entire end-to-end and front-to-back visible can empower teams to understand the connection between their domain of work, and the outcomes that the government delivers for people.It may often be invisible to the people we serve, but this big picture perspective is where we believe there is a huge opportunity to improve both the services we deliver, and also how the government as a whole approaches supporting services. 

By understanding services as a combination of components across both the end-to-end and from front-to back we can:

• See the opportunities to de-duplicate effort.
• Better support programs and services to avoid buying or building large “all-in-one” solutions that introduce risks, dependencies, and lock-in that make it difficult to reuse or reconfigure.
• Connect how we measure various component parts and capabilities within the system.
• Better understand the influence specific components or capabilities have on the quality of service delivery.
• Make visible how the deeper layers impact the ability of teams or programs to deliver services.
• Reduce demand failure by helping various teams within the big picture see up and downstream from their part of delivery.

We’ll have more to say about what we’re learning as we apply this framework and continue to refine it. In the meantime, we’d love to connect and learn what the end-to-end or front-to-back looks like from your vantage point. Do you have a suggestion or question? Reach out and share your experiences with us. Together, we can improve service delivery for people.