The Good, the Bad and the Hard to Solve

At the last LocalGovCamp of 2023, we ran a workshop to delve into the intricacies of resident accounts. This wasn't your typical supplier workshop; it was a continuation of the 'Placecube vibe,' where the focus extends beyond showcasing products to actively seeking solutions for common challenges faced by both creators and consumers.

The chosen topic: resident accounts. The workshop, aptly named "The Good, The Bad, and the Hard to Solve," aimed to unravel the controversy  surrounding the functionality of resident accounts in local government settings. The discussions ventured beyond the mere examination of what works well, delving into the complexities and challenges that often accompany these systems.

We looked at the landscape of resident accounts, exploring their successes, pitfalls, and the seemingly insurmountable problems that demand innovative solutions. In this blog, we'll share the insights, debates, and breakthroughs that emerged from this dynamic workshop, offering a glimpse into the collaborative efforts to enhance the efficiency and effectiveness of resident accounts in the ever-evolving realm of local governance.

Here’s Gavin Beckett introducing the workshop:

“Eight years ago Carrie Bishop, co-founder of FutureGov, wrote a blog post that many of us in Local Gov Digital roles read and violently agreed with. In that post she said that over the previous 8 years of work that FutureGov had done with councils they hadn’t come across any evidence that there was a genuine user need for a single citizen or resident account.

Carrie talked about several user needs that they had observed, and some business needs that councils legitimately wanted to meet. But none of them needed a single account - instead they were mostly about building good services, using digital technologies to make the user experience easier online and integrating data behind the scenes through open APIs and standards.

She highlighted one group of services where it makes sense to link up people’s data in an account like front-end - housing, benefits and social care - because people often do have clusters of needs that are met by this combination of services, and a long-running relationship with the council and a financial account style experience makes sense.

Fast forward to July this year, and Dave Briggs posted a blog asking whether things have changed in the last 8 years - and rapidly answered it with a no!

Dave agreed with Carrie’s argument that there isn’t a user need, and  introduced a new dimension; that in practice “single resident accounts” don’t exist, and are near impossible to create, certainly at a reasonable cost that is justified by real benefits. Every council that claims to have a Resident account also has up to a dozen other accounts, and has to publish a web page explaining which account to login to for which services…

And then Phil Rumens responded to Dave with a post that suggested that even if there’s no user need for one account, there surely is a user need to have fewer passwords to remember! His post focused on the potential to use open standards authentication protocols and services like OpenID Connect to unify the experience of logging in to the multiple accounts that Dave had pointed out are a fact of life in councils today.

So that’s all great - three leading people in the localgov digital and technology community argue compellingly against the need for a single resident account. But I can tell you, as a supplier, that every single council tender that comes out for a digital, CRM, or customer experience platform makes a single account a mandatory feature! So there’s something not quite joined up here… 

And not only do councils want single accounts, but they also want to connect the data from every back office system together with the account. And one particularly challenging requirement that’s included in most tenders is the ability to support and record relationships between people, and enable them to act on behalf of others - what we might call proxy relationships.”

What we wanted to do with the workshop was:

• arrive at a shared understanding of user needs for accounts, and where they aren’t appropriate
• get insights into the business requirements councils have for accounts, and how they might be satisfied in other ways
• discover ideas on how councils might record relationships and “proxy” rights whilst managing privacy risks 

How we ran the workshop

The workshop ran in two parts:

• Some quick-fire voting questions using Mentimeter to see where the mood of the room was on user accounts in light of the ideas in the blog posts on the subject
• More in-depth discussion using  real examples of user stories for participants to review individually and reflect on how their councils would deal with these scenarios, what issues or concerns would arise, and whether they would need any kind of authorisation and authentication in place. We asked participants to feed back their thoughts as they went 

Voting on ideas for resident accounts

We used a Likert scale to get participant views on three key questions so that we could see the distribution of answers.

For the statement “There is no user need for a single resident account”, we saw an even split across the 27 responses we received. It seems the jury is still out on this one.

The second question looked to probe how far participants agreed with Carrie Bishop’s idea of focusing a resident account around three key areas. This time there was more general agreement with this approach amongst the responses.

Finally, we tested Phil Rumen’s suggestion that the focus should be on creating a single login, simplifying people’s experience of signing in to multiple accounts, which got the strongest level of agreement of the three questions.

So it felt like participants were in line with Phil’s sentiments in his blog post:

“Once you have a single login across your many platforms it then becomes easier to join up data between them enabling you to do a lot more, that’s a topic for another day, and even then should you develop a single customer portal?

The answer, like Dave said, is still no.”

Proxy relationships and accounts

We gave participants a range of 7 user stories that we had taken from real examples to help bring out conversations around the complexities and potential solutions of proxy relationships. These varied in complexity from simple reporting tasks to acting as an advocate for someone.

We used Mentimeter again and encouraged participants to contribute their thoughts to this as they discussed.

Simple transactions

For the more straightforward transactions, participants didn’t see the value of capturing the details in an account, or dealing with proxy actions. 

This reflected our thinking on the real-life behaviours of residents when dealing with issues like this; people tend to just act on behalf of others without the need for a formal arrangement, preferring to impersonate them just to get a task completed easily.

Portals

The general issue of accounts (or “portals”) continued from the initial part of the workshop when viewed against specific user needs/transactions. 

Consent

The issue of consent also loomed large in the feedback. This has been a key consideration for us when we’ve considered the practical issues around proxy relationships in a resident account. How is it given and for how long? How is it withdrawn? What degree of consent is granted and how can this be controlled?

We had an excellent contribution from a participant that worked with the Chinese community talking about the effort and cost involved in getting a Power of Attorney to allow her to assist non-English speaking residents. This did give us an example of a controlled consent arrangement with clear terms, but not one that has a wider application.

As much as we’d have liked a practical answer to the dilemma to have emerged from our discussions and feedback, it feels like this topic will be the subject of debate for some time.

Access to accounts

An interesting thread was on making access to accounts easier using established patterns or new technologies that don’t require email/password combinations. This is an approach we’ve been using for our work on the DLUHC Low Code Waste project for signing up for reminders. 

While this could assist in managing control to non-account based transactions, the verification steps (as used in the GOV.UK services that use the pattern) could be considered more onerous than using an account. 

Our conclusions

• the debate on the user need for resident accounts is likely to continue, but there appears to be more consensus on improving access to a range of services requiring identification with a single login. We will be following research emerging from the GOV.UK One Login project to discover what lessons we can learn 
• participants joined us in thinking the issue of consent around proxy relationships is a complex one that doesn’t lend itself to an easy solution that can provide adequate safeguards. In addition,  the practical issues of creating consent mechanisms can far outweigh the benefits.

This workshop at Local Gov Camp highlighted the balance between innovation and safeguarding, emphasising that in addressing the challenges of resident accounts, the path forward continues to require thoughtful consideration and a commitment to overcoming practical obstacles for the greater benefit of the users. It’s been a helpful check-in against the experiences and thoughts of others that we’ll take with us as we continue to work on this.

To find out more further information about our findings,  contact our team or visit HERE.