The Royal Borough of Kingston upon Thames undertook a discovery project to better understand the adult social care invoicing and debt recovery process. The aim was to explore both how residents experience billing and recovery processes and how internal systems, ownership structures, and operational practices shape those experiences.

This work focused on the design and launch of the Digital Health and Care Technology (DHACT) service in the Royal Borough of Greenwich, delivered in partnership with the NHS.

The service provides residents with connected devices that enable 24/7 monitoring and emergency response, supporting people to live independently and safely at home while staying connected with family and carers.

The aim was to create an integrated service that improves resident outcomes while reducing pressure on health and social care systems through prevention and early intervention.

To achieve this, we used an operating model design approach to define how the service would work across organisations, roles, and systems. The work built on earlier research and involved close collaboration with frontline staff, residents, senior leaders, and delivery partners.

When I joined the project, I started by building a deep understanding of what already existed. I reviewed the research conducted with Rethink Partners, spent time with the existing Telecare and JET teams, and spoke directly with frontline staff. This helped me understand both the strengths of the current service and the areas where change was needed.

A visit to Warrington Council provided a valuable external perspective. Seeing how another local authority had implemented a similar service helped us understand what was possible in practice and what challenges to anticipate.

From this work, we defined a set of design principles—keep it human, make it simple, and build together—which guided the development of the service.

I then developed an initial version of the future (TO-BE) operating model, mapping how referrals, roles, processes, and data flows would work. To support different needs, we created both a detailed version for the design team and a simplified version for wider stakeholders.

We used the operating model as the basis for co-design workshops with colleagues from social care, health, digital teams, and the monitoring centre. These sessions were hands-on, with participants actively shaping the model based on their experience. This ensured the service was grounded in real operational conditions.

Senior leaders were engaged throughout, which helped ensure alignment with strategic priorities and enabled the model to be approved at service manager level.

Once agreed, the focus shifted to implementation. I worked closely with teams to translate the operating model into practical tools, including referral pathways, forms, and data processes. We also began developing the digital referral form early so that it could be tested and refined.

At the same time, we worked with Rethink Partners to design training and support for staff, recognising that confidence and capability would be critical to successful adoption.

In the lead-up to launch, I ran drop-in sessions with teams to walk through the new processes, answer questions, and gather feedback. This allowed us to refine the service further and build confidence ahead of go-live.

By the time the service launched in March 2025, we had not only defined how it would operate but had also built shared understanding and ownership across the teams involved.

Using an operating model design approach was fundamental to delivering this service.

It enabled us to bring together a complex set of elements—people, processes, technology, and data—into a coherent and shared understanding of how the service would function. This was particularly important given the cross-organisational nature of the work, involving the council, the NHS, and multiple internal teams.

One of the key strengths of the approach was the ability to move between strategic and operational levels. It allowed us to align the service with wider priorities, such as supporting independent living and reducing pressure on health and care systems, while also working through the practical details needed for delivery.

The operating model also supported communication and decision-making. It provided a clear and structured way to explain the service to senior leaders, frontline staff, and partners, helping to move discussions from high-level ideas to concrete implementation.

Importantly, it enabled meaningful co-design. By making the service visible, it allowed teams to engage with it, challenge assumptions, and contribute to shaping how it would work in practice. This helped ensure that the final service was both realistic and deliverable.

Finally, it supported implementation by reducing ambiguity. Clearly defined roles, processes, and data flows meant that teams were better prepared for launch, and that the transition from design to delivery could happen more smoothly.

1. The operating model only works if people recognise themselves in it
   Early versions of the model were useful structurally, but only became meaningful once frontline teams could see their actual work reflected in it. Co-design wasn’t just about validation—it was about making the model credible enough that people trusted it.
2. You are constantly translating between worlds
   Health, social care, and digital teams approached the service with different priorities, language, and levels of risk tolerance. A large part of the work was not designing the service itself, but helping these perspectives meet—often by reframing the same problem in different ways for different audiences.
3. Detail is necessary for delivery, but can alienate stakeholders
   The level of detail required to define roles, data flows, and processes was essential for implementation, but not always accessible to everyone. Creating simplified views of the model was not just a communication task—it was necessary to keep people engaged and involved.
4. You will have to design before everything is known
   Procurement timelines meant that key elements of the service—particularly devices and systems—were not fully defined when parts of the operating model were being developed. This required making informed assumptions and being prepared to revisit and adapt decisions later.
5. Momentum and belief cannot be assumed
   At points in the project, some stakeholders were unsure whether the service would launch as planned. Progress had to be made visible, repeatedly, to build confidence and sustain engagement across teams.
6. Workshops create alignment, but don’t sustain it
   Co-design sessions were effective in shaping the model, but alignment did not hold on its own. It required continuous follow-up, one-to-one conversations, and revisiting decisions as the service evolved.
7. Prototyping is as much about confidence as it is about testing
   Early versions of referral processes and forms helped identify issues, but just as importantly, they allowed teams to see how the service would actually work, reducing uncertainty.
8. Leadership support needs to be active, not just present
   Senior leaders played a crucial role in removing barriers and enabling decisions. Their involvement was most effective when it was hands-on and responsive to the realities of the work.
9. The hardest part of implementation is not technical
   While the service involved new technology, the more significant challenge was supporting teams to adopt new ways of working and feel confident in a new, shared service.
10. Positioning the service as unfinished helps it succeed
    Framing the service as something that would continue to evolve after launch created space for learning and adjustment, and reduced pressure to resolve every detail upfront.