Traditional organisations are increasingly recognising themselves as service providers and talking about service design. Defining the services an organisation offers is a good way to start being a better service provider.
It’s not just about putting the things an organisation does in a list. It’s about recognising what it takes for an organisation to see and manage itself better. To expose what wasn’t visible before. To organise its work and conceive of performance in a way that puts the focus outside itself. To deliver better and more valuable services to people, more efficiently.
Services aren’t usually viewed or organised in anything like the ways we’re talking about here. It’s surprisingly easy to get wrong and to miss opportunities. This is a definitive guide to helping organisations define, shape and scope services well.
- is defined from an external end user’s point of view
- describes something someone would want to do, in their language
- has an outcome that relates to the organisation’s goals
- includes all the steps between the user and provider
- includes all the parts involved in delivering it
You can immediately see problems with these criteria. What if ‘what someone wants to do’ is beyond what an organisation does? Or outside of the public, or private sector? What if what someone wants to do is in conflict with what the service provider wants its users to do? What about services for internal users?
To understand and protect the value that comes from defining services well, let’s take each point in turn.
1. A service is defined from an external end user’s point of view
Organisations have purpose. They exist to change or achieve something outside themselves. Yet their focus is often on internal functions or departments. Or portfolios, projects and IT systems. This misses the connection between the work of the organisation and what users are doing. Problems, opportunities and avoidable cost can be invisible. When an organisation focuses instead on providing great services to external users, better outcomes, cost-saving or revenue follows.
We still need to think about the work an organisation does internally. It’s just that we don’t think about it as a service in its own right. For example, when working on a (external) service, you need to think through how it’s delivered. This includes all the processes, tools and other things teams need to make their jobs possible, or easier. As well as all the systems and other parts, automated or not. There is much to improve, design and make decisions about. In the UK, when an internal part is re-designed in the style of GOV.UK it can cause confusion if it’s then assessed as if it itself were a service. It’s more helpful to see these as the supporting components of an external service with end users outside the organisation.
Organisations do other things that are like a service, but where end users or stakeholders aren’t exactly external. For example, when a team finds information or prepares reports for a minister’s office or for parliament. You might think of these as internal-to-government services, of sorts. Although they’re similar, we don’t want to confuse what are internally focused activities with the services for end users that we’re defining on here.
Every organisation recruits people. The end users of this are often external to the organisation. Things like ‘recruiting people’, ‘getting a job’, ‘become an employee/member of our team’ should absolutely be considered, designed and managed, end to end. But they’re more self-serving than the external services we’re defining.
These are not external services in the way that we’re talking about:
- the on-boarding of new staff
- the intranet
- a new HR management system
- the way performance reviews work
- recruitment of people
- an internal wifi service
2. A service describes something someone would want to do, in their language
Services should be recognisable to someone with that need, described using plain english and starting with a verb. The UK government’s digital service described what they mean when they talk about services, following Lou Downe’s good services are verbs.
Often what are called ‘services’ still reflect internal organisational structure and remit. This doesn’t define or design services at a level that is about what someone actually wants to get done. For example, ‘starting a company’. In the UK, you still have to complete tasks with 7 different organisations to do this. This isn’t tackling the whole goal or problem for users.
What a ‘whole problem’ is isn’t obvious, though. It doesn’t tell us what size of problem to aim for. On the one hand we want to define services around things that someone ultimately wants to do, like ‘buy a house’ or ‘have enough income to live on’. But to define services practically, we need to identify parts of them an organisation can actually do something about.
If you zoom in too far or stick with how your organisation currently sees things, your focus could be too narrow: things like ‘submit a form for a licence’, or an IT system that issues certificates, or any other individual part of an organisation.
You can zoom out too far too. Say, ‘get an education’ or ‘healthcare’. It’s vast. It’s unlikely you’ll be able to manage and deliver practical change at this level. Not unless you’re a Secretary of State with budget, an excellent team and political support.
Defining the whole problem well is not straightforward. Take ‘buying a house’ or ‘selling land’. There are many organisations involved, both public and private sector: banks, solicitors, agents, local authorities, buyers and sellers. Should government guide you through the whole process? Should it help you find good solicitors or even houses — things that aren’t a part of government? Is it enough to define a service for government as ‘buy a house’, and assume users will understand that parts of it aren’t government? Or do you define an individual service more precisely as ‘register a change in ownership’? Assuming that someone will tackle the 100+ year old policy on land ownership and redesign it all to work better, with new or fewer services in time. Should there be a master list of services for the public sector that ignores the remit of each institution? Yes. But that doesn’t help organisations and services right now.
The distinction is whether your organisation or team sees itself as the ‘main’ one that helps glue a wider service together. Including all the work of others. Or whether you define your organisation’s job as just doing its part within a wider context. It’s an important choice, whether consciously or unconsciously made. Either way, an organisation still needs to visualise what it does itself, as well as its role in wider services, so that it can evaluate performance, manage work and navigate priorities and budgets.
For government, it makes sense to design and operate services that increasingly solve whole problems for users. This is because government has a policy interest in achieving better outcomes, which results from making things simpler, faster or better. This could include directing people to where they can do other things they need to do, even where government doesn’t provide the whole service. In the UK, step by step guides and whole service communities are an example of work to support this. It’s now even a part of the Government Service Standard.
For the private sector, whether to provide a “whole problem” service or to focus on doing one part is a choice. It depends on the strategy, positioning and business model. Services are defined at a level that works for both user and provider, for the most mutual value. So it could be that ‘get a mortgage’ is a more practical level to operate a service at, than ‘buy a house’. ‘Insure your business’ more than ‘run a company’.
None of this means you don’t ever reconsider the whole thing from first principles. Whether that’s through good research about a high level human need, a life event, or specifically how to redesign a sprawling, cross-cutting theme from scratch. It’s vital to do this to get to better outcomes, whatever sector you’re in.
The purpose here is to define services to help an organisation see its work and impact from the outside-in. At a scale that makes sense for the larger services to be operated on an ongoing basis, actively improved over time by permanent, empowered teams. Not just one-off redesigns.
Services in the public sector are things like:
- find childcare
- drive a vehicle
- get training
- become an apprentice
- work in the UK
Where the service is explicitly a part or subset of a larger whole service, you can link it with what someone actually wants to do:
- buy a house — register a change in land ownership
- get a passport — get a passport for a child
A team can then focus on improving, or on removing these parts. While working with all the other organisations to redesign how the broader goal (e.g. buying a house) works for the better. They can also be lobbying for someone to own and prioritise work along the whole thing, across government.
Whole services are not things like ‘apply for a licence’, ‘book a driving test’, ‘submit a statutory return’ or ‘register a car SORN’.
Services in the private sector are things like:
- get a mortgage
- insure a business
- rent a car
3. A service has an outcome that relates to the organisation’s goals
Services don’t exist purely because someone wants them. There are reasons organisations operate particular services. For the public sector, it’s about why government is interested. Such as:
- a wider policy intent or organisational goal. Like making sure that roads are safe
- a specific outcome this particular service is aiming to achieve. Like access to good driving education and appropriate testing before granting a licence to drive
In the private sector it’s about how the service relates to an organisation’s strategic and regulatory goals, as well as the value it provides to people and the resulting revenue.
Describing the wider intent helps you know whether a service is supporting it. As well as how it’s performing in terms of its specific job for users and the organisation. This is a stronger place from which to (re)consider the best way to design and deliver it. Teams that don’t spend time understanding these are going to find it hard to talk about service performance.
Services can run across several policy, operational areas, or organisations. They can each have different desired outcomes. If you only think about the services your organisation or area provides currently and in full, you miss the real picture, and interesting opportunities.
A government policy intent could be to ‘prevent people from falling into poverty’. A related service might be ‘get support because of low income’. A successful outcome for this service might be ‘a successful and eligible payment of the right benefits’. For this all to work, the impact of this service outcome should support the policy intent. Which means people should be able to continue living safely and well, without spiralling into poverty and debt when something happens.
Another policy intent could be to minimise harm to animals while supporting legitimate use of animal research. The organisation might also have other goals, like increasing public trust and confidence in regulation and reducing overhead to the taxpayer as well as industry. A related service could facilitate licencing for appropriate research.
4. A service includes all the steps between the user and provider
A service includes all the interactions between a service user and a provider. Whether that’s online, paper, phone, text, face to face or any other way.
Most services in the organisations we’re talking about already exist. The work is to make them radically better. We often don’t mean building new ones. Many haven’t recently been improved, don’t work well yet online or haven’t been looked after. This doesn’t mean they’re not a service. More often, they’re the result of other decisions or delivery in pieces.
While it doesn’t have to work online to be a service, there is likely major room for improvement if it doesn’t. You can identify which services are most in need of investment to improve. It’s just as important to know about valuable and well-running face to face services, as well as costly, paper-based services that can be designed more efficiently.
Services also encompass all the steps it takes, whether that’s between people or computers. For a user, these are things like ‘find out how to do something’, ‘choose the best option’, ‘apply’, ‘get something’. For a provider, it’s things like ‘check eligibility and suitability’ or ‘make a decision’.
Different types of service have common steps. Knowing these helps an organisation identify and categorise common needs and problems. It doesn’t mean you can develop a single way of, say, ‘checking eligibility’ for all services — how that’s done is often completely different in important ways. But knowing the steps can help to place genuinely common components in context. Such as customer data repositories, ways of notifying users about something, taking payment, customer support or physical real estate.
‘Adopt a child’ or ‘foster a child’ are still services even if they’re mostly face to face, and most of the transactional parts are done on paper. The online application, contact centres and interview rooms for ‘work in the UK’ are all part of a single service. They can also be shared capabilities across many services.
Work in the UK government around licencing lead to the identification of a ‘do something with permission’ type of service. This permissions type of service is similar to many services in the private sector, where certain checks are made to see if someone is eligible for something. Like ‘open a bank account’, ‘get a credit card’ or ‘get a loan’. There’s much to learn from teams working on services of the same type.
5. A service includes all the parts involved in delivering it
Services include all their constituent parts. The internal capability, activities, tools, systems and relationships are a part of its delivery. The way in which an organisation holds data. Or the contractual arrangements and service levels agreed with an outsourced provider. It isn’t only the bits the user sees and interacts with.
This also means a service is not a component part in and of itself. It’s not a website, a database, identification or authentication. Nor what internal team A does for internal team B. Not if you want to re-think how things work more fundamentally.
Much of these internal things are needed for a service. But they’re often shared across services. So the way your organisation does access and authentication, or its customer data repository, is a part of a set of services. In addition to being a component in its own right.
For those that think of what organisations do as capabilities, a service isn’t one. Though it might draw on existing capabilities to operate. It might create the need for new capabilities for it to work better. The work involved in a service could create capabilities that other services could draw on.
The whole ‘get a passport’ service includes contact centres, passport offices, casework systems and reminder text messages. It’s how well the physical passport works in other countries. It’s the work of fraud teams. It’s the arrangements with logistics and fulfilment suppliers, including high street photo booths. As well as how you can apply for a new passport on screen.
IT systems aren’t services in the way we’re talking about. Rather, things like data repositories, content management systems, payment processing tools or certificate-issuing systems are usually a part of a wider service, or services.
Defining services well
If organisations don’t have well defined services, their internal efforts and priorities won’t be aligned with what it takes to operate them successfully. Without a clear understanding of real world service performance, it’s too easy to become a bad service provider — and not be able to see it. Organisations that define them well, aligning their internal work to services and their outcomes, are the ones that will become, and remain, the better service providers.
This draws on Kate Tarling and Matti Keltanen’s individual work with different organisations in the public and private sector. It’s also building on the work and writing of many people involved in government in the UK, including Lou Downe and their posts like ‘what we mean by service design’, ‘good services are verbs, bad services are nouns’, Stephanie Marsh and ‘what we talk about when we talk about services’, Kate Ivey-Williams and ‘building end to end services in to GOV.UK’. It relates to recent changes to the UK government service standard and particularly point 2 ‘solve a whole problem for users’. The intention is to gather collective thinking, develop it through individual work with different organisations, put it in a single place, and make it relatable to both the public and private sector.