Ever thought about starting a service lab?
Last week, I experienced another service failure during my own interactions with the NHS.
The backstory… I’ve been waiting 4 months for an important ENT consultation, only to get a phone call 10 minutes before it was due to start to say no one had realised the consultant was on leave.
The result was that some poor person had to cancel a full afternoon of appointments, one phone call at a time.
To add to this, the consultation was to discuss scans I had to have redone in November, because the previous consultation follow-ups had been delayed for so long.
It reflects a system under pressure and is an example of the need to improve how demand/capacity and patient flow are managed more effectively.
Finding a place to start, finding things to fix
An NHS goal should be to be seamless at the point of transaction. That should mean making sure the fundamentals of appointment management, booking and patient communications meet needs and expectations.
I’ve always been an advocate of starting small and finding things to fix – like these small yet significant touch points.
The framing I like to use here is optionality. This is the need for a system to find ways to continuously improve alongside more substantial change programmes – the need to invest in small initiatives. It’s the principle that small cross-functional teams can deliver quick wins while limiting the cost of failure.
If there’s one thing I think that every NHS trust could do, it’s to invest in a small service lab. Not an innovation lab, or skunkworks. A service lab.
How is this different? A service lab isn’t tied to experiments with new technologies; it exists to find service improvements in whatever ways are possible. It focuses on outcomes, linked to real use cases. It creates a focal point in the organisation for services, and how service pain points and failure demand can be better understood.
In contrast, there’s sometimes a lack of accountability with tech labs – the focus is on the viability of the tech (finding a use case), rather than real, measurable improvements to patient experience. Therefore, a service lens is important. To start with, it means looking for the simplest, cheapest solutions. This could be existing tech, combined with manual interventions in the short to medium term. It’s about focusing on where real impact is possible – a service lab can then manage the feasibility of scaling solutions sustainably with further investment (that includes the ability to retire or replace more temporary solutions where appropriate in the longer term).
I used the example of service labs in Multiplied when talking about the need for organisations to make space for experimentation. An important emphasis here was the importance of service labs working with existing ideas and knowledge inside organisations:
“…innovation and change needs inside knowledge and expertise, but a great source of ideas can already be found inside the public sector if we’re open to working with those closest to front-line service delivery […] One such approach is to set up dedicated service or innovation labs. This is where digital, design and technology specialists work directly alongside staff to identify and configure technologies to be trialled and tested as part of real service situations. This model can be delivered effectively as either short ‘design sprints’ or as longer cycles of work – anything from 1-3 months to build, test and learn from new uses of technology.”
The book goes on to describe how this type of work requires support from a central team or dedicated digital resources. But most importantly, it must give the people closest to service delivery the room to experiment, working from their own experience and expertise.
There can be principles introduced for keeping service labs accountable. For example, working in the open, sharing research, prototypes, and learnings more widely. This also helps navigate the potential downsides of a lack of coordination between multiple teams, fixing things independently.
Where to start?
With a service lab, any organisation can start small, be ambitious and share progress. Work can start by building a backlog from service mapping and insights, including finding places to start by looking at data and cost points, such as missed appointments.
Multiplied also includes a list of ‘opportunity’ areas to consider as themes for any service lab initiatives:
- Changing how people find, contact, or are referred to services
- Supporting improved or simpler interactions and onboarding processes
- Keeping people updated with relevant information and notifications
- Creating new connections between people and information as part of a service
- Making real-time adjustments to a service using data
- Providing timely support when something goes wrong
- Highlighting the need for additional support and interventions
- Monitoring for errors in systems and processes
Some of these invite experiments with both existing and emerging technologies, but others potentially start more with reconfiguring processes, roles, and ways of working.
The language around ‘starting’
Finally, the language around ‘starting’ matters.
You can have a culture of small initiatives designed to quickly demonstrate value, but without public organisations acting like startups in the more traditional sense.
To be clear, real startups fail at scale, and public systems shouldn’t tolerate writing off £millions of investment. But the principle of test and learn with cross-functional teams, and involving a range of experts, means that we should be able to scale and spread innovations and real service improvements in this way.
This is my blog where I’ve been writing for 20 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky and LinkedIn.