A service rarely runs the way it looks on a journey map. Service-dominant logic, developed by Vargo and Lusch, reframes what a service actually is: rather than treating value as something an organisation manufactures and hands over, it argues that value is always co-created between multiple actors (the organisation, its staff, its suppliers and the people using the service) through the resources and knowledge each contributes (Vargo and Lusch, 2004). This is why service designers talk about a ‘service system’ rather than a single process: a GP appointment, a loan application or a parcel delivery only happens because a configuration of people, technology and information is working together, much of it invisible to the user. Mapping that system (who does what, front-stage and back-stage, and where it depends on partners outside the organisation) is what makes a service designable, rather than just a set of screens or interactions.
A service system only keeps running if something pays for it. The Business Model Canvas, developed by Osterwalder and Pigneur, sets out nine building blocks, including value propositions, key activities, key resources, partners, and revenue and cost structures, that describe how an organisation creates, delivers and captures value (Osterwalder and Pigneur, 2010). For a service designer, this matters because a service can be highly desirable to users and technically feasible to build and still fail if it is not viable: if no one has worked out who pays, what it costs to run, or which activities and partnerships the organisation needs to sustain it. Business model thinking forces that viability question into the same conversation as user needs, rather than leaving it for someone else to resolve after the design is finished.
Even a well-designed system with a workable business model will drift if no one is accountable for it end to end. UK government services, for example, are built around a single service owner: someone accountable for a service’s quality, performance and outcomes, with the authority to make decisions across policy, delivery and operations rather than leaving each part to a different team (Government Digital and Data Profession Capability Framework, 2025). The Service Standard makes a similar point about teams: people involved in decision-making need to sit inside the multidisciplinary team delivering the service, so they are directly accountable to it rather than approving from a distance (GOV.UK, 2026). Without this, responsibility for a service tends to fragment across departments (policy, IT, operations, finance) and problems that cross those boundaries end up belonging to no one.
Service systems, business models and accountability are not three separate checklists; they are the same design problem viewed from different angles. The Design Council’s Systemic Design Framework makes this explicit, asking designers to look beyond the immediate service to the wider structures, relationships and institutions that shape it, and to work across disciplines and sectors rather than within a single team’s boundaries (Design Council, 2023). In practice, that means a service map is incomplete without a view of what funds each part of it, and a business model is incomplete without a named owner accountable for the trade-offs it requires. For a leader sponsoring service design work, the practical implication is simple: ask not just ‘does this work for users?’ but ‘who is accountable for keeping this system and its funding model working, once we have left the room?’
Action Point
Think about a service your organisation runs. Could you name, without checking, who is accountable for its quality and outcomes end-to-end, and whether the business model funding it is designed to sustain the level of service being promised to users? If not, that gap is worth raising before the next redesign or improvement project begins.