3 Findings From Piloting a Community Wellbeing Platform

Every community holds more information about the wellbeing of its residents than any single organisation realises. Community support health services, local charities, councils, schools and grassroots groups each hold a piece of the picture but rarely the whole one.

Over the past few months, Hexaware has been piloting a community wellbeing project in Greater Manchester designed to support communities. The premise was straightforward: help individuals understand their own needs and find the organisation they feel is best placed to support them, rather than relying solely on government or statutory services.

The pilot wasn’t about building a finished product. It was about learning quickly, in the open, with real users and real data constraints. Three findings stood out, and together, they’re reshaping how we’re approaching the next phase.

Community data is deeply siloed and standardisation isn’t optional

Almost every organisation we worked with holds useful data: referral records, service usage, attendance, needs assessments and outcome tracking. Almost none of it speaks the same language.

One organisation logs “food insecurity” as a category; another buries the same signal inside free-text case notes; a third doesn’t capture it at all because it isn’t visible to their clients. Multiply that across different community support services and you quickly end up with partial views of the same community and the needs within it.

This isn’t primarily a technology problem. Systems can be integrated relatively quickly once there’s agreement on what a “referral”, a “household” or a “vulnerable resident” actually means across organisations.

Without that shared vocabulary, integration produces noise rather than insight. We end up reconciling incompatible categories instead of surfacing patterns.

The practical implication for our next phase is clear: before we invest further in technical plumbing, we need a lightweight, shared data standard that the smallest voluntary group can adopt just as easily as the largest statutory service.

It needs to be simple enough to require no dedicated IT resource and flexible enough to map onto existing systems rather than forcing wholesale replacement.

Standardisation, done well, isn’t bureaucracy for its own sake. It’s the precondition for the sharing, matching, and reporting benefits that motivated the project in the first place.

People want it in their pocket, not behind a login on a desktop portal

We initially assumed a web portal would be the natural front door: a single place where residents, caseworkers and commissioners could log in and see relevant information.

In practice, user research and engagement told a different story. Users preferred something they could access on a mobile device.

This shouldn’t have been a surprise, in hindsight. Many of the people who most need community support services — those juggling shift work, caring responsibilities or unstable housing — don’t sit down at a desktop computer to check their support options. They’re on their phones, often on the move, often with limited time and patience for a multi-step login journey.

Frontline workers, too, are frequently out in the community rather than at a desk. A tool that only works when they’re back at their laptop simply doesn’t get used consistently.

The lesson isn’t just “build an app instead of a website.” It’s more specific than that: design for short, interrupted sessions; minimise the steps between opening the tool and finding something useful; and treat notifications and simple prompts as a feature, not an afterthought.

A mobile-first approach also has a quieter benefit — it forces discipline.

When the entire interface has to work on a small screen, you’re pushed to prioritise the two or three things that actually matter, rather than replicating the sprawling menu structures that portals tend to accumulate over time.

But mobile-first doesn’t mean digital-only. The platform also needs to work for frontline workers supporting people who may not be able or willing to navigate digital services independently. The goal is to make community support easier to access, not to create another barrier to it.

Lack of transparency is quietly costing both people and funding

The third finding was the most sobering.

In several cases, people who were eligible for support simply didn’t know it existed, or couldn’t work out how to access it. Services that could have helped went underused — not because they were poorly designed, but because information about them wasn’t visible at the point someone needed it.

A resident dealing with a difficult situation rarely has the time or knowledge to search across multiple organisational websites to find the right service.

There’s a knock-on effect that’s easy to miss.

When community support services are underused, the case for funding them can weaken. Funders and commissioners look at utilisation data to justify continued or expanded investment. A good service with low visible uptake — purely because people didn’t know it was there — can end up struggling to secure the funding it needs to continue, even though the underlying need in the community hasn’t gone away.

Low visibility can therefore become low uptake, making it harder to demonstrate demand and sustain services.

Transparency, in other words, isn’t just a user-experience nicety. It’s directly connected to the sustainability of the services themselves.

Fixing this doesn’t necessarily require every organisation to overhaul how it communicates. It requires a shared, trustworthy layer that surfaces what’s available, where, and how to access it — presented in a way that’s honest about eligibility and capacity.

The challenge is keeping that information current. An idealised directory that is accurate when launched but quickly becomes outdated won’t solve the problem.

Keeping service information current is a governance challenge as much as a technical one, and it’s something we’re treating as a first-class requirement rather than a nice-to-have.

What this means for the next phase

None of these findings is particularly glamorous.

Shared data definitions, mobile-first design and transparent signposting aren’t the kind of things that make headlines. Taken together, though, they give us a clear roadmap.

Agree on simple, shared definitions before investing further in integration. Design for the phone, not the portal. And treat the visibility and currency of service information as core infrastructure, not a communications task bolted on at the end.

The community wellbeing technology itself is only part of the challenge. The next phase is about making the shared infrastructure as simple and unobtrusive as possible: mapping existing records onto common definitions without forcing organisations to replace what they already use, making it easier to keep service information current, and helping those involved understand community needs and service utilisation.

If the smallest organisation in the network can participate without needing significant additional technical resource, the design is working.

The pilot has done exactly what a pilot should do. It has told us, quickly and with real-world evidence, where our assumptions were wrong.

The next phase is about acting on that learning with clarity.

If you’re working on something similar in your own community, I’d love to hear about your experience and compare notes. Contact now.