An Introduction to Relational Service Design
Introduction to the Relational Service Design book
Why you should keep consultants and service designers away from your mum - an introduction by Dennis Vergne
My mum is 82 years old and full of wisdom. She's been my go-to for parenting advice ever since my two teenagers decided that communicating in grunts and eye-rolls was perfectly acceptable.
One evening, while I was face-timing her for some advice, she stopped me in my tracks. "Before I can help, fill in this form."
Contrary to the impression she's given me over my entire working life, it turns out she's fascinated by the world of consulting.
Knowing how important her "advice service" is to me, she contacted a local consultancy and asked them to help her optimise her process.
Amused and a little touched, I decided to play along.
The form asked me to provide my name, which I suspected she didn't need, and to describe my "issue." I didn't know how to articulate "help, my teenagers have turned into strangers who raid my fridge at midnight," but I gave it my best shot.
Three days later, I missed a call from an unknown number, and later that afternoon, I received a text from MAGS ("Mum's Advice-Giving Service") telling me she'd tried to call. If I still needed to speak with her, I could phone on weekdays between 10 am and 12 noon to make an appointment.
The following day, I called again, and after waiting on hold for 20 minutes, an unfamiliar voice greeted me.
"Hi, thanks for calling MAGS; you're through to Martha. How can I help?"
Martha explained she played bridge with my mum every Wednesday afternoon. The consultancy thought it would be useful to establish a triage service to better deal with my increasing demand. Mum had "recruited" Martha and the rest of the bridge gang to help.
She booked an appointment and assured me I'd get a call between 1 and 3 pm the next day. I cleared my calendar and waited for Mum to call.
The phone rang at 2:30 pm. This time, it was Anne. I asked for my mum, who, as it turned out, was in the same room but couldn't answer the phone.
"Hi Honey," she called cheerily from the background.
Bridge happens at 3 pm sharp on Wednesdays. She was early, but not on duty.
Anne explained it was her turn on the rota today and got to work. She's known me for 15 years but asked me to verify my name nonetheless. We replayed the discussion I'd had with Martha, and she explained that she had 20 minutes to complete the assessment.
She seemed a little irritated when I asked questions, especially when I asked her why I couldn't just speak with my mum.
The discussion didn't feel very helpful, but 20 minutes later, she brought our conversation to an efficient end with the sound of clinking tea cups and shuffling playing cards in the background.
"The panel meets after our bridge game," she concluded. "We'll confirm in writing what support you're entitled to following the meeting."
By the end of the day, I received an email with an attachment explaining the "sessions" I was entitled to. The team had decided that Thea, the fourth musketeer and retired teacher, would best fit my specific needs.
After another week of waiting, we met online for our appointment. We spent an hour discussing my family tree, my past challenges, and my most pressing concerns. She listened patiently.
"This parenting survival guide should help," she explained. "The exercises on page 24 should be particularly useful."
The exercises on page 24 were useful. But not at all what I wanted. When I explained that I thought I needed something more tailored to my needs, she interrupted me.
"I'm afraid your needs don't meet the threshold for more intensive support," she explained. "If things get worse, call us again, and we'll make another referral."
Why I spent so much time making this up
This didn't happen. Thank goodness.
But it might sound familiar.
My interactions with my mother are relational. There is no fragmentation. I don't get passed from one person to another. My needs are complex; there are no clear, simple answers or predefined steps. She listens and helps me by making suggestions. She coaches me through the process of trying them out. I feel able to act on her advice because we have a deep understanding and trust built over a lifetime.
You can't design this customer journey. You can't optimise it. You can't break it into steps and allocate each step to whoever's on the rota.
And yet this is exactly what we do, every day, to public services where, just like with my mum, the relationship is everything.
Two kinds of services
In our work, we distinguish between transactional and relational service design.
But first, a clarification.
As Toby Lowe rightly points out, a transaction is itself a type of relationship. Every interaction between citizen and state involves some form of relationship. The question isn't whether services are relational, but what kind of relationship is appropriate for the context.
What we're really talking about is relational density. How much relationship does this service need to work?
Some services need only a thin relationship. The problem is known. The solution is standard. The goal is to help the person do what they came to do as efficiently as possible. Renewing a passport. Paying a bill. Booking a vaccine. We call these transactional services, not because they lack relationship, but because a brief, efficient interaction is exactly what's needed. For these, designing the ideal customer journey makes perfect sense.
Other services need a thick relationship. The problem is tangled. The solution emerges through conversation and experimentation. Trust must be built before help can even begin. Think of a family on the edge of crisis. A person cycling through homelessness. An elderly person isolated and struggling to cope. We call these relational services because they depend on sustained, adaptive human connection. For these, trying to optimise the journey often makes things worse.
The failure mode we see most often is where a low-density relationship is applied to high-complexity problems. Treating a family in crisis like a passport renewal. That's what the Service Factory does, and it's what this book pushes against.
This doesn't mean all public services should become "relational" in the thick sense. It means getting the match right. And it means recognising that the current system is badly skewed toward thin relationships, even where thick ones are essential.
Working to improve relational services requires a different approach.
Rather than designing the perfect process, we should help teams become more self-organising. We should create conditions that enable them to build relationships and give them the autonomy to do what they think is most helpful.
Just as my mum can't predict exactly what advice will be most effective in all circumstances, a relational service can't know exactly what support will work when a resident asks for help.
Together, the resident and helper learn what works in practice. The act of helping builds trust, and over time, with more trust, it's easier to know how to help.
This book is our attempt to move beyond the factory logic. We want to build a clear case for why human connection is so vital, and share the practice that makes Relational Service Design possible in public services.
P.S. Please don’t share this with my mum.
Turning clouds into clocks - an introduction by Joe Badman
Image inspired by Karl Popper's 1966 essay "Of Clouds and Clocks"
Image inspired by Karl Popper's 1966 essay "Of Clouds and Clocks"
Karl Popper's essay "Of Clouds and Clocks" (1966) offers a helpful lens for thinking about Transactional and Relational services.
Popper contrasts "clouds"; messy, unpredictable systems, with "clocks"; orderly, mechanical ones.
While transactional services (like paying council tax or reporting a missed bin) can often function like clocks, relational services (like social care and homelessness) are more like clouds: complex, fluid, and shaped by human relationships.
The mistake we make is trying to turn clouds into clocks. You can't mechanise a relationship. You can't standardise trust.
But you can design systems where clocks and clouds work together. Where the efficient, predictable parts of public service support, rather than undermine, the relational work that helps people with complex lives.
Popper's metaphor reminds us that not everything can (or should) be engineered into predictability. The skill is knowing which is which, and designing the connections between them with care.
Who this book is for
This book is for three groups of people:
Transformation teams: service designers, user researchers, digital specialists, agile coaches, who have sophisticated tools for managing complex projects but who are frustrated that the services they design often ignore the complexity of citizens' lives.
Relational practitioners: social workers, family support workers, housing prevention officers and community workers. All those who know deep in their bones that relationships are everything, but who often feel like the system reduces their contribution to just processing people.
Managers and leaders: team leads, service managers, directors, and commissioners, who set the conditions that either enable or prevent relational work. You control the caseloads, the targets, the performance frameworks, the permission to deviate. Without your contribution, relational services are unsustainable and burn out the people who try to provide them.
All three are fighting the same enemy: a system that treats every human interaction like a passport renewal. All three have something to learn from each other. The path forward requires them to work together.
Above all else, if you've ever felt the unease of forcing a complex human situation through a standardised process, or watched someone else do it, this book is for you.
© Basis Ltd, 2026 Dennis Vergne & Joe Badman
References:
Popper, Karl Raimund (1966). Of clouds and clocks. St. Louis,: Washington University.